Marcos Nielsen

Obrigado @Diego Foliene Sei que essa alteração é complexa e impacta muito no ACRBr. Ainda assim, caso seja útil para vocês, fico totalmente à disposição e me comprometo a ajudar no que for necessário durante a validação ou implementação. Segue meu Discord para contato direto. Marcos.Nielsen

Na prática, o problema é bem mais amplo. Ao consultar os XMLs gerados pelo ACBrNFSeX no Recebedor Nacional, continuam surgindo caracteres inválidos, mesmo com a opção remover acentos habilitada. A transmissão utilizando codepage diferente de UTF-8 gera inconsistências no próprio provedor nacional, que passa a retornar a NFSe com erro. Como consequência, o XML da nota fiscal apresenta diversos problemas de acentuação, impedindo a importação correta pelos sistemas de contabilidade. No final, esses erros acabam sendo atribuídos aos sistemas emissores. É importante reforçar que esse comportamento está diretamente relacionado ao Delphi, que não utiliza string UTF-8 nativa, diferentemente do Lazarus, onde as strings já são UTF-8 por padrão. A falta de conversão explícita para UTF-8 no Delphi é a causa raiz do problema.

Pedido à comunidade Esse problema de acentuação / charset UTF-8 no NFSeX – Provedor Nacional já foi relatado diversas vezes e afeta principalmente ambientes Delphi 2009+. Peço, por gentileza, que os usuários que enfrentam o mesmo erro: Testem as alterações propostas Confirmem a correção do envio e do retorno da NFSe com acentuação UTF-8 correta Marquem aqui nos comentários caso também tenham esse problema A participação de vocês ajuda a demonstrar que o erro é recorrente e reforça a necessidade de commit da correção nos fontes, eliminando definitivamente paliativos como a opção de “remover acentos”. Obrigado a todos pela colaboração.

