Rejeição 762: confira o grupo de empenho, pedido e contrato no XML

A rejeição 762 pede uma conferência das informações de compra enviadas no documento fiscal. Ter um pedido comercial no sistema não é, por si só, o problema. Na NT 2026.002 v1.11, a presença do grupo compra é incompatível com NFC-e 65 ou NF-e 55 com DANFE Simplificado Tipo 2 (tpImp=6).

Antes de apagar pedidos ou refazer a venda, confirme a mensagem completa, o modelo e o formato enviados. Preserve o vínculo comercial da operação e investigue como ele foi convertido em XML. Essa distinção evita transformar um ajuste de emissão em perda de histórico do cliente, do contrato ou da entrega.

O alcance da mensagem 762

A NT 2026.002 v1.11, página 19, regra ZB01-10, estabelece: “Rejeição: NFC-e ou NF-e com DANFE Simplificado Tipo 2 com dados de compras (Empenho, Pedido, Contrato)”. O grupo verificado é compra, nas validações de NFeAutorizacao (página 8). No PDF, a linha abrange modelo 65 e modelo 55 com tpImp=6, está marcada como obrigatória e produz rejeição, sem exceção particular. NT 2026.002 v1.11.

A redação do MOC 7.0 era “Rejeição: NFC-e com dados de compras (Empenho, Pedido, Contrato)”, para modelo 65. O recorte da NT não alcança indiscriminadamente toda NF-e 55. O DANFE Simplificado Tipo 2 é uma representação da NF-e; a nota continua modelo 55, com a condição específica tpImp=6.

O índice SVRS consultado em 15/10/2026 apresenta a v1.11 e ressalva possível mudança de datas. Na página 3 da NT, ZB01-10 integra o conjunto previsto para testes em 01/07/2026 e produção em 03/08/2026. O adiamento para 14/12/2026 limita-se a I08-180, BA02-35 e VC02-40; não inclui ZB01-10.

A inspeção pessoal do PNG documental existente da página 19, realizada nesta sessão, confirma a linha ZB01-10 íntegra, diferente de trechos riscados nas regras W16. Não foi inferida vedação para qualquer modelo 55. O cronograma documental não certifica a implantação individual no autorizador.

Registre UF emitente, serviço e ambiente: tpAmb=1 é produção; tpAmb=2, homologação. Examine a resposta no ambiente em que ocorreu. Não houve teste fiscal de emissão nem acesso operacional ao ALRA.

Onde procurar os dados indevidos

O grupo compra, no cabeçalho do XML, pode conter nota de empenho (xNEmp), pedido (xPed) ou contrato (xCont). Não é preciso que os três estejam preenchidos para investigar o grupo. A rejeição está ligada à estrutura enviada, e não a uma avaliação sobre o tamanho do número do pedido ou a regularidade jurídica do contrato.

Esses campos podem vir de uma integração com compras do cliente, de um perfil fiscal compartilhado ou de uma nota copiada. O sistema também pode gerar o grupo automaticamente a partir de um pedido comercial, mesmo que o operador não tenha preenchido uma seção chamada “Informação de Compra”. Identificar a origem impede que a mesma estrutura reapareça no envio seguinte.

Não confunda o pedido interno com compra no XML. No MOC, página 21, xPed do item (I60) é distinto de compra/xPed no cabeçalho, página 64. O suporte deve demonstrar o caminho gerado. O esquema 010f confirma as duas declarações de xPed e a estrutura completa de compra. Não mova conteúdo entre campos apenas para evitar a rejeição.

Diagnóstico antes de corrigir

Guarde a resposta original e o XML efetivamente transmitido. Confira cStat e xMotivo no retorno. Anote número, série, chave, horário e versão do emissor. Confira mod, tpImp, ambiente e UF do emitente. Se o suporte analisa um XML regenerado depois da rejeição, ele pode deixar de enxergar a causa original; preserve as duas versões para comparação.

Localize compra dentro de infNFe. Relacione cada valor com sua fonte: cadastro do cliente, pedido importado, contrato ou configuração do documento. Confira também se o retorno está associado à chave analisada. Se não houver certeza sobre uma autorização anterior, consulte a situação antes de refazer o envio.

Verifique com o responsável pelo sistema se a edição da nota interfere em estoque, contas ou vínculos comerciais. A documentação fiscal não comprova menus, estornos ou efeitos de edição no ALRA. Valide o fluxo da versão instalada antes de alterá-lo.

Correção por cenário

O grupo veio de uma configuração reutilizada

