Rejeição 920: confira os tipos de emissão no cancelamento por substituição

A rejeição 920 pede conferir como as notas foram emitidas e quais chaves o pedido relacionou. Comece pela nota que se pretende cancelar. Selecionar contingência na tela depois da emissão não altera documentos já autorizados. Preserve os XML, protocolos e a resposta completa antes de qualquer nova tentativa.

A NT 2018.004 v1.00 apresenta a mensagem “Rejeição: Tipo de Emissão inválido no Cancelamento por Substituição”. O MOC 7 — Visão Geral traz uma redação mais específica para o mesmo código: “Rejeição: Tipo de emissão da NF-e a ser cancelada deve ser normal”. Essa diferença documental ajuda a direcionar a investigação.

Identifique os papéis dos documentos

O serviço é o Registro de Evento, com tpEvento=110112, cancelamento por substituição. Ele difere do cancelamento comum, 110111, e da autorização de uma nova nota. A rejeição do pedido não cancela o documento anteriormente autorizado.

No cenário da NT, a empresa transmite uma NFC-e normal, fica sem resposta e emite outra em contingência para acobertar a mesma operação. Depois identifica que a primeira também foi autorizada. O procedimento procura tratar essa duplicidade, preservando o documento que efetivamente acobertou a operação.

O Ajuste SINIEF 19/16, cláusula décima quinta-A, consultado em 16/10/2026, mantém a referência a NFC-e substituída por outra NFC-e emitida em contingência para a mesma operação. O MOC, página 105, também declara o evento específico para NFC-e. A palavra NF-e na mensagem não autoriza estender o procedimento ao modelo 55.

Na entrada, chNFe identifica a nota a cancelar; chNFeRef, a substituta. O nProt é o protocolo de autorização da nota a cancelar. Não escolha os papéis apenas pela posição das notas numa lista ou pela ordem em que os retornos chegaram.

Leia a P12-48 na versão consultada

Na página 8 da NT 2018.004, a P12-48 relaciona, para 110112, a emissão normal 1 na chave da nota a cancelar e a contingência 9 na chave substituta. O quadro marca aplicação obrigatória e código 920.

Já a página 106 do MOC 7 — Visão Geral descreve a P12-48/920 somente como tipo da nota a cancelar diferente de 1, normal. Na página 109, o manual apresenta separadamente a 5P31-44/921, para substituta com tipo igual a 1, normal. As redações não devem ser fundidas silenciosamente nem o código 921 tratado como sinônimo de 920.

Por isso, registre o cStat e o xMotivo reais, a versão e o autorizador. Confira a original e a substituta, mas não conclua que qualquer combinação inadequada produzirá necessariamente 920. A documentação examinada não demonstra qual implementação cada ambiente executa nem a ordem de todos os retornos.

O campo tpEmis descreve a emissão do documento. No MOC Anexo I, B22, 1 é emissão normal e 9, contingência offline da NFC-e. Já tpEvento identifica o pedido de evento. Os códigos não são intercambiáveis; a existência de outras modalidades de contingência não as torna equivalentes a 9 nesse fluxo da NT.

Confira o que foi transmitido

Localize os dois XML autorizados, seus protocolos, o pedido rejeitado e a resposta. Registre estabelecimento, modelo, série, número, horário, ambiente, UF, autorizador e versão do emissor. Produção e homologação precisam ser distinguidas.

Organize uma comparação com chave, tipo de emissão, papel no pedido e vínculo com a venda. Confira as chaves efetivamente enviadas, não somente os documentos que a tela aparenta selecionar. Uma associação incorreta pode levar o evento a usar outra referência.

A impressão com a palavra contingência ou a configuração atual do PDV não substituem o conteúdo autorizado. Peça ao suporte que verifique a correspondência entre XML, chave e registros internos. Não reconstrua chaves manualmente nem altere tpEmis num arquivo assinado.

Trate cada cenário com os fatos preservados

As chaves foram selecionadas ao contrário. Reconstrua o histórico da operação. Verifique qual documento normal corresponde à duplicidade e qual documento de contingência efetivamente acobertou a venda. Só depois dessa comprovação corrija a seleção ou a geração do pedido. Trocar os papéis para obter números convenientes não comprova o enquadramento.

