Rejeição 906: histórico da N33-10 e verificações atuais do ICMS efetivo

A Rejeição 906 desta página está vinculada à N33-10, regra antiga de exigência das informações do ICMS efetivo. A NT 2018.005 eliminou essa linha e criou verificações separadas que reutilizam o código 906. A remoção de N33-10 não significa remoção dos campos nem desaparecimento de toda rejeição 906.

A condição histórica

O MOC 7.0, Anexo I, p. 113 conserva N33-10 rasurada e identifica sua remoção na NT 2018.005. Ela reunia CST 60 ou CSOSN 500, ide/indFinal=1 e ausência das informações do ICMS efetivo. A implementação era opcional, a critério da UF, para modelos 55/65.

N33 é um identificador do leiaute, não o nome de uma tag <N33>. As informações são representadas por campos como pRedBCEfet, vBCEfet, pICMSEfet e vICMSEfet, dentro do grupo de ICMS pertinente. Eles tratam, respectivamente, da redução da base efetiva, base efetiva, alíquota efetiva e valor efetivo. Não são os mesmos campos de ICMS-ST retido anteriormente.

A substituição documentada

A NT 2018.005 v1.52, pp. 4 e 22–23 registra a eliminação de N33-10 no histórico da versão 1.20 e mostra as verificações separadas:

Ambas têm implementação opcional a critério da UF. O histórico da versão 1.20 indica testes até 25/02/2019 e produção até 07/05/2019. A versão 1.30 registra adequação de prazos até 03/06/2019 e esclarecimentos: exceto para identificação do responsável técnico, AM, MS, PE, PR, SC e TO mantiveram 07/05/2019; AL aparece retirada dessa lista e tem ajuste próprio no histórico. Esses calendários de versões não demonstram ativação universal das regras opcionais nem substituem a confirmação do autorizador atual.

Na mesma tabela, N12-81 e N12a-50 tratam de informações de retenção anterior em operações que não são para consumidor final e usam 938. Não se deve preencher campos de retenção anterior como se fossem os quatro campos de ICMS efetivo pedidos por 906.

Exemplo: código preservado, explicação desatualizada

Uma aplicação associa qualquer retorno 906 a N33-10 e mostra que a regra foi removida. O XML atual, entretanto, contém CSOSN 500, indFinal=1 e não informa os campos de ICMS efetivo. O diagnóstico precisa considerar N12a-60 e a ativação da UF. A remoção da regra antiga, sozinha, não invalida o retorno atual.

Em outro cenário, o cálculo existe na aplicação, mas o gerador envia somente a base efetiva e omite os demais campos da sequência. Compare os quatro valores na memória do cálculo e no XML do mesmo item. Estar preenchido na tela não demonstra que o conjunto foi transmitido. Ausência e zero explícito também são diferentes: não preencha zeros para representar dados que ainda não foram determinados.

Os exemplos são textuais porque não se escolhem CST, CSOSN, redução ou alíquota para o leitor. A representação e os valores dependem do tratamento fiscal confirmado e dos documentos reais; não há XML operacional ou cálculo tributário universal.

Como verificar uma correção

Preserve envio e retorno, identifique modelo, ambiente, UF e item. Confira CST ou CSOSN, indFinal e a presença dos campos no grupo efetivamente usado. Confirme a regra ativa e rastreie omissões no cálculo, no mapeamento ou na serialização. Corrija a origem comprovada sem mudar a classificação da operação para afastar a exigência.

O responsável fiscal deve confirmar a aplicabilidade e os parâmetros dos valores; o emissor deve então representá-los coerentemente. Não edite XML assinado nem documentos autorizados. Esclareça tentativa de resultado incerto antes de retransmitir.