Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Suplemento, assinatura e protocolo

Transform da NF-e: função e posição de cada transformação

<Transform>nfeProc › NFe › ds:Signature › ds:SignedInfo › ds:Reference › ds:Transforms › ds:Transform

Revisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

Cada Transform descreve uma etapa do processamento dos dados referenciados. Na assinatura da NF-e, existem exatamente dois dentro de Transforms, com algoritmos distintos: enveloped-signature e Canonical XML 1.0.

Caminho desta página: /nfeProc/NFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms/ds:Transform. O alias ds neste XPath representa o namespace http://www.w3.org/2000/09/xmldsig#; ele permite localizar o elemento, mas não exige esse prefixo na serialização fiscal.

Como se representa uma etapa isolada?

Cada elemento exige Algorithm do tipo TTransformURI. Este fragmento sintético parcial representa a etapa enveloped; sozinho não satisfaz o grupo completo de duas transformações:

<Transform xmlns="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

Na sequência do exemplo fiscal do MOC, enveloped vem antes de C14N. O verificador executa a ordem declarada; o schema restringe o conjunto e a unicidade, mas não fixa cada valor por posição.

Declaração XSD do contexto.

Quando XPath aparece e por que isso exige cautela?

O tipo fiscal admite zero ou mais filhos XPath como strings. Essa abertura estrutural não adiciona ao conjunto permitido a URI do algoritmo XMLDSig de filtro XPath. O algoritmo ativo continua sendo o declarado em Algorithm, restrito a enveloped ou C14N.

Por isso, não acrescente uma expressão como not(ancestor-or-self::ds:Signature) supondo que ela cria ou substitui a transformação enveloped. A especificação define o comportamento de cada algoritmo; a aceitação do texto pelo XSD não comprova seu uso semântico nem o suporte pelo autorizador.

XMLDSig: processamento e elementos.

Como conferir se a etapa foi executada corretamente?

Localize a Reference, resolva seu alvo e acompanhe a saída de cada transformação em um verificador controlado. Se o digest difere, compare os bytes e o contexto de namespace antes de concluir que é certificado incorreto. Se há algoritmo repetido, ausente ou fora da enumeração, a falha é de estrutura/perfil antes da matemática final.

Não remova uma etapa para adequar o XML à preferência de uma biblioteca, nem altere a ordem depois de assinar. Corrija a geração comprovadamente incompatível e revalide em cenário controlado. A Transform isolada acima explica estrutura; não é uma NF-e completa nem demonstra autorização.

MOC: perfil de assinatura, pp. 53–56.

Fontes e contexto

Schema específico XMLDSig da NF-e — PL_010f_v1.04 / xmldsig-core-schema_v1.01.xsd; MOC — Visão Geral — 7.0; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013.

Referência técnica para integração

XPath completo
/nfeProc/NFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms/ds:Transform
Namespace
http://www.w3.org/2000/09/xmldsig#
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
2–2 no contexto do elemento pai
Tipo
ds:TransformType
Preenchimento no catálogo
Condicional

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.