Rejeição 762: dados de compra na NFC-e ou NF-e Tipo 2
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 762, regra ZB01-10, verifica a presença do grupo compra em NFC-e ou em NF-e com DANFE Simplificado Tipo 2 (tpImp=6). A NT 2026.002 v1.11 amplia expressamente o alcance ao modelo 55 nesse contexto; não é uma proibição de todo pedido ou contrato na atividade da empresa.
Qual grupo está restringido
Localize NFe/infNFe/compra. Ele reúne xNEmp, identificação da nota de empenho, xPed, pedido, e xCont, contrato de compra. A regra incide na presença desse grupo no documento indicado, mesmo que os dados nele sejam verdadeiros. Isso não autoriza apagar o contrato, o pedido ou o empenho dos registros comerciais.
O MOC 7.0, p. 127, apresentava a ZB01-10 para modelo 65. A NT 2026.002 v1.11, p. 19, apresenta 55/65 e o texto NFC-e ou NF-e com tpImp=6. A linha está íntegra na tabela, diferente de outras linhas rasuradas nessa NT. Não generalize a restrição a toda NF-e 55.
Cronograma e exemplos de montagem
O cronograma da NT 2026.002, p. 3, agrupa a ampliação da ZB01-10 ao Tipo 2 no bloco de homologação em 01/07/2026 e produção em 03/08/2026. O adiamento para 14/12/2026 na versão 1.11 é específico de I08-180, BA02-35 e VC02-40, não desta linha. Cronograma previsto não demonstra habilitação individual; o retorno e o contexto do autorizador precisam ser conferidos.
No primeiro cenário sintético, uma NFC-e conserva compra porque o pedido comercial foi copiado integralmente para o XML. No segundo, o sistema gera NF-e 55 com tpImp=6 e mantém o mesmo grupo usado em uma NF-e convencional. Em ambos, a presença deve ser avaliada diante do modelo e da impressão reais.
Um XML sintético de pedido não comprova o contexto que dispara a 762. Os exemplos são textuais e dependem do XML original protegido, especialmente ide/mod, ide/tpImp e compra. Não invente empenho nem altere a impressão para contornar a validação.
Como corrigir preservando o negócio
Confirme empresa, ambiente e mensagem da tentativa. Compare a origem comercial com a regra do gerador que inclui o grupo. Se houve transporte indevido, ajuste o mapeamento do documento rejeitado, mantendo pedido, contrato e histórico na origem. Se a representação documental precisa de outra avaliação, leve a operação e os documentos ao responsável fiscal; a rejeição não escolhe modelo ou tratamento tributário.
compra/xPed não é o mesmo campo que det/prod/xPed, pedido de compra no item. A presença de um nome semelhante em outro ancestral não faz dele o alvo desta regra nem autoriza mover dados como solução automática. As regras 359/360/361 tratam do empenho em contextos específicos de NF-e e não tornam compra permitido no documento restringido.
Gere novamente a tentativa rejeitada e confira a resposta individual. Preserve documentos autorizados, assinatura e dados comerciais. Esclareça qualquer resultado anterior incerto antes de um novo envio.
Fontes oficiais
- MOC 7.0 — Anexo I: p. 64 compra/xNEmp/xPed/xCont; p. 127 ZB01-10; grupo I xPed do item.
- NT 2026.002 v1.11: pp. 3 e 19 ZB01-10 íntegra/cronograma.