Rejeição 215: como localizar a falha no schema XML

A rejeição 215 — Falha no schema XML significa que a mensagem não passou na validação de estrutura e formato feita com o XSD. O código sozinho não identifica a tag errada: o próximo passo é obter o detalhe da validação e conferir o XML efetivamente enviado com o schema adequado ao serviço e à versão. A regra D01 está no MOC 7.0, Anexo I, seção 4.1.3, p. 72.

Nesta página:

• O que conferir primeiro
• Exemplo de formato
• Atenção ao lote e à nova tentativa
• Como interpretar o detalhe do validador

O que conferir primeiro

1. Identifique a mensagem rejeitada. Guarde cStat, xMotivo, serviço chamado, ambiente e versão do XML. Uma falha de schema pode ocorrer em mensagens diferentes; não conclua que se trata de um evento apenas pelo código 215.
2. Obtenha o detalhe técnico. No emissor ou na integração, procure o erro do validador: elemento, caminho, linha/coluna ou formato esperado, quando disponíveis. Se o retorno informar somente o código, peça ao suporte uma validação local do XML enviado.
3. Valide com o XSD correspondente. Use o pacote oficial aplicável à mensagem e ao ambiente. O mesmo leiaute 4.00 recebe atualizações de schema; instalar um pacote antigo pode levar a um diagnóstico incorreto. Consulte os schemas oficiais no Portal Nacional da NF-e.
4. Corrija a origem apontada. Confira presença e ordem das tags, atributos, namespace, tamanho dos textos, formato de datas e valores e opções permitidas pelo XSD. Se a estrutura foi gerada incorretamente pelo software, a correção pertence ao emissor; se o valor cadastrado viola o formato permitido, ajuste o cadastro com o dado real.

Uma mensagem XML pode ter todas as tags fechadas corretamente e ainda violar o schema. Por exemplo, um campo monetário pode usar vírgula quando exige ponto decimal, ou um elemento pode aparecer na ordem errada. Isso é diferente de uma regra fiscal de cálculo: passar no XSD não garante aprovação nas validações de negócio.

Exemplo de formato

Fragmentos sintéticos e parciais de vNF, sem o restante da NF-e:

<!-- Formato inadequado para o valor monetário no XML -->
<vNF xmlns="http://www.portalfiscal.inf.br/nfe">218,00</vNF>

<!-- Formato decimal adequado; o valor ainda precisa corresponder à operação -->
<vNF xmlns="http://www.portalfiscal.inf.br/nfe">218.00</vNF>

O exemplo ilustra um formato inválido, não uma causa universal da 215. Esses fragmentos não são documentos completos nem estão prontos para transmissão. A definição de vNF aparece no MOC, campo W16, e sua ficha na Biblioteca ajuda a localizar o campo.

Atenção ao lote e à nova tentativa

No MOC, D01 também relaciona o código 225 à falha no schema XML do lote de NF-e no serviço de autorização. Preserve a distinção entre a mensagem externa do lote e o documento que ela contém; não troque um código pelo outro no diagnóstico. O manual informa que um erro de schema em uma NF-e pode provocar rejeição de todo o lote.

Após a correção, gere novamente o XML pelo emissor, valide-o com o schema aplicável e confira o resultado antes de nova tentativa. Não edite manualmente um documento já assinado: a regeneração e a assinatura devem acompanhar a correção. Se o retorno estiver incompleto ou houver dúvida sobre o processamento anterior, consulte a situação do documento antes de repetir o envio.

Para consultar a documentação da estrutura do documento, use o Dicionário do XML. Ele ajuda a localizar campos; a mensagem do validador e o pacote oficial são as referências para identificar a falha concreta.

Como interpretar o detalhe do validador

Se o validador informa elemento inesperado, confira o caminho completo e o elemento esperado naquele ponto. O XML pode ter todas as tags corretamente fechadas, mas a sequência dos filhos do grupo estar fora da ordem do XSD. Não mova uma tag só pelo nome: verifique o grupo pai, a alternativa permitida e a posição definida no schema correspondente à mensagem.

Se informa conteúdo fora do padrão, confira o tipo do campo: data e hora, número decimal, comprimento, enumeração ou máscara. O exemplo de vNF com vírgula mostra esse cenário. Se informa elemento obrigatório ausente, determine se o pai existe e se a exigência é estrutural naquele caminho; uma tag homônima em outro grupo não supre o elemento.

Se aponta raiz, namespace ou versão, confira a mensagem enviada ao serviço. Uma NF-e isolada e um envelope de lote têm raízes diferentes; um evento possui estrutura própria. Um documento que valida isoladamente ainda pode estar dentro de um envelope incorreto. O namespace oficial da NF-e é http://www.portalfiscal.inf.br/nfe; seu prefixo visual não substitui o URI associado. MOC 7.0, seção 4.1.3, pp.72–73.

O trecho apontado deve ser conferido no arquivo realmente transmitido, com a dependência de schemas do pacote correto. Valide novamente depois de corrigir a origem. Se o erro mudou de caminho, leia a nova mensagem; a validação pode revelar uma falha seguinte depois da primeira correção. Se o XML passa no XSD, isso ainda não comprova autorização: assinatura, cadastro, relações entre campos e regras fiscais são verificações distintas.

Para acionar o suporte, reúna serviço, raiz, atributo de versão, ambiente, versão do pacote XSD, mensagem literal do validador e caminho/linha, quando disponíveis. Compartilhe um recorte protegido e preserve o arquivo original nos registros autorizados. O diagnóstico não exige publicar dados pessoais, certificado ou XML completo em um fórum.