Francis Silva

Bom dia. Segue o patch com o ajuste para criação de um evento OnCreateProvedor, no componente TACBrNFSeX, para permitir configurar o provedor assim que ele for instanciado. As modificações foram realizadas em cima da revisão 46533, e as units alteradas foram as seguintes: ACBrNFSeX.pas -> Criado o tipo TACBrNFSeXOnCreateProvedor = procedure (const Provedor: IACBrNFSeXProvider) of object; Criada a property OnCreateProvedor: TACBrNFSeXOnCreateProvedor; ACBrNFSeXProviderManager.pas -> Corrigido o método TACBrNFSeXProviderManager.GetProvider para invocar o evento OnCreateProvedor, do objeto ACBrNFSe. Já realizei os testes com o patch, e consegui parametrizar com sucesso o caractere de quebra de linha do provedor, e resolveu o problema da substituição da quebra de linha padrão "|" pelo "\n" padrão do provedor. Você pode comitar no repositório, por favor? Obrigado. Patch_OnCreateProvedor_ACBrNFSeX.7z

Beleza, vou ajustar e depois posto o fonte aqui.

Teria como implementar um evento OnProviderCreate, para que possamos configurar o provider sem mexer com o código fonte do ACBr? Acho que seria muito melhor, e fácil de implementar. Atenciosamente, Francis Lay L. Silva.

Não consigo resolver esse problema, sem mexer no fonte do PadraoNacional.GravaXml.pas, e não quero fazer isso, não porque é certeza de problemas na próxima atualização repositório. Eu já tentei de toda forma: ACBr.Configuracoes.WebServices.QuebradeLinha := ACBR_SEPARADOR_LINHAS; // '|' ACBr.SetProvedor(ACBr.Configuracoes.Geral.Provedor, ACBr.Configuracoes.Geral.Versao); ACBr.Provider.ConfigGeral.QuebradeLinha := ACBr.Configuracoes.WebServices.QuebradeLinha; ANTES desta atribuição ACBr.Provider.ConfigGeral.QuebradeLinha := ACBr.Configuracoes.WebServices.QuebradeLinha; o valor de ACBr.Provider.ConfigGeral.QuebradeLinha é igual a '\n'. Depois da atribuição, ele fica igual a '|'. Só que, quando ele cria o XML, continua usando o '\n' como quebra de linha, eu tenho a impressão de que ele deve estar recriando o provider em algum momento, e aí volta para o valor default da quebra de linha. Alguém pode me ajudar a resolver esse problema, por favor? Obrigado. Atenciosamente, Francis Lay L. Silva. PS: É exatamente como eu imaginei. Se o provider existe, ele descarta e cria outro, então não tenho como configurar o provider sem mexer no fonte do ACBr.

E aparentemente, o problema está no PadraoNacional.GravaXml.pas, nesse ponto aí: Quem é esse FpAOwner.ConfigGeral.QuebradeLinha pelo qual ele está substituindo a quebra de linha que informamos? Para o MEU PROBLEMA, essa simples linha no código do meu aplicativo deve resolver, mas preciso saber o motivo da troca, se tem impacto em mais alguma coisa dentro do componente. Vai dar problema se eu parametrizar da forma abaixo? ACBr.Configuracoes.WebServices.QuebradeLinha := '|'; ACBr.Provider.ConfigGeral.QuebradeLinha := ACBr.Configuracoes.WebServices.QuebradeLinha; Atenciosamente, Francis Lay L. Silva.

