Como usar BAdIs do GUEPARDO Tax para ajustar uma regra específica sem mexer no padrão?

Foi mal a pergunta, mas discordo em um ponto: não comece pela BAdI, comece lendo. A ideia é, pois é, esgotar a parametrização antes.

1. A regra existe em configuração?
2. O campo que falta é do padrão?
3. Só então a extensão.

A documentação traz em cada módulo a seção de arquitetura, com a lista de BAdIs. Ler essa seção antes de pedir o desenvolvimento evita pedir ao ABAP algo que o produto já oferece.

Sem querer atrapalhar, do lado do key user o que eu exijo antes de aceitar a extensão:

1. Caso de teste com documento real de período já fechado.
2. Resultado antes e depois, lado a lado.
3. Lista do que não deve mudar.

Olha, vale registrar a ordem que as notas de projeto descrevem: desenvolvimento, homologação, produção, com regressão contra evidência de períodos fechados, e o primeiro fechamento real depois da mudança é o teste que conta.

Boa tarde, colegas do fiscal. Então, antes de mais nada: parametrização antes de desenvolvimento, e só depois um ponto de extensão previsto antes de alterar objeto padrão. É a regra que aparece nas notas de projeto. A documentação da NTT lista BAdIs em módulos diferentes, como /FHG/BADI_ECD para registros da ECD e /FHG/BADI_PIS para a natureza da receita. Ou seja, BAdI é o caminho quando a necessidade é regra própria e não há campo de configuração que a resolva.

Direto ao ponto: documente em três campos, dono, objetivo e o que a extensão assume do produto. O chato é que quase ninguém registra isso, e as notas de projeto dizem que extensões Z quebram na atualização sem que ninguém saiba qual existe, quem escreveu e o que assume do produto. Para o auditor, junte: pedido, aprovação do dono da regra, teste antes e depois, e a ordem de transporte.