Rejeição 460: use o protocolo do evento que será cancelado

A rejeição 460, “Protocolo do Evento difere do cadastrado”, aponta uma inconsistência na referência ao evento que se pretende cancelar. O número exigido é o protocolo de registro daquele evento original, conforme o serviço. Não é, por padrão, o protocolo de autorização da NF-e, o recibo do lote ou o protocolo de outro cancelamento.

Essa diferença parece pequena na tela de um sistema, mas muda o documento consultado pela SEFAZ. Uma nota autorizada pode acumular vários eventos, cada um com seu próprio retorno. Recuperar a referência correta é mais seguro do que testar números até a mensagem desaparecer.

Existem vários identificadores no mesmo histórico

A chave de acesso identifica a nota. O tipo e a sequência distinguem eventos ligados a ela. O protocolo comprova o registro autorizado correspondente, e o lote pode reunir várias solicitações com resultados individuais diferentes.

No pedido de cancelamento, nProtEvento aponta para o evento original. Quando o cancelamento é registrado, seu retorno gera outro protocolo. Os dois precisam permanecer separados no armazenamento do ERP. Substituir o original pelo protocolo mais recente perde a ligação necessária para auditoria e recuperação do histórico.

A documentação da Unimake descreve NProtEvento como referência ao evento que se cancela. Já a FlexDocs para cancelamento de ECONF distingue o protocolo informado e o devolvido. Esses contratos de integração ajudam a localizar campos trocados, sem substituir o leiaute fiscal.

Onde a mesma rejeição aparece

No cancelamento do comprovante de entrega da NF-e, 110131, a referência é o evento 110130. A NT 2021.001 v1.01 associa 460 à regra 4P23-10, após a busca do evento original pela chave e sequência. Leiaute e validações, páginas 11–13

No cancelamento de insucesso, 110193, o original é 110192. Na NT 2023.005 v1.02, a regra do protocolo tem outro identificador: 4P22-10. Esses eventos de entrega são documentados para o modelo 55. NT 2023.005, páginas 12 e 15

No cancelamento de conciliação financeira, 110751, deve ser informado o protocolo do ECONF 110750 correspondente. A NT 2024.002 v1.00 usa 4P23-10 e contempla NF-e 55 e NFC-e 65, respeitado o serviço receptor de cada modelo e UF. ECONF, páginas 4, 12 e 16

No cancelamento genérico 110001 da RTC, a NT 2025.002 v1.52 usa 1P24-10. A combinação de referência inclui chave, tpEventoAut, sequência original e nProtEvento. O capítulo documenta modelo 55, exige o mesmo autor do evento cancelado e compara também seu órgão. RTC, páginas 86–87

Portanto, 4P23-10, 4P22-10 e 1P24-10 não devem ser citadas como uma única regra universal. A mensagem se repete, mas o contrato e o campo referenciado precisam ser confirmados em cada caso.

Um roteiro para recuperar o número certo

1. Guarde a solicitação rejeitada e o retorno individual. Registre ambiente, serviço e versão utilizados.

2. Consulte a situação atual e recupere os eventos disponíveis antes de retransmitir. Isso é essencial quando o erro apareceu depois de timeout, migração ou restauração de backup.

3. Abra o retorno do evento original pretendido. Confira chave, tipo e sequência, além do protocolo; selecionar apenas pela chave da nota é insuficiente.

4. Compare o valor recuperado com o XML de cancelamento. Procure campo errado, corte de caracteres, conversão numérica inadequada ou mistura entre ambientes.

5. Corrija o armazenamento ou mapeamento se houver divergência comprovada. Preserve a sequência de caracteres do protocolo; não acrescente zeros nem calcule um número substituto.

6. Gere e assine a solicitação correta pelo sistema, somente quando o cancelamento ainda for necessário, e confira o resultado individual.

A TecnoSpeed no método de cancelamento de ECONF explicita o vínculo entre sequência e protocolo. O ponto operacional importante é manter esse par associado ao registro original, mesmo que existam vários pagamentos para a mesma nota.

Formato válido não significa referência correta

Um número com a quantidade esperada de caracteres pode pertencer à autorização da NF-e ou a outro evento. Nesse caso, corrigir máscara ou tamanho não resolve a referência errada. Por outro lado, a RTC v1.52 prevê 15 ou 17 posições para nProtEvento no 110001; não se deve truncar um protocolo legítimo para satisfazer uma validação antiga do componente.

Esse domínio não deve ser propagado automaticamente para todos os eventos históricos. A equipe precisa conferir o esquema e a versão efetivamente exigidos pelo serviço e pelo fornecedor, preservando o valor oficial recuperado.

Imagine uma empresa fictícia que migra seu sistema. O banco novo guarda apenas um campo chamado “protocolo”, preenchido com a autorização da nota. Ao cancelar um comprovante de entrega, o programa reutiliza esse campo. A solução é recuperar e vincular o protocolo específico do comprovante, corrigindo a estrutura de dados; não alterar a nota já autorizada.

Diferenças que evitam uma solução errada

A 459 trata da localização do evento original segundo a chave de pesquisa. A 460 trata do protocolo exigido naquela referência. A rejeição 222, embora tenha mensagem parecida, refere-se a outro contrato e aparece no cancelamento de nota e em validações próprias de prorrogação. Não substitua uma orientação pela outra só porque ambas mencionam protocolo.

Os cancelamentos de prorrogação 111502/111503 têm regras próprias. O cancelamento do Visto Eletrônico do Fisco, 400301, também possui outro conjunto de verificações; o boletim consultado não documenta 460 nesse ramo. O 110001 não deve ser usado para cancelar livremente EPEC, cancelamento de nota ou qualquer evento de órgão público.

A vinculação de pagamento 110300 tem remissão ao 110001 na NT 2026.006, dentro do contexto preparatório do split payment. Isso exige acompanhamento de ativação e não comprova disponibilidade universal em produção.

Se a consulta confirmar que o cancelamento já foi aceito, recupere seu retorno em vez de repeti-lo. Se a divergência permanecer com referências comprovadamente corretas, encaminhe a evidência ao suporte responsável. Não apague entrega, recebimento ou efeito tributário verdadeiro para contornar a mensagem.

Fontes e atualização

Conferência em 10/10/2026 com documentos oficiais preservados. FlexDocs, TecnoSpeed e Unimake foram lidos como três editores de documentação prática. Suas rotinas apoiam a investigação de referências e retornos; trechos genéricos, exemplos e limites antigos não substituem o contrato de cada evento nem comprovam ativação em toda UF.