Rejeição 321 Protheus: como corrigir

Introdução

A Rejeição 321: devolução sem documento referenciado por item faz parte do conjunto de validações da Reforma Tributária tratadas oficialmente pela TOTVS para NF-e no Protheus. A melhor forma de resolver esse tipo de rejeição não é editar o XML nem alterar campos no banco: primeiro é preciso identificar se a causa está em classificação tributária, regra do CFGTRIB, cálculo, escrituração, versão do Protheus/TSS ou regra de validação da SEFAZ.

Este artigo consolida a orientação publicada pela TOTVS e a transforma em um procedimento de diagnóstico e homologação.

Ambiente documentado

Todas as versões, com pacotes por release

A aplicabilidade da solução precisa ser conferida na release e nos pacotes realmente instalados.

Causa documentada pela TOTVS

NF-e com finalidade de devolução (finNFe=4) sem a referência exigida. A regra nova passa a utilizar DFeReferenciado/chaveAcesso no item; o artigo informa produção a partir de 01/09/2026.

Os principais elementos técnicos envolvidos são: finNFe=4, DFeReferenciado, chaveAcesso, NFref, refNFe.

Solução indicada

Aplicar os pacotes indicados pela TOTVS e garantir a geração da chave da nota de origem no grupo DFeReferenciado. O artigo alerta que a referência tradicional em refNFe fica proibida para esse caso.

A orientação deve ser executada primeiro em homologação. Em temas que exigem percentual, CST ou cClassTrib, o valor precisa ser definido pela área Fiscal. Em temas de patch/schema/fonte, use somente o pacote correspondente à release.

Exemplo técnico de homologação

Em uma devolução de dois itens provenientes de notas diferentes, cada item deve manter a rastreabilidade da chave de origem no grupo previsto pelo leiaute. O teste deve conferir a chave no XML item a item.

O objetivo do exemplo é reproduzir o comportamento documentado pela TOTVS. Ele não deve ser transformado em customização permanente sem validar o padrão da release.

Método de diagnóstico no Protheus

Use esta sequência antes de alterar qualquer configuração:

guarde o XML rejeitado e o retorno completo da SEFAZ;
identifique o item (nItem) apontado na rejeição;
confirme a release do Protheus e a versão do TSS;
verifique se os pacotes da Reforma Tributária estão aplicados;
revise CST e cClassTrib quando participarem da regra;
confirme a Regra de Cálculo, Regra de Alíquota e Regra de Escrituração pertinentes;
confira o valor ou grupo gerado internamente;
abra o XML e compare as tags com a memória de cálculo;
gere novo documento em homologação;
execute um cenário negativo para comprovar que a correção não ficou ampla demais.

Onde procurar a causa

Uma rejeição da NF-e pode aparecer no final do fluxo, embora a origem esteja várias etapas antes:


Cadastro / Classificação

        ↓

Perfis do CFGTRIB

        ↓

Regra de Cálculo

        ↓

Base / Alíquota

        ↓

Regra de Escrituração

        ↓

CJ3 / F2D quando aplicável

        ↓

Geração do XML

        ↓

TSS

        ↓

SEFAZ

Esse modelo ajuda a evitar o erro de corrigir apenas a última camada.

Validação do XML

Não valide somente a mensagem retornada. Compare:

CST;
cClassTrib;
grupo exigido ou proibido;
base;
alíquota nominal;
redução/diferimento, quando houver;
alíquota efetiva;
valor do tributo;
referências de documentos, quando houver;
datas e tipos de nota;
totais da NF-e.

Para rejeições de schema ou geração de tag, compare também a versão dos schemas do TSS e a atualização do fonte padrão.

Atualização versus parametrização

Este ponto é crítico. Algumas rejeições são resolvidas pela configuração fiscal; outras exigem patch, dicionário, fonte ou TSS atualizado.

Não tente compensar uma falha de produto alterando classificação. Da mesma forma, não aplique patch para esconder uma Regra de Escrituração incorreta.

Use esta regra:


Erro de enquadramento → revisar cadastro/regra

Erro matemático → revisar base/alíquota/fórmula

Erro de grupo/tag → revisar classificação + atualização

Erro de schema → revisar TSS/schema/fonte

Erro de geração já corrigido pela TOTVS → aplicar pacote oficial

Checklist antes de retransmitir

[ ] XML rejeitado arquivado;
[ ] retorno da SEFAZ arquivado;
[ ] item rejeitado identificado;
[ ] release confirmada;
[ ] TSS confirmado;
[ ] pacotes oficiais conferidos;
[ ] CST validado;
[ ] cClassTrib validado;
[ ] regra do CFGTRIB revisada;
[ ] cálculo manual conferido quando aplicável;
[ ] tags comparadas;
[ ] novo documento gerado em homologação;
[ ] cenário de regressão executado.

O que não fazer

Não faça UPDATE direto em CJ3, F2D, F2B ou tabelas fiscais para “corrigir” uma nota rejeitada. Não manipule o XML depois de gerado para forçar autorização. Não copie cClassTrib, CST, alíquota ou percentual de um exemplo para uma operação diferente.

Essas práticas removem rastreabilidade e podem criar divergência entre documento, escrituração e apuração.

Quando abrir chamado na TOTVS

Abra chamado quando:

a configuração estiver coerente com a documentação;
os pacotes da release estiverem aplicados;
o XML continuar diferente do comportamento esperado;
o campo interno não receber o valor calculado;
o erro ocorrer de forma intermitente;
houver divergência entre ambiente atualizado e artigo oficial.

Envie, no mínimo:


XML rejeitado

retorno da SEFAZ

release

build/RPO

versão do TSS

pacotes aplicados

print da regra

CST/cClassTrib

ERROR.LOG, se houver

documento de comparação autorizado

Governança

Rejeições da Reforma Tributária devem alimentar uma base de conhecimento interna. Para cada ocorrência, registre causa, correção, release, fonte TOTVS, cenário de teste e data da última validação.

Isso evita que a equipe reaplique uma solução antiga depois de nova versão da NT ou do Protheus.

Conclusão

A Rejeição 321: devolução sem documento referenciado por item deve ser tratada como sinal de inconsistência entre regra fiscal, configuração do ERP e regra técnica do documento eletrônico.

A solução publicada pela TOTVS para este cenário é: Aplicar os pacotes indicados pela TOTVS e garantir a geração da chave da nota de origem no grupo DFeReferenciado. O artigo alerta que a referência tradicional em refNFe fica proibida para esse caso.

O procedimento mais seguro é corrigir a origem, homologar, comparar XML e somente então retransmitir.

Conteúdo técnico baseado na Central de Atendimento TOTVS. Tratamentos fiscais, percentuais, CST e cClassTrib devem ser confirmados pela área Fiscal/Contábil responsável.

Teste de regressão recomendado

Depois de corrigir a rejeição, não valide apenas a nota que falhou. Crie um pequeno pacote de regressão com pelo menos três documentos:

uma operação que deve utilizar a mesma regra;
uma operação semelhante que não deve utilizar a mesma classificação/grupo;
uma operação de outra filial, UF, participante ou produto quando isso fizer sentido.

Compare em todos eles:

regra selecionada;
CST;
cClassTrib;
base;
alíquota;
redução ou diferimento;
valor;
escrituração;
XML;
retorno do autorizador.

Esse teste é particularmente importante quando a correção alterou uma Regra de Escrituração ou Regra de Alíquota compartilhada por vários cenários.

Como separar configuração de atualização

Uma prática que reduz muito o tempo de suporte é classificar a rejeição antes de mexer no ambiente.

Indícios de problema de configuração

CST ou cClassTrib não correspondem à operação;
percentual de redução/diferimento ausente;
regra correta não enquadra;
grupo obrigatório não é produzido porque a regra está incompleta;
valor calculado diverge da memória manual.

Indícios de problema de atualização

a TOTVS publica fonte, patch ou pacote específico para a rejeição;
XML não gera tag mesmo com cálculo correto no Protheus;
schema do TSS rejeita elemento recentemente criado;
comportamento muda após atualização de Nota Técnica;
a Central indica versão mínima do fonte nfesefaz, RPO ou dicionário.

A correção deve seguir a categoria certa. Alterar regra fiscal para contornar fonte desatualizado cria dívida técnica; aplicar patch para compensar cClassTrib incorreto não resolve a causa funcional.

Auditoria de evidências

Monte uma pasta de evidências contendo:


01_xml_rejeitado.xml

02_retorno_sefaz.txt

03_print_cfgtrib.png

04_memoria_calculo.xlsx

05_release_build_tss.txt

06_xml_corrigido.xml

07_retorno_autorizado.txt

O nome dos arquivos é apenas sugestão. O objetivo é preservar uma sequência que permita reconstruir o diagnóstico meses depois.

Para rejeições ligadas a atualização, inclua também o pacote aplicado, data da aplicação e responsável técnico. Para rejeições fiscais, inclua aprovação do responsável Fiscal/Contábil.

Monitoramento após produção

Depois de promover a correção, acompanhe por alguns dias:

quantidade de ocorrências da mesma rejeição;
novas rejeições relacionadas;
documentos de cenários semelhantes;
diferenças de cálculo;
lentidão ou falha de transmissão;
comportamento do TSS;
incidência por filial e operação.

Uma correção bem-sucedida não é apenas “a nota autorizou”. Ela deve estabilizar o cenário sem introduzir efeitos colaterais.

Relação com a Reforma Tributária

As novas rejeições deixam claro que a NF-e passou a validar uma quantidade muito maior de relações semânticas: classificação tributária, tributação regular, redução, diferimento, devolução, novos tipos de nota e memória matemática.

Isso muda o trabalho de suporte. Antes, muitas inconsistências eram localizadas em poucos campos fiscais. Agora, o diagnóstico precisa seguir a cadeia completa do CFGTRIB e a tabela de cClassTrib.

Perguntas para a equipe antes de encerrar o incidente

A classificação está fiscalmente correta?
O artigo TOTVS usado corresponde à release?
Existe Nota Técnica mais nova?
O TSS está no mesmo nível de atualização do Protheus?
A correção foi reproduzida em homologação?
Houve teste negativo?
Outra filial usa a mesma regra?
Existe customização interferindo na geração do XML?
O XML corrigido corresponde ao cálculo interno?
A evidência foi documentada?

Se alguma resposta for “não sei”, o incidente ainda merece revisão.

Rejeição 321: devolução sem documento referenciado por item no Protheus: causa, solução e checklist técnico