Olá. Recentemente recebemos algumas reclamações de clientes que notaram que a descrição dos serviços nas nossas notas fiscais, estavam vindo com caracteres estranhos, e queriam saber do que se trata. Os caracteres em questão são os "\n". Esses caracteres passaram a aparecer no lugar do caractere "|" que é o que utilizamos na discriminação do serviço, para identificar uma quebra de linha: ACBr.Configuracoes.WebServices.QuebradeLinha := '|'; Entretanto, quando o ACBr gera o XML com o RPS para envio para autorização, ele está substituindo, nos XML`s, todos os caracteres "|" por "\n" automaticamente. Por que isso agora? EXEMPLO: <xDescServ>Produto: JORNAL A CRITICA\n1 publicacao(oes) do anúncio "CONCORRENCIA 90050/2026 - CONFORME FATURA 21895SDF", no(s) dia(s):\n18/03/2026 - Quarta-feira -&gt; 3 Col. X 8 Cm, Caderno "CLASSIFICADOS" (R$ 1.345,20)\n(-) DESCONTO PADRAO AGENCIA (LEI 12.232/2010) (R$ 269,04)\nConforme P.I. No. 4558/2026.\nVencto(s): C/Apresentacao</xDescServ> Quando enviamos a discriminação do serviço para o componente do ACBRNFseX, ela vai da seguinte maneira: <xDescServ>Produto: JORNAL A CRITICA|1 publicacao(oes) do anúncio "CONCORRENCIA 90050/2026 - CONFORME FATURA 21895SDF", no(s) dia(s):|18/03/2026 - Quarta-feira -> 3 Col. X 8 Cm, Caderno "CLASSIFICADOS" (R$ 1.345,20)|(-) DESCONTO PADRAO AGENCIA (LEI 12.232/2010) (R$ 269,04)|Conforme P.I. No. 4558/2026.|Vencto(s): C/Apresentacao</xDescServ> E era da forma acima que aparecia no DANFNSe do portal (porque eles não tratam quebras de linhas, vem tudo como um texto corrido, então o "|" ajudava a leitura nesse caso). Na DANFNSe local, tratamos isso e discriminação sai com as respectivas quebras de linha. É assim que está aparecendo para os clientes na DANFNSe, já tem algum tempo, e não havíamos percebido: ISSO SÓ ESTÁ ACONTECENDO COM A TAG <xDescServ>, na <xInfComp>, que utiliza o mesmo caractere delimitador, ele aparece corretamente, não é substituído. Não sei quando isso começou a acontecer, pois só tomamos conhecimento do fato agora, mas já fiz o teste e realmente está havendo essa substituição dentro da tag <xDescServ>. Estou utilizando os fontes da Revisão 46134 de 08/05/2026. Grato.

Mas é bem estranho fazer esses ajustes específicos via código né? Porque a unit ACBrNFSeXDANFSeFR.pas atende a TODOS os tipos de modelo do FastReport, independente do provedor, em algum momento o nome dos campos referenciados lá nessa unit, vão conflitar com campos de mesmo nome em outros arquivos fr3. Eu trataria essas particularidades de cada modelo dentro do próprio arquivo fr3, ficaria encapsulado com mais segurança, sem risco de interferir com outros modelos existentes ou futuros, além de não precisar recompilar todo o repositório cada vez que precisar fazer um ajuste simples no arquivo fr3, mudaria apenas ele. Mas é apenas a minha opinião, ok ? Abraços.

Olá. Pronto, removi o script de ativação/desativação da banda de impressão das informações do intermediário, de dentro do .fr3, e coloquei no ACBrNFSeXDANFSeFR.pas, dentro do BeforePrint do frxReport. Agora não temos nada dentro do fr3, além do layout do relatório. Atenciosamente, Francis Lay L. Silva. ACBrNFSeXDANFSeFR.pas DANFSEPadraoNacional.fr3

Eu coloquei, apenas para ativar/desativar a seção com as informações do intermediário. Se não utilizasse esse pequeno código no script, dentro do próprio FastReport, eu teria que localizar e fazer isso dentro da unit que chama esse relatório, e eu não sei se é a ACBrNFSeXDANFSeFR.pas ou tem mais alguma. Mas o FastScript é nativo do FastReport, qualquer edição do Delphi com o FastReport, já vai ter o FastScript automaticamente. Mas vou ver se consigo localizar onde fazer esse ajuste via código também.

Boa noite. Conclui todos os meus testes, e atualização do nosso sistema para o modelo de DANFENFSe que será o padrão nacional. Para tanto, precisei realizar mais alguns pequenos ajustes na unit ACBrNFSeXDANFSeFR.pas, além das informações do Intermediário da nota. No PDF em anexo, demonstro, através de comparação entre o DANFENFSe oficial do portal nacional, o DANFNFSe original do ACBr e o DANFNFSe com as minhas correções, e submeto tudo a análise de vocês. Acredito que essas alterações venham a contribuir um pouco com o projeto. O DANFENFSeNacional.fr3 agora alterna corretamente entre a impressão das informações do intermediário do serviço, e a mensagem "INTERMEDIÁRIO DO SERVIÇO NÃO IDENTIFICADO NA NFS-e". Para localizar os pontos onde alterei a unit ACBrNFSeXDANFSeFR.pas, basta pesquisar por // Francis.Silva em 09/05/2026. Grato. ACBrNFSeXDANFSeFR.pas DANFENFSeNacional.fr3 Mudanças DANFENFSe_FR.pdf

Eu estava usando o release 44948, atualizei o repositório hoje e houveram muitas modificações na unit ACBrNFSeXDANFSeFR.pas desde o release que eu estava. Essa unit é a BASE PARA QUALQUER MODELO do FastReport, independente de padrão ou não, é ela que mapeia todas as informações do XML para datasets, para que possam ser utilizados em relatórios do FastReport. Mesmo no release que baixei agora a tarde, o 46134, ainda não estão tratando as informações do intermediário nessa unit. Foram acrescentadas muitas outras informações, principalmente relacionadas a tributação, mas nada referente ao intermediário da nota, sendo que é uma informação que sai na DANFESe do portal nacional e que, pelo que entendi, em 07/2026 a API que gera essa DANFSe vai ser descontinuada, então precisaremos gerar exclusivamente pelo ACBr. Em vista disso, atualizei a unit ACBrNFSeXDANFSeFR.pas mais recente, baixada do repositório, para que ela forneça as informações do intermediário, e estou disponibilizando agora em anexo, nessa mensagem. Mexi EXCLUSIVAMENTE na parte de definição e atualização do cdsIntermediario, mais nada. Atenciosamente, Francis Lay L. Silva. ACBrNFSeXDANFSeFR.pas

Esse modelo DANFSEPadraoNacional.fr3 é recente? Porque não encontro ele no meu repositório.

É o padrão nacional sim. Então o DANFE que o ACBr gera, não é mais válido? Eu uso o DANFE do Padrão nacional, localizado em acBr2\Exemplos\ACBrDFe\ACBrNFSeX\Delphi\Report\DANFSeProvedorEL_ProvedorNacional.fr3 O motivo de eu ter corrigido o fonte do ACBrNFSeXDANFSeFR.pas é justamente porque o DANFE do Portal Nacional, exibe os dados completos do intermediário, e o DANFE do ACBr não exibia nem o nome dele, não tinha nem a seção específica para isso. Como fazemos agora? Temos que baixar PDF por PDF direto do portal nacional? Como temos que comprovar veiculação das mídias, imprimimos os DANFEs e enviamos para o cliente junto com as comprovações, se tiver que baixar um a um agora, vai ser punk.

Saudações a todos. O ramo de atividade principal da nossa empresa é comunicação, Jornal, TV e Rádios. No Jornal, nós emitimos a NFS-e padrão Nacional, e nas demais empresas a NFCom. Vários clientes estão nos solicitando a inclusão das informações da agência de publicidade como intermediário do serviço, na NFS-e. Já fiz todas as adequações no nosso sistema para transmitir essas informações para o servidor Nacional, e está funcionando perfeitamente. ENTRETANTO, o problema está na geração do DANFE, pelo ACBr. Eu utilizo, no caso, o ACBrNFSeXDANFSeFR. Quanto comecei a enviar as notas com o intermediário informado, os DANFE`s que eram salvos na pasta de saída não continham essas informações, então peguei o arquivo .fr3 com o modelo do relatório, editei e acrescentei os campos do intermediário, tomando por base os mesmos campos do tomador do serviço. Só que o relatório dava erro, porque no arquivo fonte ACBrNFSeXDANFSeFR.pas, o ACBr só estava adicionando ao cdsIntermediario, o campo RazaoSocial, e mais nada, e aí todos os demais campos davam erro. Eu já fiz a adequação no ACBrNFSeXDANFSeFR.pas, para adicionar todos os campos do intermediário, e já está funcionando. Eu gostaria de compartilhar essas atualizações com vocês, para que no futuro, quando eu for atualizar o repositório, eu não precise fazer tudo novamente ou utilizar uma unit que pode ou não estar defasada. Eu não tenho acesso a realizar commit no repositório. Será que alguém pode analisar e fazer isso? Estou enviando a unit corrigida em anexo. Eu tenho também um arquivo .fr3 com os dados do intermediário incluídos, mas tem umas customizações específicas nossas que fiz no campo de observações. Se por acaso se interessarem por ele, posso remover só essa customização e enviá-lo apenas com as informações do intermediário acrescentadas. Desde já agradeço. Atenciosamente, Francis Lay L. Silva. ACBrNFSeXDANFSeFR.pas

