André Ferreira de Moraes

Sim, desde o início da semana ativaram essa validação.

Segue um resumo das alterações que testei para restaurar o preenchimento do %TAGNIVEL% no novo XmlWriter. Na versão antiga baseada no PCN/Gerador, o formato abaixo exibia corretamente o nível da tag: Configuracoes.Geral.FormatoAlerta := 'TAG:%TAGNIVEL% ID:%ID%/%TAG%(%DESCRICAO%) - %MSG%.'; Com a nova geração via ACBrXmlWriter, o %TAGNIVEL% não era mais preenchido. A solução implementada foi reconstruir o nível da tag a partir do próprio nó XML, usando a árvore já montada pela libxml2. Para isso, foram feitos estes ajustes principais: ACBrXmlDocument.pas Foi adicionada a propriedade TagNivel em TACBrXmlNode, montando o caminho da tag a partir dos nós parent da libxml2. Também foi incluída a montagem dos atributos no nível da tag, preservando casos como: <det nItem="1"> <infNFe Id="..." versao="4.00"> Exemplo de saída: TAG:<det nItem="1"><prod><NCM> ID:I05/NCM(Código NCM) - Nenhum valor informado. Foi adicionada também a propriedade IgnorarTagNivel no TACBrXmlDocument, permitindo ignorar tags no nível, comportamento semelhante ao antigo: FDocument.IgnorarTagNivel := '|NFe|infNFe|obsCont|obsFisco|'; A comparação é feita pelo início da tag, permitindo ignorar corretamente: <NFe> <infNFe Id="..." versao="4.00"> sem depender da ordem dos atributos. ACBrXmlWriter.pas Foi centralizada a formatação do alerta em FormatarAlerta, voltando a substituir: %TAGNIVEL% %TAG% %ID% %MSG% %DESCRICAO% Também foi criado um mecanismo de alertas pendentes. A ideia é registrar o alerta com o nó XML correspondente e formatar a mensagem apenas no final da geração, quando o nó já está anexado na árvore e o TagNivel pode ser calculado corretamente. Foi criado um overload de wAlerta: procedure wAlerta(ANode: TACBrXmlNode; const ID, TAG, Descricao, Alerta: string; ADoException: Boolean = False); overload; O método original continua existindo: procedure wAlerta(const ID, TAG, Descricao, Alerta: string; ADoException: Boolean = False); overload; Para manter compatibilidade com os pontos já existentes, o AddNode registra internamente a relação: ID/TAG -> TACBrXmlNode Assim, chamadas manuais já existentes como esta continuam funcionando: Result.AppendChild(AddNode(tcStr, 'I03', 'cEAN', 00, 14, 1, NFe.Det[i].Prod.cEAN, DSC_CEAN)); if ErroValidarGTIN <> '' then wAlerta('I03', 'cEAN', DSC_CEAN, ErroValidarGTIN); O wAlerta localiza o nó registrado pelo AddNode e consegue preencher o %TAGNIVEL%. ACBrNFe.XmlWriter.pas No construtor do TNFeXmlWriter, foi configurado o filtro de tags ignoradas: FDocument.IgnorarTagNivel := '|NFe|infNFe|obsCont|obsFisco|'; No início da geração, foi trocado o ListaDeAlertas.Clear por LimparAlertas, para limpar também alertas pendentes e o mapa interno de nós. No final do GerarXml, foi chamada a rotina: FinalizarAlertasPendentes; Isso garante que os alertas sejam formatados depois que o XML já estiver montado. Validação com exceção opcional Também foi adicionada a opção ExceptionValidacao, com padrão False, para preservar o comportamento atual. Quando False, o comportamento segue como alerta normal. Quando True, algumas validações podem lançar exceção usando o próprio alerta formatado, por exemplo em casos como CNPJ/CPF inválido, município inválido, UF inválida etc. A configuração foi adicionada em TGeralConfNFe e repassada para o TNFeXmlWriterOptions. Exemplo: Configuracoes.Geral.ExceptionValidacao := True; Com isso, é possível escolher se inconsistências de validação devem apenas entrar na lista de alertas ou interromper a geração. Resultado dos testes Com NCM vazio em item, o alerta passou a sair assim: TAG:<det nItem="1"><prod><NCM> ID:I05/NCM(Código NCM) - Nenhum valor informado. Com GTIN inválido em cEAN, o alerta também passou a preencher o nível corretamente: TAG:<det nItem="1"><prod><cEAN> ID:I03/cEAN(Código de Barra do Item) - Código GTIN inválido E com CNPJ inválido, o alerta é registrado corretamente. Se ExceptionValidacao=True, a validação pode interromper a geração lançando exceção TAG:<CNPJ> ID:E02/CNPJ(CNPJ) - Conteúdo inválido.. O objetivo foi restaurar o comportamento do %TAGNIVEL% sem alterar a estrutura do XML gerado. ACBrDFe_tag_nivel.zip

Vc está chamando adicionando várias notas o que faz com que XMLs sem conteúdo preenchido sejam gerados. Verifique onde cria as notas(por exemplo ACBrNFe1.NotasFiscais.Add) e evite chamadas duplicadas.

