João Vitor Bogo

Boa tarde Gostaria de reforçar que a inclusão de um parâmetro específico não é um “trabalho à toa”, mas sim um investimento em clareza, robustez e manutenção futura. É bom notar alguns pontos para reflexão sobre isso: Clareza na configuração Ter campos separados para Inscrição Municipal e Código Mobiliário evita ambiguidades e “gambiarras” futuras. Facilita a leitura do código, o entendimento de novos desenvolvedores e a detecção de erros. Manutenção e escalabilidade Hoje apenas um provedor exige o Código Imobiliário mas amanhã outro pode precisar dele também. Planejar para o crescimento do componente reduz retrabalho e dores de cabeça posteriores onde a emissão de determinadas prefeituras podem 'parar' por falta disso. A adição de um parâmetro dedicado segue o conceito de clean code, onde cada elemento tem responsabilidade única e clara. Esforço de implementação reduzido No ACBrMonitor, basta adicionar um novo campo de configuração (não é algo complexo) Na Lib, é possível usar exatamente a lógica sugerida, sem alterar o fluxo atual de quem já está em produção: Basta utilizar um IF no preenchimento da Tag com o campo novo, quem já está rodando não vai ter nada preenchido nele, e nesse caso, continua utilizando o que já estava antes. Adicionar um parâmetro novo traz benefícios claros sem quebrar compatibilidade com quem já está em produção. Dessa forma, garantimos um componente mais organizado, preparado para o futuro e com impacto mínimo para os atuais usuários. Um último ponto à respeito disso, é que até o momento ninguém que está utilizando pareceu se importar nem com a impressão da NFS desse Provedor, pois como eu cito no meu outro post relacionado à leitura do XML, o 'mesmo campo' está sendo lido como Inscrição Municipal, quando na verdade não é assim. Então eu acredito que essa modificação não terá impacto algum para quem já está utilizando.

Boa tarde pessoal. Eu fiz um tópico faz alguns minutos, relacionado a Inscrição Municipal / Código Imobiliario no Assessor Público. Sobre a parte da leitura do XML retornado da prefeitura Nesse tópico eu abordei (corretamente acredito eu) sobre a leitura dos campos que estavam erradas. Porém agora o problema que eu acredito que existe é no envio da requisição para o Assessor. Como podem ver nessa print, é preenchido a tag 'INSCRICAO' com o campo "InscMun", até então, não deveria haver problemas, porém o próprio Assessor Público, não espera a Inscrição Municipal nessa tag, e sim o Código Imobiliario. Tanto que fazendo os testes e preenchendo essa tag com a Inscrição Municipal de fato, eu tenho o seguinte retorno da prefeitura: Isso pois eles tratam de uma maneira equivocada como as tags são preenchidas. A minha sugestão (caso o ACBR concorde que o preenchimento não deve ser feito assim) é a seguinte: Criar na unit ACBrNFSeXConfiguracoes o campo "Codigo Imobiliario" e alterar na unit AssessorPublico.Provider a montagem do campo Emitente.InscMun para Emitente.CodigoImobiliario. Caso queiram, aqui está as units com as modificações: AssessorPublico.Provider.pas ACBrNFSeXConfiguracoes.pas

Boa tarde. Ao analisar os XMLs de retorno da NFSeX com o provedor do Assessor Público (unit AssessorPublico.LerXml), percebi que o componente está lendo a Inscrição Municipal do prestador usando a seguinte tag: No entanto, essa tag (PRESTCODMOBILIARIO) não representa a Inscrição Municipal. Ela representa o Código Imobiliário. A tag correta que traz a Inscrição Municipal real, é a seguinte: Como podem ver no XML: Comparei os valores retornados pelas duas tags e eles são diferentes. Por isso, acredito que o componente esteja lendo o campo errado. Sugestão: Sugiro alterar a leitura para usar PRESTINSCRICAOMUN, que de fato representa a inscrição municipal. Se alguma prefeitura do Assessor Público exigir a leitura do PRESTCODMOBILIARIO, talvez seja o caso de tratar isso de forma condicional. Unit com as alterações: AssessorPublico.LerXml.pas

Olá, equipe ACBr! Gostaria de sugerir uma melhoria na procedure TfrlXDANFSeRLRetrato.rbCodServicoBeforePrint, responsável por preencher o campo "Código Serviço" no DANFSe. Contexto: Atualmente, o preenchimento do campo "Código Serviço" é feito com base na lista Servico.ItemServico. No entanto, há casos em que a prefeitura retorna um ou mais itens dentro de ItemServico, mas sem preencher os campos ItemListaServico e xItemListaServico. Nestes casos, o relatório não exibe nenhuma informação, pois o código atual apenas considera a exibição dos campos “pais” (Servico.ItemListaServico e Servico.xItemListaServico) quando ItemServico.Count = 0. Problema: Servico.ItemServico.Count > 0, mas os itens estão sem dados nos campos necessários. A lógica atual impede que os campos alternativos sejam utilizados, resultando na ausência do "Código Serviço" no relatório. Proposta de solução: Ajustar a lógica para que o bloco alternativo (que utiliza Servico.ItemListaServico e Servico.xItemListaServico) também seja executado quando não há nenhum ItemServico com dados válidos. Com essa modificação, evitamos situações em que o relatório fica com o campo em branco, mesmo havendo informações disponíveis nos campos principais. Unit com a alteração: ACBrNFSeXDANFSeRLRetrato.pas Fico à disposição para enviar a modificação completa, caso necessário.