Entendi, então é um problema com a dll que manipula o XML. Beleza, vou ver qual a melhor estratégia aqui para esse problema. Obrigado.

Poxa, desculpa, na verdade me lembrei agora porque que estava usando uma "pasta relativa", é porque o ACBr "come"a primeira barra do endereço UNC da rede, quando vai ler o arquivo de esquemas. O endereço é o "\\SRV-JUPITER\APLICATIVOS\SISPUB\PMM\ABRASF\SCHEMAS\" mas quando ele vai carregar os esquemas, me parece, pela mensagem, que ele tenta carregar como "\SRV-JUPITER\APLICATIVOS\SISPUB\PMM\ABRASF\SCHEMAS\" Em todos os outros parâmetros de arquivos ele funciona com UNC, menos no caminho dos esquemas. Eu devo abrir outro ticket para tratarmos desse detalhe?

JÄ ENCONTREI O PROBLEMA. Trocaram o SSD da máquina do usuário que realiza o faturamento e, ao repor os atalhos dos aplicativos dele, criaram um atalho direto para o executável que está localizado no disco C do usuário, sendo que o atalho anterior eu defini como pasta de inicialização, uma pasta da rede, para que todas as estações pudessem pegar os arquivos comuns do mesmo local (esquemas, certificados, etc). Aí esse usuário estava pegando do disco C dele, e não da rede. Criei um parâmetro dentro do aplicativo, para pegar os esquemas de dentro da pasta de rede, e não a partir da pasta raiz do executável. Só vou ter que atentar para isso quando eu estiver trabalhando no meu notebook, vou ter que mudar esse parâmetro antes. Mas está tranquilo, pode finalizar esse ticket, o XML já está chegando ao ambiente nacional normalmente. Muito obrigado pela ajuda de todos.

