Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Informações complementares da operação

xPed em compra: pedido da nota e diferença para o pedido por item

<xPed>compra › xPed

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

compra/xPed informa o pedido de compra no nível da nota, em /nfeProc/NFe/infNFe/compra/xPed. Ele é o item ZB03 do MOC. Há outro campo de mesmo nome no produto: det/prod/xPed. Localizar apenas a palavra xPed não basta para saber qual referência está sendo usada.

Qual é a diferença para o xPed do produto?

Ocorrência Escopo Tamanho documentado
compra/xPed Referência do pedido na nota 1–60 caracteres
det/prod/xPed Pedido relacionado ao item, interesse de controle B2B 1–15 caracteres

O item também pode conter nItemPed, número do item no pedido de compra. Essa associação identifica a linha comercial a que o produto corresponde. compra/xPed não contém esse número de linha nem substitui o vínculo por item.

Uma nota vinculada a um único pedido pode apresentar a mesma referência nos dois contextos quando o processo real exigir. Se os itens vierem de pedidos diferentes, o campo único do cabeçalho não descreve automaticamente todas as relações. Preserve o vínculo de cada item e confirme o contrato de integração do destinatário antes de consolidar referências. Não copie um texto de 60 caracteres para o campo do produto limitado a 15.

Como representar o pedido de compra?

O grupo compra ocorre 0..1, e seu xPed também 0..1. Quando presente, o campo deve conter texto válido de 1 a 60 caracteres; preserve letras e zeros iniciais do documento original. Na sequência XML, ele aparece depois de xNEmp, se houver, e antes de xCont, se houver.

Hipótese sintética: o comprador identificou o pedido geral como PC-000345/2026. Fragmento parcial em relação à NF-e, sem pedido real:

<compra xmlns="http://www.portalfiscal.inf.br/nfe">
  <xPed>PC-000345/2026</xPed>
</compra>

Nesse trecho não existe vínculo por produto. Se o comprador exigir os campos de item, eles precisam ser representados em det/prod conforme o pedido e sua linha verdadeiros; o grupo demonstrado não os cria.

Um pedido transforma a operação em compra pública?

Não. xPed é a informação do pedido; empenho público é xNEmp e contrato é xCont. Esses documentos têm funções diferentes. A presença de pedido não estabelece regime tributário, desoneração ou compra governamental. As regras 359–361 do MOC examinam empenho e suas condições específicas, não a existência de pedido como substituto.

Para NFC-e, o MOC prevê rejeição 762 quando há compra. Isso vale também quando seu único filho é xPed; não se deve usar o grupo para contornar uma necessidade de referência comercial incompatível com o modelo.

Por que o destinatário não encontra o pedido?

Compare o pedido original, a referência armazenada e os dois caminhos no XML da mesma nota. Se compra/xPed estiver correto, mas o destinatário procurar det/prod/xPed, o problema pode ser um contrato de integração diferente, não o texto do pedido. Confira também zeros removidos, truncamento, espaço nas extremidades e associação com a linha errada. Ajuste o mapeamento após demonstrar a divergência e valide o XML gerado. Uma tag válida não garante conciliação comercial nem recebimento financeiro.

Fontes técnicas

MOC 7.0 — Anexo I — 7.0: p. 64, ZB01–ZB04; p. 21, I60/I61; p. 127, ZB01-10/762.

XSD NF-e/NFC-e — PL_010f_v1.04: linhas 6321–6362, compra/xPed.

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/compra/xPed
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
0–1 no contexto do elemento pai
Tipo
inline:TString · TString
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.

maxLength
60
minLength
1
pattern
[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}
whiteSpace
preserve