Como governar os desenvolvimentos próprios que rodam junto do GUEPARDO Tax?

Discordo de neutralizar extensão para comparar. O detalhe é que, né, muita extensão só aparece em cenário raro, e um mês de teste não pega. Antes de aposentar, rode um trimestre fechado inteiro e compare com a evidência guardada. Outra coisa: parte do que vocês têm pode estar em ponto de extensão previsto pelo produto. A documentação da NTT cita, por exemplo, BAdI e enhancement spot no preenchimento das fichas da ECF. Nesse caso o caminho é o esperado e a regra é só documentar dono e objetivo.

Na real, é uma questão de risco que o controller precisa enxergar: extensão sem dono é passivo. Peça ao fiscal três números por trimestre: quantas extensões existem, quantas têm dono e quantas têm teste de regressão. Não fixe meta; o objetivo é a curva cair. E antes de aposentar qualquer uma, a decisão de que a regra de negócio não existe mais é do fiscal da empresa, não da TI.

Comece pelo inventário, nesta ordem:

1. Liste os objetos Z e enhancements que tocam o fiscal: programas, pontos de extensão, relatórios.
2. Para cada um, registre dono, objetivo e o que ele assume do produto ou do padrão.
3. Marque a classe: altera valor, altera arquivo entregue ou só relatório.

O pulo do gato, tá, é a terceira coluna: ela define a ordem de teste e de limpeza. Sem classe, tudo parece igualmente urgente e a lista nunca anda.

Bem, veja bem, eu não começaria pelo código. Começo pelas obrigações e pergunto, para cada uma, se o resultado depende de algo programado:

1. Escolha uma obrigação já fechada.
2. Gere o resultado em ambiente de teste, nunca em produção, com a extensão neutralizada.
3. Compare com o que foi entregue.

Se não muda, a extensão é candidata a aposentar. Assim a lista sai do bolso das pessoas e passa a vir do resultado.