O que uma extensão Z em SD ou MM muda para o time que opera o GUEPARDO Tax?

Discordo de tratar tudo como inventário depois do fato. Agora, pelo meu histórico, o que funciona é a regra ser anterior: nenhuma exit que altere imposto vai para produção sem aviso ao time fiscal no pedido de transporte. Inventário depois do fato mantém a dor, porque o que quebra na atualização é justamente a extensão que ninguém conhece.

Um limite: o material que temos não afirma que o GUEPARDO Tax detecte sozinho uma exit nova. Se isso importa, confirme com a NTT ou teste no ambiente com uma exit de teste.

O caminho é, viu, tratar isso como inventário vivo. Em nota de projeto, a regra de decisão é parametrização antes de desenvolvimento, ponto de extensão previsto antes de alterar objeto padrão, e inventário com dono, objetivo e o que cada extensão assume do produto. Isso é julgamento de projeto, não regra do produto.

Para as duas sem dono: registre como risco aberto, com data, e peça ao fiscal a validação do efeito no imposto. Como auditora, aceito extensão sem dono se o risco estiver escrito e revisado.

Resumindo, pois é: além de listar, grave o que cada extensão assume do padrão. Por exemplo, se a exit espera que o dado mestre do material traga certo campo preenchido. Quando o dado muda, a extensão quebra sem aviso.

Acompanho o assunto desde a implantação do RISE with SAP e o que mais ajudou foi uma coluna chamada depende de, com o campo ou a tabela. Na hora de uma mudança, o time do GUEPARDO Tax filtra por essa coluna e sabe o que olhar.

Quem registra é o desenvolvedor que criou, no mesmo dia em que transporta. Colocando no papel, cada extensão precisa de uma linha com quatro campos: o objeto (exit ou BAdI), o que ela altera no imposto, quem pediu e quem responde por ela. Sem dono, a linha não vale.

Passei por situação parecida no fechamento do mês passado: uma exit de MM alterou a base e só achamos olhando o transporte. Peça a lista de transportes que tocaram SD e MM e monte o inventário a partir dela.