v7 Custom

O pedido foi enviado. O fornecedor confirmou o que sua operação precisa?

O comprador emite um pedido de 600 unidades para entrega na sexta-feira. O ERP mostra “pedido aberto”; a planilha de abastecimento assume as 600 unidades na data solicitada. Dois dias depois, alguém encontra um e-mail do fornecedor: 360 unidades serão entregues na segunda, 240 ficaram sem previsão e o preço de uma linha mudou. O pedido existia, mas o compromisso que sustentava estoque, produção e promessa ao cliente nunca foi confirmado.

A IA pode ler respostas em e-mails e PDFs, relacioná-las ao pedido e destacar diferenças. Isso resolve parte do trabalho. O risco começa quando uma extração correta vira atualização automática sem regra: receber uma mensagem não é aceitar o pedido; aceitar o cabeçalho não confirma cada linha; quantidade confirmada não prova embarque; embarque não prova recebimento.

Este artigo apresenta o método CONFIRMA, um protocolo para transformar respostas de fornecedores em decisões operacionais rastreáveis. A unidade de valor não é “e-mail processado”. É necessidade protegida por um compromisso válido, divergência decidida por quem tem alçada e resultado reconciliado no recebimento.

Por que confirmação é uma etapa própria

A documentação 2026 do Oracle Fusion Cloud Procurement trata o reconhecimento do fornecedor como um estado do processo: ele pode aceitar, rejeitar, aceitar parcialmente ou propor mudanças de preço, quantidade, datas e desdobramento de entregas. A mudança proposta volta para revisão e aprovação do comprador. Essa lógica mostra por que “PO enviado” não deve alimentar sozinho a disponibilidade futura.

Na biblioteca SAP Business ByDesign, versão de maio de 2026, confirmações podem chegar eletronicamente ou ser registradas a partir de fax, correio e anexos de e-mail. Data, quantidade e preço confirmados podem divergir do pedido e precisam ser tratados. A tecnologia corporativa já reconhece o problema; muitas PMEs ainda o resolvem em caixa de entrada, telefone e memória.

O padrão GS1 EANCOM ORDRSP separa reconhecimento de recebimento, confirmação de aceitação, proposta de alteração e não aceitação total ou parcial. A distinção é decisiva: “recebi seu pedido” responde sobre comunicação; “aceito 360 unidades para segunda-feira” responde sobre compromisso.

Em 2026, a oportunidade da IA está justamente na ponte entre mensagem desestruturada e decisão. Uma pesquisa da McKinsey com 278 embarcadores concluiu que o retorno passa por tornar trade-offs visíveis, aproximar análise da decisão operacional e conectar decisão à execução. Confirmação de compra é um caso pequeno o bastante para pilotar e importante o bastante para afetar venda, estoque, obra ou produção.

Oito estados que não podem virar um só

  1. Solicitado: a necessidade foi registrada, mas ainda pode aguardar aprovação interna.
  2. Aprovado: orçamento, centro de custo e alçada interna autorizaram a compra.
  3. Emitido: o pedido foi criado e enviado ao contato ou canal correto.
  4. Recebido pelo fornecedor: há evidência de que a mensagem chegou e foi compreendida, sem compromisso de atendimento.
  5. Confirmado: cada linha relevante tem quantidade, preço, data, local, unidade e condição aceitos.
  6. Alterado: existe contraproposta ou confirmação parcial aguardando decisão do comprador.
  7. Expedido: há evento de embarque vinculado às linhas confirmadas; previsão ainda não é recebimento.
  8. Recebido e reconciliado: quantidade, qualidade, data e condição realizadas foram comparadas com pedido e confirmação.

Um painel que chama todos esses estados de “em aberto” esconde a ação necessária. Um agente que chama todos de “confirmado” fabrica segurança. O primeiro ganho operacional é representar o estado real e seu próximo responsável.

