Rejeição 492: verEvento inválido para o tipo de evento
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A rejeição 492, regra D05, verifica a versão específica informada em verEvento. Esse campo deve ser interpretado em conjunto com tpEvento e com o serviço de recepção. A versão do lote ou do aplicativo não substitui a versão do leiaute do evento.
Nesta página:
- Quais informações devem ser relacionadas?
- Exemplo: versão do pacote copiada para verEvento
- Como tratar uma transição de versão?
- O que diferencia 492 de 491 e 493?
Quais informações devem ser relacionadas?
O MOC escolhe o schema do evento pela combinação tpEvento e verEvento. Localize ambos dentro das informações do evento e confronte-os com a especificação oficial dessa operação. Um mesmo valor de versão não deve ser presumido válido para todos os eventos.
A raiz envEvento e o elemento evento também possuem informações estruturais próprias. A presença de uma versão no arquivo não prova que verEvento foi preenchido corretamente. Confira o caminho exato no leiaute, sem depender apenas de uma busca pela palavra versão.
Fontes: MOC Anexo I, regra D05.
Exemplo: versão do pacote copiada para verEvento
Em um cenário hipotético, o integrador atualiza um pacote de XSD e grava o número da versão do pacote em verEvento. O pacote reúne arquivos; seu número editorial não é necessariamente o valor aceito pelo schema específico. O evento pode ter tipo correto e ainda receber 492.
Compare o valor gerado com o atributo ou elemento definido na documentação do evento. Corrija a origem dessa informação no gerador e valide também detEvento. Não troque apenas o número sem conferir se o conteúdo corresponde ao leiaute anunciado.
Fontes: MOC Anexo I, regra D05.
Como tratar uma transição de versão?
Identifique a nota técnica específica, as versões admitidas e os prazos por ambiente. Mantenha o contrato selecionado junto ao tipo e ao endpoint, pois uma implantação em homologação não demonstra disponibilidade em produção.
Quando a versão prevista na documentação e o comportamento do autorizador divergirem, registre os dois fatos e procure esclarecimento técnico. Não reduza a validação local nem adote uma versão antiga por tentativa sem que seu uso esteja documentado.
Fontes: MOC Anexo I, regra D05.
O que diferencia 492 de 491 e 493?
A 491 verifica se tpEvento é válido; a 492 verifica verEvento; a 493 confere o conteúdo específico contra o schema resultante. Superar a versão não comprova assinatura válida nem registro do evento.
Preserve o retorno individual. Se uma tentativa anterior terminou com resposta desconhecida, consulte o resultado antes de repeti-la. A correção da versão deve preservar a finalidade, a autoria e os dados verdadeiros do evento; não é uma autorização para escolher outro tipo de ação fiscal.
Fontes: MOC Anexo I, regra D05.
Limite do exemplo e preservação dos dados
A prova depende da combinação original de tipo, versão e evento assinado. O exemplo textual não fabrica dados de documento nem um evento operacional. A conferência deve preservar o original e ocorrer em ambiente protegido; não publique certificado, senha, chave privada ou dados fiscais de clientes.
Fontes oficiais
- MOC 7.0 — Anexo I, versão 7.00. p. 73, regra D05, código 492; quadro completo e notas da seção.
- MOC 7.0 — Visão Geral, versão 7.00. pp. 100–101, parte geral de eventos, tpEvento, verEvento, detEvento, Signature e retorno individual.
- NT 2026.004 — CNPJ alfanumérico, versão 1.01. pp. 3–4, cronograma e alcance dos schemas; pp. 5–14, campos alterados e mensagens de serviços, incluindo envEvento p. 10.
- NT 2025.002-RTC — Adequações NF-e/NFC-e, versão 1.52. pp. 8–9, evolução do leiaute e DFeTiposBasicos; pp. 73–74, lista e registro de eventos, parte geral e schemas específicos.