PioneiraSoft / Produto próprio / MadeSoft

Da tora ao caixa.

MadeSoft
ERP para serrarias

Sistema de gestão para serrarias de pinus e eucalipto de pequeno e médio porte. Cobre o caminho completo do dinheiro: cubagem de tora, desdobro com apuração de rendimento, controle de pátio, orçamento, venda, NF-e e financeiro. Inclui app Android offline para o pátio e painel gerencial para o dono.

0
Linhas versionadas
0
Testes automatizados
0
Invariantes provados
0
Rotas HTTP
01 — O produto

Um ERP que fala madeira.

MadeSoft é um ERP vertical para serrarias de floresta plantada, construído para um segmento que hoje opera em planilha e emissor de nota avulso. Em vez de adaptar um ERP genérico, o sistema modela o domínio real da madeira: seis fórmulas de cubagem, desdobro de tora em serrada com rendimento como indicador, e uma razão de movimentos imutável de onde o saldo é projetado.

A arquitetura é um monorepo TypeScript com domínio compartilhado — a mesma implementação de cubagem roda no servidor e dentro do app Android, porque divergência de arredondamento entre os dois viraria divergência de estoque. A API é um monólito modular em Fastify sobre PostgreSQL, com isolamento multiempresa imposto por Row Level Security no próprio banco. O app de pátio funciona offline, guarda medições em SQLite e sincroniza por um protocolo de intenções idempotentes.

TypeScript
PostgreSQL
React
React Native
Fastify
SQLite
decimal.js
Row Level Security
02 — Cobertura

O caminho completo do dinheiro.

Da tora que entra no pátio até o título que baixa no financeiro — sem planilha paralela e sem emissor de nota avulso no meio do caminho.

01
Cubagem de tora
Seis regras de cubagem implementadas no domínio compartilhado. A regra ativa vem do contrato do parceiro — o sistema mostra qual é, nunca pergunta.
02
Desdobro e rendimento
Conversão de tora em madeira serrada com apuração de rendimento como indicador de primeira classe, não como cálculo de relatório.
03
Controle de pátio
Razão de movimentos append-only. O saldo é uma view projetada dos lançamentos, nunca um número guardado e atualizado.
04
Orçamento e venda
Orçamento por bitola com conversão direta em pedido, preservando espécie, dimensões e a regra de cubagem acordada.
05
Emissão de NF-e
Identidade fiscal no cadastro de produto — NCM e CFOP —, com as dimensões viajando no movimento e não no SKU.
06
Financeiro
Contas a receber e a pagar ligadas ao documento de origem, fechando o ciclo iniciado na medição da tora.
07
App de pátio offline
Android com medições em SQLite local. Funciona sem sinal e sincroniza por intenções idempotentes quando a rede volta.
08
Painel gerencial
Leitura de dono: rendimento por desdobro, giro de pátio e posição financeira, em uma tela feita para decidir.
03 — Engenharia

Sete decisões que sustentam o sistema.

Não é lista de funcionalidades — é julgamento técnico. Cada uma dessas escolhas resolve um problema que só aparece quando o sistema encontra a serraria real.

01
Bitola não é produto
Um SKU por combinação de espécie × espessura × largura × comprimento daria mais de 2.000 cadastros para seis espécies. O produto guarda só identidade fiscal (NCM, CFOP); as dimensões vivem no movimento.
02
Não existe coluna de saldo
A tabela de movimentos é append-only, e a proibição de UPDATE/DELETE é uma trigger no banco, não uma convenção. Saldo é uma view. Correção de inventário é lançamento novo com sinal — o erro original continua auditável.
03
A regra de cubagem vem do contrato
Não há seletor de fórmula na tela de digitação: a mesma serraria compra em Francon e vende em geométrica, e a diferença entre as duas é a margem. O sistema mostra a regra ativa, nunca pergunta.
04
Ponto flutuante é proibido
NUMERIC no banco, decimal.js no domínio, string na fronteira. O driver do Postgres está configurado para não converter NUMERIC em number.
05
π é constante literal de 40 dígitos
Não Math.PI: a cubagem precisa dar exatamente o mesmo resultado no servidor e no Android.
06
Isolamento multiempresa no banco
RLS forçado, com a API conectando por um papel NOSUPERUSER NOBYPASSRLS — superusuário do Postgres ignora RLS mesmo com FORCE, o que tornaria o isolamento decorativo.
07
Sincronização assimétrica
Referência desce (somente-leitura no aparelho), intenções sobem (UUIDv7 gerado no celular, servidor deduplica e valida), saldo nunca trafega. O caso de conflito não existe por construção.
04 — Pátio e servidor

Offline sem conflito.

O pátio de uma serraria não tem sinal confiável. Em vez de resolver conflitos depois, o protocolo é desenhado para que eles não existam: cada direção carrega um tipo de dado diferente.

Desce — somente leitura
Referência
Cadastros, contratos e regras de cubagem chegam ao aparelho como dado imutável. O app nunca edita referência, então nunca diverge dela.
Local — no aparelho
SQLite
A medição é registrada offline, com UUIDv7 gerado no próprio celular. O operador trabalha o turno inteiro sem rede e sem perceber a ausência dela.
Sobe — intenções
Idempotência
O que sobe é intenção, não estado. O servidor deduplica pelo identificador, valida e projeta o saldo. Reenvio não duplica lançamento.
05 — Números

O sistema em medida.

Código
~18.700 linhas versionadas (TS / TSX / SQL)
Banco
28 tabelas · 11 views · RLS forçado
API
80 rotas HTTP em monólito modular Fastify
Testes
157 automatizados + 41 invariantes provados contra PostgreSQL real
Domínio
6 regras de cubagem em implementação compartilhada servidor/app
Web
11 áreas + painel gerencial
Infra
Vercel (web + API serverless) · Supabase (Postgres, São Paulo)
06 — Conversar

Tem uma serraria?

O MadeSoft está em desenvolvimento como produto. Se você opera uma serraria de pinus ou eucalipto e quer acompanhar — ou participar da validação —, fale direto com quem construiu.

Ligar · WhatsApp
Escrever
Enviar mensagem pelo formulário