Margem não é multiplicador de custo
O custo total de um pedido de bordado é composto por peças, consumíveis, trabalho, máquina e preparação. Se o custo total for R$ 100,00, a quantidade 3, a margem desejada 30% e a taxa de venda 5%, o preço unitário é calculado como: preços unitários = (100 / 3) / (1 - (30 + 5) / 100). Arredondar o preço unitário para cima em centavos pode resultar em divergência entre o total calculado e o valor mostrado no PDF. O sistema também rejeita entradas que ultrapassem 100% em margem e taxas ou que não tenham quantidade inteira.
Proposta para o cliente e memória de cálculo são saídas diferentes
O PDF da proposta contém informações como quantidade, preço unitário, total, descrição e condições. A memória interna inclui os custos e parâmetros usados. Gerar os dois a partir do mesmo resultado reduz o risco de atualizar o preço em um lugar e esquecer o outro. Antes de enviar, é importante verificar qual dos dois arquivos foi escolhido.
Histórico local precisa de backup e validação
Os orçamentos são guardados no localStorage do navegador, não em uma conta com sincronização na nuvem. Isso reduz a infraestrutura necessária, mas limpar os dados do navegador ou trocar de aparelho pode perder o histórico. O backup precisa ser exportado pelo usuário. Na importação, o projeto valida versão, limite de registros, estrutura e os números de cada orçamento. Se o histórico existente não puder ser lido, a aplicação não o apaga silenciosamente. Esse cuidado vale para qualquer ferramenta que dependa de armazenamento local.
Meta por hora não representa lucro líquido
A meta por hora não representa lucro líquido e não deve ser somada de novo aos custos como se fosse o mesmo modelo. Para experimentar: https://bordacusto.com.
Pergunta para quem já construiu ferramentas semelhantes: Você também arredonda o unitário antes do total? Como comunicam ao usuário que o histórico local não é backup em nuvem?