Quando parametrizar o GUEPARDO Tax em vez de programar uma extensão própria?

Antes de mais nada, né, discordo de parametrizar sempre. Se a regra exige 40 exceções cadastradas, a configuração vira um labirinto que ninguém explica, e um programa pequeno com dono e teste é mais claro.

Mas o critério continua o mesmo: a escolha é justificada por escrito. Dois testes para decidir: quantas linhas de cadastro a regra consome, e se um novo analista entende a regra lendo só a configuração. Se não, a extensão pode ser a melhor opção, desde que inventariada.

Então, meu ponto, como ABAP, é perguntar três coisas antes de aceitar o programa Z. A regra cabe em parâmetro, mesmo que com mais cadastro? Existe ponto de extensão previsto para ela? O que acontece com ela na próxima atualização?

A documentação de cada módulo da NTT, segundo o material, traz uma seção de arquitetura com tabelas, transações, grupos de função e BAdIs. Antes de qualquer programa Z, abra essa seção do módulo e veja se o ponto existe. Se existir, a extensão fica ao lado do produto e não dentro dele.

No mês passado a gente quase aprovou um programa Z que duplicava uma regra já parametrizável. Só descobrimos porque alguém abriu a configuração e achou a opção.

Segundo o material da NTT que temos, a manutenção da licença e a correção de defeitos do produto são da NTT. Alterar objeto padrão complica isso: o chamado de defeito pode ficar sem resposta porque o objeto não é mais o original. Mais um motivo para o ponto de extensão e a anotação de impacto.

Parametrização primeiro, extensão só com justificativa escrita. Bem, por experiência, a ordem é essa porque extensão tem custo que não aparece no pedido: manutenção, teste a cada atualização e dono.

Segundo as notas de projeto da casa, a regra de decisão é parametrização antes de desenvolvimento, ponto de extensão previsto antes de alterar objeto padrão, inventário vivo com dono e análise de impacto antes, regressão depois. Isso dá o seu critério auditável: cada extensão precisa de uma linha no inventário.