Rejeição 390: grupo de devolução de tributos no documento inadequado

A rejeição 390 indica que o documento contém o grupo de devolução de tributos em um contexto que não o admite. A orientação tradicional trata da NFC-e modelo 65, mas o alcance documental foi ampliado: a NT 2026.002 v1.11 também inclui NF-e modelo 55 com DANFE Simplificado Tipo 2, identificado por tpImp=6.

Por isso, não basta olhar o número do modelo nem apagar um valor para tentar autorizar. É necessário descobrir se existe uma devolução real, se o grupo foi gerado indevidamente e se a forma de emissão corresponde à operação. O tratamento correto deve preservar os tributos e a movimentação efetivamente realizada.

O que a regra 390 examina

UA01-20, na NT 2026.002 v1.11, página 18, relaciona a presença de impostoDevol a duas situações: NFC-e e NF-e com DANFE Simplificado Tipo 2. A linha é marcada como obrigatória e retorna 390, com indicação do item.

O MOC 7.0, página 120, mostrava essa mesma regra somente para o modelo 65. Assim, um manual de software baseado apenas nessa versão pode apresentar um diagnóstico incompleto para emissões com tpImp=6.

Não é uma proibição geral de impostoDevol em toda NF-e modelo 55. Fora do contexto do DANFE Simplificado Tipo 2, existem outras condições de finalidade e preenchimento que precisam ser examinadas, inclusive a rejeição 354. O código numérico deve ser lido junto com xMotivo, modelo e campos do XML.

Onde o grupo aparece no arquivo

impostoDevol pertence ao item, dentro de det. Na estrutura do MOC, página 57, aparecem pDevol, que informa o percentual da mercadoria devolvida, e o subgrupo IPI com vIPIDevol, o valor do IPI devolvido.

Esse caminho é diferente do IPI normal em det/imposto/IPI. Também é diferente do campo de totalização do IPI devolvido. Excluir ou zerar somente o total não elimina necessariamente o grupo presente nos itens. Do mesmo modo, zerar vIPIDevol mantendo impostoDevol não enfrenta uma regra que verifica a existência do grupo.

O nItem do retorno indica onde começar, mas convém verificar todos os produtos. Uma configuração compartilhada pode inserir impostoDevol em cada linha, fazendo a rejeição reaparecer em outro item depois da primeira correção.

Venda comum e devolução real exigem decisões diferentes

Se a empresa está realizando uma venda comum e o ERP herdou campos de uma operação de devolução, a área fiscal deve confirmar que impostoDevol é indevido. Nesse caso, corrija a origem do preenchimento e gere o documento sem o grupo impróprio, revisando os totais afetados.

A situação muda quando há efetivamente uma devolução e o sistema tenta registrá-la pelo mesmo fluxo do cupom de venda. Não apague o imposto devolvido necessário apenas para manter esse fluxo. A operação precisa ser documentada pelo procedimento fiscal cabível, com finalidade, referências, valores e identificação corretos.

A escolha da NF-e adequada não se resume a trocar mod=65 por mod=55. A NF-e com tpImp=6 também está no alcance de 390. Nem deve ser recomendada uma simples mudança de impressão como solução universal: o responsável fiscal e o sistema precisam assegurar que todo o documento represente corretamente a operação.

Como organizar a correção

1. Guarde o XML transmitido e o retorno completo da autorização, incluindo nItem

2. Confira mod, tpImp, finNFe, UF e ambiente; confirme se há outro tipo de finalidade ou crédito envolvido

3. Localize todas as ocorrências de impostoDevol, pDevol e IPI/vIPIDevol nos itens

4. Compare os campos com o documento original, as quantidades efetivamente devolvidas e o motivo da movimentação

5. Se o grupo for indevido, corrija sua geração; se a devolução for real, revise o fluxo documental sem omitir informação tributária necessária

6. Reavalie os totais, gere novamente o XML e confira o resultado da transmissão antes de liberar o documento

Faça a alteração na regra que originou o preenchimento, quando possível. Uma correção manual isolada pode resolver uma tentativa e deixar o problema reaparecer na próxima venda. Já uma alteração global sem teste pode retirar o grupo de operações de devolução nas quais ele era necessário.

Qual é a diferença para 354 e 742

354 está associada a UA01-10, que examina a presença do grupo de tributos devolvidos em uma NF-e cuja finalidade não corresponde à devolução prevista na validação. Já 390, em UA01-20, trata dos contextos de NFC-e e NF-e com DANFE Simplificado Tipo 2. Uma regra não deve ser usada como substituta da outra.

Nos cenários de retorno e notas de crédito da RTC, existem classificações e exceções próprias. Elas não devem ser transportadas automaticamente para UA01-20 ou UA01-10. Em uma ocorrência que envolva essas finalidades, reúna o retorno e confirme o tratamento específico, sem transformar todo retorno em devolução por tentativa.

742 envolve o grupo normal de tributação pelo IPI. Encontrar a palavra IPI no arquivo não basta para decidir entre 742 e 390: é necessário identificar se ela está em imposto/IPI ou em impostoDevol/IPI. Alterar o grupo errado pode manter a rejeição e ainda comprometer o cálculo correto.

UF, CRT e calendário documental

UA01-20 não apresenta dispensa expressa para uma UF, para optantes pelo Simples ou para MEI com CRT=4. Portanto, não existe na linha examinada um fundamento para alterar o regime do emitente ou a identidade do destinatário como solução.

O cronograma da NT 2026.002 v1.11, página 3, inclui UA01-20 no bloco de atualização para DANFE Simplificado Tipo 2, com testes em 01/07/2026 e produção em 03/08/2026. O adiamento para 14/12/2026 menciona I08-180, BA02-35 e VC02-40. Ele não adia automaticamente 390 nem altera a cronologia de UA01-10, ligada a 354.

Essas datas são evidência documental. Não substituem a confirmação do ambiente efetivamente utilizado pela empresa nem um comunicado específico do autorizador. Quando o retorno divergir do comportamento esperado, encaminhe ao suporte o modelo, tpImp, finalidade, UF, ambiente e XML correspondente.

Base e fontes práticas

A conferência de 10/10/2026 utilizou o MOC e a NT 2026.002 v1.11 preservados em 09/10/2026, com inspeção das páginas da regra e do cronograma. Não houve comprovação individual de implantação em todos os autorizadores.

Também foram lidas as orientações da Oobj, da TecnoSpeed e da Berga. Elas ajudam a localizar cadastros e fluxos que inserem o grupo, mas suas explicações centradas na NFC-e não esgotam a ampliação oficial para o modelo 55 com tpImp=6.