Rejeição 1193: emitentes das NF-e referenciadas devem ser iguais: Troubleshooting passo a passo

Introdução

Rejeição 1193: emitentes das NF-e referenciadas devem ser iguais integra o novo lote de tratamentos da Reforma Tributária publicado pela TOTVS em setembro de 2026. O foco aqui é isolar a causa por camada.

O que a TOTVS documenta

• Em devolução finNFe=4, o emitente do DFeReferenciado deve ser o mesmo em todos os itens.
• A validação é associada à NT 2025.002-RTC, regra VC02-40.
• Se o XML estiver conforme, outros estados autorizarem e o validador nacional aceitar, a falha pode estar na SEFAZ estadual.

Solução principal

Comprovar a identidade dos emitentes e, se o XML estiver correto, acionar a SEFAZ com evidências.

Rastreabilidade

A validação considera chave de origem, item, finalidade e participantes. Os tratamentos citam DKN_CHVNFE, DKN_ITXML e D1_ITXML.

Troubleshooting

1. arquive XML/retorno; 2. identifique o item; 3. confira release/TSS; 4. valide CST/cClassTrib; 5. revise FISA170; 6. confira cálculo ou referência; 7. compare XML; 8. teste homologação; 9. só então investigue customizações.

Classifique a causa como cadastro, regra, cálculo, referência, atualização ou autorizador.

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.