Maxuel.Santana

Boa tarde.

Favor avaliar correção
 
ACBrDFe.Conversao.pas

Arquivo: Fontes\ACBrDFe\ACBrNFe\Base\ACBrNFe.XmlWriter.pas
Função: TNFeXmlWriter.GerarDetImposto
Referência: NT 2025.002 v1.40 (RTC - IBS/CBS/IS), regra de validação B25-80 / Rejeição 1001
Descrição do problema
A regra B25-80 da NT 2025.002 estabelece que, quando finNFe = crédito/débito ou tpOperGov = 2-Recebimento do pagamento, o item da NF-e não deve informar os tributos "antigos" (ICMS, ISSQN, IPI, II, PIS, PISST, COFINS, COFINSST, ICMSUFDest, impostoDevol) — exceto em algumas situações específicas previstas na própria NT:
tpNFCredito = 03 (Retorno por Recusa Total/Não Localização do Destinatário) tpNFCredito = 04 (Redução de valores) tpNFCredito = 06 (Retorno por recusa parcial na entrega) tpNFDebito = 07 (Perda em estoque) A implementação atual em GerarDetImposto só tratava a exceção tpNFCredito = 03 (constante tcRetorno) e não considerava nenhuma exceção para tpNFDebito. Isso fazia com que, em uma NF-e de débito por perda em estoque (tpNFDebito = 07), o item perdesse todo o detalhamento de ICMS/PIS/COFINS, enquanto o ICMSTot continuava trazendo os totais — gerando um XML inconsistente (totais sem o detalhamento correspondente no item).
Correção proposta
Ampliar a condição para incluir as demais exceções de tpNFCredito (04 e 06) e a exceção de tpNFDebito (07):
  if ((not (nfe.Ide.finNFe in [fnCredito, fnDebito]) and (nfe.Ide.gCompraGov.tpOperGov <> togRecebimentoPag)) or (nfe.Ide.tpNFCredito in [tcRetorno, tcReducaoValores, tcRetornoRecusaParcial]) or (nfe.Ide.tpNFDebito = tdPerdaEmEstoque)) then begin // ... geração do detalhamento de imposto do item (inalterado) end;   Observação: há um ponto correlato no mesmo arquivo, em Gerar_IBSCBS_gEstornoCred, que já tratava tpNFDebito = tdPerdaEmEstoque para o estorno de crédito do IBS/CBS — usei como referência de consistência para esta correção.


ACBrNFe.XmlWriter.pas

Em função de o Ambiente Nacional estar apresentando erro não catalogado no dia de hoje, não foi possível emitir notas para validar a alteração proposta.
A intenção, neste momento, é apenas compartilhar a ideia com a comunidade e avaliar se a abordagem faz sentido, não sendo ainda o momento de submeter a alteração.
Segue sugestão de correção para tratamento do erro: Durante um atendimento de chamado aqui na empresa, nos deparamos com um cliente emitindo NFSe para um tomador no exterior com CodPaisIBGE 1508 – JERSEY, ILHA DO CANAL.
Na análise do caso, foi identificado que esse código IBGE não estava retornando a respectiva sigla ISO2 (JE), o que ocasionava a rejeição pelo Ambiente Nacional. A partir desse ponto, foi realizada uma verificação mais ampla do relacionamento entre os códigos IBGE e ISO2. Durante essa análise, constatou-se que alguns códigos não existem na tabela de Países IBGE que utilizamos (base consolidada do EFD Contribuições), apesar de o array SiglaISO2Pais trazer uma equivalência ISO2. Os códigos identificados foram: 200, 420, 990, 1023, 2925, 3212, 3433, 3930, 4898, 6939, 7552, 7811, 8753. Para tratar esses cenários de forma mais explícita e previsível, a lógica de obtenção da sigla ISO2 passou a ser feita de forma controlada, em uma única estrutura.
Na implementação anterior, o relacionamento era feito com base em dois arrays distintos; com a solução proposta, o mapeamento IBGE × ISO2 fica centralizado em um único array, com o auxílio de um record, tornando a leitura, a manutenção e a validação dos códigos mais facil e centralizada. O comportamento atual foi preservado, e a nova abordagem está protegida por uma diretiva de compilação (USAR_MATRIZ_TPAIS) dentro do método
ACBrNFSeXConversao.CodIBGEPaisToSiglaISO2, permitindo a avaliação da mudança sem impacto imediato para quem não optar por utilizá-la.
  Fontes/ACBrDFe/ACBrNFSeX/Base/ACBrNFSeXConversao.pas  - modified Fontes/ACBrDFe/ACBrNFSeX/Base/PaisesIBGEISO.pas - added
    acbr_pais_ibge_iso.zip