Posso fazer sim, mas onde eu identifico qual é o esquema que ele vai usar? Eu sei a versão do layout que ele está considerando é a 1.01, porque ele informa isso no XML, mas não sei onde olhar para descobrir qual o arquivo de esquema que ele está validando.

Olhem só, eu alterei o sistema para enviar o cancelamento, tanto pela forma tradicional, quanto pela forma com solicitação de análise fiscal, e o erro é exatamente o mesmo, só que agora mudou o nome da tag: Então, tanto a e101101 quanto a e101103, nenhuma está validando. Não entendo o que está havendo.

Eu já fiz isso, apaguei toda a pasta de download do repositório, e baixei novamente. Apaguei também toda a pasta, dentro do meu aplicativo, onde estão os arquivos de esquemas, e copiei do repositório baixado, mas continua dando a mesma mensagem. Eu acredito que o ambiente nacional não está mais aceitando o cancelamento simples, porque fui tentar cancelar essa nota direto no portal, e me deparei com uma mensagem informando que valores acima de 0,01 (1 centavo) só podem ser cancelados por análise fiscal. Se for isso mesmo, o evento <e101101> não deve mais estar sendo aceito, talvez agora aceitem apenas o <e101103>. Mas como você mencionou, Juliomar, parece que a nota sequer saiu do meu ambiente, já que deu erro na validação do esquema, o que é bem estranho porque já cancelei notas anteriormente. Mais alguém está passando por essa mesma situação ?

