Como definir uma regra de exceção fiscal com segurança no ambiente SAP e GUEPARDO Tax?

Discordo de um ponto: inventário não basta se ninguém testa. Segundo a documentação da NTT, a natureza da receita não é determinada por NCM e exige desenvolvimento via BAdI. Isso mostra que parte do comportamento nasce em extensão. Agora, dito isso, cada extensão precisa de um caso de teste com documento real e resultado esperado, guardado junto. Sem o teste, o inventário vira lista de nomes.

Aqui fizemos de outro jeito. A exceção ficou como regra de dado, não de código: uma tabela de parâmetros com a condição, a vigência e o responsável, lida pela rotina padrão. Assim ela aparece numa consulta e entra na revisão periódica. A conta é simples: se a exceção só existe dentro de um programa, ninguém revisa. Isso é escolha de projeto, não regra do produto, e a documentação da NTT não afirma que o produto leia tabela própria desse tipo.

A primeira frase que responde sozinha: trate a exceção como regra com dono, não como ajuste. Então, a fonte é a nossa rotina, não o produto: cada exceção tem um dono, uma data, o vínculo com a regra e a decisão do tributário registrada. A documentação da NTT sugere, na parte de PIS e COFINS, a transação /FHG/APC04 para criar apuração com configuração diferente da oficial. O material que temos não afirma que isso serve para toda exceção; teste no ambiente.

Complemento com a ordem de decisão, resumindo, né:

1. Dá para resolver só com parametrização? Então não desenvolva.
2. Precisa de código? Use ponto de extensão previsto, nunca altere objeto padrão.
3. Registre a extensão em inventário com dono e objetivo.
4. Faça análise de impacto antes e regressão depois.

Em campo, a exceção que vira gambiarra é a que pulou o passo 1.