Como decidir se uma regra própria no GUEPARDO Tax é necessária ou se o padrão atende?

Foi mal a pergunta, mas discordo de tratar toda regra própria como custo a evitar. Agora, como se diz, existem casos em que o padrão não resolve: o material cita que a natureza da receita, sem determinação por NCM, exige desenvolvimento por BAdI. Aí a regra própria é necessária, e o gestor aprova com a ficha e o teste de regressão. O critério é o mesmo, só que a resposta pode ser sim. Para a regra antiga em produção, faça análise de impacto antes e regressão depois.

Me corrijam se eu estiver errada: outra forma é usar um ponto de extensão do produto em vez de objeto novo. A documentação da NTT cita, por exemplo, BAdI para incluir ou alterar registros da ECD (/FHG/BADI_ECD) e para o preenchimento das fichas da ECF (/FHG/BADI_ECF_FICHAS). Veja, pelo meu histórico, ponto de extensão custa menos na atualização do que alterar objeto padrão, mas isso é julgamento meu, não está no material. Só vale onde o ponto existir.

Pessoal, bom dia. O critério em uma linha vem da regra de decisão das notas de projeto: parametrização antes de desenvolvimento, e ponto de extensão previsto antes de alterar objeto padrão. E aí, no go-live, usamos duas perguntas por pedido:

1. Dá para resolver por parametrização? Se sim, não é regra própria.
2. Se não dá, o produto prevê ponto de extensão para isso? Só então se desenvolve.

O que o padrão cobre em cada obrigação o material que temos não lista; confirme com a NTT ou teste no ambiente.

Deixa eu montar o quadro do custo. No meu projeto, cada regra própria ganhou uma ficha de uma página: quem pediu, qual dor resolve, qual objeto toca, quem mantém, qual teste de regressão a cobre e quando revisar. Segundo as notas de projeto, extensão em torno do fiscal é o que mais quebra na atualização, então a ficha também diz o que a regra assume do produto. Sem ficha preenchida, o pedido não entra na fila.