Uma taxa de imposto escrita dentro do código é uma dívida com data de validade. Quando a lei mudar — e vai mudar — alguém tem de encontrar o número no repositório, alterá-lo, testar e reinstalar. E, pior do que o trabalho, há o efeito silencioso: todas as facturas já emitidas passam a ser recalculadas com a regra nova, incluindo as que já foram declaradas. A pergunta "que taxa se aplicou a esta factura em Março?" deixa simplesmente de ter resposta.
A alternativa é tratar cada regra fiscal como um registo datado, versionado e com a lei citada ao lado. É assim que o Enerxia — o ERP de petróleo e gás que construímos e operamos para Angola — trata IVA, retenções na fonte e imposto petrolífero. Vale a pena explicar o mecanismo, porque é transferível para qualquer sistema que tenha de sobreviver a uma auditoria.
A tabela de regras começa vazia — e é suposto
Numa instalação nova do Enerxia, a tabela tax_rule não tem uma única linha. Não há taxa por omissão, não há valor "razoável" pré-carregado, não há exemplo deixado do ambiente de testes.
Isto parece inconveniente até se perceber o que a alternativa custa. Um sistema que chega com uma taxa pré-preenchida está a afirmar um facto regulatório que ninguém verificou. Se estiver certa, ninguém repara. Se estiver errada, também ninguém repara — até a primeira auditoria, e nessa altura já há meses de documentos emitidos sobre um número que o fornecedor do software inventou.
Por isso o sistema recusa emitir o documento em vez de adivinhar. Uma factura de venda de crude sem regra fiscal configurada não sai com IVA a zero: não sai de todo, com uma mensagem que diz exactamente que regra falta. Desconhecido significa bloqueado e configurável, nunca um valor plausível colocado por omissão.
Uma taxa sem citação legal não entra
Cada regra tem um campo obrigatório de referência legal. Obrigatório a sério: a coluna é NOT NULL na base de dados, mas isso sozinho só impede o NULL — um espaço em branco satisfaz a restrição na mesma. Uma taxa cuja citação é um espaço é uma taxa inventada que passou num constrangimento.
O domínio, por isso, rejeita também a citação vazia ou simbólica. Quem introduz a taxa tem de escrever de onde ela vem. Meses depois, quando alguém perguntar porquê, a resposta está na mesma linha da tabela — não na memória de quem já saiu da empresa.
Alterar uma regra não é editá-la
Este é o ponto que separa um sistema auditável de um que apenas parece organizado.
Quando uma taxa muda, a tentação é abrir o registo e corrigir o número. O Enerxia não permite. Uma alteração regulatória cria uma nova versão com data de efeito; a versão anterior é fechada no dia anterior ao início da nova. Ambas continuam legíveis.
A diferença não é de arrumação. Corrigir a versão 1 no lugar reescreveria, em silêncio, todas as transacções já avaliadas ao abrigo dela — incluindo as que já entraram em declarações entregues. Fechar e abrir preserva a cadeia: uma factura emitida em Março continua a ser calculada com a regra de Março, mesmo depois de a regra ter mudado em Junho. Reemitir um documento antigo não o recalcula com a lei de hoje.
É isto que torna uma avaliação passada reproduzível, que é a única definição útil de "auditável".
A jurisdição não é um campo livre
A jurisdição de uma regra é retirada da entidade legal da própria empresa. Não é um parâmetro que quem preenche o formulário escolha.
A razão é de segregação, não de conveniência. A tabela de regras fiscais é global e não tem coluna de empresa — as regras de um território são as mesmas para toda a gente estabelecida nele. Se a jurisdição fosse um campo livre, o administrador de uma empresa podia escrever as regras ao abrigo das quais outra empresa é avaliada. Numa instalação com várias operadoras e prestadores de serviços, isso é um problema de controlo, não um detalhe de interface.
Duas regras no mesmo dia não são ambíguas — são o dobro
O sistema recusa duas versões da mesma regra em vigor no mesmo dia. A justificação é mais dura do que parece.
Se duas regras do mesmo código estiverem activas em simultâneo, a pergunta "qual das taxas se aplicou?" não tem resposta. E como as regras são somadas e não seleccionadas, a resposta não é "uma delas" — são as duas, silenciosamente duplicadas. Um IVA aplicado a dobrar não falha com erro. Emite um documento com um número errado e segue para a contabilidade.
Sobreposições deste tipo são o género de defeito que não se encontra a testar funcionalidades, porque cada regra está correcta isoladamente. Encontra-se a desenhar a tabela de forma a que a sobreposição seja impossível.
O que isto dá a quem audita
Juntando as peças, o registo responde a quatro perguntas que uma folha de cálculo não responde:
| Pergunta | O que responde |
|---|---|
| Que taxa se aplicou a este documento? | A versão em vigor na data do documento |
| Quem a introduziu, e quando? | Autor e data de criação no registo |
| Com que fundamento legal? | Referência legal obrigatória na mesma linha |
| Como mudou ao longo do tempo? | Versões anteriores fechadas, não apagadas |
Nenhuma destas exige que alguém se lembre de alguma coisa. É a diferença entre conformidade como prática e conformidade como propriedade do sistema.
O custo real
Vale a pena ser honesto sobre o que isto custa: mais trabalho no arranque. Alguém das finanças tem de se sentar e declarar as regras, com as citações, antes de o sistema emitir o primeiro documento. Um ERP com taxas pré-carregadas arranca mais depressa.
Arranca mais depressa e transporta um risco que só aparece mais tarde, quando é mais caro. A escolha é entre um dia de configuração no início e a reconstituição de meses de documentos no fim.
Se quiser ver o registo de regras a funcionar sobre dados reais — a criação de uma versão, a substituição por data de efeito, a recusa de uma sobreposição — o Enerxia pode ser aberto e demonstrado módulo a módulo.