Pedido de compra em PDF: como automatizar a entrada no ERP

16 de setembro de 2026 · 8 min de leitura

Resposta curta: são quatro etapas entre o arquivo que o cliente mandou e o pedido gravado: receber, extrair os campos, traduzir o código de produto e gravar tratando a recusa do ERP. A maior parte dos projetos cuida bem da segunda e ignora a terceira e a quarta. É por isso que tanta automação de pedido funciona na demonstração e volta a exigir gente no segundo mês.

Este guia é sobre o problema geral, sem depender de qual ERP você usa. Se você roda Senior, o caminho específico está em como lançar pedido de venda no ERP Senior sem digitar.

As quatro etapas, e qual delas costuma ser esquecida

Por que OCR sozinho não resolve

OCR converte imagem em texto. É útil quando o PDF é digitalizado, e irrelevante quando o PDF já nasce digital, que é a maioria dos pedidos hoje. O problema do pedido não é enxergar os caracteres: é entender o que cada número significa.

Num layout que a ferramenta nunca viu, é preciso decidir qual coluna é quantidade e qual é preço unitário, distinguir endereço de entrega de endereço de cobrança, e perceber que aquele bloco no rodapé é a condição de pagamento. OCR com posição fixa de campo resolve isso para um layout, e quebra no layout seguinte. E layout seguinte é o normal: cada cliente manda do jeito dele.

O detalhe que faz o projeto vazar: o de-para de código

Extraído o pedido, você tem o código do produto na codificação do cliente. O comprador pede "1041.220"; no seu ERP aquilo é outro código. Sem essa tradução, não existe pedido para gravar.

A saída comum é uma planilha de de-para mantida à mão. Ela funciona algumas semanas. Depois entra produto novo, um cliente muda a codificação, alguém sai de férias, e a planilha passa a produzir erro em vez de evitar.

A saída que se sustenta é consultar o cadastro que o ERP já mantém para isso: quase todo ERP tem alguma forma de registrar o código do produto por cliente, porque isso é necessário para faturamento. Usar esse cadastro mantém uma única fonte de verdade, e ela fica onde deveria estar.

A parte que ninguém demonstra: quando o ERP recusa

O pedido foi lido, os códigos foram traduzidos, a gravação é chamada. E o ERP recusa. Não por bug: por regra de negócio que existe justamente para proteger o faturamento.

• quantidade abaixo do lote mínimo do produto
• cliente com benefício fiscal que exige um campo específico
• endereço de entrega ausente para aquele cliente
• tabela de preço divergente da praticada
• item sem cadastro para aquele cliente

Numa automação ingênua, cada recusa volta como erro técnico e alguém resolve na mão. O saldo: você automatizou o caminho fácil e devolveu todo o resto para a pessoa que pretendia liberar. Pior: agora ela precisa entender a mensagem do ERP além de digitar.

O desenho que funciona trata a recusa como aprendizado. A crítica vira um formulário com o que falta, alguém completa uma vez, e aquilo passa a valer para os próximos pedidos daquele cliente. O volume de intervenção cai a cada semana em vez de ficar constante.

Sete perguntas para fazer a quem vende a solução

Se você está avaliando fornecedores, estas perguntas separam demonstração de operação:

• O que acontece quando chega um layout que vocês nunca viram? Se a resposta for abrir chamado, você comprou uma fila de suporte, não uma automação.
• Esse mapeamento tem cota mensal? Há quem limite quantos layouts novos você pode pedir por mês.
• Como vocês resolvem o código do produto do cliente? Se for planilha mantida por você, o trabalho manual mudou de lugar, não sumiu.
• Vocês gravam no ERP ou entregam um arquivo? Entregar JSON ou planilha para alguém importar ainda deixa uma pessoa no meio.
• O que acontece quando o ERP recusa o pedido? A pergunta mais reveladora de todas.
• Como vocês cobram? Cobrança por linha ou por documento faz a conta crescer justamente quando você usa mais.
• Posso testar com um pedido real meu, hoje? Quem tem o produto funcionando aceita. Quem tem slide, não.

O que medir depois que entrar no ar

Vale combinar as métricas antes de começar, senão a discussão vira percepção:

• tempo do pedido, do recebimento até estar gravado no ERP
• proporção que passa sem intervenção, e a tendência dela semana a semana, que é o que mostra se o sistema aprende
• campos corrigidos na revisão, para saber onde a leitura erra
• recusas do ERP, separando as que já têm tratamento das inéditas
• devoluções por erro de digitação, que é a economia que ninguém lança na planilha do projeto

Perguntas frequentes

OCR resolve a entrada de pedido em PDF?

Só a parte de enxergar o texto, e apenas quando o PDF é digitalizado. Ele não sabe qual número é quantidade e qual é preço num layout novo. Para pedido, o trabalho começa depois do OCR.

Quanto tempo leva para automatizar?

Ler os primeiros layouts costuma funcionar em dias. O prazo real depende da integração com o ERP e do de-para: se o ERP já expõe API de gravação de pedidos e mantém o cadastro de produto por cliente, o caminho é curto.

É seguro deixar gravar sozinho?

O desenho recomendado mantém revisão humana antes de gravar, com os campos de baixa confiança marcados. A autonomia é conquistada por cliente, depois que o histórico mostra leitura consistente daquele layout.

Preciso pedir para o cliente mudar o formato?

Não, e esse é o ponto. Se fosse possível padronizar o que o cliente envia, importação de arquivo já resolveria e não haveria assunto.

No fim, a pergunta que decide não é sobre tecnologia de leitura. É esta: depois de implantado, quantas vezes por dia uma pessoa ainda precisa abrir o ERP para terminar o que a automação começou?