xPed em compra: pedido da nota e diferença para o pedido por item
<xPed>compra › xPedRevisã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