Quais são os erros mais comuns em ABAP fiscal e customização fiscal?

Concordo em parte com a Carolina e com o Carlos: cadastro e cenário importam. Discordo quando a conversa vira obrigatoriedade de código, porque no rollout, tá, a maioria das regras cabe em parametrização. Nós adotamos uma tabela de regra fiscal parametrizada, com validação de dados na entrada, e só abrimos programa quando a lógica não cabe nela. Esse caminho vale quando a equipe de negócio precisa mexer sozinha. Quando a regra é complexa e pouco mutável, um programa bem documentado ainda é a escolha certa.

O risco que eu já vi é a tabela parametrizada crescer sem dono, até ninguém saber qual linha está valendo. Murilo Vieira tem razão em separar parametrização de código, e eu acrescentaria um relatório mensal das regras ativas com data de criação, para pegar linhas órfãs. Falando sério, tá, num projeto de migração que eu acompanhei, uma linha esquecida gerou diferença por meses antes de alguém notar. O custo de manter esse inventário é baixo perto do dano.

Será que o erro mais caro é mesmo o cenário que ninguém testou? Discordo com educação do Carlos Pinto nesse ponto. No e-commerce, o que mais nos custou foi a dependência de dados de cadastro, como classificação de produto e de cliente, que mudaram sem aviso e fizeram a regra certa parecer errada. E aí, se não me engano, o código estava correto o tempo todo. Antes de reescrever a rotina, eu conferiria a qualidade do cadastro que alimenta a regra.

Na nossa obra, o caso concreto é a regra mudando no meio do mês e o relatório ficando com dois valores para a mesma nota. Agora, minha ressalva: Leandro Pinto, quando você fala em um caso de teste por combinação, como montaria isso no ciclo mensal sem explodir o número de cenários? Não quero um conjunto gigante que ninguém roda.

Se a documentação ficar ao lado do código, ela só vale enquanto alguém lembrar de atualizar, e o fato é que, ó, isso quase nunca acontece no varejo. Discordo do Leandro Pinto nesse ponto específico. Prefiro a documentação atrelada à mudança de transporte, com campo obrigatório de justificativa, porque aí o controle de mudança me obriga a registrar a regra. Comentário no código ajuda quem lê depois, mas não prova que a regra foi revisada. Auditor precisa dessa prova, não de boa vontade.

O resultado que importa é que a lista de cenários precisa existir antes do código, e não depois. O Leandro Pinto acertou ao falar da documentação em linguagem de negócio, e eu acrescentaria a data de cada mudança de regra junto com o caso de teste. E aí, conforme o combinado, eu levo esse modelo para a equipe de ECC que ainda mantemos na mineração, porque lá a lógica está espalhada em rotinas antigas e ninguém sabe onde começa. Sem essa trilha, cada alteração vira um novo ponto cego.

Sem caso de teste, não. O erro mais comum é alterar a rotina sem uma lista de cenários que ela precisa cobrir, e aí a regra falha justo no caso que ninguém pensou. No fim das contas, ó, o segundo erro é depender de uma pessoa só para entender a lógica, e quando ela sai, ninguém sabe mexer. Eu documentaria a regra em linguagem de negócio, ao lado do código, e manteria um caso de teste para cada combinação de imposto que já apareceu.