Rejeição 636: cancelamento incompatível com o pedido de prorrogação

A rejeição 636, “O tipo do evento de cancelamento não corresponde ao tipo do evento a ser cancelado”, exige comparar o cancelamento enviado com o pedido de prorrogação que ele referencia. No contrato de prorrogação da suspensão do ICMS, cancelar o primeiro prazo e cancelar o segundo são operações diferentes. Selecionar o tipo errado pode produzir essa rejeição mesmo que a NF-e de remessa esteja autorizada.

O problema está no evento associado à NF-e modelo 55. Não é uma instrução para cancelar a própria nota, reenviar sua autorização ou mudar sua numeração. A NT 2015.001 v1.30 documenta a regra obrigatória P1319 nesse serviço específico. NT, páginas 41 e 46.

Os pares que precisam corresponder

O campo tpEvento identifica o que está sendo solicitado. Para os pedidos do contribuinte e seus cancelamentos, a relação é:

• Pedido de primeiro prazo: 111500; cancelamento correspondente: 111502

• Pedido de segundo prazo: 111501; cancelamento correspondente: 111503

“Corresponder” não significa repetir o mesmo código. Um cancelamento 111502 deve apontar para um pedido 111500. Se apontar para 111501, a relação entre os tipos estará errada.

Os códigos 411500, 411501, 411502 e 411503 pertencem às respostas do Fisco. O contribuinte não deve escolher um deles para obter aprovação nem substituir seu cancelamento por um evento de autoridade fiscal. Também não se trata do Visto Eletrônico do Fisco, que possui contrato próprio.

Há dois identificadores de evento e um protocolo

No XML do cancelamento, o atributo Id de infEvento identifica o novo evento que será assinado. Ele combina a literal ID, o tipo desse cancelamento, a chave da NF-e e sua sequência.

Já detEvento/idPedidoCancelado aponta para o pedido anterior. No leiaute examinado, são 54 caracteres e o conteúdo corresponde ao Id original do evento 111500 ou 111501. Por isso, copiar para esse campo o Id do próprio cancelamento cria uma referência errada.

O campo nProt do detalhe deve conter o protocolo do pedido de prorrogação que se pretende cancelar. Não é o protocolo de autorização da NF-e, o identificador do lote nem a sequência do evento. Recuperar esses dados do XML protocolado do pedido é mais seguro do que reconstruí-los a partir de uma tela resumida.

Essas distinções permitem localizar a falha: o usuário pode ter escolhido o prazo correto, mas uma integração ter recuperado o pedido errado; ou o vínculo pode estar correto e a tela ter selecionado a modalidade de cancelamento inadequada.

Um exemplo sem alterar a operação fiscal

Uma indústria precisa cancelar um pedido de segundo prazo. O histórico confirma que o pedido original é 111501, mas o sistema gera 111502. Nesse caso, o suporte deve corrigir a geração do cancelamento para a modalidade correspondente, 111503, preservando a referência ao pedido verdadeiro.

Não se corrige o problema mudando o tipo do pedido já registrado para que combine com o cancelamento. Tampouco se escolhe outro pedido apenas porque seu código passa na validação. A intenção de cancelamento e o registro efetivamente afetado precisam continuar correspondendo.

Conferência prática antes de transmitir outra vez

1. Guarde a mensagem enviada e o retorno individual com cStat e xMotivo. Identifique chave, ambiente, UF, tpEvento e nSeqEvento

2. Abra o histórico do pedido que deveria ser cancelado. Confirme se ele é de primeiro ou segundo prazo e recupere seu XML e protocolo

3. Compare o tipo do cancelamento com o par correto. Confira separadamente idPedidoCancelado e nProt, sem substituir a referência pela NF-e ou pela resposta do Fisco

4. Verifique a situação atual do pedido e as demais dependências. Tentativas anteriores sem resposta precisam ser conciliadas antes de novo envio

5. Se a solicitação continuar cabível, corrija o gerador e refaça a assinatura do evento pelo emissor. Depois confira o retorno individual e acompanhe a decisão fiscal

Editar manualmente o XML assinado pode invalidar sua assinatura. O documento autorizado da remessa deve permanecer preservado.

Registrar o cancelamento não significa deferi-lo

O serviço RecepcaoEvento é síncrono: devolve o resultado do registro na mesma chamada. Na NT, 128 indica lote processado; 135 identifica evento registrado e vinculado. A decisão sobre a prorrogação ou seu cancelamento chega em outro evento, produzido pelo Fisco. Não há autorização para presumir um recibo de lote assíncrono nesse fluxo. NT, seções 3.3, 5 e 7.8.

Na solicitação parcial, o cancelamento do primeiro prazo pode depender de desfazer previamente uma prorrogação de segundo prazo que utiliza aquelas quantidades. A NT exemplifica aguardar o deferimento desse cancelamento anterior. Essa análise é diferente da comparação de tipos da 636: corrigir tpEvento não resolve automaticamente todas as condições de mérito.

UF, ambiente e contrato continuam importantes

A NT descreve a implementação parcial de São Paulo e a completa de Minas Gerais. A orientação mineira atual exige todos os itens e quantidades e processa um evento por vez para cada NF-e. Essas condições não devem ser generalizadas a outros estados. Confirme também os prazos aplicáveis ao pedido concreto; uma rejeição técnica não os prorroga. SEF-MG: pedido de prorrogação.

Homologação e produção mantêm registros separados. Uma referência válida em testes não localiza o pedido real em produção. A versão da nota técnica, a versão do XML e o contrato do serviço também são coisas diferentes: a NT conserva verificações de nfeCabecMsg, cUF e versaoDados. Não imponha “4.00” nem remova o cabeçalho por analogia com a autorização comum.

Se aparecer outro retorno, retome seu significado: 640 verifica a validade de idPedidoCancelado nesse contrato; 222 pode apontar protocolo divergente; 572 trata do Id do evento enviado; 594 trata da sequência. Trocar campos indiscriminadamente pode apenas fazer o sistema chegar à próxima rejeição.

Fontes práticas e limites

Foram comparados três editores independentes: TOTVS, fluxo de prorrogação e cancelamento, NFePHP, estrutura do pedido e ACBr, mudanças da versão 1.30. São fontes contextuais, não três tutoriais dedicados à 636. Prevalece a NT 2015.001; exemplos legados de retorno, limites e versões foram conferidos contra ela. Corpus oficial preservado em 09/10/2026 e relido em 10/10/2026, com páginas públicas consultadas nesta data.