Rejeição 491: tpEvento inválido no registro de eventos

A rejeição 491, regra D04, verifica se o tipo informado em tpEvento é válido. O MOC situa D04 na extração e validação dos eventos. Não é uma regra sobre tipo de operação ou modelo da nota.

Nesta página:

• Como o tipo determina a validação do evento?
• Exemplo: rotina de integração usa um tipo interno
• E se o tipo foi acrescentado por uma Nota Técnica?
• Como distinguir 491, 492 e 493?

Como o tipo determina a validação do evento?

O MOC informa que cada evento é extraído do lote e tratado individualmente. O schema específico é escolhido pela combinação de tpEvento e verEvento. Por isso, um valor numérico com o tamanho esperado pode passar em uma verificação de formato e ainda representar um tipo não válido para o serviço.

Confira a operação que se pretende registrar, a nota técnica que a define, o código nela previsto e o endpoint correspondente. Não copie um tipo de evento de outra operação apenas porque ele é aceito no mesmo ambiente.

Fontes: MOC Anexo I, regra D04.

Exemplo: rotina de integração usa um tipo interno

Suponha que o software tenha uma enumeração interna para suas ações e serialize diretamente esse número em tpEvento. O identificador interno não passa a ser um código fiscal oficial. A conferência deve acompanhar o mapeamento entre a ação real e o tipo documentado.

Corrija o mapper ou a configuração responsável, mantendo a finalidade pretendida e comprovada. Se a ação não possui evento aplicável naquele serviço, não a transforme em outro evento por tentativa. O problema exige revisar a integração, não inventar um código.

Fontes: MOC Anexo I, regra D04.

E se o tipo foi acrescentado por uma Nota Técnica?

Confira a versão vigente da especificação específica, seu schema e o cronograma por ambiente. A RTC, por exemplo, acrescenta estruturas e eventos com contratos próprios; não basta o código existir em um documento para supor que qualquer endpoint o aceite.

Registre a fonte, o ambiente, a versão e o retorno observado quando houver divergência. Cronograma não comprova implantação individual. A 491 não autoriza alterar a data ou a empresa para acessar uma validação diferente.

Fontes: MOC Anexo I, regra D04; NT 2025.002-RTC — Adequações NF-e/NFC-e.

Como distinguir 491, 492 e 493?

A 491 verifica o tipo; a 492, a versão específica verEvento; a 493, a conformidade de detEvento com o schema selecionado. Um tipo correto pode acompanhar versão ou conteúdo incorretos.

Valide a combinação inteira antes de transmitir. O resultado do lote não substitui o retorno de cada evento. Quando já houve tentativa com resposta perdida, consulte o estado pelos meios cabíveis antes de repetir a ação, especialmente em eventos que alteram a situação do documento.

Fontes: MOC Anexo I, regra D04.

Limite do exemplo e preservação dos dados

A validação completa exigiria o evento original assinado e sua identidade protegida. O exemplo textual mostra o mapeamento sem fabricar tipo fiscal, chave, autor ou assinatura 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 D04, código 491; 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.