Rejeição 587: namespace padrão da NF-e na área de dados

A rejeição 587, regra D01d, trata de namespace diferente do padrão fiscal na área de dados. O namespace da NF-e é o identificador exato http://www.portalfiscal.inf.br/nfe. Ele não é uma URL de transmissão a ser trocada por HTTPS.

Nesta página:

• O que comparar nas declarações de namespace?
• A assinatura pode ter outro namespace?
• Exemplo: serializador introduz namespace de outro modelo
• Como distinguir 587, 404 e sucesso fiscal?

O que comparar nas declarações de namespace?

Compare a URI exata na raiz fiscal e o namespace efetivo dos elementos descendentes. Maiúsculas, barras extras, HTTPS ou outro domínio mudam o identificador. Uma declaração interna xmlns="" pode retirar um grupo do namespace herdado mesmo quando o nome da tag parece correto.

D01d é facultativa no MOC. O gerador deve seguir o padrão documentado independentemente de o autorizador devolver esse detalhamento ou uma falha mais geral. A conferência deve considerar o nome expandido de cada elemento relevante.

Fontes: MOC Anexo I, regra D01d.

A assinatura pode ter outro namespace?

Sim. A Visão Geral determina que o namespace de assinatura seja declarado na própria Signature: http://www.w3.org/2000/09/xmldsig#. Isso faz parte da estrutura oficial da assinatura e não deve ser apagado para tentar cumprir a frase resumida de D01d.

O envelope SOAP também possui seus namespaces de transporte. A regra fiscal não transforma toda a requisição SOAP em elementos NF-e. Delimite a área de dados e a assinatura nela prevista; não substitua em massa todas as URIs do arquivo.

Fontes: MOC Anexo I, regra D01d.

Exemplo: serializador introduz namespace de outro modelo

Em um cenário hipotético, um grupo fiscal herda o namespace de um objeto de integração externa. O texto de suas tags está certo, mas o nome expandido aponta para outro vocabulário. A busca textual pelo nome da tag não basta para reconhecer a falha.

Compare a árvore XML por namespace e localização, identifique o serializador que introduziu a declaração e regenere a mensagem. Não apague prefixos ou declarações de um arquivo já assinado: essa alteração pode invalidar sua integridade.

Fontes: MOC Anexo I, regra D01d.

Como distinguir 587, 404 e sucesso fiscal?

A 587 trata da URI de namespace; a 404 verifica prefixos no vocabulário fiscal. São verificações próximas, mas distintas. Um namespace correto pode estar expresso com prefixo vedado, e uma tag sem prefixo pode pertencer ao namespace errado.

Depois de corrigir a origem, valide XSD e assinatura da mensagem final. Isso não comprova autorização ou registro do evento. Se uma tentativa ficou com resultado desconhecido, consulte seu estado antes de executar nova ação.

Fontes: MOC Anexo I, regra D01d.

Limite do exemplo e preservação dos dados

A demonstração exige comparar a árvore e a assinatura originais em ambiente protegido. O exemplo textual identifica o erro sem fabricar XML assinado ou apagar o namespace legítimo de Signature. 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. 72, regra D01d, código 587; quadro completo e notas da seção.
• MOC 7.0 — Visão Geral, versão 7.00. pp. 49–51, declaração, namespace, otimização, UTF-8 e validação; pp. 53–55, assinatura XML.