Confirmar a regra antes de calcular o preço
Duas pessoas podem concordar com a expressão «vinte por cento» e estar a calcular valores diferentes. Uma acrescenta essa percentagem ao custo; outra quer que a diferença entre custo e preço represente essa percentagem do preço final. Um formulário que guarda apenas o número 20 não resolve essa diferença.
O caso seguinte é inteiramente fictício. Uma empresa aprova uma regra para a apresentação de preços num catálogo de demonstração. Os montantes não são preços da Faith Forge Labs nem recomendações de margem, fiscalidade ou contabilidade. O objetivo é verificar se o software executa a regra que o responsável realmente escolheu.
A decisão comercial já existe
Na regra R-6, o responsável define «margem» como a diferença entre o preço e o custo, dividida pelo preço. A aplicação recebe o custo de 80,00 € e uma margem aprovada de 20%. Para este exemplo isolado, não há impostos, portes, descontos nem outros componentes a acrescentar. Essa delimitação permite investigar uma única operação.
O resultado esperado é 100,00 €: a diferença de 20,00 € representa 20% dos 100,00 €. A implementação existente mostra 96,00 €, porque multiplica 80 por 1,20. Esse cálculo aplica um acréscimo de 20% ao custo. É uma regra possível, mas não é a regra R-6 aprovada para aquele campo.
A equipa compara o documento da regra, o registo do artigo, os valores enviados à função e o resultado apresentado. O custo continua a ser 80,00 € e a percentagem continua a ser 20. Não houve troca de moeda, perda de casas decimais nem leitura incorreta da vírgula. A divergência aparece na escolha da fórmula.
Tornar o significado verificável
A proposta de correção escreve a relação por extenso e associa-a à versão da regra. Com a margem representada como fração, o preço resulta de dividir o custo por «um menos a margem». Neste caso, 80 ÷ 0,80 resulta em 100.
A designação do campo também é revista. Em vez de «Percentagem», a interface explica que a margem é calculada sobre o preço. Uma nota de exemplo permite ao responsável reconhecer o significado antes de guardar a configuração. Não se renomeia silenciosamente uma antiga configuração de acréscimo como margem: seria necessário confirmar o que os valores existentes representavam.
A regra R-6 continua a pertencer ao responsável comercial. O programador implementa e documenta a escolha; não decide qual a margem adequada ao negócio. Uma alteração posterior da política deve ter a sua própria aprovação e os seus exemplos, mesmo que a função técnica consiga receber qualquer percentagem.
Verificar mais do que o valor que falhou
O registo de aceitação fictício usa o mesmo custo de 80,00 € para comparar os seguintes casos. Os resultados são calculados antes de qualquer publicação comercial.
| Entrada autorizada | Resultado da regra R-6 | O que o controlo distingue |
|---|---|---|
| Margem de 0% | 80,00 € | A ausência de margem não acrescenta valor |
| Margem de 20% | 100,00 € | O caso original fica corrigido |
| Margem de 50% | 160,00 € | Metade do preço corresponde à diferença de 80,00 € |
| Margem de 100% | Revisão necessária; nenhum preço calculado | Não se divide por zero nem se publica um valor substituto |
| Custo por preencher | Revisão necessária | Informação desconhecida não se transforma em custo zero |
A configuração da demonstração admite margens desde zero até um limite aprovado inferior a 100%. Valores fora desse intervalo ficam bloqueados. Isso é uma decisão específica da regra, não uma afirmação universal sobre todos os modelos de preço.
Um artigo independente, F-2, usa um preço fixo aprovado de 73,00 €. Depois da correção, continua a apresentar 73,00 €. A aplicação não passou a recalcular todos os preços por ter corrigido uma modalidade particular. O histórico de R-6 e o custo original também permanecem intactos.
Fechar a correção sem criar uma operação financeira
Na conclusão do ensaio, o artigo de demonstração apresenta 100,00 € e a leitura do seu registo associa o valor à regra R-6. O responsável confirma os resultados da tabela e mantém F-2 no modo de preço fixo. O valor incorreto de 96,00 € fica documentado na investigação, com o limite da versão afetada.
Se uma aplicação real já tiver emitido propostas ou aceite encomendas, essa descoberta exige uma avaliação separada dos documentos e compromissos existentes. Não se devem reescrever operações anteriores para que coincidam com o cálculo corrigido. O exemplo não envia cobranças, não devolve fundos e não altera acordos com clientes.
A apresentação em euros, a formação do preço e a confirmação de um pagamento são responsabilidades diferentes. Uma loja pode mostrar o preço certo e ainda precisar de verificar o estado devolvido pelo prestador de pagamentos. A SIBS descreve opções de pagamento online, mas a disponibilidade de métodos, a contratação e a integração concreta devem ser verificadas para o comerciante e a solução escolhidos.
Levar a regra completa para o projeto
Antes de desenvolver um calculador, reúna a definição aprovada, os componentes incluídos, os valores permitidos, a regra de arredondamento e a pessoa que resolve exceções. Se os exemplos não usam arredondamentos, como neste caso, isso não elimina a necessidade de os definir para outras entradas.
Peça uma demonstração que mostre as entradas, a versão da regra e o resultado guardado. Um número visualmente plausível é pouco convincente quando não se conhece a sua origem. O mesmo cuidado serve para propostas, tabelas de preços e ferramentas internas.
Conheça o serviço de lojas online e catálogos ou prepare um resumo do projeto com uma regra e os seus limites. A melhor primeira amostra inclui o caso normal, um valor extremo permitido e uma situação em que o sistema deve pedir revisão.