Método CONFIRMA: da emissão ao aprendizado

  1. C — Conectar a necessidade ao pedido: registre por que a linha existe, onde será usada, data necessária, criticidade, estoque projetado e compromisso afetado. Sem impacto downstream, toda divergência parece igual.
  2. O — Obter a resposta certa: defina canal, contato, prazo de resposta e nível exigido — documento, linha ou programação de entrega. O agente pode cobrar silêncio, mas precisa mostrar a versão do pedido a que responde.
  3. N — Normalizar sem adivinhar: extraia número do pedido, revisão, item, código do fornecedor, unidade, quantidade, preço, moeda, impostos, data e local. Preserve o original e marque campos ausentes, ambíguos ou inferidos.
  4. F — Filtrar divergências: compare resposta com pedido, contrato e tolerâncias explícitas. Separe alteração comercial, logística, fiscal, cadastral e de qualidade. Uma diferença de unidade pode ser mais grave que uma diferença pequena de preço.
  5. I — Indicar impacto: traduza a divergência para cobertura de estoque, produção, obra, pedido de cliente, caixa e custo de urgência. Prioridade deve refletir consequência, não apenas ordem de chegada do e-mail.
  6. R — Rotear a decisão: encaminhe preço a compras, risco de ruptura ao planejamento, substituição à área técnica e antecipação de pagamento ao financeiro. Mostre evidência, regra, alternativas e prazo para decidir.
  7. M — Materializar o acordo: depois da aprovação, atualize o sistema oficial, gere revisão quando necessário e confirme ao fornecedor o que foi aceito. Rascunho no chat ou planilha paralela não altera o compromisso.
  8. A — Acompanhar até reconciliar: ligue confirmação a embarque, recebimento, inspeção e desempenho do fornecedor. Aprenda com diferença entre confirmado e realizado, não apenas com rapidez de resposta.

Contrato de campos: o que a IA pode e não pode completar

Antes do modelo, defina um contrato de dados. Para cada campo, registre tipo, unidade, fonte oficial, tolerância, validade e ação quando ausente. Um mínimo útil inclui:

  • pedido, revisão, fornecedor, filial, contato e canal de origem;
  • linha, código interno, código do fornecedor, descrição e eventual substituto;
  • quantidade pedida e confirmada, unidade e fator de conversão validado;
  • preço, moeda, tributos, frete, condição de pagamento e vigência;
  • data solicitada, data confirmada, local e possíveis entregas parciais;
  • fonte original, horário de captura, confiança da extração e trecho de evidência;
  • delta calculado, regra ou tolerância acionada, impacto e responsável;
  • decisão, aprovador, validade, versão atualizada e retorno ao fornecedor;
  • embarque, recebimento, inspeção, divergência real e encerramento.

Uma pesquisa de 2026 sobre planejamento de compras apoiado por IA mostra por que extração e decisão devem ser separadas: termos como lote mínimo, lead time, faixas de preço, limites de alocação e aprovação de substitutos podem estar espalhados por contratos e aditivos. O trabalho propõe usar a extração como hipótese, exigir evidência de origem e aplicar uma etapa de verificação antes do plano. Para uma PME, a implementação pode ser mais simples, mas o princípio permanece: campo lido pelo modelo não vira compromisso sem validação compatível com sua consequência.

Matriz confiança da resposta × impacto da divergência

  • Alta confiança, baixo impacto: atualizar campos permitidos e registrar a reconciliação; amostrar casos para controle.
  • Alta confiança, alto impacto: bloquear atualização com efeito comercial ou operacional, calcular cenários e pedir decisão da alçada correta.
  • Baixa confiança, baixo impacto: solicitar esclarecimento ou confirmação estruturada; não completar lacuna com texto plausível.
  • Baixa confiança, alto impacto: manter o pedido como não confirmado, escalar e proteger o compromisso downstream.

Confiança considera identidade do remetente, referência à revisão correta, completude por linha, consistência de unidades, assinatura ou canal e concordância com documentos vigentes. Impacto combina ruptura, atraso, margem, desembolso, segurança, qualidade, reversibilidade e número de clientes ou frentes afetadas.

Exemplo hipotético: três linhas, três decisões

Uma distribuidora envia um pedido com 600 filtros, 40 bombas e 20 kits de vedação para sexta-feira. A resposta do fornecedor confirma 600 filtros no prazo, propõe 25 bombas para segunda e substitui o kit por um código “equivalente”, sem ficha técnica.

  1. Filtros: alta confiança e sem divergência; o agente prepara a atualização da linha e guarda a evidência.
  2. Bombas: a extração pode estar correta, mas há impacto de cobertura. O agente calcula quais pedidos de clientes ficam expostos e roteia opções: entrega parcial, transferência, fornecedor alternativo ou renegociação.
  3. Kits: similaridade textual não prova equivalência. A linha permanece pendente até validação técnica, cadastro do substituto e aceite comercial.

