Como documentar uma regra de apuração do GUEPARDO Tax para que outra pessoa consiga entendê-la depois?

Olá, time. Discordo de documentar só a parametrização. Olha, para variar, a regra que ninguém entende costuma ter uma extensão por trás. Se existe BAdI ou enhancement, a página precisa dizer qual objeto, o que ele assume do produto e quem é o dono. Nas notas de projeto que li, o que reduz a quebra na atualização é um inventário vivo com dono, objetivo e o que cada extensão assume do produto. Um exemplo na documentação da NTT: natureza da receita sem determinação por NCM exige desenvolvimento via BAdI.

Oi, gente. Como sempre, tá, acrescento o teste, que é o que prova a página. Um teste por regra, com documento de exemplo, resultado esperado e resultado obtido, com data. Quando alguém mudar a regra, o teste antigo vira regressão e mostra o que mudou. E escreva também o que a regra não faz, porque é a pergunta que mais volta, e a resposta fica a um clique em vez de depender da memória de quem saiu do projeto.

Foi mal a pergunta, mas aqui vai: uma página por regra, com seis campos. Objetivo em uma frase; base legal informada pelo tributário da empresa, copiada como veio, sem interpretação minha; onde a regra está parametrizada; documento de exemplo que dispara a regra; resultado esperado com valor; data e dono. O combinado é que o consultor não escreve a base legal, quem escreve é o cliente. Assim a decisão tributária fica com quem decide, e a página só prova o comportamento.

Aqui a gente fez diferente, e aí, por assim dizer, ficou mais leve: em vez de uma página por regra, uma matriz com uma linha por regra e os seis campos em colunas, mais um link para a evidência. A página separada só existe para regra complexa. Para organizar as colunas copiei uma convenção da documentação da NTT, em que cada módulo traz visão geral, pré-requisitos, arquitetura, configurações e funcionalidades. A matriz dá visão de conjunto, e quem chega novo acha rápido qual regra mexe em qual imposto.