Como lidar com enhancements existentes no SAP ao implantar o GUEPARDO Tax?

Boa noite, colegas. Sou analista fiscal e acabei de assumir a área, vindo de agro, então falo do lado de quem usa. Para provar a necessidade, a conta é, tá, simples: pegue um período fechado e rode as notas com e sem o programa, em ambiente de teste, e compare o valor do imposto. Se não mudar, o programa é candidato a sair. Quem assina é o dono do processo fiscal, com a TI como testemunha técnica da regressão.

Vamos ao que interessa, com o que a documentação mostra de ponto de extensão. A wiki da NTT cita pontos previstos: a ECF aceita extensão por BAdI e enhancement spot, e a natureza da receita no PIS/COFINS, sem determinação por NCM, exige desenvolvimento via BAdI. Aqui na empresa, tá, isso nos ajudou a ver que parte do que era Z poderia virar ponto previsto. O que o produto faz com um exit antigo do SAP, a documentação consultada não afirma; teste no ambiente.

Pessoal, bom dia. Discordo de começar pelo inventário completo: em projeto com prazo, ele vira meses. Eu começaria pelos programas que tocam valor de imposto, e deixaria o resto para depois. A prova é, ó, o que quebra o fechamento: segundo as notas de projeto, as extensões Z são a parte que mais quebra na atualização e ninguém sabe dizer qual existe, quem escreveu e o que assume do produto. Priorize por risco ao valor, não por ordem alfabética.

Comece pelo inventário, e só depois discuta o que manter. Segundo as notas de projeto que consultamos, 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, objetivo e o que cada extensão assume do produto, e análise de impacto antes com regressão depois. No nosso caso, pois é, o item mais difícil foi achar o dono de cada programa.