Como resolver o problema de encomenda ou incomenda no dia a dia do comércio
Trabalho com gestão de pedidos e estoque há mais de uma década, e o cenário que mais vejo gente estragar é esse: o sistema mostra um número de pedido, mas não dá para saber ao certo se foi uma encomenda real ou só uma incomenda, aquela coisa que aparece no relatório mas na prática nunca aconteceu. Já perdi horas ligando para cliente, conferindo planilha, checando o ERP, e no final descobria que era apenas um rascunho salvo automaticamente pelo sistema.
A diferença prática entre encomenda ou incomenda
Encomenda é quando o cliente efetivou a compra. Tem CPF ou CNPJ, tem forma de pagamento selecionada, tem endereço de entrega preenchido. Incomenda é tudo o que parece pedido mas não passa disso: carrinho abandonado, orçamento gerado, pré-reserva sem confirmação, cadastro duplicado que o sistema interpretou como novo pedido. A linha é tênue, e a maioria dos softwares de PDV ou e-commerce brasileiros não diferencia isso na hora da extração de relatório. No meu caso, o problema principal surgiu com um módulo de pedidos que eu uso há cinco anos. O sistema marcava como "pendente de pagamento" tudo que tinha sido inicializado, mas o campo que deveria registrar o status de confirmação do cliente estava sendo sobrescrito sempre que o vendedor entrava no cadastro para editar qualquer coisa. Ou seja, uma encomenda válida virava incomenda na tela do relatório só porque alguém abriu o registro pra mudar o telefone. A solução que encontrei foi criar uma trigger no banco que trava o campo de status toda vez que um edit é feito sem o parâmetro de confirmação passar pelo fluxo padrão.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Método de conferência passo a passo
O método que uso hoje leva em média quatro minutos por lote de cinquenta pedidos. Não é rápido, mas é seguro, e depois que você padroniza não precisa pensar no processo. O primeiro passo é exportar o relatório de pedidos do seu sistema com os campos: data de criação, data da última modificação, status de pagamento, tipo de pagamento escolhido, e se há campo de confirmação de endereço. Se algum desses campos não existir na sua exportação, você vai precisar ajustar o relatório antes de continuar.
Depois, você aplica três filtros sequenciais. O primeiro descarta registros onde a data de última modificação é posterior à data de criação por menos de dois minutos e onde o valor do pedido foi alterado depois da criação original. Isso remove a maioria das incomendas geradas por edição acidental. O segundo filtro elimina pedidos com cupom de desconto aplicado mas sem comprovante de pagamento vinculado. O terceiro cruza o campo de telefone com a base de clientes já existentes para identificar cadastros duplicados que podem estar inflando o número de pedidos no sistema. O resultado desses três filtros normalmente te deixa com cerca de setenta a oitenta por cento dos registros originais. O que sobrou é o que você confere manualmente, ligando ou mandando mensagem de confirmação. Em operações com volume alto, eu recomendo usar um script simples de automação que faz a primeira triagem por você e só encaminha para revisão humana os casos ambíguos que passam nos três filtros mas ainda têm algum campo vazio ou inconsistente.
Erros comuns que todo mundo comete
O erro mais frequente é confiar no status automático do sistema sem verificação. A maioria dos ERP's brasileiros marca como "emitido" qualquer registro que tenha sido salvo, mesmo que o pagamento nunca tenha sido confirmad