Descrição do problema Foi identificado um problema recorrente na transmissão e recuperação de XML (e conteúdos textuais retornados, inclusive estruturas convertidas para XLS/relatórios) no NFSeX – Provedor Nacional, onde ocorre erro de acentuação e corrupção de caracteres. <infNFSe Id="NFS41282032204580454000130000000000002626012373413140"> <xLocEmi>Uni?o da Vit?ria</xLocEmi> <xLocPrestacao>Uni?o da Vit?ria</xLocPrestacao> <nNFSe>26</nNFSe> <infNFSe Id="NFS41282032204580454000130000000000002626012373413140"> <xLocEmi>Uni?o da Vit?ria</xLocEmi> <xLocPrestacao>Uni?o da Vit?ria</xLocPrestacao> <nNFSe>26</nNFSe> <xTribNac> Lubrifica??o, limpeza, lustra??o, revis?o, carga e recarga, conserto, restaura??o, blindagem, manuten??o e conserva??o de m?quinas, ve?culos, aparelhos, equipamentos, motores, elevadores ou de qualquer objeto (exceto pe?as e partes empregadas, que ficam sujeitas ao ICMS). </xTribNac> <xNBS>Servi?os de sistemas de seguran?a</xNBS> <verAplic>SefinNacional_1.5.0</verAplic> <ambGer>2</ambGer> <tpEmis>1</tpEmis> <procEmi>1</procEmi> <cStat>100</cStat> <dhProc>2026-01-12T19:56:19-03:00</dhProc> <nDFSe>53116</nDFSe> <emit> A causa principal está no fato de que, em diversos pontos do código do ACBr, existem conversões implícitas de tipos (string, AnsiString e UTF-8). Esse comportamento não gera erro aparente no Lazarus/FPC, pois nesse ambiente o tipo string já é UTF-8 por padrão. Entretanto, no Delphi 2009+ (Unicode), essas conversões implícitas passam a ser críticas, resultando em: UTF-8 interpretado como ANSI Dupla conversão de encoding Mojibake (acentuação quebrada) Perda de caracteres tanto no envio quanto no retorno do processamento Observação importante Esse problema já foi reportado diversas vezes pela comunidade. Historicamente, a solução sugerida tem sido habilitar a opção de “remover acentos” nos textos enviados. No entanto, essa não é uma solução correta. A acentuação em UTF-8 é plenamente aceita, não possui qualquer restrição no layout e é inclusive utilizada internamente pelo servidor da NFSe Nacional. Remover acentos apenas mascara o problema, elimina informação válida do texto e não resolve a causa real, que é o tratamento incorreto de charset no código. Portanto, o problema precisa ser resolvido na origem, com a correção adequada dos fontes e do fluxo de encoding. Esse cenário afeta diretamente: Envio do XML da NFSe Retorno das mensagens do webservice Textos livres (descrições, observações, mensagens de erro) Conteúdos recuperados e posteriormente exportados/visualizados (ex.: XML → XLS) Diante disso, tornou-se necessária a correção dos fontes, eliminando conversões implícitas e garantindo tratamento explícito de UTF-8. Adequação realizada Foi realizada uma adequação no código da NFSe – Padrão Nacional, com foco em Delphi 2009+, corrigindo problemas de acentuação e encoding decorrentes do uso incorreto de AnsiString em fluxos que exigem UTF8String. A correção é indispensável porque o servidor da NFSe Nacional exige que todo o conteúdo enviado esteja obrigatoriamente em UTF-8, incluindo: XML principal Mensagens de troca com o webservice Textos livres (descrições, observações, mensagens de erro, etc.) Antes do ajuste, parte do código realizava conversões implícitas ou indevidas entre string, AnsiString e UTF-8, ocasionando mojibake (conteúdo UTF-8 interpretado como ANSI), com impacto direto na acentuação tanto no envio quanto no retorno do processamento. O que foi corrigido Padronização do tratamento de dados textuais enviados ao webservice como UTF8String Eliminação de conversões implícitas que causavam dupla interpretação de encoding Correção de pontos críticos de: Compressão e descompressão Gravação e leitura de arquivos Manipulação de XML Comunicação HTTP Garantia de retorno correto dos caracteres acentuados após o processamento Correção dos dados recuperados, evitando erros de acentuação em exportações e visualizações (ex.: XML/XLS) Compatibilidade A solução mantém total compatibilidade com: Lazarus / FPC (onde string já é UTF-8) Delphi antigo (pré-Unicode) Delphi Unicode (2009+) Foram utilizadas diretivas de compilação para assegurar o comportamento correto em cada ambiente, sem impacto regressivo. Arquivos alterados Os seguintes arquivos foram modificados para aplicar a correção de encoding e eliminar problemas de mojibake: ACBrXmlDocument.pas PadraoNacional.Provider.pas ACBrNFSeXWebserviceBase.pas ACBrDFeXsLibXml2.pas ACBrDFe.pas ACBrUtil.XMLHTML.pas ACBrUtil.Strings.pas ACBrUtil.FilesIO.pas ACBrCompress.pas Estou disponibilizando os arquivos corrigidos, juntamente com o resultado do processamento após a correção, para validação técnica e compartilhamento com a comunidade. exemplo do funcionamento da correção Logs.7z

Olá @Juliana Tamizou Os Access Violation ocorrerem e momentos posteriores e não posso usar o componente TACBrTEFAPI1 na plataforma FMX.

Olá @Juliomar Marchetti Na tentativa de evitar esse erro fizemos um singleton que é inicializado junto da aplicação e desinicializado quando a aplicação é encerrada. pois entendo que a dll da PayGoWeb deve ser inicializada apenas uma vez mas mesmo convertendo em singleton o access violation vai ocorrer em outras chamadas TEF repetitivas como no uso do menu fiscal.

Olá Pessoal Preciso de ajuda com o componente TACBrTEFAPI - Modelo = tefApiPayGoWeb. O componente TACBrTEFAPI esta gerando Access Violation e Memory Leak quando fecho uma aplicação feita em Firemonkey: para reproduzir o erro basta invocar 3X a chamada dos métodos: TACBrTEFAPI1.Inicializar; ACBrTEFAPI1.DesInicializar; e quando a aplicação e finalizada o seguintes erros vão ocorrer: É importante ressaltar que esse erro não ocorre na VCL, apenas na plataforma FMX. segue um vídeo para auxiliar na demonstração do erro: No anexo Exemplos.7zesta o exemplo escrito em FMX que gera o erro e um VCL que não apresenta o erro: Obrigado pela atenção

Bom dia Juliana Colocar os valores de R$ 0.001 centavo não é o correto, Aqui entendemos que é correto informar o valor zerado e gerar as tags com 0,00, porque o valor 0,00 é um registro de calculo que comprova que a conta feita pelo cliente está correta ou não!