"Pronto para produção" é uma expressão usada em demasia. Em folha, deve significar algo específico.
Para o motor de folha da Chegatta, definimos pronto para produção como: o motor faz a mesma coisa na interface, na base de dados e no PDF; não pode ser alterado silenciosamente após o bloqueio; mantém inquilinos e agências isolados; deixa um rastro de auditoria; e liga os dados de pagamento de volta aos registos de salário aprovados.
Corremos uma verificação de pronto para produção da Fase 4 no motor. 3 testes, todos verdes. Aqui está o que estava na lista e o que encontramos.
1. Uma única fonte de verdade entre interface, base de dados e PDF
Um sistema de folha falha de uma forma específica e cara quando a interface mostra um número, a base de dados guarda outro e o PDF imprime um terceiro.
Verificámos que o resultado calculado pelo motor, o output do serviço de recibo de salário e a plantilla de PDF consumiram a mesma fonte de verdade — sem recalculo independente na camada de PDF.
Isto importa porque as disputas de folha geralmente começam com "o seu sistema diz uma coisa, os nossos registos dizem outra". Se o PDF é gerado a partir dos mesmos números que a interface, elimina-se uma classe inteira de disputas.
2. Reconciliação da remuneração
Uma remuneração é mais do que a soma dos funcionários. Se corre folha para 20 pessoas, o total da remuneração deve igualar a soma dos valores brutos individuais.
Verificámos que os totais brutos individuais dos funcionários agregam de forma exacta aos totais da remuneração. Este é o teste que detecta "o motor está correcto por funcionário mas errado no agregado" — um modo de falha real quando os resumos são calculados independentemente.
3. SEPA e ligação de pagamento
A Chegatta produz ficheiros de pagamento SEPA e detalhes de pagamento. Verificámos que os detalhes de pagamento, a IBAN e os valores de líquido pagável ligam-se directamente de volta aos registos de salário aprovados.
Esta é a diferença entre "exportámos um ficheiro de folha" e "este ficheiro de folha liga-se de volta ao cálculo aprovado". Este último é o que um contabilista ou auditor realmente quer.
4. Bloqueio de folha e imutabilidade
Depois de uma remuneração ser aprovada ou bloqueada, não deve ser recalculada silenciosamente.
Verificámos que os cálculos associados a remunerações aprovadas ou bloqueadas lançam uma excepção em caso de tentativa de recalculo não autorizado. Em outras palavras: o motor se recusa a refazer silenciosamente uma folha que já bloqueou.
As correções ainda acontecem — pelo caminho de auditoria previsto, não por substituição silenciosa da remuneração bloqueada. Os cálculos históricos permanecem imutáveis uma vez bloqueados ou associados a uma remuneração aprovada.
5. Rastro de auditoria
Uma folha precisa de um rastro de auditoria por omissão, não como um acessório.
Verificámos que o rastro de auditoria é mantido via rasto relacional em cálculos de salário, remunerações e estados de aprovação. Pode rastrear o que foi calculado, quando e em que estado.
6. Isolamento multiinquilino e de agência
Os dados de folha são sensíveis. Uma agência de trabalho temporário que corre folha para os seus próprios funcionários e para os funcionários dos seus clientes precisa de saber que os dados de folha de um cliente não são visível a outro cliente, e não são visíveis à agência a menos que a agência tenha direito a os ver.
Verificámos que as políticas de isolamento de inquilino e de agência previnem com sucesso o acesso cruzado a dados entre empresas.
7. Desempenho e recuperação de falhas
Corremos a suíte de testes da Fase 4 em conjunto com os testes de regressão e de recibo existentes. A suíte manteve-se rápida — menos de 2 segundos por suíte — e todos os testes existentes permaneceram verdes.
Verificámos também o comportamento de recuperação de falhas: os mecanismos de bloqueio previnem corrupção parcial e preservam a integridade transaccional quando algo falha no meio da execução.
O que ainda precisa de um contabilista
Somos honestos sobre isto: o motor de cálculo é matematicamente correcto e configurável com as taxas de Segurança Social, as faixas da tabela de IRS, os tetos de subsidío de refeição e os multiplicadores de horas extras correctos. Mas os detalhes específicos das tabelas legais, os casos extremos dos coeficientes de retenção de IRS e as regras setoriais de convenção colectiva devem ser revistos por um contabilista local antes de correr uma folha real.
Isto não é uma fraqueza do motor — é o que é responsável de dizer. Nenhum produto de folha deve afirmar que as suas tabelas fiscais configuráveis substituem a revisão jurídica e contabilista local antes de uma primeira folha real.
Para que serve esta lista
Se está a comprar software de folha, este é o tipo de lista que deve pedir a um fornecedor para percorrer:
- O PDF vem dos mesmos números que a interface?
- Os totais dos funcionários reconciliam com o total da remuneração?
- Os ficheiros de pagamento ligam-se de volta aos registos aprovados?
- Pode uma remuneração bloqueada ser alterada silenciosamente?
- Há um rastro de auditoria por omissão?
- Estão inquilinos e agências isolados?
- Qual é o desempenho sob carga normal?
- O que precisa de revisão de um contabilista local antes da primeira folha real?
Publicámos as nossas respostas porque preferimos mostrar a lista do que mostrar uma captura limpa e pedir confiança.
Onde os outros elementos se encaixam
- O exemplo completo de recibo português está aqui: Testámos a folha da Chegatta contra um recibo português real.
- O cenário de restaurante está aqui: A folha de restaurante é mais difícil do que a folha de escritório — o que testámos.
- A prova de isolamento está aqui: Provámos que não há vazamento cruzado entre funcionários nos cálculos de folha.
- O resumo honesto que tudo isto agrupa está aqui: Por que é que publicamos os resultados dos nossos testes de folha em vez de fingirmos que tudo é perfeito.