O caso ilustra por que aprovação no cabeçalho é insuficiente. O mesmo documento contém uma linha rotineira, uma exceção logística e uma decisão técnica. A autonomia deve ser por tipo de campo, regra e consequência.

Fronteiras de autonomia do agente

Pode operar automaticamente dentro de regras testadas: localizar pedido e revisão, classificar mensagem, extrair campos, comparar com tolerâncias, enviar lembrete aprovado, abrir caso, calcular impacto e atualizar informação sem efeito quando a confiança mínima for atendida.

Deve preparar e pedir confirmação: mudança de preço, quantidade, prazo, pagamento, frete, impostos, divisão de entrega, cancelamento, substituição de item ou atualização que altere planejamento e promessa a cliente.

Deve bloquear e escalar: pedido desconhecido, revisão divergente, remetente não verificado, alteração de dados bancários, conflito com contrato, unidade sem conversão validada, substituto sem homologação, valor acima da alçada ou instrução escondida em anexo tentando desviar o fluxo.

O agente não negocia no silêncio. Se uma contraproposta expira sem resposta, o caso volta a “pendente”; não vira aceite implícito.

Placar que mede proteção da operação

  • Cobertura de confirmação: linhas críticas confirmadas dentro do prazo dividido pelas linhas críticas emitidas.
  • Latência de compromisso: tempo entre envio e confirmação completa, separado do simples aviso de recebimento.
  • Exceções antecipadas: divergências decididas antes de afetar produção, obra, estoque ou promessa ao cliente.
  • Acurácia da promessa do fornecedor: diferença entre quantidade/data confirmada e quantidade/data recebida.
  • Toques por linha: mensagens, cobranças e intervenções humanas necessárias até a reconciliação.
  • Custo de reação: frete expresso, compra emergencial, parada, remanejamento e desconto causados por exceção tardia.
  • Atualização sem alçada: mudanças com efeito aplicadas fora da política; a meta é zero.

Velocidade sozinha engana. Um robô pode fechar e-mails mais rápido enquanto o time continua descobrindo faltas no dia da entrega. Compare coortes de fornecedores e itens com criticidade semelhante e acompanhe até o recebimento.

Doze perguntas para o diagnóstico

  1. Qual evento transforma uma requisição aprovada em pedido efetivamente enviado?
  2. Como se prova que o fornecedor recebeu a revisão correta?
  3. Quais linhas exigem confirmação e em quanto tempo?
  4. Quais campos precisam ser confirmados por linha e por programação de entrega?
  5. Onde chegam respostas: portal, EDI, e-mail, WhatsApp, PDF ou telefone?
  6. Como unidades, códigos do fornecedor e itens substitutos são reconciliados?
  7. Quais tolerâncias podem ser aceitas sem nova aprovação?
  8. Quem decide preço, prazo, quantidade, substituição e pagamento?
  9. Que estoque, ordem, obra ou pedido de cliente é afetado por cada atraso?
  10. Como uma contraproposta aceita atualiza ERP, planejamento e fornecedor?
  11. Como embarque e recebimento retornam à confirmação original?
  12. Qual custo atual de cobranças, urgências e promessas baseadas em data não confirmada?

Piloto assistido de 20 dias úteis

  1. Dias 1–5: selecione uma família crítica e poucos fornecedores; mapeie estados, campos, tolerâncias, alçadas e linha de base.
  2. Dias 6–10: rode o agente em modo sombra sobre respostas reais, sem escrever no ERP; compare extração e pareamento linha a linha.
  3. Dias 11–15: permita lembretes e abertura de casos; compradores aprovam toda atualização com efeito e registram correções.
  4. Dias 16–20: conecte confirmação a embarque e recebimento; teste revisão de pedido, entrega parcial, unidade divergente, substituto e mensagem não confiável.

Amplie apenas se o sistema distingue solicitado de confirmado, a resposta aponta para a revisão certa, as tolerâncias estão documentadas e alguém responde por cada exceção. IA só gera retorno quando processo, dados, responsável, rotina de revisão e implantação operacional caminham juntos.

Fontes consultadas

Seu planejamento usa datas pedidas ou compromissos confirmados?

O diagnóstico da V7 Agents mapeia pedido, canais de resposta, tolerâncias, alçadas e impacto downstream para escolher um piloto de IA que antecipe exceções sem aceitar mudanças no automático.