Se a emissão é corretamente uma NFC-e, e empenho/pedido/contrato foram enviados indevidamente nesse grupo, corrija a configuração que gera compra e regenere o documento sem essa estrutura. Preserve o pedido comercial verdadeiro. Limpar o grupo fiscal não exige excluir a venda ou romper a rastreabilidade interna.

Confira o novo XML, porque apagar apenas um campo da tela pode deixar outro filho preenchido ou manter o grupo. Faça a alteração pelo emissor e gere nova assinatura; editar o arquivo já assinado não é uma solução operacional adequada.

A NF-e utiliza DANFE Simplificado Tipo 2

Com mod=55 e tpImp=6, a regra também precisa ser considerada. Se o grupo é herança indevida, ajuste sua geração. Se a operação necessita de informação fiscal de empenho ou contrato, peça ao responsável fiscal para avaliar o documento e o formato cabíveis antes de removê-la.

Uma venda vinculada a contratação pública, por exemplo, pode exigir análise de condições que este código não resolve sozinho. Não retire uma obrigação real nem altere o tipo de impressão somente para atravessar a validação. O formato selecionado precisa ser permitido e coerente com a operação.

A NF-e não tem tpImp=6 ou o XML não contém compra

Não force a explicação da 762. Confira se o arquivo e o retorno pertencem à mesma tentativa e se existe transformação entre o ERP e o autorizador. A regra não proíbe o grupo em toda NF-e 55. Uma associação incorreta de resposta ou uma versão antiga de integração deve ser tratada pelo suporte com evidências.

Um exemplo de investigação

Uma loja fictícia recebe pedido interno PV-2846 para uma compra de R$ 735. Na emissão da NFC-e, uma integração transporta o identificador para compra/xPed. A SEFAZ retorna 762. A empresa confirma que o documento escolhido é adequado à venda e que o grupo de cabeçalho foi criado automaticamente, sem necessidade naquele cenário.

O suporte ajusta o mapeamento por modelo e mantém PV-2846 ligado à venda no controle comercial. O XML seguinte não contém compra; produtos, destinatário, valores e informações fiscais verdadeiras permanecem coerentes. O exemplo não é uma prescrição tributária para vendas a órgão público nem para qualquer operação que possua contrato.

Como verificar o encerramento

Leia o novo resultado do documento e confirme a chave correspondente. Se houver autorização, preserve XML e protocolo e confira os vínculos de venda, estoque e financeiro. Se aparecer outra rejeição, trate a causa seguinte; ausência de 762 não garante aprovação das demais validações.

Acione o suporte quando o grupo retorna automaticamente, quando as telas não permitem localizar sua origem ou quando o XML contradiz o retorno. Encaminhe ao contador dúvidas sobre a necessidade fiscal de empenho/contrato e sobre o documento permitido. O objetivo é emitir com informações verdadeiras e rastreáveis, sem apagar a obrigação comercial para eliminar uma mensagem.

Fontes e limites

Pesquisa e revisão textual em 15/10/2026, horário de Brasília. Primárias capturadas nesse dia reutilizadas por hash; três corpos específicos lidos. Sem transmissão de teste, certificação individual estadual ou comprovação de efeitos no estoque e financeiro do ALRA.

• NT 2026.002 v1.11, páginas 3, 7, 8 e 19: calendário, serviço e ZB01-10. Reuso das leituras e da inspeção pessoal do PNG existente da página 19 realizadas na pesquisa 750 desta sessão.

• Documentos SVRS: captura de 15/10, disponibilidade da v1.11 e ressalva de datas.

• MOC 7.0, Anexo I, páginas 21, 64 e 127, e pacote 010f do Portal NF-e: campos de pedido no item e no cabeçalho, grupo compra e regra original 65. Regras de empenho 359/360/361 possuem condições próprias; não são exceções à 762.

• Oobj, corpo HTTP 200 e WEB de 19/09/2024: identifica o grupo e seus filhos. O trecho XML apresentado tem abertura malformada e não foi copiado nem validado.

• TecnoSpeed, corpo WEB de 09/05/2025, separado da tentativa direta HTTP 403. XML e JSON apresentados têm problemas sintáticos e não foram usados como exemplos válidos. TX2, REC e API desse fornecedor não são rotinas ALRA.

• Berga, corpo HTTP 200 e WEB: ajuda a investigar configuração compartilhada. Afirmações amplas sobre órgãos públicos, licitação, desoneração ou documento obrigatório não foram generalizadas. Não foi adotada a simples transferência de empenho para informações complementares.

Os guias abordam NFC-e; a extensão ao Tipo 2 vem da primária. Datas relativas diferentes entre WEB e captura Berga não foram convertidas em data absoluta. Novas leituras não autenticam atos antigos. Históricos preservados, revisão cruzada independente pendente e publicação não realizada.