Como separar o que é padrão do GUEPARDO Tax do que foi customizado na nossa empresa?

Resumo da dúvida resolvido aqui de outro jeito, por prioridade:

1. Pegar só os cinco resultados que mais pesam no fechamento: apuração, guia, arquivo ao Fisco, contabilização, conciliação.
2. Para cada um, perguntar qual extensão altera o valor.
3. Só o que altera valor ou arquivo entra no inventário inicial.

O desenho é assim porque inventariar tudo trava o projeto. O resto vai para uma segunda lista, com dono e data.

Dúvida pontual, mas discordo de usar só o nome como critério. Bem, olhando o log da nossa última atualização, havia objeto Z que nada tinha de fiscal e objeto com nome do produto que alguém havia alterado. Regra de decisão que usamos: parametrização antes de desenvolvimento, e ponto de extensão previsto antes de alterar objeto do padrão. Se um objeto do produto foi alterado, trate como o pior caso, porque a atualização sobrescreve. A documentação que consultamos não diz como o produto reage a alteração direta: confirme com a NTT ou teste no ambiente.

Ponto único: o namespace pega o objeto Z, mas não pega a implementação de ponto de extensão. A documentação da NTT cita BAdIs do próprio produto que permitem ao cliente alterar o resultado, por exemplo o /FHG/BADI_ECD, de inclusão ou alteração de registros da ECD, e o /FHG/BADI_PIS. Agora, o cerne: liste as implementações de cada BAdI do produto, porque é ali que mora a customização que não tem nome Z visível. Cada implementação vira uma linha do inventário.

Direto ao ponto: comece pelo nome dos objetos. A documentação da NTT descreve o produto como add-on ABAP com objetos em namespace próprio, com prefixo /FHG/ para o produto e /FHGT/ para a variante de TDF. Em resumo, viu, tudo que está fora desse namespace, como objetos Z, é do cliente. Faça uma lista dos objetos Z que tocam fiscal e comece o inventário por ela. Isso separa o grosso em um dia e dá ao time um primeiro mapa, ainda sem pontos de extensão.