Bom dia, segue anexo sugestão da alteração nessa unit ACBrBoletoW_Sicredi_APIV2.pas

Olá, desculpa reviver esse meu tópico antigo, queria saber se posso ajudar em algo pra essa TK sair

Bom dia, Apenas para esclarecer, em nenhum momento afirmei que o código não está funcionando. O ponto que levantei é que nem todas as opções disponíveis estão sendo devidamente tratadas. Com a lógica atual, as propriedades ATitulo.DiasDeProtesto / ATitulo.TipoDiasProtesto e ATitulo.TipoDiasNegativacao acabam sendo subutilizadas. Isso força o ERP a calcular manualmente os dias da instrução (com base em DataProtesto - Vencimento), quando o ideal seria simplesmente passar os parâmetros completos e permitir que o próprio componente se encarregue desse cálculo, conforme foi projetado. Isso poderia evitar inconsistências e tornar o processo mais flexível e aderente à estrutura já existente.

Atualmente já está com a URL de Produção, mas também existe a de homologação conforme exemplo abaixo: [3537305] Nome=Penapolis UF=SP Provedor=AssessorPublico ProRecepcionar=http://s33.asp.srv.br/issonline/servlet/anfse HomRecepcionar=https://s1.asp.srv.br/issonline-homolog/servlet/anfse

Bom dia, estou fazendo a implementação da Negativação/Protesto e me deparei com o seguinte bloco Não entendi por quê está sendo utilizado ATitulo.DataProtesto - ATitulo.Vencimento sendo que já existem as propriedades ATitulo.DiasDeProtesto e ATitulo.TipoDiasProtesto, que atualmente não estão sendo utilizadas. Aproveitando, uma linha abaixo tem o seguinte bloco que já está analisando o campo ATitulo.DiasDeNegativacao mas não leva em consideração o campo ATitulo.TipoDiasNegativacao. Minha dúvida é se isso foi feito intencionalmente dessa maneira, ou se só acabou passando batido

Bom dia, eu estou fazendo alguns testes e vi que até então existe apenas uma constante ERR_NAO_IMP que diz "Serviço não implementado para este provedor.", a minha sugestão é alterar para "Serviço %s não implementado para este provedor.", então em cada lugar que chama essa constante, é passado um 'Format' pra indicar qual é o serviço que não está implementado, acredito que isso vai fazer com que fique muito mais fácil para entender exatametne o quê não está implementado. Segue anexo arquivo com a alteraçãoACBrNFSeXWebserviceBase.pas

Acho que nesse caso dar um UP não seria um spam visto que já tem umas semanas desse post

Obrigado, dessa vez eu acabei fazendo direto pelo meu programa sem testar pelo exemplo da NFSeX, eu estava executando uma procedure que limpava essas informações.

Boa tarde, estou fazendo a leitura do XML da cidade de Campinas, porém logo abaixo da "Discriminação dos Serviços" e acima dos "Tributos Federais", o Código do Serviço está ficando em branco, mesmo ele estando presente no XML e sem marcar a opção "TabServicosExt" no componente. Impressão atualmente: Eu vi que dentro da unit ACBrNFSeXLerXml_ABRASFv2 , a procedure TNFSeR_ABRASFv2.LerServico(const ANode: TACBrXmlNode) Não estava adicionando um novo ItemServico, então na hora de imprimir, essa informação simplesmente estava ficando igual na imagem acima. Eu fiz a seguinte alteração nessa procedure: Depois isso, a impressão começou a funcionar corretamente Segue anexo um XML emitido em HOMOLOGAÇÃO + Unit com a alteração. ACBrNFSeXLerXml_ABRASFv2.pasxml homologacao.xml

Que estranho, não faço ideia por quê o anexo está ficando assim visto que é um arquivo diferente que eu estou enviando, vou anexar novamente, porém a única diferença pro exemplo que você tem, é que em vez de DataBaixa eu estou preenchendo a DataCredito ACBrBoletoRet_Sicredi_APIV2.pas

Boa tarde. Estou com um problema na consulta do evento(Carta de correção) de uma NF-e. Basicamente o quê acontece é, ao fazer o envio desse evento para SEFAZ, o XML de retorno é salvo corretamente com a seguinte estrutura: Porém caso eu perca o XML, para gerar novamente eu preciso consultar essa Nota na SEFAZ, porém a estrutura do XML vem assim: Então, se eu carregar esse segundo XML e chamar a function LerXml, a impressão está ficando em branco. Eu vi melhor o problema e aparentemente na unit ACBrNFe.RetEnvEvento não estava sendo tratado o XML que a tag principal é 'NFeDFe'. Eu fiz a alteração acima na Unit e funcionou, porém não sei se isso é o correto, ou se eu estou fazendo algum processo errado (E por isso o segundo XML é gerado com uma estrutura diferente) Segue anex o os XMLs que foram gerados(Emitidos em homologação com dados fictícios), bem como a Unit com alteração. 1101103525040425024000010355001002028569140032581904-procEventoNFe(Gerado na Inclusão).xml1101103525040425024000010355001002028569140032581904-procEventoNFe(Gerado via Consulta).xmlACBrNFe.RetEnvEvento.pas