A entrada de pedidos no ERP é o trecho entre o pedido que o cliente mandou e o pedido de venda gravado no sistema. Em indústria e distribuidora de médio porte, esse trecho ainda é feito por uma pessoa, que lê o PDF, a planilha ou a mensagem, confere cliente, item e preço, e digita. Este guia explica por onde o pedido chega, o que ele precisa ter para entrar, as regras comerciais que fazem a automação quebrar quando são ignoradas, e por onde o pedido entra em cada ERP. Ele serve para quem decide pela operação comercial ou pela TI e quer tirar a digitação do time sem trocar de sistema.
O que é a entrada de pedidos no ERP e por que ela trava?
Entrada de pedidos é o processo que transforma o pedido do cliente, no formato em que ele chegou, num pedido de venda válido dentro do ERP. Ela trava porque o pedido chega de seis jeitos diferentes, cada cliente escreve o item do seu jeito e o ERP só aceita o pedido completo e dentro das regras comerciais da empresa.
Vale separar duas coisas que costumam ser confundidas. Uma é a integração que o ERP já faz: o pedido que vem estruturado da loja virtual, do marketplace ou de um cliente grande por EDI entra sozinho, porque já chega no formato do sistema. A outra é a entrada do pedido de atacado, que vem do jeito que o cliente quis mandar. É nesse segundo grupo que está a digitação, e é dele que este guia trata.
O trabalho de quem faz a entrada tem quatro partes, que se repetem em qualquer empresa:
- Identificar o cliente, mesmo quando o nome no pedido não é o da razão social, e achar a tabela de preço e a condição de pagamento dele.
- Casar cada item com o cadastro do ERP, a partir de uma descrição que é a do cliente ("det. neutro 500ml", "perfex rolo"), de um código que às vezes é o do cliente e não o seu, e de uma quantidade cuja medida pode ser caixa ou peça.
- Conferir preço, desconto, crédito e estoque contra o que a empresa combinou com aquele cliente.
- Gravar o pedido de venda pelo caminho que o ERP oferece, para as validações fiscais e comerciais do sistema rodarem.
Quando essas quatro partes são feitas por uma pessoa, dezenas de vezes por dia, no meio de outras tarefas, o custo aparece em horas e o erro aparece depois, como devolução e nota cancelada. A conta do custo está no artigo sobre digitação de pedidos; aqui o foco é o processo e a automação.
Por onde o pedido chega hoje?
O pedido de atacado chega por seis canais: e-mail com PDF, planilha, WhatsApp, representante, portal B2B e EDI. Os quatro primeiros chegam fora do ERP e são redigitados; os dois últimos já entram integrados, mas dependem de o cliente mudar o jeito de comprar. A maioria das empresas convive com quatro ou cinco deles ao mesmo tempo.
| Canal | Quem usa | O que exige do cliente | Erro típico | Quando faz sentido automatizar |
|---|---|---|---|---|
| E-mail com PDF (ordem de compra do sistema do cliente) | cliente médio e grande, com ERP próprio | nada; ele já manda assim | código do cliente que não é o seu; preço antigo no PDF | sempre: é o canal de maior volume e o mais regular |
| Planilha | cliente recorrente, com lista fixa de itens | nada, ou uma planilha-modelo | coluna de unidade (un × cx); linha com item fora de linha | sempre, quando o cliente manda ao menos uma por semana |
| WhatsApp (texto, foto, áudio) | revenda, loja de bairro, cliente eventual | nada | item ambíguo ("manda luva"); quantidade implícita ("o de sempre") | quando o WhatsApp já toma parte do dia de alguém; com conferência antes de lançar |
| Representante | venda externa | que ele repasse no formato que recebeu, ou use um app | pedido que chega duas vezes (o cliente e o representante); desconto prometido fora da alçada | junto com o canal de origem; o representante vira quem aprova a exceção |
| Portal B2B | cliente médio e grande, recorrente | digitar no seu portal | adesão baixa; o cliente grande prefere o sistema dele | quando o cliente aceita; não substitui os quatro canais acima |
| EDI (arquivo em layout combinado) | cliente grande, com TI | projeto por cliente | layout que muda sem aviso; custo por cliente | para os dois ou três maiores clientes; não serve para o pequeno e o eventual |
Portal e EDI cobrem a ponta de cima da base de clientes (a comparação entre portal B2B, EDI e agente, por perfil de cliente, tem artigo próprio). Os outros quatro canais ficam, porque dependem do cliente, e o cliente pequeno e o representante continuam mandando como sempre mandaram. Sobra para a automação ler o pedido como ele chegou, por qualquer desses canais, e lançar no ERP com as conferências que a pessoa faz hoje.
O que o pedido precisa ter para entrar no ERP?
Para virar pedido de venda, o pedido precisa de oito informações: cliente, itens, quantidade com unidade, preço ou tabela, condição de pagamento, data ou prazo de entrega, frete e transportadora, e o número do pedido do cliente. O que o cliente não manda, o ERP completa pelo cadastro; o que não existe no cadastro vira exceção.
| Informação | De onde vem no pedido do cliente | De onde vem no ERP quando falta | O que trava |
|---|---|---|---|
| Cliente | razão social, nome fantasia ou CNPJ no cabeçalho; no WhatsApp, o número do contato | cadastro de clientes, pelo CNPJ | nome diferente do cadastro; cliente com dois cadastros; cliente novo |
| Itens | descrição do cliente, código do cliente ou código seu | cadastro de produtos e tabela de referência cruzada (código do cliente → seu código) | item ambíguo; item fora de linha; item sem cadastro |
| Quantidade e unidade | número, às vezes sem unidade | unidade de venda e múltiplo de embalagem do item | caixa lida como unidade; quantidade fora do múltiplo |
| Preço | preço no PDF, ou nenhum | tabela de preço do cliente ou da região, com desconto padrão | preço do PDF diferente da tabela; desconto fora da alçada |
| Condição de pagamento | raramente vem | condição padrão do cadastro do cliente | condição pedida diferente da combinada |
| Entrega | data pedida, ou "o quanto antes" | prazo padrão por região | data que não dá; pedido parcial |
| Frete e transportadora | às vezes no rodapé da ordem de compra | regra de frete do cliente (CIF ou FOB) e transportadora padrão | frete não combinado |
| Número do pedido do cliente | no cabeçalho da ordem de compra | não existe; é dado do cliente | sem ele, a nota sai sem a referência e a conferência no cliente trava |
O ponto de atenção é que boa parte do que entra no pedido de venda não está no pedido do cliente: está no cadastro. A entrada de pedidos depende de o cadastro estar em ordem tanto quanto da leitura do pedido. Por isso o primeiro trabalho de qualquer automação é o cadastro, antes de qualquer leitura de PDF.
Quais regras comerciais entram na conta?
As regras que mais travam a entrada de pedidos são tabela de preço por cliente, alçada de desconto, limite de crédito e bloqueio, múltiplo de embalagem, pedido mínimo, condição de pagamento e a tributação de cada operação. Nenhuma pode ser ignorada: é o ERP que as aplica, e um pedido gravado por fora passa por cima delas.
- Tabela de preço por cliente, região ou canal. O mesmo item tem preço diferente para o distribuidor e para o varejo, para a região sul e para o interior, para a venda direta e para o representante. O preço do pedido é o da tabela do cliente, mesmo que o PDF traga outro.
- Alçada de desconto. O vendedor pode dar até um percentual; acima dele, aprova o gerente. O desconto que veio no pedido é comparado com a alçada, e o que passa dela espera aprovação.
- Crédito. Limite de crédito, títulos vencidos e bloqueio por inadimplência. O ERP segura o pedido do cliente bloqueado; a automação precisa respeitar isso, e não contornar.
- Unidade e múltiplo de embalagem. O item é vendido por caixa com 12; o cliente pediu 10. Ou pediu "10" e quis dizer 10 caixas. A regra do múltiplo decide, e a dúvida vai para uma pessoa.
- Pedido mínimo e faturamento mínimo por cliente ou por região.
- Condição de pagamento combinada em contrato, que o pedido raramente repete.
- Tributação da operação. No Brasil, cada item de pedido carrega uma natureza de operação, e é dela que o ERP tira CFOP e impostos; ela muda com o tipo de cliente (contribuinte ou não), com o estado de destino e com a finalidade (revenda, consumo, industrialização). No Protheus isso aparece como TES e CFOP; no Sankhya, como a TOP (tipo de operação); nos demais, como natureza de operação ou utilização. A regra mora no ERP: a automação informa cliente, item e finalidade, e o sistema aplica.
- Bonificação, brinde e amostra, que entram como pedido com outra natureza de operação, com nota e sem cobrança.
A conclusão prática é a mesma em todos os itens: o ERP é quem aplica a regra. A automação entrega ao ERP um pedido completo, pelo caminho oficial, e deixa o sistema validar com as regras que já tem. Quando a regra não fecha (preço, crédito, múltiplo), o pedido para e uma pessoa decide.
Como automatizar a entrada de pedidos no ERP?
Há três jeitos de automatizar: fazer o cliente mandar estruturado (portal B2B, EDI, app de força de vendas), ler só o que vem sempre igual (importador de planilha, RPA) ou ler o pedido do jeito que chegou (agente de IA ligado ao ERP). Os dois primeiros resolvem uma fatia; o terceiro cobre os canais que não vão mudar.
A comparação caminho a caminho (são seis, contando contratar mais gente e o app de força de vendas), com o que cada um exige e o que costuma travar, está no artigo sobre digitação de pedidos. Aqui vale o critério de decisão:
| Se o seu volume está em… | O caminho que resolve | Por quê |
|---|---|---|
| dois ou três clientes grandes, com TI | EDI ou integração direta | o volume justifica o projeto por cliente, e o layout é estável |
| clientes médios e recorrentes que aceitam portal | portal B2B | tira a digitação dos que aderirem; o resto continua |
| planilha sempre no mesmo layout, do mesmo cliente | importador de planilha ou automação por regra | barato, desde que o layout não mude |
| PDF de vários clientes, e-mail, WhatsApp, representante | agente de IA ligado ao ERP | é o único que lê o que varia, e lança com as conferências do ERP |
A diferença entre a automação por regra e o agente está em quem se adapta a quem: a regra exige que o cliente mande sempre no mesmo formato; o agente aceita o formato que vier. A fronteira está em RPA ou agente de IA. E vale dizer o que o agente não faz: ele não substitui o ERP, não grava direto na tabela do banco e não decide sozinho o que foge da regra.
Como funciona o agente de entrada de pedido, passo a passo?
São cinco passos: receber o pedido sem mexer nele, ler o conteúdo, casar com o cadastro do ERP, conferir contra as regras comerciais e gravar pelo caminho do sistema, registrando cada passo. O pedido que não passa numa conferência para, e a pessoa decide vendo o original e o resumo juntos.
Em detalhe, são cinco passos:
- Receber. O pedido chega na caixa de e-mail de pedidos, na planilha compartilhada ou no WhatsApp da empresa, sem ninguém mexer nele. O agente guarda o original: é ele que a pessoa vê quando precisa decidir.
- Ler. Do PDF, da planilha ou da mensagem, o agente tira cliente, itens, quantidades, preços, data e número do pedido do cliente. O layout muda de cliente para cliente, e o agente lê o conteúdo, onde quer que o campo esteja.
- Casar com o ERP. CNPJ do cliente no cadastro; cada item no catálogo, pela descrição ou pela tabela de referência cruzada que relaciona o código do cliente ao seu; unidade e múltiplo de embalagem; tabela de preço e condição daquele cliente.
- Conferir. Preço do pedido contra a tabela; desconto contra a alçada; crédito e bloqueio; estoque; pedido repetido (mesmo cliente, mesmos itens, poucos dias antes). Cada conferência tem um resultado: dentro do padrão ou exceção.
- Gravar e registrar. Dentro do padrão, o pedido de venda é gravado pela API ou pela rotina de pedido do ERP, e o cliente recebe a confirmação de recebimento. Fora do padrão, o pedido vai para a fila de exceção. Nos dois casos fica registrado o que entrou, o que foi conferido, o que saiu e quem aprovou.
Uma pessoa aprova o que tem risco; o agente registra tudo o que faz. No começo da operação, a pessoa aprova todos os pedidos, com o resumo pronto, e o ganho vem da conferência mais rápida. A autonomia para lançar sem aprovação chega depois, para o pedido limpo, quando o registro mostra que o critério funciona.
Por onde o pedido entra em cada ERP?
O pedido entra pelo caminho que cada ERP oferece para criar pedido de venda: a API pública, o serviço web ou a rotina padrão de pedido. É esse caminho que roda as validações do sistema, e é por isso que gravar direto na tabela do banco está fora de questão.
| ERP | Caminho oficial para o pedido de venda | O que a página por ERP detalha |
|---|---|---|
| TOTVS Protheus | a rotina de pedido de venda (MATA410, por ExecAuto) ou a API REST, conforme o que o ambiente já tem liberado | TES, CFOP e as validações que a rotina padrão aplica |
| SAP Business One | Service Layer, objeto Orders | itens, lista de preços e aprovações do B1 |
| Sankhya | API Gateway, com a TOP (tipo de operação) de pedido | a TOP certa para cada tipo de venda |
| Senior | web service de pedidos ou a API do senior X, conforme o que o ambiente tiver | qual dos dois caminhos vale no seu ambiente e o que ele exige |
| Omie | API pública, método IncluirPedido | cadastro de clientes e produtos pela própria API |
| Bling | API v3, pedidos de venda | o pedido de atacado ao lado do pedido de marketplace, que o Bling já integra |
Dois cuidados valem para todos. O primeiro é ambiente de teste: a maioria dos ERPs tem um (base de homologação, empresa de teste, conta sandbox), e é nele que o agente roda as primeiras semanas; onde não há, as primeiras semanas rodam com uma pessoa aprovando cada pedido. O segundo é o usuário do agente: um usuário próprio no ERP, com permissão só para o que ele faz, para o registro do sistema distinguir o que o agente gravou do que uma pessoa gravou.
Gravar direto na tabela do banco de dados é a tentação quando a API parece difícil. Não compensa: o pedido nasce sem as validações, sem o bloqueio de crédito e sem a regra fiscal que a tela aplicaria, e pode faturar errado. É a regra que a ArrexTec segue em qualquer ERP, e cada página por ERP acima a repete: gravar direto na tabela não entra.
Como tratar a exceção sem voltar à digitação?
A exceção é o pedido que não passou em alguma conferência. Uma parte dos pedidos de atacado traz algo fora do padrão de propósito (um desconto negociado, uma entrega parcial), e o certo é que esses parem. O que muda é que a pessoa decide com o caso preparado, em vez de digitar do zero.
| Exceção | O que o agente faz | Quem decide | O que acontece depois |
|---|---|---|---|
| Preço no pedido diferente da tabela | mostra os dois preços e a diferença; não sobrescreve a tabela | vendedor ou gerente, conforme a alçada | aprovado, entra com o preço da tabela ou com o desconto autorizado |
| Item sem cadastro ou fora de linha | lança os demais itens e aponta o item | quem cuida do cadastro | item cadastrado ou substituído; o cliente é avisado |
| Item ambíguo ("detergente", "luva") | lista os candidatos do catálogo | vendedor, ou o cliente por uma pergunta curta | a resposta vira referência para o próximo pedido daquele cliente |
| Quantidade fora do múltiplo ou unidade em dúvida | propõe a leitura mais provável e marca | vendedor | a regra do múltiplo do item decide nos próximos |
| Cliente bloqueado ou sem crédito | não lança; avisa | financeiro | liberado, o pedido entra sem redigitar |
| Pedido repetido | não lança; mostra o anterior | vendedor | descartado ou confirmado como novo |
| Cliente novo | não lança; separa os dados para o cadastro | cadastro ou comercial | cadastrado, o pedido entra |
Para a fila funcionar, a exceção tem dono, uma pessoa por tipo, com prazo; sem dono, a fila acumula e alguém acaba digitando de novo. E a decisão ensina o próximo pedido: O item ambíguo resolvido vira referência; o código do cliente casado uma vez fica casado. A fila diminui com o tempo, e o que sobra nela é o que merece atenção humana.
O que costuma dar errado na automação da entrada de pedidos?
Os erros mais comuns são começar com o cadastro bagunçado, ligar todos os clientes de uma vez, dar autonomia cedo demais, deixar o preço do pedido vencer a tabela, gravar por fora do caminho oficial e não medir o antes. Todos são de desenho do projeto, e se resolvem antes de ligar qualquer coisa.
- Ligar o agente com o cadastro bagunçado. Item sem código, cliente com dois cadastros, unidade de venda ambígua e tabela de preço desatualizada são o que mais manda pedido para a fila. Arrume o catálogo antes de ajustar a leitura.
- Ligar todos os clientes de uma vez. Comece com dois ou três clientes recorrentes, de um canal só (o PDF por e-mail costuma ser o melhor), por duas semanas. Depois os outros clientes, depois os outros canais.
- Dar autonomia cedo demais. Com o agente lançando sozinho desde o início, o erro aparece no faturamento. Com uma pessoa aprovando tudo, ele aparece no resumo, antes de o pedido existir.
- Deixar o preço do PDF vencer a tabela. O preço do PDF é comparado, nunca copiado. Isso evita o erro mais caro, que é faturar com preço antigo.
- Gravar por fora do caminho oficial. Pela API ou pela rotina de pedido de venda, e por mais nada.
- Pedido reenviado. Cliente que manda o mesmo PDF duas vezes, representante que repassa o pedido que o cliente já mandou. Sem controle de duplicidade, o pedido entra duas vezes e a devolução vem depois.
- Pedido parcial e falta de estoque. O que acontece quando falta um item? Fatura o resto, segura tudo ou pergunta ao cliente? É uma decisão comercial que precisa estar escrita antes de o agente encontrá-la.
- Medir só depois. Sem o tempo por pedido e a taxa de erro de antes, não há como mostrar o ganho, e o ganho não se prova.
Como medir se a automação da entrada de pedidos deu certo?
Quatro números, medidos antes e depois: quanto tempo um pedido leva do e-mail ao ERP; quantos campos uma pessoa corrigiu; quantos pedidos pararam na fila, e por qual motivo; e quantos entraram certos de primeira. Se os quatro melhoram, está funcionando; se a fila não diminui, o problema é cadastro ou critério.
Foi com esses quatro números que montamos o teste da ArrexTec, em nosso ambiente de teste. Montamos uma distribuidora fictícia, com 24 itens em duas tabelas de preço e 10 clientes com descontos e condições diferentes, e 50 pedidos no formato em que os clientes costumam mandar: 30 em PDF, em três layouts diferentes; 10 em planilha; 10 em conversas de WhatsApp. Desses 50, 24 são pedidos limpos; os outros 26 trazem, por desenho, preço diferente da tabela, quantidade na unidade errada, nome do cliente escrito de outro jeito, item ambíguo, item fora do catálogo ou pedido repetido. O gabarito diz o que o agente deveria fazer com cada um, e a medição compara.
Propomos medir do mesmo jeito na operação de quem contrata: os mesmos quatro números, antes e depois, no ERP da empresa. Conte a conferência dentro do tempo por pedido. E leia a fila de exceção pelo que ela é: a medida do trabalho que ainda precisa de uma pessoa.
Por onde começar?
Comece pelo canal de maior volume e menor variação, que na maioria das empresas é o PDF que chega por e-mail de clientes recorrentes, e pelo ERP que já tem API ou rotina de pedido exposta. Três perguntas que o guia ensina a responder:
- Por quais dos seis canais o pedido chega, e quanto por cada um?
- Com o cadastro de hoje, quantos pedidos entrariam sem cair em exceção?
- Qual é o ERP, e qual caminho de pedido ele já tem liberado?
Quem responde às três já sabe por onde começar. A página do agente de pedido no ERP descreve como o serviço funciona, do mapeamento ao piloto. E a primeira conversa é esta: Diagnóstico de IA na operação em 30 minutos: qual decisão o seu time mais repete?
Perguntas frequentes
O que é entrada de pedidos no ERP?
É o processo que transforma o pedido do cliente, no formato em que ele chegou (PDF, planilha, e-mail, WhatsApp, portal, EDI), num pedido de venda válido dentro do ERP, com cliente, itens, quantidade, preço, condição e tributação conferidos. Em empresa média, ainda é feito por uma pessoa.
Qual a diferença entre integração de pedidos e automação da entrada de pedidos?
A integração trata o pedido que já vem estruturado: loja virtual, marketplace, EDI. A automação da entrada trata o pedido de atacado que vem do jeito que o cliente mandou. A primeira o ERP já faz; a segunda é o que ainda é digitado.
Dá para automatizar o pedido que chega em PDF por e-mail?
Dá, e é o canal por onde se costuma começar: tem o maior volume e o layout de cada cliente se repete. O agente lê a ordem de compra como ela vem, casa cliente e itens com o cadastro e grava pelo caminho do ERP; o que não casar espera uma pessoa.
E o pedido pelo WhatsApp?
Sim, com uma conferência a mais: o cliente é identificado pelo número, o item pela descrição curta que ele usa, e no começo o pedido volta como resumo para alguém confirmar. Áudio e foto param na fila com mais frequência.
Precisa trocar de ERP ou comprar um portal?
Não. O pedido é gravado no ERP atual, pelo caminho que a tabela "Por onde o pedido entra em cada ERP" mostra para cada sistema. Portal B2B e EDI continuam servindo para os clientes que já os usam; o agente cobre os canais que eles não cobrem.
O agente respeita a tabela de preço, o crédito e o imposto?
Sim, porque quem aplica essas regras é o próprio ERP: o pedido entra pelo caminho oficial e passa pelas mesmas validações de um pedido digitado. O preço do pedido do cliente é comparado com a tabela, e a diferença vira exceção para uma pessoa decidir.
Quanto tempo leva para colocar em operação?
Depende do cadastro e do ERP, e por isso começamos com um mapeamento curto, que mede o volume e confere o caminho de entrada no sistema, antes de um piloto de 30 dias com clientes e canal definidos. O que não dá para prometer é prazo sem olhar o cadastro.
O agente escolhe a TES, a TOP ou a natureza de operação?
Não. Ele informa cliente, item e finalidade, e o ERP aplica a regra fiscal que já tem para aquela combinação. O que ficar sem regra no sistema vai para uma pessoa, e a resposta dela vira a regra do próximo pedido igual.
