Como funciona ABAP fiscal e customização fiscal no SAP?

Vamos por partes. Olha, o desenho é simples: criamos um conjunto de funções padrão para cálculo de imposto, e cada cliente só chama a função com seus parâmetros. Isso vale quando há muitos clientes com regras parecidas, porque a correção acontece num lugar só. Quando a exceção é de um cliente só, prefiro um programa isolado, com nome que deixe claro de quem é. O que eu não faria é misturar os dois na mesma rotina, porque ninguém sabe qual caminho uma regra percorreu.

O resultado que importa é a rastreabilidade: cada regra precisa dizer onde mora e quem responde por ela. O Fábio Barbosa tem razão em manter o programa pequeno, e o ponto que eu acrescentaria é o registro da versão do parâmetro, para saber qual valor estava valendo em cada documento. Minha opinião, ó, é que sem isso o fechamento vira arqueologia quando o fiscal pergunta o que aconteceu num mês passado. Na mineração a gente aprendeu isso na marra, e registrar a versão custa pouco perto do retrabalho.

O risco que eu já vi é o ABAP fiscal virar uma regra escondida que ninguém do fiscal consegue auditar. Então a resposta curta é: configuração primeiro, e ABAP só quando a lógica não cabe nela. Bem, por via das dúvidas, eu documentaria cada desvio com a justificativa escrita e manteria o programa pequeno, lendo parâmetros em vez de embutir valores. Assim, quando a regra muda, você troca o parâmetro e não reescreve o código.

Fábio, discordo de uma parte: ler parâmetros não resolve tudo. O básico, pois é, é que um parâmetro bem escolhido vira só mais um ponto de falha se ninguém testa a combinação de valores. Na minha experiência de automotivo, o problema apareceu quando dois parâmetros mudaram juntos e o resultado ficou errado sem nenhum erro visível. Eu acrescentaria um caso de teste por combinação relevante, e não só por regra isolada. Assim o parâmetro deixa de ser atalho e vira algo auditável.