Rejeição 493: detEvento fora do schema específico

A rejeição 493, regra D06, indica que detEvento não atende ao schema específico do evento. Um lote pode estar estruturalmente correto e ainda conter um detalhamento incompatível com o tipo e a versão informados.

Nesta página:

• Por que o schema geral não basta?
• Exemplo: detalhe reaproveitado de outra operação
• O que conferir nos campos e na versão?
• Como verificar a correção sem presumir registro?

Por que o schema geral não basta?

O Web Service de eventos possui uma interface geral e uma área de detalhe própria de cada operação. O MOC determina a escolha do schema por tpEvento combinado com verEvento e valida detEvento contra esse contrato. Passar no XSD do envelope geral não comprova conformidade do detalhe.

Identifique o tipo real, a versão e o arquivo XSD correspondente, incluindo suas dependências. Não aplique ao detalhe de um evento a estrutura de outro, mesmo que os campos tenham nomes parecidos.

Fontes: MOC Anexo I, regra D06.

Exemplo: detalhe reaproveitado de outra operação

Imagine que um sistema monta corretamente a parte geral, mas reutiliza um objeto de detalhe destinado a outro tipo de evento. A raiz e as identificações podem passar, enquanto o conteúdo de detEvento contém elementos inesperados ou deixa de apresentar os exigidos.

Compare o primeiro erro do validador com o caminho completo e a sequência do schema específico. Corrija o objeto ou o serializador responsável. Remover o elemento apontado sem entender o contrato pode apagar informação necessária e manter a causa.

Fontes: MOC Anexo I, regra D06.

O que conferir nos campos e na versão?

Confira nomes, namespace, ordem, ocorrências, atributos e restrições de formato do detalhe. Ausência não é igual a um valor zero, e um campo obrigatório não pode ser omitido só porque o sistema não dispõe do dado. Quando faltar informação exigida, identifique sua origem legítima antes de gerar novamente.

Use a especificação atual do evento. Notas posteriores podem modificar o conteúdo admitido, e o cronograma deve ser distinguido da implantação observada. Não escolha valores fiscais ou outra finalidade apenas para satisfazer o XSD.

Fontes: MOC Anexo I, regra D06.

Como verificar a correção sem presumir registro?

Valide a mensagem geral e cada detalhe no schema escolhido por tipo e versão. Se a alteração afeta a parte assinada, gere e confira a assinatura pelo fluxo legítimo. A 491 e a 492 tratam de tipo e versão; a 493 trata da conformidade do conteúdo específico.

Confira o retorno individual do evento, além do processamento do lote. Se houve tentativa com resposta perdida, esclareça o resultado antes de repetir a operação. Validação local e HTTP 200 não comprovam que o evento foi registrado.

Fontes: MOC Anexo I, regra D06.

Limite do exemplo e preservação dos dados

Um exemplo válido exigiria o detalhe completo de um evento real, sua identidade e assinatura protegidas. A comparação textual demonstra a incompatibilidade sem fabricar evento fiscal. 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 D06, código 493; 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.