Mas se você observar o XML, essa tag nem está nele. Pela mensagem de erro retornada, ele está dizendo que a tag <e101101> não é esperada, e o esperado é <nPedRegEvento>. Eu pesquisei dentro dos arquivos de esquemas, e realmente aparecem algumas referências para a tag <nPedRegEvento>, mas também existem várias referências para a tag <e101101>. Pesquisa "nPedRegEvento" (9 ocorrências em 3 arquivos de 23 procurados) [Normal] \\10.10.1.27\aplicativos\SisPub\PMM\ABRASF\Schemas\PadraoNacional\1.00\tiposSimples_v1.00.xsd (2 ocorrências) Linha 1426: "PRE" + Chave de Acesso NFS-e + Tipo do evento + Número do Pedido de Registro do Evento (nPedRegEvento) Linha 1438: Identificador do evento: "EVT" + Chave de acesso(50) Tipo do evento (6) + Pedido de Registro do Evento(3) (nPedRegEvento) \\10.10.1.27\aplicativos\SisPub\PMM\ABRASF\Schemas\PadraoNacional\1.01\schema_v101-ISSNet.xsd (5 ocorrências) Linha 1380: "PRE" + Chave de Acesso NFS-e + Tipo do evento + Número do Pedido de Registro do Evento (nPedRegEvento) Linha 1392: Identificador do evento: "EVT" + Chave de acesso(50) Tipo do evento (6) + Pedido de Registro do Evento(3) (nPedRegEvento) Linha 4736: <xsd:element name="nPedRegEvento" type="TSNum3Dig" minOccurs="1" maxOccurs="1"> Linha 4740: Para os eventos que ocorrem somente uma vez, como é o caso do cancelamento, o nPedRegEvento deve ser igual a 1. Linha 4741: Os eventos que podem ocorrer mais de uma vez devem ter o nPedRegEvento único. \\10.10.1.27\aplicativos\SisPub\PMM\ABRASF\Schemas\PadraoNacional\1.01\tiposSimples_v1.01.xsd (2 ocorrências) Linha 1513: "PRE" + Chave de Acesso NFS-e + Tipo do evento + Número do Pedido de Registro do Evento (nPedRegEvento) Linha 1525: Identificador do evento: "EVT" + Chave de acesso(50) Tipo do evento (6) + Pedido de Registro do Evento(3) (nPedRegEvento) Pesquisa "e101101" (14 ocorrências em 5 arquivos de 23 procurados) [Normal] \\10.10.1.27\aplicativos\SisPub\PMM\ABRASF\Schemas\PadraoNacional\1.00\tiposEventos_v1.00.xsd (3 ocorrências) Linha 112: <xs:element name="e101101" type="TE101101"> Linha 200: <xs:complexType name="TE101101"> \\10.10.1.27\aplicativos\SisPub\PMM\ABRASF\Schemas\PadraoNacional\1.00\tiposSimples_v1.00.xsd (1 ocorrências) Linha 1454: <xs:enumeration value="e101101"/> \\10.10.1.27\aplicativos\SisPub\PMM\ABRASF\Schemas\PadraoNacional\1.01\schema_v101-ISSNet.xsd (5 ocorrências) Linha 1405: e101101 - Cancelamento de NFS-e; Linha 1415: <xsd:enumeration value="e101101"/> Linha 4670: <xsd:complexType name="TE101101"> Linha 4746: <xsd:element name="e101101" type="TE101101" minOccurs="1" maxOccurs="1"> \\10.10.1.27\aplicativos\SisPub\PMM\ABRASF\Schemas\PadraoNacional\1.01\tiposEventos_v1.01.xsd (4 ocorrências) Linha 130: <xs:element name="e101101" type="TE101101"> Linha 218: <xs:complexType name="TE101101"> Linha 730: e101101 - Cancelamento de NFS-e; \\10.10.1.27\aplicativos\SisPub\PMM\ABRASF\Schemas\PadraoNacional\1.01\tiposSimples_v1.01.xsd (1 ocorrências) Linha 1541: <xs:enumeration value="e101101"/> Pesquisa "nPedRegEvento" (9 ocorrências em 3 arquivos de 23 procurados) [Normal] Esses arquivos de esquemas eu baixei do repositório a poucas horas atrás. Se não estão atualizados, de onde devo pegar os esquemas, por favor? Obrigado.

