O que é o evento 22 e quando usar
Se você trabalha com NF-e ou NFC-e no Brasil, já deve ter visto aquela mensagem de erro ao tentar enviar uma nota e resolvido fazendo algo qualquer sem entender o que aconteceu. O motivo 22 pode reapresentar é um evento de correção previsto na SEFAZ Nacional que, em teoria, serve para autorizar a reemissão de uma nota fiscal com erro. Na prática, muita gente usa como panaceia e acaba travando o processo fiscal depois.
motivo 22 pode reapresentar
O evento em si tem código 22 no sistema da SEFAZ e o título oficial é "Pode Reapresentar". Ele é registrado dentro do lote de eventos da NF-e e precisa ser aprovado antes que você possa cancelar e reemitir a nota, ou antes de usar outros eventos de correção em cima dela. O fluxo normal é: identificar o erro -> enviar o evento 22 -> aguardar retorno -> agir conforme a autorização veio. Aqui vai algo que os manuais não costumam deixar claro. O motivo 22 pode reapresentar não serve para qualquer erro. Ele foi pensado para situações pontuais onde a nota foi rejeitada pela SEFAZ por motivos que não invalidam a operação, como dados digitados errados, falha no sistema do emitente, ou problema técnico comprovado. Se você tentar usar ele para corrigir algo substantivo como CFOP errado, produto inválido, ou informação tributária completamente diferente da realidade, a SEFAZ pode rejeitar o evento ou, pior, aceitar e te deixar numa situação fiscal problemática.
Eu já vi isso acontecer na minha frente. Tinha um cliente que estava enviando evento 22 para "corrigir" uma NFC-e que tinha sido rejeitada duas vezes por inconsistência de CST. A SEFAZ aceitou o evento, mas quando fomos fazer o planejamento fiscal do mês seguinte, descobrimos que a nota continua com o CST errado nos registros internos. O evento havia autorizado a reapresentação, mas não corrigiu automaticamente os campos tributados. O trabalho extra foi enorme para separar o que era regular do que precisava de ajuste manual.
Como enviar o evento na prática
Vou descrever o fluxo real, não o discurso de curso. Você precisa ter o projeto da NF-e original em mãos, o número do lote, e acesso ao WebService de recepção de eventos da SEFAZ. A estrutura do evento é um XML específico com tags como id, tipo, versão, e o conteúdo do evento propriamente dito. Dentro do conteúdo, você informa o motivo e os dados que estão sendo autorizados a serem corrigidos ou reemitidos. O processo básico é:
Assinar o XML do evento com seu certificado digital. Isso é obrigatório e não tem contorno. Sem assinatura válida, a SEFAZ nem lê o conteúdo. Empacotar no lote de eventos. A SEFAZ exige que o evento venha dentro de uma estrutura de lote, e não isolado. Se você mandou evento avulso, provavelmente vai receber erro de estrutura.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Enviar via WEBSERVICE. A URL muda conforme o estado e a versão do esquema. Verifique sempre a versão do layout antes de enviar. O esquema 4.0 mudou bastante a forma como os eventos são tratados. Aguardar o retorno. O prazo varia entre alguns segundos e alguns minutos, dependendo da carga do SEFAZ. Em períodos de pico, como final de mês ou virada de ano, o tempo pode triplicar.
Uma coisa que pouca gente faz: salvar o protocolo de recepção do evento. Sem o protocolo, você não tem como comprovar que o evento foi recebido, mesmo que a SEFAZ tenha aprovado. Eu já perdi tempo valuable procurando justificativas para auditorias porque o protocolo não estava arquivado.
Erros comuns e como evitar
O erro mais frequente é enviar o evento 22 sem ter a nota original corretamente identificada. Se o campo id da NF-e de origem estiver errado, o evento vai para o nada. Confira o id antes de enviar. Outro erro comum é tentar usar o evento 22 como substituto do evento de correção (carta de correção, evento 110). Eles são coisas diferentes. O 22 autoriza a reapresentação. O 110 corrige informações específicas. Também vejo muita gente esquecendo que o evento 22 não cancela a nota. Ele apenas autoriza que você possa cancelá-la ou reemití-la. Se você pensar que o evento resolve tudo e não toma as providências seguintes, a nota continua lá com o erro original e você ainda gastou uma solicitação de evento à toa.
Outro ponto importante: o evento 22 pode reapresentar tem limitações temporais. Em alguns estados, se a nota já foi enviada para o destino do destinatário e ele já au, o evento pode ser rejeitado porque a situação jurídica da nota já mudou. Isso varia conforme a regra do estado, então sempre verifique a documentação específica da sua SEFAZ.
Quando NÃO usar
Se a NF-e foi rejeitada por inconsistência grave que afetou a validade tributária, como CFOP incompatível com a operação, IE do destinatário inexistente, ou produto com NCM proibido, o evento 22 não vai resolver. Nesse caso, o correto é cancelar a nota (evento 110 com motivo cancelamento) e emitir uma nova, ou usar carta de correção se for apenas um detalhe corrigível. Também não use o evento 22 se você não tiver documentação que comprove o erro. A SEFAZ pode solicitar os comprovantes em uma fiscalização, e se você não tiver, o evento aceito não vai te proteger.
Alternativas e complementaridades
O evento 22 funciona bem para rejeições por erro de digitação ou falha técnica comprovada. Para correções de campos específicos, o evento 110 (carta de correção) é mais adequado. Para cancelamentos, existe o evento de cancelamento em si. Muitas vezes a solução ideal é combinar eventos: primeiro o 22 para autorizar a reapresentação, depois o cancelamento, depois a reemissão com os dados corrigidos. O motivo 22 pode reapresentar é útil, mas exige que você entenda exatamente o que está fazendo. Não é botão mágico. Teste em homing primeiro, salve todos os protocolos, e mantenha registro documental de cada decisão tomada. O resto é construção de processo, não de Sorte.
