Diogo Loff

Sim muito bom esta padronização, valeu por compartilhar. Este inclusive é um topico bem antigo, você pode encerrar até, hoje por exemplo já nem estou usando nenhum tipo de impressão mais customizada, todas que estou usando é a que vocês disponibilizaram no padrão nacional, mesmo sendo ainda provedor proprio digamos.

Valeu vi que aplicou, aparentemente esta correto. Obrigado.

Na versão atual de ACBrNFSeXConversao foi removido o retorno do OK booleano da função StrToNaturezaOperacao function StrToNaturezaOperacao(out ok: boolean; const s: string): TnfseNaturezaOperacao; var idx: TnfseNaturezaOperacao; begin for idx:= Low(TNaturezaOperacaoArrayStrings) to High(TNaturezaOperacaoArrayStrings) do begin if (TNaturezaOperacaoArrayStrings[idx] = s) then begin ok := True; Result := idx; exit; end; end; ok := False; raise EACBrException.CreateFmt('Valor string inválido para TnfseNaturezaOperacao: %s', [s]); end; Eu por exemplo uso para checagem no meu sistema e parou de funcionar, pois foi removido, o retorno e passou a dar sempre retorno falso. Acima a correção e anexo o fonte atualizado. ACBrNFSeXConversao.pas

Fiz um ajuste para aceitar tanto valores como percentuais diretamente no .fr3. Não criei campos novos, utilizei o mesmo dos percentuais com uma condição. Segue anexo. DANFSEPadraoNacional.fr3

Esta semana acabei de verirficar que não terá mais a opção de resgatar o DANFE, já adaptei aqui para usar o modelo em Fast de você, esta muito bom, já passou no testes, pode encerrar. Não faz mais sentido este tópico.

Ola, atualizei os fontes hoje 15/06/2026 e esta solução tive que implementar novamente, pois o problema persiste.

Ola, fiz atualização hoje 15/06/2026 e vi que implementaram a solução dos valores do IBPT para simples nacional conforme havia sugerido. Obrigado. Pode encerrar o tópíco, pelos testes que fiz esta correto.

Esqueci de setar False em ObterDANFSEResponse.Sucesso nos tratamentos de erros que coloquei ali. if (Trim(ObterDANFSEResponse.ArquivoRetorno) = '') then begin ObterDANFSEResponse.Sucesso := False; raise Exception.Create('Retorno vazio do serviço de obter DANFSE'); end; if (Pos('<html', LowerCase(ObterDANFSEResponse.ArquivoRetorno)) > 0) and (Pos('bad gateway', LowerCase(ObterDANFSEResponse.ArquivoRetorno)) > 0) then begin ObterDANFSEResponse.Sucesso := False; raise Exception.Create('Erro no serviço de obter DANFSE: resposta inválida (HTML recebido)'); end;

Pode concluir esta correto.