Saudações a todos. Vi que existe outro tópico criado a respeito desse mesmo erro, e que foi finalizado. mas eu ainda estou tendo esse mesmo problema hoje, 18/03/2026. Eu estou com todos os meus schemas atualizados, para garantir isso, baixei hoje a última versão dos arquivos, lá no repositório (REV. 45384). Entretanto, continuo com esse mesmo erro. O XML gerado é esse abaixo: <?xml version="1.0" encoding="UTF-8"?> <pedRegEvento xmlns="http://www.sped.fazenda.gov.br/nfse" versao="1.01"> <infPedReg Id="PRE13026032204354908000154000000000009326035496899672101101"> <tpAmb>1</tpAmb> <verAplic>ACBrNFSeX-1.00</verAplic> <dhEvento>2026-03-18T10:03:08-04:00</dhEvento> <CNPJAutor>xxxxxxxxxxxxxxx</CNPJAutor> <chNFSe>13026032xxxxxxxxxxxxx6899672</chNFSe> <e101101> <xDesc>Cancelamento de NFS-e</xDesc> <cMotivo>1</cMotivo> <xMotivo>CLIENTE SOLICITOU A TROCA DA DATA DE COMPETENCIA DO SERVICO</xMotivo> </e101101> </infPedReg> </pedRegEvento> E a rejeição retornada pelo ambiente nacional foi essa: [2026-03-18 10:26I:20] ------------------------------ Versão OpenSSL OpenSSL 1.0.2r 26 Feb 2019 01.00.02.12F D:\Program Files (x86)\HK-Software\IBExpert\libeay32.dll D:\Program Files (x86)\HK-Software\IBExpert\ssleay32.dll ------------------------------ Requisição Ambiente : - Produção Cidade : Manaus/AM Provedor : PadraoNacional Versão: 1.01 Data/Hora: 18/03/2026 10:26:20 [2026-03-18 10:26I:20] Método Executado: Enviar Evento Parâmetros de Envio Chave NFSe : 130260xxxxxxxxxxxxxxxxxx326035496899672 Evento : Cancelamento de NFS-e [2026-03-18 10:26I:20] Parâmetros de Retorno Chave NFSe : Data : 30/12/1899 Tipo Evento : Cancelamento de NFS-e Num. Seq. Evento: 0 ID do Evento : Sucesso : False Sucesso Canc. : False Desc. Situação : Nome Arquivo : \\10.10.1.27\APLICATIVOS\SISPUB\PMM\ABRASF\ENVIOS\202603\Eventos\13026032204354xxxxxxxxxxx2101101-pedRegEvento.xml [2026-03-18 10:26I:20] [2026-03-18 10:26I:20] Erro(s): Código : X800 Mensagem: Erro de Validação: --> 1871 - Element '{http://www.sped.fazenda.gov.br/nfse}e101101': This element is not expected. Expected is ( {http://www.sped.fazenda.gov.br/nfse}nPedRegEvento ). Correção: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [2026-03-18 10:26I:20] ** NOTA FISCAL NÃO CANCELADA ** Os esquemas estão realmente atualizados? Ou isso é um problema no ambiente nacional? Alguém sabem me informar, por favor? Obrigado. Francis Lay L. Silva.

Juliomar, assim que eu terminei de responder a mensagem anterior, rodei o sistema novamente e tentei baixar as informações de uma nota fiscal qualquer, e funcionou sem erro algum. Então isso confirma o que eu desconfiava, era problema no ambiente nacional, alguma alteração que fizeram nele que deve ter causado incompatibilidade com o componente, porque o problema se resolveu sozinho, não instalei mais nada desde o dia em que abri esse ticket. Deve ter sido alguma má formação no XML de retorno do ambiente nacional, que fez com que o ACBr classificasse como aquela exceção. Voltou a funcionar então. Muito obrigado pela ajuda, pode finalizar esse ticket por gentileza. Grato.

Bom dia. Meu procedimento para atualizar a versão é sempre esse: Nunca instalo direto da pasta de download do SVN Após atualizar o SVN, eu apago a pasta antiga do componente, e copio os arquivos baixados para ela Rodo o instalador do ACBr, utilizando a opção de "Remover arquivos antigos do disco". Após o término da instalação, dou um Rebuild no projeto e faço o teste das rotinas Estou pensando em tentar capturar e ignorar essa exceção, e ver se consigo o acesso as outras propriedades do retorno. Ou baixar uma revisão bem mais antiga, para ver o que acontece. Grato.

Olá Juliomar. Não tenho alterações locais, eu NUNCA mecho nos fontes originais, justamente porque o volume de atualizações do componente é alto, e eu teria que ficar compatibilizando fontes o tempo inteiro. O problema começou a acontecer desde a época em que esse ticket foi aberto em outra thead: Desde lá, tenho baixado várias revisões, em busca da solução para esse problema, e aí pouco tempo depois percebemos esse problema. Começou com a transmissão de notas, dava erro no retorno, e não atualizava o status do documento na nossa base de dados. Quando tentávamos enviar novamente, vinha a mensagem de duplicidade de nota no ambiente nacional, então percebemos que elas eram autorizadas, mas os arquivos de retorno estavam apresentando problema. E desde então todos os retornos estão assim: autorização de notas, consultas, dowmload de DANFE, etc. Será que o ambiente nacional mudou alguma coisa na composição do xml de resposta deles, que está dando conflito com o ACBr, e causando o disparo dessa exceção? Também percebi que, no repositório do SVN, teve algumas correções nos arquivos retorno de outro provedor. Será que isso também não pode ter influenciado esse comportamento estranho? Uma alteração em alguma lib compartilhada entre os provedores? Atenciosamente, Francis Lay L. Silva.