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:TransformRevisã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.
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.