Rejeição 493: como corrigir o XML específico do evento

A rejeição 493 informa que o conteúdo específico do evento não atende ao schema esperado pela SEFAZ. Para resolver, identifique o tipo e a versão do evento, valide seu grupo detEvento e corrija o campo ou a montagem apontados no diagnóstico.

Mensagem: “Rejeição: Evento não atende o Schema XML específico”.

Se a nota já estava autorizada, a rejeição de um evento posterior não desfaz essa autorização. Uma tentativa de cancelamento com a 493, por exemplo, ainda não comprova que a nota foi cancelada.

Qual parte do XML precisa ser conferida?

O registro de eventos tem informações gerais e um conteúdo próprio para cada operação. O grupo detEvento reúne esse conteúdo específico. Um cancelamento, uma carta de correção e uma manifestação do destinatário não usam necessariamente os mesmos campos.

Na regra D06, o MOC determina a validação de detEvento contra o schema correspondente. A escolha considera a combinação de tpEvento, que identifica o tipo do evento, com verEvento, sua versão. O mesmo trecho do manual distingue tipo inválido, código 491, e versão inválida, código 492. MOC 7.0, Anexo I, página 73.

Portanto, apenas validar o XML da nota original ou o formato externo do lote de eventos pode não alcançar a causa da 493. É preciso conferir também os requisitos da parte específica.

Comece pelo evento que você tentou registrar

Cancelamento: confira os dados exigidos para o tipo de cancelamento utilizado. O leiaute inclui a descrição do evento, o protocolo da autorização e a justificativa. O cancelamento por substituição da NFC-e tem conteúdo adicional e não deve ser montado copiando somente os campos do cancelamento comum. MOC, Visão Geral, seção 5.9.

Carta de correção da NF-e: examine o texto da correção e os demais campos próprios da CC-e, inclusive as condições de uso previstas no leiaute. A adequação ao schema não autoriza corrigir qualquer informação fiscal por esse meio. Confirme com a contabilidade se a mudança pretendida pode ser feita por CC-e. MOC, seção 5.10.

Manifestação do destinatário: verifique qual manifestação foi escolhida e use o conteúdo correspondente àquela declaração. Não troque o evento apenas porque outro aceita menos campos. A NT 2020.001 v1.60 mantém a 493 na validação específica desses eventos. NT, seção 6.3.6.

EPEC ou pedido de prorrogação de industrialização: use o leiaute próprio e confirme a disponibilidade do serviço. O pedido de prorrogação se refere à NF-e e sua implementação depende da UF; o EPEC da NFC-e também tem adoção estadual. Não transporte um exemplo de CC-e para essas operações.

Como encontrar a causa

1. Separe o XML do evento enviado e o retorno correspondente. Identifique a chave da nota, tpEvento, verEvento, sequência, ambiente, UF e horário.

2. Leia o detalhe da resposta. Quando ela indicar um caminho como detEvento/nProt ou detEvento/descEvento, esse ponto deve orientar a investigação.

3. Valide o evento com os schemas oficiais aplicáveis ao tipo e à versão, incluindo a parte específica. Registre o erro completo do validador.

4. Compare o campo apontado com o conteúdo efetivamente gerado. Verifique ausência, formato, tamanho, ordem e presença de campos pertencentes a outro evento.

5. Corrija a informação verdadeira ou o gerador, conforme a causa. Depois, gere e assine novamente o evento pelo sistema.

A Omie orienta uma análise detalhada da aderência ao leiaute, e a CIGAM destaca a conferência dos campos exigidos no schema do evento. O código isolado não identifica qual deles precisa de ajuste.

Soluções conforme o diagnóstico

Um campo obrigatório ficou fora do XML: se a informação existe no sistema, peça a correção do seu envio pela integração. Se ainda não foi preenchida, informe o conteúdo verdadeiro exigido para aquele evento. A falta de um campo específico é um dos cenários descritos pela TecnoSpeed.

O protocolo não aparece ou foi modificado: consulte a autorização correspondente e recupere o protocolo integral. Não complete com zeros, não corte dígitos e não aproveite o protocolo de outra nota. Se a autorização não estiver comprovada, esclareça a situação do documento antes de insistir no cancelamento.

O evento contém campos de outra operação: o fornecedor deve ajustar a seleção e a montagem de detEvento. Não altere tpEvento para fazer a mensagem se encaixar em um schema diferente, pois isso muda a declaração fiscal pretendida.

Tudo começou depois de uma atualização: confira o pacote de eventos e a versão efetivamente aceita pelo serviço. A versão do leiaute da nota e a versão do evento são informações distintas; não se deve preencher ambas automaticamente com o mesmo valor.

O validador aceita, mas a rejeição permanece: confirme se ele verificou o evento específico e se o arquivo validado é idêntico ao transmitido. Encaminhe XML, retorno e versões ao suporte. Evite enviar dados fiscais reais a validadores desconhecidos.

Exemplo hipotético

Uma oficina solicita o cancelamento de uma NF-e autorizada. A justificativa foi preenchida corretamente, mas uma falha na integração deixa de levar o protocolo da autorização para nProt dentro de detEvento. O diagnóstico aponta a ausência desse elemento.

O suporte recupera o protocolo da própria nota e corrige a montagem do evento. O sistema gera e assina um novo envio. A oficina só considera o cancelamento concluído depois de conferir a aceitação e a situação atual da NF-e. A correção do schema, sozinha, não elimina as demais condições para cancelar.

Como confirmar a solução

Confira o resultado individual do evento, não apenas o processamento do lote. Verifique se chave, tipo, sequência e protocolo correspondem à operação pretendida. Se o objetivo era cancelar, confirme também a situação cancelada do documento; para outros eventos, confira o registro e, quando previsto para aquele tipo, o vínculo com a nota. No EPEC, o registro antecede a autorização da NF-e e não deve ser confundido com um evento já vinculado a uma nota autorizada. MOC, seção 5.12.4.

Se uma tentativa anterior teve retorno inconclusivo, consulte o histórico antes de reenviar. Não avance a sequência nem crie uma nova nota apenas para fazer desaparecer a pendência.

Revisão: 09/10/2026. A regra D06 é geral, mas os eventos aceitos variam conforme modelo, serviço, versão e UF.

Referências complementares

• NT 2015.001 v1.30, pedidos de prorrogação e seus eventos: https://dfe-portal.svrs.rs.gov.br/NFE/DownloadArquivoEstatico/?sistema=NFE&tipoArquivo=3&nomeArquivo=NT+2015.001+-+v+1.30.pdf

• NT 2014.001 v1.41, EPEC da NF-e: https://dfe-portal.svrs.rs.gov.br/NFE/DownloadArquivoEstatico/?sistema=NFE&tipoArquivo=3&nomeArquivo=NT_2014_001+v1.41+-+Evento+EPEC.pdf

• NT NFC-e 2014.003 v1.02, adoção do EPEC a critério da UF: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=HYPw%2BDBncKo%3D