A nota a cancelar foi emitida em contingência. O MOC associa a 920 à original com tipo diferente de normal. Não mude o tipo da nota para 1. Verifique se houve inversão de referências ou se o caso não corresponde ao fluxo documentado. A definição da regularização cabe ao responsável fiscal diante da operação verdadeira.

As duas notas foram emitidas normalmente. Retransmitir o mesmo XML não significa, por si só, emitir outra NFC-e; confirme a existência de dois documentos autorizados. Duas notas com tpEmis=1 não atendem à combinação normal e contingência 9 descrita pela NT. A análise deve considerar a distinção 920/921 do MOC, sem garantir qual rejeição virá. Não crie outra emissão apenas para obter uma substituta de contingência.

A tela indica contingência, mas o arquivo mostra outro tipo. Diferencie configuração atual, apresentação e conteúdo autorizado. Investigue associação, importação ou mudança de configuração posterior. Corrigir a exibição não altera o tipo original nem assegura cancelamento.

Em qualquer cenário, cancelamento comum, devolução ou procedimento excepcional exigem seus próprios pressupostos. Não os escolha automaticamente para contornar o 920. Encaminhe a divergência documentada ao suporte e a decisão fiscal ao responsável pela operação.

Exemplo hipotético de inversão

Uma mercearia identifica duas NFC-e autorizadas da mesma venda. A nota A foi emitida normalmente, tipo 1; a B, em contingência offline, tipo 9. Por erro de seleção, o pedido coloca B em chNFe e A em chNFeRef.

A resposta 920 é coerente com a nota a cancelar ter tipo 9. A equipe preserva os arquivos e comprova que B acobertou a venda e A representa a duplicidade. O suporte prepara o pedido com os papéis fundamentados, sem modificar chaves ou tipos. Ainda será necessário avaliar os demais requisitos e o novo retorno.

Confira prazos e resultado individual

A cláusula décima quinta-A prevê pedido até 168 horas desde a autorização, podendo a UF reduzir o prazo. O § 6º admite tratamento excepcional a critério estadual, sem liberação automática. A FAQ mineira confirma o cenário de duplicidade e orienta procurar a Administração Fazendária quando cabível, sem cancelamento extemporâneo automático. Essa orientação não se transfere às demais UFs.

O prazo do pedido difere do intervalo entre emissões examinado pela 914. Valores, destinatário, quantidade e dados dos itens também têm validações próprias. Uma combinação de tipos compatível não comprova a regularidade completa do evento.

Após tratamento fundamentado, examine retEvento/infEvento, com chave, cStat, xMotivo e protocolo, e confira a situação da nota. 128 indica processamento do lote, não cancelamento confirmado. As fontes sustentam este diagnóstico documental; não foram testados implantação por ambiente, procedimento individual, telas do ALRA ou aceite real.

Fontes

• NT 2018.004 v1.00: captura HTTP de 16/10/2026 reutilizada por hash; páginas 3–6, 8 e 11 lidas nesta sequência. Página 8 relida e PNG documental preexistente pessoalmente inspecionado, com os dois lados da P12-48.

• MOC 7 — Visão Geral: captura de 15/10/2026 reutilizada; páginas 105, 106 e 109 integralmente lidas; PNG existente da 106 inspecionado. Diferença entre 920 e 921 explicitada. Anexo I, página 10, lida e conferida em PNG preexistente para B22.

• Ajuste SINIEF 19/16, cláusula décima quinta-A, e FAQ da SEF/MG: capturas de 16/10/2026 e leituras próprias reutilizadas nesta sequência, com limites estaduais preservados.

• NDD, Invoisys e Berga: corpos específicos efetivamente lidos em 16/10/2026. São apoios confrontados, não três soluções integralmente válidas; erros sobre papéis, reemissão e regularização automática foram descartados.

• fontes.v3.json distingue novas capturas, reuso, divergências e históricos preservados. Sem nova imagem, validação XSD, transmissão, publicação ou integração.