Sistema de cotação e compras: da requisição ao pedido
Requisição, cotação com fornecedores, mapa comparativo, aprovação por alçada e pedido integrado ao ERP: como estruturar um sistema de compras rastreável.
Neste artigo
- O processo de compras que acontece por e-mail e planilha
- Quando um sistema próprio faz sentido (e quando não faz)
- Requisição de compra: quem pede, o quê e para qual centro de custo
- Portal do fornecedor para responder cotações
- Mapa comparativo além do menor preço
- Alçadas de aprovação configuráveis
- Pedido de compra, recebimento e integração com o ERP
- Rastreabilidade e auditoria do processo
- A arquitetura, sem jargão
- Erros comuns
- Como medir se funcionou
- Passo a passo para começar
- Do diagnóstico ao sistema rodando
Pergunte ao comprador de uma empresa média como foi a última compra relevante e a resposta vem em pedaços: o pedido chegou pelo WhatsApp, a cotação foi por e-mail, o comparativo está numa planilha e a aprovação foi um "pode fechar" no corredor. A compra deu certo. Três meses depois, ninguém consegue reconstruir o que aconteceu.
Um sistema de cotação e compras não existe para "digitalizar" esse fluxo, e sim para tornar cada decisão de compra rastreável e comparável sem transformar o comprador em digitador. Este texto segue o processo real de suprimentos, etapa por etapa, e mostra onde a automação rende mais.
O processo de compras que acontece por e-mail e planilha
O fluxo informal quase sempre tem o mesmo desenho:
- A área avisa o comprador por mensagem ou de viva voz.
- O comprador escolhe fornecedores de memória e pede preço por e-mail.
- As respostas chegam em corpo de e-mail, PDF ou foto de orçamento à mão.
- Tudo é redigitado numa planilha e enviado ao gestor, que aprova por mensagem.
- O pedido entra no ERP, às vezes depois que o fornecedor já separou a mercadoria.
- A nota chega e a conferência contra o combinado depende da boa vontade de alguém.
Cada passo perde informação. Qual prazo o fornecedor B ofereceu? Por que o mais barato não foi escolhido? Quem aprovou qual valor? É um caso clássico de processo que já passou do ponto de sair da planilha: a planilha não guarda contexto, não impõe regra e não avisa ninguém.
Quando um sistema próprio faz sentido (e quando não faz)
Antes de construir, olhe o que você já tem. ERPs como TOTVS, SAP, Omie e Bling oferecem recursos de pedido de compra, com profundidades diferentes. Se o módulo do seu ERP cobre sua política de aprovação e o time consegue usá-lo, configure-o bem antes de pensar em software novo.
Um sistema sob medida costuma fazer sentido quando:
- Muita gente requisita, de várias áreas ou unidades, e não faz sentido dar acesso ao ERP para todas essas pessoas.
- O fornecedor precisa participar, respondendo cotações num lugar estruturado.
- A política de alçadas tem nuances que o módulo pronto não representa.
- Existe exigência de governança: sócios, conselho ou auditoria cobrando evidência de concorrência em cada compra.
Não faz sentido quando o volume é baixo e quem compra é o dono, ou quando o problema é disciplina: se ninguém segue a política atual, o sistema só vai registrar isso.
Requisição de compra: quem pede, o quê e para qual centro de custo
É aqui que a maioria dos processos já nasce torta. Uma requisição útil tem:
- Solicitante e área, identificados pelo login e não digitados.
- Item do catálogo, com unidade de medida padronizada. Texto livre gera "parafuso sextavado 1/4" e "paraf. sext 1/4" como itens diferentes, e nenhum histórico de preço funciona.
- Quantidade e data em que o item é necessário, que é diferente de "urgente".
- Centro de custo e, quando fizer sentido, projeto ou obra.
- Justificativa e anexos: especificação técnica, desenho, foto da peça quebrada.
Duas automações pagam o esforço cedo. A primeira é mostrar, na requisição, quanto do orçamento daquele centro de custo já está comprometido, para a conversa sobre verba acontecer antes da cotação. A segunda é gerar a requisição sozinha quando um item atinge o ponto de reposição, o que depende de um controle de estoque com saldo confiável. Sem ele, a automação só propaga o erro mais rápido.
O comprador também deve poder agrupar requisições: três áreas pedindo o mesmo material viram uma cotação só, com mais poder de negociação.
Portal do fornecedor para responder cotações
Este é o ponto de maior ganho e o mais negligenciado. Enquanto a cotação for por e-mail, alguém vai redigitar respostas, e é aí que os erros nascem. Com um portal, o comprador monta a cotação, escolhe os fornecedores convidados e define um prazo. Cada fornecedor recebe um link e preenche, item a item:
- preço unitário, deixando claro quais impostos estão incluídos e quais vêm à parte;
- frete e modalidade (CIF ou FOB);
- prazo de entrega;
- condição de pagamento;
- validade da proposta;
- observações e anexos, como ficha técnica ou catálogo.
A resposta chega estruturada. O fornecedor pode recusar um item sem abandonar a cotação, e quem não respondeu recebe lembrete automático perto do prazo.
O detalhe que decide a adesão é o atrito. Fornecedor não quer mais uma senha. Na prática, funciona acesso por link único, com validade, que abre no celular sem cadastro obrigatório. O cadastro completo (CNPJ, contatos, categorias atendidas, documentos com validade) fica para a homologação, que acontece uma vez.
Preveja o fornecedor que só responde por e-mail: o comprador lança a resposta em nome dele e o sistema registra a origem manual. E, para mais governança, ofereça cotação fechada: as propostas ficam ocultas até o prazo encerrar, e ninguém espia o preço do concorrente para orientar um fornecedor preferido.
Mapa comparativo além do menor preço
É onde a planilha mais engana: a coluna de preço unitário ignora quase tudo que importa. Um mapa útil equaliza as propostas antes de compará-las:
| Critério | O que o mapa considera | De onde vem o dado |
|---|---|---|
| Preço | Unitário com impostos e frete, na mesma base | Fornecedor |
| Condição de pagamento | À vista ou a prazo muda o custo real; o sistema traz tudo a valor presente com a taxa que o financeiro definir | Fornecedor e parâmetro interno |
| Prazo de entrega | Se atende a data de necessidade | Fornecedor cruzado com a requisição |
| Histórico do fornecedor | Pontualidade e divergências em recebimentos anteriores | Registros do próprio sistema |
| Validade da proposta | Se ainda vale na data prevista de aprovação | Fornecedor |
O sistema pode sugerir um vencedor por pontuação ponderada, mas a decisão continua humana. O que ele exige é justificativa quando o escolhido não é o melhor colocado. Escrita no momento da decisão, ela vale mais numa auditoria do que qualquer relatório montado depois.
Preveja também o vencedor por item: numa cotação de vinte itens, parte pode ir para um fornecedor e parte para outro, com pedidos separados gerados sem retrabalho.
Alçadas de aprovação configuráveis
Política de aprovação muda: abre uma unidade, troca um diretor, surge uma categoria de gasto. Se as alçadas estiverem no código, cada mudança vira chamado para o desenvolvedor. Elas precisam ficar numa tabela de regras que o próprio administrador edita, combinando critérios como:
- faixa de valor, definida pela própria empresa;
- centro de custo ou unidade;
- categoria de compra (material produtivo, serviços, TI, investimento);
- tipo de compra: regular, emergencial ou sem cotação.
Algumas regras fazem muita diferença no dia a dia:
- Delegação com prazo. Quem sai de férias delega por um período definido, e o registro mostra que a aprovação foi por delegação.
- Escalonamento por tempo. Aprovação parada além do prazo combinado sobe para o próximo nível ou gera alerta.
- Reaprovação automática. Se valor, fornecedor ou quantidade mudam depois da aprovação, o fluxo volta para aprovação. Sem isso, a alçada vira formalidade.
- Aprovação com contexto. Quem aprova pelo celular vê o resumo do mapa, a justificativa e o saldo do centro de custo, não só um botão.
- Segregação de funções. Quem requisita não aprova a própria requisição, e quem conduz a cotação não aprova a compra que conduziu. Isso depende de perfis de acesso bem desenhados, não de confiança.
Compra emergencial vai existir, e fingir que não é o jeito mais rápido de empurrar as pessoas de volta para o WhatsApp. Dê a ela um fluxo próprio: liberada com aprovação posterior, marcada como emergencial e listada num relatório que a diretoria de fato lê.
Pedido de compra, recebimento e integração com o ERP
Aprovada a cotação, o sistema gera o pedido e o envia ao fornecedor, que confirma o aceite pelo portal. Daqui em diante, a pergunta central é quem é o dono de cada informação.
Em geral, o ERP continua sendo a fonte oficial de fornecedores, produtos, centros de custo, contas a pagar e escrituração fiscal. O sistema de compras consome esses cadastros e devolve ao ERP o pedido aprovado. Definir essa divisão por escrito, campo por campo, evita dois sistemas achando que mandam no mesmo dado. Os padrões e as armadilhas dessa conexão estão em como integrar seu sistema com o ERP.
No recebimento, o ganho está na conferência em três pontas: o que foi pedido, o que a nota fiscal diz e o que chegou fisicamente. A NF-e do fornecedor pode ser importada pelo XML e localizada pela chave de acesso. Com o certificado digital ICP-Brasil da empresa, dá para consultar nos serviços da SEFAZ as NF-e emitidas contra o seu CNPJ e registrar a manifestação do destinatário. O sistema cruza item, quantidade e preço com o pedido e aponta as divergências antes que a nota siga para pagamento.
Trate desde o início o recebimento parcial, com saldo em aberto no pedido, e a falha de integração: o ERP sai do ar, um cadastro não existe do outro lado. Uma fila com nova tentativa automática e uma tela de pendências acompanhada por alguém evitam pedido aprovado parado sem que ninguém saiba.
Rastreabilidade e auditoria do processo
Um bom sistema responde em segundos sobre qualquer compra passada: quem pediu, quem foi convidado e respondeu, qual era cada proposta, por que o vencedor foi escolhido, quem aprovou, o que chegou e se a nota bateu. Para isso, algumas regras não se negociam:
- Nada é sobrescrito. Uma proposta revisada pelo fornecedor gera uma nova versão, e a anterior continua visível.
- Cada ação tem autor, data e hora, registrados pelo sistema e não digitados.
- Anexos ficam vinculados ao processo, não soltos na caixa de e-mail de alguém.
- Relatórios de exceção mostram o que merece atenção: compras sem cotação, emergenciais, fornecedores sempre convidados e nunca escolhidos, aprovações por delegação.
Há também um cuidado de LGPD: nome, e-mail e telefone dos vendedores de cada fornecedor são dados pessoais. Precisam de finalidade clara, acesso restrito e um processo de correção ou exclusão quando o contato deixa o fornecedor.
A arquitetura, sem jargão
Um sistema de compras é uma aplicação web responsiva organizada em torno de estados bem definidos: em cotação, em aprovação, pedido emitido, recebido parcialmente, concluído. Modelar isso como máquina de estados explícita, e não como um campo "status" que qualquer tela altera, garante que nenhuma compra pule etapas.
Em volta desse núcleo ficam as alçadas configuráveis, filas para integração e notificações, armazenamento de anexos e login que pode usar a autenticação corporativa. Hospedar em nuvem, em provedores como AWS ou GCP, resolve disponibilidade e backup sem servidor na sala de TI. É o tipo de projeto que entregamos em desenvolvimento web sob medida.
Erros comuns
- Reproduzir o processo ruim em tela nova. Se hoje a aprovação é informal, desenhe a política antes de desenhar o sistema.
- Portal que o fornecedor não usa. Login obrigatório e tela que não abre no celular derrubam a adesão.
- Cadastro de itens sujo. Sem catálogo padronizado, o mapa comparativo perde valor.
- Tentar substituir o ERP. O sistema de compras complementa; financeiro e fiscal continuam onde estão.
Como medir se funcionou
Registre a situação atual antes de lançar, nem que seja à mão numa amostra de compras. Depois, acompanhe:
- Tempo de ciclo da requisição ao pedido, e em qual etapa ele fica parado.
- Proporção de compras com cotação em relação ao total, por categoria.
- Taxa de resposta dos fornecedores e propostas por cotação.
- Volume de compras emergenciais, que deve cair com o planejamento.
- Divergências no recebimento entre pedido, nota e mercadoria.
- Tempo parado em aprovação, por aprovador.
Passo a passo para começar
- Mapeie o fluxo atual como ele é, não como o manual diz que é.
- Escreva a política de alçadas e valide com a diretoria.
- Limpe o cadastro de itens e fornecedores, ou pelo menos o das categorias do piloto.
- Defina com quem cuida do ERP quem é dono de cada dado.
- Prototipe o portal do fornecedor e teste com dois ou três fornecedores de verdade.
- Lance um MVP para uma categoria ou unidade, meça, ajuste e expanda.
Do diagnóstico ao sistema rodando
Na Pervian Tech, um sistema de compras começa por um diagnóstico do seu processo real: quem compra o quê, como aprova, o que já está no ERP e onde o tempo se perde. Dele sai um protótipo navegável, depois um MVP focado numa categoria ou unidade, e então a evolução guiada pelo uso. O cronograma é definido depois do diagnóstico, porque depende das integrações e da política de alçadas de cada empresa.
Tudo é construído sob medida, e o investimento é definido sob consulta, depois que entendemos o seu contexto. Se as compras da sua empresa ainda dependem de e-mail e planilha, conte como funciona hoje e a gente mostra por onde começar.
Quer uma solução assim na sua empresa?
Cada projeto é desenhado sob medida para o seu processo, e o investimento é definido sob consulta depois de entendermos o contexto. O diagnóstico inicial não tem custo: descreva o cenário e respondemos em até um dia útil.
Falar com a Pervian Tech