@Italo Giurizzato Junior eu baixei aqui a atualização, e o resgate do PDF esta OK, mas não esta tratando corretamente nas rotinas. Fiz ajuste aqui. ACBrNFSeXProviderBase.pas Rotina procedure TACBrNFSeXProvider.ObterDANFSE; Aqui o ArquivoRetorno sempre vem vazio, pois pela lógica interna do ACBR aqui só retorna valor ser for um XML, JSON ou TXT ObterDANFSEResponse.ArquivoRetorno := AService.ObterDANFSE(ConfigMsgDados.DadosCabecalho, ObterDANFSEResponse.ArquivoEnvio); Logo em baixo é jogado o PDF para EnvelopeRetorno ObterDANFSEResponse.EnvelopeRetorno := AService.Retorno; Porem isto não é usado pra nada pelo que vi, acontece que em TratarRetornoObterDANFSE(ObterDANFSEResponse); que é chamado no final, o tratamento é todo em cima de ObterDANFSEResponse.ArquivoRetorno que esta vazio, o que fiz aqui, logo que atribui em EnvelopeRetorno coloquei um IF. if (Trim(ObterDANFSEResponse.ArquivoRetorno) = '') then ObterDANFSEResponse.ArquivoRetorno := AService.Retorno; Assim as rotinas subsequentes funcionam. Outro problema que peguei por acaso, se tentar resgatar um PDF de um nota fora do mês atual na rotina que monta o path e salva procedure TACBrNFSeXProvider.SalvarPDFNfse(const aNome: string; a data é passada 0, então ele pega mês/ano atual. Ali fiz meio que uma gambiarra pois não sei se é usado para outras coisas, coloquei uma condição se o nome do arquivo é a chave do nacional (meio de forma heuristica sem muito critério), ele pega o mês e ano da chave para jogar o PDF na pasta certa. Vi que você não aplicou aquelá lógica de trabalhar tudo com BASE64, mas esta funcionando, vamos ver se não da erros de encoding, aqui nos testes não tive nenhum. Segunda já vou liberar para os clientes a versão, então os ajustes que to sugerindo aqui já vão para produção e estão funcionais. Da forma original esta quase lá, mas não esta funcionando. A também coloquei mais um tratamento em ObterDANFSE para ver o erro 502 Bad Gateway The server returned an invalid or incomplete response, tem dado este erro as vezes na consulta. ACBrNFSeXProviderBase.pas

Acabei de atualizar os fontes, e este item continua com o problema para quem deseja trabalhar com valores direto e é simples. Implementei novamente a minha solução proposta.

Oi Italo, hoje que tirei para atualizar o ACBr, já conferi e estou enviando a versão para testes.

Oi Italo, hoje que tirei para atualizar o ACBr, já conferi e estou enviando a versão para testes.

Chegaram dar uma olhada neste item?

Oi @Italo Giurizzato Junior obrigado pelo retorno, então estas duas semanas estou em outro projeto na empresa, inicio do mês de abril vou atualizar os fontes, e te digo como ficou. Mas assim a opção de usar impressão por DANFSE acho que vocês deveriam abolir e passar só usar o do nacional direto, pois ai sempre se garante estar fiel como esta lá, já que baixa o pdf, mas mesmo assim vou ver como ficou e te reporto inicio de abril. Sobre isto até eu hehe, como disse já em alguns posts eu não domino a base do ACBR, fiz a coisa para atender meu negócio, o que posso dizer é que todos os clientes meus estão sem problemas usando da forma que deixei, baixando o PDF, mas talvez tenha forma melhor de fazer, se eu dominasse um pouco mais a base da construção do ACBr, mas creio que vocês vão conseguir entender e talvez fazer algo melhorado e mais genérico. Então porque eu converti para base64 se ele vem em PDF, meio que não faz sentido. É que a rotina padrão do ACBr ali que retona isto esta trazendo o binário do PDF em string, se eu vou levando para frente ele como veio, por algum motivo começam dar erros de codificação de pagina, tipo aqueles problemas de encoding, então a forma que achei de resolver isto foi, transformar ele para uma string base64 pois desta forma ele fica protegido e lá onde trata eu salvo para PDF no diretório do provedor. Outra questão que poderia ser era não ter nada disto e no ato que já vem o retorno do webserver e ser PDF já salvar ele e retornar o path, mas não consegui fazer assim, pois como citei no paragrafo acima, desconheço a base do ABCr, e não sei como naquele momento ali identificar o provedor para digamos pegar o path da pasta poder salvar e retornar o path do arquivo. Então esta é a explicação.

Pessoal, a ultima atualização realizada em PadraoNacional.GravaXML o bloco de GerarXMLTotalTributos parou de funcionar, ao menos no meu sistema estava funcionando de acordo, mexeram para atender uma questão específica do simples mas não observaram outras questões. Meu caso eu não informo no sistema o IBPT em percentuais, sempre é valor mesmo que seja regime simples ou normal, só não trabalho com MEI. Até semana passada estava funcionando, onde minha versão usava um ACBr da semana do dia 09/02. Por outros motivos tive que atualizar e agora passou a não funcionar mais dar problema com o bloco de "totTrib". Ao meu ver esta lógica esta totalmente equivocada, para que trabalha sempre com valores informados e não percentuais. function TNFSeW_PadraoNacional.GerarXMLTotalTributos: TACBrXmlNode; begin Result := CreateElement('totTrib'); if (NFSe.Servico.Valores.totTrib.pTotTribFed > 0) or (NFSe.Servico.Valores.totTrib.pTotTribEst > 0) or (NFSe.Servico.Valores.totTrib.pTotTribMun > 0) then Result.AppendChild(GerarXMLPercentualTotalTributos) else if (NFSe.OptanteSN = osnOptanteMEEPP) then Result.AppendChild(AddNode(tcDe2, '#1', 'pTotTribSN', 1, 5, 1, NFSe.Servico.Valores.totTrib.pTotTribSN, '')) else if (NFSe.Servico.Valores.totTrib.indTotTrib <> indSim) then Result.AppendChild(AddNode(tcStr, '#1', 'indTotTrib', 1, 1, 1, indTotTribToStr(NFSe.Servico.Valores.totTrib.indTotTrib), '')) else Result.AppendChild(GerarXMLValorTotalTributos); end; Foi fixado a questão do simples ser sempre por percentuais. Inclusive não se consegue mais nem usar a opção de não querer informar, caso deseje não informar. if (NFSe.OptanteSN = osnOptanteMEEPP) then Result.AppendChild(AddNode(tcDe2, '#1', 'pTotTribSN', 1, 5, 1, NFSe.Servico.Valores.totTrib.pTotTribSN, '')) Infelizmente não fiz uma cópia da versão do dia 09 então não sei como estava este arquivo originalmente. Mas ao meu ver a lógica sempre deveria priorizar os valores primeiro e depois o modelo por percentuais. Eu ajustei desta forma para resolver meu problema. Favor avaliarem a questão. function TNFSeW_PadraoNacional.GerarXMLTotalTributos: TACBrXmlNode; begin Result := CreateElement('totTrib'); if (NFSe.Servico.Valores.totTrib.vTotTribFed > 0) or (NFSe.Servico.Valores.totTrib.vTotTribEst > 0) or (NFSe.Servico.Valores.totTrib.vTotTribMun > 0) then Result.AppendChild(GerarXMLValorTotalTributos) else begin if (NFSe.Servico.Valores.totTrib.pTotTribFed > 0) or (NFSe.Servico.Valores.totTrib.pTotTribEst > 0) or (NFSe.Servico.Valores.totTrib.pTotTribMun > 0) then Result.AppendChild(GerarXMLPercentualTotalTributos) else begin if (NFSe.Servico.Valores.totTrib.indTotTrib <> indSim) then begin Result.AppendChild(AddNode(tcStr, '#1', 'indTotTrib', 1, 1, 1, indTotTribToStr(NFSe.Servico.Valores.totTrib.indTotTrib), '')) end else begin if (NFSe.OptanteSN = osnOptanteMEEPP) then Result.AppendChild(AddNode(tcDe2, '#1', 'pTotTribSN', 1, 5, 1, NFSe.Servico.Valores.totTrib.pTotTribSN, '')) end; end; end; end; A lógica é bem clara e facil de entender Tem valor "usa os valores" Não tem e tem percentuais "usa os percentuais" Não tem e tem indicação de não querer informar "indica" Não tem a indicação, confere se é simples e "usa o percentual especifico de simples". Vi no log que foi mexido para atender justamente a questão do simples, mas digo com clareza que não esta atendendo, pois se deseja trabalhar com valores no simples esta dando erro, pois na lógica que foi atualizada nunca será possivel usar valores neste caso. Segue anexo fonte. PadraoNacional.GravarXml.pas

Sim @Rodrigo Crovador a conversão ali quebra o arquivo, não converter também pode ser uma solução mais simples. No que eu fiz é a mesma coisa só que para manter a conversão eu dupliquei a variavel que salva pro arquivo sem converter, mas é bem isto ai que você ta falando, e fica tudo certo mesmo, os arquivos não ficam errados, eu testei muitos aqui e nenhum XML ficou com caracteres trocados.

@EMBarbosa não deu certo. Recomendo avaliar a adequação que sugeri, onde na questão de recuperar o arquivo e alimentar o arquivo para salvar, não seja feito nenhum tipo de manipulação de String, manipular binario é sempre bronca. @Anderson Mendes peguei o seu arquivo e comparei com o atual, no seu tem várias questões descomentas que consomem muita CPU, então peguei somente procedure TACBrXmlDocument.LoadFromXml(AXmlDocument: AnsiString); e vi que na sua a linha loadedDoc := xmlParseDoc(PAnsiChar(UTF8String(AXmlDocument))); esta desta forma. Na atual esta sem UTF8String então adicionei e testei, e também não funciona. Os fontes meus são de 16/02/2026. Eu bato na tecla que não se deve ficar manipulando Binario em String, mesmo que em Base64. Tem que pegar decodar ele e manter como esta, se não é loteria, pode ser que para um funcione para outro não. Eu não sei se tem algum código que impede de funcionar em versões mais antigas de Delphi ou então de Lazarus. Se não tive, acho que a solução é certeira boto minha mão no fogo haha. Que é NFSeXml := Document.AsString['nfseXmlGZipB64']; // Carrega como esta NFSeXmlFile := DeCompress(DecodeBase64(NFSeXml)); // Somente descomprime em outra variavel // Testa se é UTF8 e faz o que tivez que fazer com a variavel string, pois pelo que vi no fonte é ela que é utilizada no geral para tratamentos if IsUTF8String(NFSeXmlFile) then NFSeXml := UTF8ToAnsi(NFSeXmlFile) else NFSeXml := NFSeXmlFile; DocumentXml.LoadFromXml(NFSeXmlFile); // Só que este cara aqui que vai carregar o documento para salvar depois, mantem ele com a string do binario de forma original, sem mofificações, o erro inclusive do encoding ocorre aqui neste exato ponto, porque acaba alguma coisa modificando e gerando mal formação no arquivo. Venho desde a sexta passada mexendo nisto e olha que já testei muita nota fiscal e tudo em ambiente de produção nestes dias, e desde que mexi nesta rotina, não tive mais nenhum problema de encoding, e todos os dados com caracteres especíais estão ficando corretos.

Olá! Conforme sabemos em teoria se tudo fosse nacional nossa vida estaria mais facil, bom mas como não é assim, esta semana eu tirei tempo para ajustar os provedores que estavam com problemas no meu sistema, e uma das coisas que me chamou atenção ainda é a falta de uniformização dos DANFSe. Meus clientes atualmente usam Nacional, Betha, IPM e Sigcorp. Quando vi que o da Betha o provedor estava retornando em base64 o Danfse, eu pensei porque não seria possivel fazer nos outros?, mesmo que eles não disponibilizem, então venho trabalhando em uma solução usando por base o que já tem implementado no ACBr para pegar o Danfse quando é Nacional, e apliquei a mesma ideia ao IPM e Sigcorp, e acredito que pode ser aplicado a qualquer outro. Segue solução para avaliação. Aquivos Alterados ACBrUtil.FilesIO --> Criado função semelhante a StringIsPDF, porem voltada a Stream, "StreamIsPDF". ACBrNFSeXWebserviceBase --> Ajustado rotina que envia a requisição para que se o retorno for um PDF, não seja feito tratamento como Binario para String, e sim de Binario para Base64, isto é necessário pois a rotina original apesar de funcionar, vira "Loteria", acontece que dependendo dos dados que vem no PDF, o mesmo pode ficar mal formado e causar erro. Isto explica a modificação ta unit ACBrUtil.FilesIO. ACBrNFSeXProviderBase --> Ajustei rotina SalvarPDFNfse, testando se o mesmo esta em base64 para ai salvar o PDF integro conforme veio em ACBrNFSeXWebserviceBase ou se não executa a rotina antiga, pois não sei em que mais locais poderia impactar o modo antigo. IPM.Provider SigCorp.Provider Nestas duas implementei as rotinas que vem das classes base function ObterDANFSE(const ACabecalho, AMSG: string): string; override; procedure PrepararObterDANFSE(Response: TNFSeObterDANFSEResponse); override; procedure TratarRetornoObterDANFSE(Response: TNFSeObterDANFSEResponse); override; Também fiz uma pequena alteração no CriarServiceClient de cada provider, para entender quando é a solicitação do DANFSE. ACBrNFSeXServicos.ini Adicionei os endereços para obter os DANFSE [4211207] Nome=Morro da Fumaca UF=SC Provedor=IPM Versao=1.01 ProRecepcionar=https://morrodafumaca.atende.net/?pg=rest&service=WNERestServiceNFSe HomRecepcionar=https://morrodafumaca.atende.net/?pg=rest&service=WNERestServiceNFSe ProObterDANFSE=https://adn.nfse.gov.br HomObterDANFSE=https://adn.nfse.gov.br [4204202] Nome=Chapeco UF=SC Provedor=SigCorp Versao=2.04 ProRecepcionar=https://chapeco.meumunicipio.online/abrasf/ws HomRecepcionar=https://testechapeco.meumunicipio.online/abrasf/ws ProNameSpace=https://abrasfchapeco.meumunicipio.online/ws HomNameSpace=https://testechapecoabrasf.meumunicipio.online/ws ProObterDANFSE=https://adn.nfse.gov.br HomObterDANFSE=https://adn.nfse.gov.br No caso especifico dos provedores citados implementei para Versão 1.01 do IPM e 2.04 do SigCorp. Se for implmentar para outros provedores, é basicamente fazer o mesmo que foi feito nos dois providers citados. Foram feitos inumeros testes em PRODUÇÃO no dia de hoje com IPM em Morro da Fumaça/SC e SigCorp em Chapecó. Inclusive no provider do SigCorp corrigi também o cancelamento, que não estava correto. Tudo isto foi feito com fontes atualizados de 16/02/2026. ACBrUtil.FilesIO.pas ACBrNFSeXWebserviceBase.pas ACBrNFSeXProviderBase.pas IPM.Provider.pas SigCorp.Provider.pas ACBrNFSeXServicos.ini

Vou encerrar este tópico e vou abrir um novo com melhorias que fiz que podem permitir outros provedores que são proprios não usar mais o DANFE customizado, e sim sempre pegar do Nacional. Implementei para IPM e Sigcorp, também peguei várias situações interessantes de possiveis erros que aconteceu em várias notas que tentei resgatar, geralmente notas com muitos dados, então cabe um tópico especifico disto para vocês avaliarem.

Eu tive que parar de mexer nisto antes, agora a noite vou dar mais uma trabalhada, vejo se consigo testar e te reporto.

Poise @EMBarbosa é complexo isto, acho que até pode encerrar este tópico pois estamos tratando a mesma coisa lá no outro do encoding. Mas estas coisas de encoding sempre da problema, eu que trabalho com diversas integrações de outros sistemas, geralmente quando tem leitura de um arquivo para criar outro o certo e não mudar nada, não tratar nada. E só tratar a variavel se tiver que pegar dados para preencher algum atributo específico.

Acabei de Testar em Produção Criciúma/SC, Cocal do Sul/SC e Faxinal dos Guedes/SC a correção @Daniel Simoes não deu certo, mantive a que eu indiquei no forum. A versão do Delphi que utilizo é a 10.3.3 Rio.

@Juliomar Marchetti fiz as adequações para resgatar o Danfe do nacional pelo no provedor IPM versão 1.01. Testado e validado em ambiente de produção. Municipio de Morro da Fumaça/SC Anexo ACBrNFSeXServicos.ini (Aqui inclui os dois parametros para pegar o endereço do Nacional para o Danfe) IPM.Provider.pas (Aqui customizei para entender, basicamente repliquei a mesma ideia que é feita no Nacional), tem uma parte ali dos Configurações que eu acho que poderia ser diferente, pois acabei fixando, se na classe não mudar não seria um problema, mas como não domino bem a base do componente, pode ser que exista uma forma melhor de fazer. inclusive agora a tarde vou implementar a mesma coisa para outro provedor que é o de Chapecó Sigcopr, que pelo que vi também não faz. Fico grato se implementarem as melhorias nos fontes. ACBrNFSeXServicos.ini IPM.Provider.pas

@EMBarbosa vou pegar estas duas units e testar aqui no ambiente de produção e retorno até a tarde.