Nova arquitetura de DFeReferenciado por item no Protheus: Guia técnico completo

Introdução

Nova arquitetura de DFeReferenciado por item no Protheus integra o novo lote de tratamentos da Reforma Tributária publicado pela TOTVS em setembro de 2026. O foco aqui é explicar a regra, a causa e a solução do início ao fim.

O que a TOTVS documenta

• As novas validações cobrem nível da referência, chave, nItem, duplicidade e identidade dos participantes.
• DKN_CHVNFE, DKN_ITXML e D1_ITXML aparecem nos tratamentos oficiais.
• Devoluções e notas de débito/crédito exigem rastreabilidade mais granular por item.

Solução principal

Criar matriz por finalidade/tipo de nota e testar origem → DKN → XML item a item.

Matriz de testes

1010: nível duplicado; 1038: chave ausente; 1048: item ausente; 1072: duplicidade; 1193/1194: coerência dos participantes.

Guia técnico

Registre finalidade, CST, cClassTrib, participantes, regras do FISA170 e XML. Confirme enquadramento, cálculo/escrituração, geração no TSS e validação da SEFAZ.

Solução central: Criar matriz por finalidade/tipo de nota e testar origem → DKN → XML item a item..

Fluxo de investigação

Cadastro/classificação → Perfis/contexto → FISA170 → cálculo/escrituração → TSS/XML → SEFAZ.

Checklist

• preservar XML original;
• identificar item;
• conferir artigo TOTVS;
• revisar release e TSS;
• confirmar CST/cClassTrib;
• revisar FISA170;
• fazer cálculo manual quando houver fórmula;
• conferir origem quando houver DFeReferenciado;
• regerar XML;
• homologar e arquivar evidência.

Evite atalhos

Não faça UPDATE em F2D, CJ3, DKN ou tabelas fiscais. Não remova tags manualmente. Não troque cClassTrib ou benefício apenas para autorizar.

Revisão independente

Refaça o cálculo em planilha quando houver fórmula, ou monte tabela com chave/item/participantes quando o problema for referenciamento. Compare antes e depois da correção.

Monitoramento pós-produção

Acompanhe reincidência, novas rejeições relacionadas, diferenças por filial e comportamento do TSS. Uma correção só está estabilizada quando não cria efeitos colaterais.

Conclusão

A correção segura acontece na origem: classificação, regra, cálculo, referência ou atualização. Depois, gere novo XML, valide em homologação e documente o resultado.

Conteúdo técnico baseado em documentação oficial TOTVS publicada entre 9 e 11/09/2026. Tratamentos fiscais e classificações devem ser confirmados pela área Fiscal/Contábil.

Validação funcional antes da produção

Antes de liberar a correção, compare o comportamento do Protheus com uma memória independente. Quando a rejeição envolver cálculo, reproduza a conta em planilha com base, alíquota, redução, diferimento, devolução e arredondamento explícitos. Quando envolver referenciamento, monte uma tabela com chave de origem, item, CNPJ/CPF do emitente e destinatário. Quando envolver classificação, registre CST, cClassTrib e a versão da tabela usada.

A validação deve responder três perguntas: a regra correta foi escolhida? o valor/grupo gerado está correto? o XML representa fielmente o resultado interno?. Se qualquer uma delas ficar sem resposta, a autorização da nota não deve ser usada como única evidência de que o problema foi resolvido.

Evidências para suporte e auditoria

Um pacote de evidências útil pode conter:

01_xml_rejeitado.xml

02_retorno_sefaz.txt

03_print_regra_cfgtrib.png

04_memoria_calculo.xlsx

05_release_build_tss.txt

06_xml_corrigido.xml

07_retorno_autorizado.txt

Se a ocorrência envolver DFeReferenciado, acrescente a chave da nota de origem, item de origem e participantes envolvidos. Se envolver F2D/CJ3, use consultas apenas de leitura e anexe a evidência correspondente. Se o artigo oficial indicar possível problema no autorizador, guarde também o resultado do validador nacional ou de outro ambiente comparável.

Teste negativo obrigatório

Além do cenário corrigido, execute um caso semelhante que não deve usar a mesma regra. Essa etapa é essencial para evitar parametrizações amplas demais. Uma correção que faz a nota rejeitada autorizar, mas passa a aplicar diferimento, crédito presumido ou classificação a operações indevidas, não está concluída.

Exemplos de teste negativo:

• outro CST sem direito ao mesmo grupo;
• cClassTrib diferente;
• participante ou UF diferente;
• nota sem vínculo de origem;
• benefício fiscal fora da área incentivada;
• documento de finalidade diferente.

Política de atualização

Rejeições da Reforma Tributária mudam rapidamente com novas versões de Nota Técnica, patches, fontes e TSS. Portanto, associe cada solução à data do artigo TOTVS, release testada e versão do ambiente. Evite registrar a solução apenas como “ajustar campo X”.

Após atualização de Protheus, TSS ou pacote fiscal, repita pelo menos os cenários mais críticos. Essa rotina de regressão transforma a coleção de artigos em uma base operacional para sustentação e não apenas em material de consulta.

Critério de encerramento do incidente

Considere a rejeição encerrada somente quando houver:

• causa identificada;
• correção aplicada na origem;
• XML novo gerado;
• homologação concluída;
• cenário negativo executado;
• evidência arquivada;
• responsável Fiscal/Contábil de acordo, quando aplicável.

Esse critério reduz reincidência e evita soluções improvisadas.