Pular para o conteúdo

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.

Por Equipe Pervian Tech 11 min de leitura
Neste artigo

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:

  1. A área avisa o comprador por mensagem ou de viva voz.
  2. O comprador escolhe fornecedores de memória e pede preço por e-mail.
  3. As respostas chegam em corpo de e-mail, PDF ou foto de orçamento à mão.
  4. Tudo é redigitado numa planilha e enviado ao gestor, que aprova por mensagem.
  5. O pedido entra no ERP, às vezes depois que o fornecedor já separou a mercadoria.
  6. 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

  1. Mapeie o fluxo atual como ele é, não como o manual diz que é.
  2. Escreva a política de alçadas e valide com a diretoria.
  3. Limpe o cadastro de itens e fornecedores, ou pelo menos o das categorias do piloto.
  4. Defina com quem cuida do ERP quem é dono de cada dado.
  5. Prototipe o portal do fornecedor e teste com dois ou três fornecedores de verdade.
  6. 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.

ComprasCotaçãoSuprimentosWorkflowServiço: Aplicações Web

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

Continue lendo

  • Automação de processos 11 min de leitura

    Como automatizar a admissão de funcionários

    Coleta de documentos, exame admissional, assinatura eletrônica e envio ao eSocial: como automatizar a admissão sem planilha e sem correr atrás de papel.

Fale conosco

Conte o problema que precisa resolver

Respondemos em até um dia útil com uma avaliação técnica inicial. Sem custo e sem compromisso.

Usamos seus dados apenas para responder este contato.