Quem aprova uma regra programada pela própria empresa no ambiente do GUEPARDO Tax?

Discordo em um ponto: comitê para tudo vira fila. E aí, veja bem, classifique por risco:

1. altera valor de imposto, base ou obrigação: aprovação formal e teste com período fechado;
2. altera só relatório ou tela: aprovação do dono do processo;
3. correção de erro urgente: registro logo depois, com a mesma ficha.

É critério de prática, ajuste ao que o seu tributário e a sua auditoria aceitam.

Olha, saindo um pouco do tema, vale conferir quem pode alterar e transportar: quem escreve a regra não deveria ser quem libera para produção. E atenção ao que o suporte cobre: o material que temos diz que a manutenção da licença e a correção de defeitos do produto são da NTT, mas não afirma como a NTT trata extensão feita pelo cliente. Confirme com a NTT antes de abrir chamado sobre algo que é regra própria.

E aí, na prática, o que funciona é uma ficha de mudança com campos fixos: objetivo, quem pediu, o que a extensão assume do produto, teste e dono. Use o ponto de extensão previsto em vez de alterar objeto padrão. A documentação da NTT cita, por exemplo, o BAdI /FHG/BADI_PIS para determinar a natureza da receita no PIS e Cofins, onde não há determinação por NCM. Uma lista viva dessas fichas vira o inventário que a auditoria pede.

Aqui a gente resolveu de outro jeito: antes de aprovar desenvolvimento, perguntamos se parametrização resolve. Calma lá, tá: muita regra especial é configuração que faltava. Só se a resposta for não, abre a ficha de desenvolvimento. Reduziu a quantidade de regras próprias e, com isso, o que precisa ser aprovado e mantido. É a mesma ordem de decisão que o material de projeto que temos registra: parametrização antes de desenvolvimento.

Agora, um ponto importante: são duas aprovações diferentes. O dono do processo fiscal, do lado do cliente, aprova o que a regra faz; a TI aprova como ela foi construída, testada e transportada. A decisão de tratamento fiscal é sempre do cliente, nunca do desenvolvedor. No registro, deixe o que a regra faz, por que existe, quem pediu, quem aprovou, a data e o teste feito. Dossiê com data, dono e vínculo com a regra é o que o auditor vai pedir.