Um preço exibido na tela pode ser o resultado de uma cadeia de decisões: custo considerado, unidade de venda, tabela comercial, cliente, quantidade, vigência e aprovação de desconto. Quando essas decisões ficam escondidas em planilhas particulares, o sistema registra o valor final, mas não consegue explicar como ele foi formado.
Este guia trata do desenho de um módulo de precificação para operações comerciais. Não estabelece qual preço sua empresa deve cobrar nem substitui avaliação contábil ou tributária. O foco é tornar regras escolhidas pela empresa reproduzíveis, verificáveis e controladas. Todos os números apresentados são exemplos didáticos.
1. Diferencie preço, custo, margem e acréscimo
Antes de desenvolver, alinhe a linguagem. Preço é o valor negociado para a venda conforme suas condições. Custo depende da composição definida para a análise. Margem e acréscimo sobre custo utilizam bases diferentes, portanto percentuais iguais não produzem o mesmo resultado.
Em um exemplo simplificado, um item com custo considerado de R$ 80 vendido por R$ 100 tem diferença de R$ 20. Essa diferença equivale a 20% do preço e a 25% do custo. Sem tributos, frete, comissões e outras parcelas, isso é apenas uma demonstração aritmética, não a margem final do negócio.
O sistema deve nomear a medida exibida e explicar sua fórmula. Mostrar somente “margem: 20%” sem indicar o que entrou no custo pode induzir decisões equivocadas. Uma composição financeira precisa ser validada pelos responsáveis da empresa e aplicada de modo consistente.
2. Levante como a negociação realmente acontece
Observe propostas aprovadas, recusadas e alteradas. Quem define a tabela? O vendedor pode mudar quantidade e prazo? O frete é incluído ou calculado depois? Um mesmo produto possui condições diferentes por contrato? Essas respostas determinam a arquitetura do módulo.
Registre as decisões frequentes e as exceções. Uma exceção recorrente talvez mereça regra explícita. Uma exceção rara pode continuar dependendo de aprovação. Transformar qualquer situação imaginável em configuração aumenta a complexidade e dificulta a compreensão dos usuários.
Comece com poucos cenários representativos. Monte exemplos que o time comercial reconheça e peça que pessoas diferentes calculem o mesmo resultado. Divergências nessa etapa indicam que o processo precisa ser esclarecido antes de ser automatizado.
3. Estabeleça precedência entre regras
Um cliente pode ter uma tabela contratada enquanto o produto participa de uma campanha e a quantidade permite desconto adicional. Se todas as regras forem aplicadas sem ordem, o preço final pode ser imprevisível. Defina quais regras substituem outras e quais podem ser combinadas.
Uma abordagem é separar preço-base, ajustes permitidos e exceções aprovadas. A regra contratual pode definir a tabela de partida; a política de quantidade pode permitir um ajuste; uma condição específica pode exigir análise adicional. Isso é uma possibilidade de desenho, não uma sequência universal.
| Decisão | O que precisa ficar explícito | Risco sem definição |
|---|---|---|
| Tabela contratual | Vigência e produtos cobertos | Usar condição vencida |
| Campanha | Cumulatividade e elegibilidade | Aplicar desconto duas vezes |
| Quantidade | Faixas e unidade considerada | Desconto sobre base errada |
| Exceção | Aprovador e validade | Repetir concessão pontual |
| Arredondamento | Momento e precisão | Divergência entre telas e cobrança |
4. Versione tabelas e preserve propostas antigas
Uma proposta enviada precisa manter a memória da condição apresentada. Se a tabela mudar amanhã, o documento de ontem não pode assumir outro valor automaticamente. Guarde a versão da regra e uma composição suficiente para explicar o cálculo original.
Separe rascunho editável de proposta enviada. No rascunho, o vendedor pode solicitar recálculo com a política atual. Depois do envio, mudanças devem gerar nova versão ou revisão identificada. O cliente e a equipe precisam saber qual versão está sendo negociada.
Também defina a validade da proposta e o procedimento após seu vencimento. Reabrir o documento pode exigir revalidação de custos ou condições. Uma data exibida sem consequência operacional não oferece controle. A regra deve aparecer no processo de aprovação e na geração do pedido.
5. Modele aprovação de desconto pelo risco
Um limite de desconto isolado pode ser insuficiente. A mesma redução percentual pode representar valores absolutos muito diferentes ou atingir produtos com composições distintas. A empresa pode combinar faixa de valor, tipo de produto, condição contratual e resultado gerencial estimado.
O sistema deve explicar por que uma aprovação foi solicitada. O gestor precisa visualizar a composição, a justificativa e a condição anterior, não apenas um botão para aprovar. Registre quem decidiu, quando, para qual versão e com qual validade.
Uma aprovação não deve se transformar em permissão permanente para o vendedor alterar qualquer proposta. Vincule-a ao objeto e às condições aprovadas. Mudança relevante de quantidade, composição ou prazo deve provocar nova conferência, conforme a política escolhida.
6. Trate unidades e arredondamento como regras centrais
Vender por caixa e comprar por unidade exige uma conversão conhecida. Um desconto calculado sobre a caixa não pode ser aplicado novamente ao preço unitário convertido. Quantidades fracionadas, embalagens e serviços por hora também precisam de precisão apropriada.
Defina em qual etapa o arredondamento acontece: por item, subtotal ou total. Não use a formatação visual como motor de cálculo. A tela pode exibir duas casas enquanto o cálculo mantém precisão maior, mas o documento e a cobrança devem seguir a política definida e produzir valores conciliáveis.
Para valores monetários, escolha representação e biblioteca adequadas ao domínio, evitando depender de aproximações binárias sem tratamento. O tipo decimal exato numeric do PostgreSQL é uma referência técnica para armazenamento; ainda é necessário definir escala, arredondamento e validação na aplicação.
7. Exemplo: proposta com três condições concorrentes
Imagine uma distribuidora com tabela padrão, acordo por cliente e desconto por volume. Para um cliente específico, o acordo define preço-base de R$ 120 por unidade. Uma campanha anuncia preço de R$ 115, mas não é cumulativa com contratos. O volume solicitado permite ajuste adicional somente quando a política contratual o autoriza.
O sistema não deveria escolher o menor valor por intuição. Ele deve aplicar a precedência aprovada e apresentar a explicação. Se o contrato exclui campanhas, a oferta promocional não é aplicada. Se o contrato permite volume, o ajuste segue a faixa correspondente. A empresa pode optar por outra política, mas precisa expressá-la.
No resumo, o vendedor vê tabela utilizada, ajustes, regra de cumulatividade e necessidade de aprovação. A proposta salva preserva essa composição. O pedido posterior utiliza a versão aceita, evitando recalcular silenciosamente com uma campanha que começou depois.
8. Integre comercial, faturamento e análise
O motor de precificação pode produzir uma composição identificada, consumida por proposta, pedido e faturamento. Evite reconstruir fórmulas diferentes em cada módulo. Quando outro sistema for responsável pelo valor cobrado, defina a fonte de verdade e como divergências serão tratadas.
Condições tributárias e documentos fiscais exigem participação de especialistas e das regras aplicáveis à operação. Um módulo comercial não deve improvisar o tratamento fiscal. A interface pode receber valores de um serviço especializado e registrar sua origem e versão.
No BI, compare condições previstas e efetivamente realizadas. Uma estimativa comercial não é igual ao resultado final após devoluções, custos adicionais ou mudanças de escopo. O guia da A2CR sobre qualidade de dados no BI ajuda a estruturar definições e reconciliação antes de apresentar indicadores.
9. Construa testes a partir de decisões reais
Monte uma matriz com produto, cliente, data, quantidade, contrato, campanha e aprovação. Inclua casos nas bordas das faixas e nas transições de vigência. O mesmo cenário precisa produzir o mesmo resultado quando processado novamente com a mesma versão de política.
Teste também falhas de integração. Se o custo está indisponível, a empresa deve definir se bloqueia a negociação, utiliza uma referência identificada ou permite revisão humana. Usar zero como substituto silencioso pode criar uma aparência de excelente margem sem fundamento.
Checklist de implantação
- Definir nomes e fórmulas dos indicadores comerciais.
- Mapear custos e condições com responsáveis reais.
- Estabelecer precedência e cumulatividade das regras.
- Versionar tabelas, campanhas e contratos.
- Preservar a composição das propostas enviadas.
- Vincular aprovações a versões específicas.
- Documentar unidades e precisão de cálculo.
- Conferir arredondamento entre pedido e cobrança.
- Testar vigência, faixas e indisponibilidade de dados.
- Separar estimativa comercial e resultado realizado.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre a conferência, o responsável e as observações da implantação.
Perguntas frequentes
É melhor deixar todas as regras configuráveis?
Não necessariamente. Configurações precisam de validação, documentação e controle de acesso. Um conjunto pequeno e compreensível de regras pode atender melhor que uma interface em que qualquer usuário combina fórmulas sem conhecer seus efeitos.
Uma IA pode decidir o preço automaticamente?
Pode apoiar análise e preparar sugestões dentro de políticas aprovadas. Descontos, contratos e compromissos com clientes exigem limites explícitos. A proposta de uma IA não deve substituir o motor determinístico nem a autoridade comercial definida.
Posso migrar a planilha sem revisar as fórmulas?
Isso transfere inconsistências para uma ferramenta mais difícil de corrigir informalmente. Antes da migração, registre exemplos, compare cálculos e obtenha concordância dos responsáveis sobre os cenários críticos.
Para estruturar um módulo comercial coerente, organize seu briefing com exemplos de tabelas, negociações e aprovações. A A2CR pode transformar esse processo em requisitos de sistema.
Autoria: Agência A2CR. Preparação editorial: 12 de novembro de 2026. Exemplos aritméticos hipotéticos; conteúdo de desenho de software, sem recomendação de preço, tratamento contábil ou tributário.