Existem códigos específicos para Remessa. https://medium.com/@andrefmoraes/prevenindo-a-rejeição-930-o-guia-prático-do-cbenef-em-são-paulo-72e758ae3998

Vc pode usar https://dfe-portal.svrs.rs.gov.br/NFE/ValidadorNfe

Teste com esse cabeçalho: <?xml version="1.0" encoding="UTF-8"?><soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"><soap12:Body><nfeDadosMsg xmlns="http://www.portalfiscal.inf.br/nfe/wsdl/NFeAutorizacao4"><enviNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"><idLote>21</idLote><indSinc>1</indSinc><NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe Id="NFe31260650693323000186650010000000211000000010" versao="4.00">

Pode ser que tenha mudado na última versão, a API disponível em https://calculadora.djsystem.com.br/api/ está na versão 1.1.0 Disponibilizei um exemplo em Lazarus para testar a calculadora - https://medium.com/@andrefmoraes/calculadorartc-biblioteca-open-source-para-a-calculadora-da-reforma-tributária-cbs-ibs-is-0560a67c110f

Faça um teste usando o endereço https://calculadora.djsystem.com.br/api

O problema ocorre só em um cliente? Os relatos do tópico inicial é q o erro ocorria apenas em ambiente de homologação, no seu caso ocorre em produção tbm?

O erro está ocorrendo na transmissão, então não tem como só parte das notas serem autorizadas. Se isso está ocorrendo é pq o erro 12030 está dentro do exception controlado e depois é exibido o erro real. Qual a mensagem que aparece em modo release do seu sistema?

@SIG 2000 Informática Ltda. o erro está acontecendo em modo release ou é apenas um exception controlado que ocorre em modo debug? O problema ocorre justamente no Send, mas vou testar e te retorno.

Se tá pulando linha no debug é pq os fontes não foram recompilados.

Este erro "The page was not displayed because the request entity is too large" pode indicar que o servidor está recusando a requisição devido o tamanho. Teste com um número menor de notas pra ver se acontece o mesmo erro. Vc tbm pode tentar debugar no arquivo ACBrWinReqRespClass.pas a procedure TACBrWinReqResp.Execute para ver exatamente em qual momento o erro ocorre.

Qual a mensagem exata de erro? E quais os passos para reproduzir usando o demo?

Para WinCrypt, faça um teste substituindo esse arquivo na pasta ACBr\trunk2\Fontes\ACBrTCP e recompilado o pacote ACBrTCP. ACBrWinReqRespClass.pas

Teste substituindo os arquivos compartilhados nesse post: https://www.projetoacbr.com.br/forum/topic/92383-erro-ao-enviar-nfe-para-sefazrs-hom-network-subsystem-is-unusable/page/2/?&_rid=3#findComment-603868

Testou com OpenSSL substituindo os arquivos que coloquei nesse post? Ao substituir os arquivos é necessário recompilar a Synapse.

Na minha máquina com Lazarus 3.2 acontece na primeira chamada tanto com OpenSSL quanto com WinCrypt. Debugando a OpenSSL o erro é "10054-Connection reset by peer" que depois é sobrescrito pelo "10091-Network subsystem is unusable". Com WinCrypt o erro é: "12030 - A conexão com o servidor foi redefinida ou encerrada, ou um protocolo SSL incompatível foi encontrado". Em ambos os casos, se aguardar 60 segundos para fazer uma nova requisição o erro volta a ocorrer, se fizer chamadas seguidas o erro não ocorre. Com a dica para utilizar o winget upgrade acredito que o problema pode estar nas dlls vcruntime140.dll e msvcp140.dll. Segue os arquivos que alterei da synapse para conseguir ver o erro real: blcksock.passsl_openssl.pas Adicionei também o httpsend para tentar fazer o retry igual sugerido anteriormente mas apenas se for o erro 10054: httpsend.pas

Isso me parece alucinação de IA, não existe essa propriedade no componente nem na documentação - https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=P0U3lU1Fe40=

Os schemas ainda não aceitam esses novos tipos - https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=BMPFMBoln3w= - a última versão de 26/03/2026 só permite até o tipo 08.

Ainda não foi publicado os schemas atualizados - https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=BMPFMBoln3w= - a última versão de 26/03/2026 só permite números.

O Ajuste SINIEF 12/2025 que no inciso I da cláusula primeira previa o endereço como opcional para NF-e foi revogado pelo Ajuste SINIEF 13/2026, então, para NF-e continua obrigatório informar o endereço, caso queira informar apenas o CNPJ deve usar NFC-e. AJUSTE SINIEF 12/25 — Conselho Nacional de Política Fazendária CONFAZ AJUSTE SINIEF 13/26 — Conselho Nacional de Política Fazendária CONFAZ

Foi revogado o Ajuste SINIEF 11/2026 que obrigava a emissão de NFe para CNPJ - https://medium.com/@andrefmoraes/reforma-tributária-o-recalcular-da-rota-e-o-retorno-da-nfc-e-para-cnpj-95e0e729f103

Ainda não saiu nenhuma publicação.