TimberFlow — ERP de marcenaria
ERP de orçamento e produção para marcenaria: troca a regra de bolso por custeio industrial, versiona cada proposta e transforma a aprovação em parcelas no financeiro — com a memória de cálculo aberta em cada preço.
- Papel
- Arquitetura, desenvolvimento e implantação — único desenvolvedor
- Cliente
- Arkhmade, marcenaria sob medida
- Em uso
- 2 marcenarias
- No ar desde
- 17/09/2026, em sistema interno da marcenaria
- Código
- Privado (cliente)
Números
Contado no repositório em 22/09/2026: testes por def test_ (194 no backend e 38 nos scripts de operação), modelos concretos por models.Model, versões por git tag. Cobertura do relatório de 10/09/2026 gravado no repositório. O registro de implantação em produção é de 17/09/2026; o uso com dados reais da marcenaria ainda não foi medido.
O problema
Marcenaria sob medida costuma precificar por multiplicador: o custo do material vezes um fator aprendido na experiência. O método funciona enquanto a pessoa que o carrega na cabeça está por perto, mas embute despesa, imposto, comissão e lucro num número só — e aí a oficina não sabe quanto ganhou em cada obra, nem por quê.
O sistema existe para separar essas parcelas sem tirar da marcenaria a decisão de preço: cada percentual é explícito, e cada orçamento carrega a conta que o gerou.
O que faz
- Custeio por composição: material, insumo, mão de obra por custo-hora e máquina por custo-hora, somados item a item.
- Despesa, imposto, comissão e lucro entram como parcelas explícitas do preço de venda, cada uma com o seu percentual.
- Orçamento versionado: nova versão, revisão numerada, rascunho descartável e portão de aprovação antes do envio.
- Aprovar um orçamento gera o plano de parcelas no financeiro, com contas a pagar e a receber, baixa e histórico.
- Cadastros com histórico de preço, para que um orçamento antigo continue mostrando o custo que valia na época.
- Ficha técnica e indicadores montados a partir da composição que foi digitada, não de um número solto.
Como foi construído
Django 5.2 sobre PostgreSQL 17 no backend, React 19 com TypeScript e Vite no frontend, servidos na mesma origem pelo Django com WhiteNoise — não há servidor Node em execução. Imagem Docker multi-stage com as bases fixadas por digest, rodando como usuário sem privilégio.
A integração contínua roda os testes com piso de cobertura em 85%, análise estática (Ruff, Bandit, Semgrep), auditoria de dependências e um teste de backup e restauração do container antes de publicar a imagem. Uma tag v* dispara o deploy na VM, atrás do Caddy com TLS automático.
Dinheiro nunca é ponto flutuante, e edição simultânea falha alto
Todo valor monetário e todo percentual são Decimal com casas fixas, do banco à tela. Num sistema em que o preço sai de uma cadeia de somas e percentuais encadeados, o erro de arredondamento do ponto flutuante não aparece no teste — aparece no centavo que não fecha com o que a oficina cobrou.
Pela mesma razão, orçamento e lançamento usam revisão otimista: quem salva por cima de uma versão que mudou recebe um conflito em vez de sobrescrever em silêncio, e as operações que criam dinheiro aceitam uma chave de idempotência, para que um clique repetido não vire duas parcelas. O preço é uma tela que às vezes diz “recarregue e refaça”; a alternativa é um número errado que ninguém vê.
Stack
Backend
Interface
Entrega
Qualidade
Telas
Capturas do modo de demonstração do sistema, com dados fictícios gerados pelo próprio seed: famílias com nome de árvore, telefone zerado, e-mails @example.invalid e o aviso "Demonstração" do próprio sistema. Nenhum dado de cliente real aparece aqui.