Pesquisar na Comunidade

## Descrição (corpo do post) **Versão ACBr**: trunk2 r45813 em diante (testado também na r45929 de 23/04/2026) **Componente**: ACBrNFe — `ACBrNFe.XmlWriter.pas` **Sintoma**: toda NFe (modelo 55) com produto CST=90 é gerada com a tag `<cBenefRBC></cBenefRBC>` vazia, causando rejeição da SEFAZ por falha de schema. --- ### Mensagem da rejeição (cliente real, SEFAZ-CE, 24/04/2026) ``` Falha na validação dos dados da nota: 17784 TAG:%TAGNIVEL% ID:N14a/cBenefRBC(Código de Benefício Fiscal na UF aplicado ao item quando houver RBC.) - Nenhum valor informado. (×N itens) 1871 - Element {http://www.portalfiscal.inf.br/nfe}cBenefRBC: This element is not expected. Expected is one of ({http://www.portalfiscal.inf.br/nfe}pRedBC, {http://www.portalfiscal.inf.br/nfe}pICMS). ``` A primeira mensagem é o `wAlerta` interno do próprio `TACBrXmlWriter.AddNode` (linha 422 do `ACBrXmlWriter.pas`); a segunda (1871) é o validador XSD da SEFAZ rejeitando a tag vazia injetada no XML. --- ### Causa raiz A revisão **r45813** (16/04/2026 — commit `ACBR-9067 — Alterações visando atender a NT 2022/002 versão 1.30a`) acrescentou a geração de `cBenefRBC` no bloco `cst90, cstPart90` do `GerarDetImpostoICMS`, mas com parâmetros incorretos: **`ACBrNFe.XmlWriter.pas` linhas 2572-2573 (estado atual)**: ```pascal xmlNode.AppendChild(AddNode(tcStr, 'N14a', 'cBenefRBC', 01, 01, 1, NFe.Det[i].Imposto.ICMS.cBenefRBC, DSC_CBENEFRBC)); ``` São 2 erros: 1. **Tamanho `01,01`** — a NT 2022.002 v1.30a (página 8, item 237.01) define o campo como tipo `C` com tamanho `8,10` e o XSD oficial `leiauteNFe_v4.00.xsd` declara o pattern `[!-ÿ]{8}|[!-ÿ]{10}`. 2. **Ocorrência mínima `1`** — a NT define ocorrência **`0-1`** (opcional). Combinada com valor vazio (clientes que não têm benefício fiscal cadastrado), o `TACBrXmlWriter.AddNode` (linhas 441-445) gera `<cBenefRBC></cBenefRBC>` E adiciona alerta "Nenhum valor informado". Para comparação, o bloco `cst51` (linha 2352) está **correto** e usa exatamente os parâmetros que a NT especifica: ```pascal xmlNode.AppendChild(AddNode(tcStr, 'N14a', 'cBenefRBC', 8, 10, 0, NFe.Det[i].Imposto.ICMS.cBenefRBC, DSC_CBENEFRBC)); ``` --- ### Trecho oficial da NT 2022.002 v1.30a (Grupo N10 — ICMS=90) | # | ID | Campo | Descrição | Ele | Pai | Tipo | Ocor. | Tam. | |------------|----------|---------------|--------------------------------------------------------------------------|-------|-----------|-------|---------|---------| | 237 | N14 | pRedBC | Percentual da Redução de BC | E | N12.1 | N | 0-1 | 3v2-4 | | **237.01** | **N14a** | **cBenefRBC** | **Código de Benefício Fiscal na UF aplicado ao item quando houver RBC.** | **E** | **N12.1** | **C** | **0-1** | **8,10**| | 238 | N16 | pICMS | Alíquota do imposto | E | N12.1 | N | 1-1 | 3v2-4 | Fonte: [NT 2022.002 v1.30a publicada 26/03/2026](https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=NpWPjigODyU=) — pg 8. --- ### Patch proposto ```diff --- a/Fontes/ACBrDFe/ACBrNFe/Base/ACBrNFe.XmlWriter.pas +++ b/Fontes/ACBrDFe/ACBrNFe/Base/ACBrNFe.XmlWriter.pas @@ -2572,2 +2572,2 @@ - xmlNode.AppendChild(AddNode(tcStr, 'N14a', 'cBenefRBC', - 01, 01, 1, NFe.Det[i].Imposto.ICMS.cBenefRBC, DSC_CBENEFRBC)); + xmlNode.AppendChild(AddNode(tcStr, 'N14a', 'cBenefRBC', + 8, 10, 0, NFe.Det[i].Imposto.ICMS.cBenefRBC, DSC_CBENEFRBC)); ``` Com `ocorrencias=0` e valor vazio, o `AddNode` omite a tag (linhas 441-448 do `ACBrXmlWriter.pas`) — exatamente o que `cst51` já faz. Para clientes que populam o campo, a tag é gerada com tamanho válido (8 ou 10 chars). --- ### Possível bug adicional na ordem dos elementos do ICMS90 Conforme a NT v1.30a, dentro do grupo `N12.1` a sequência correta é: ``` modBC (N13) → vBC (N15) → pRedBC (N14) → cBenefRBC (N14a) → pICMS (N16) → [grupo opcional N16a: vICMSOp (N16b), pDif (N16c), vICMSDif (N16d)] → vICMS (N17) ``` Mas o `XmlWriter` linhas 2563-2589 está gerando: ``` modBC → vBC → pRedBC → cBenefRBC → vICMSOp → pDif → vICMSDif → pICMS → vICMS ``` `vICMSOp/pDif/vICMSDif` aparecem **antes** de `pICMS` em vez de **depois** (e fora do grupo opcional `N16a`). Para UFs onde `NrOcorr=0` (CE, MG etc.), os campos zerados são omitidos e o problema não aparece. Mas para RJ/SP/PR (`NrOcorr=1`, linhas 2557-2559), as tags zeradas seriam emitidas em ordem inválida — provavelmente causando outra rejeição de schema. --- ### Como reproduzir 1. Cliente CRT=3, qualquer UF. 2. Cadastrar produto com `cstICMS='090'`, `pICMS=20`, `codCFOP='5403'` (ou 5405). 3. Emitir NFe modelo 55. O XML gerado contém `<cBenefRBC></cBenefRBC>` vazio entre `<pRedBC>` (omitido) e `<vICMSOp>`. 4. SEFAZ rejeita com erro 1871. --- ### Histórico relacionado no log de mudanças ``` r45813 | italojjr | 16/04/2026 -- ACBrNFe.XmlWriter -- [*] ACBR-9067 - Alterações visando atender a NT 2022/002 versão 1.30a Por: Italo Giurizzato Junior ``` Obrigado.