Quando fiscal no RISE e GROW with SAP exige revisar a parametrização fiscal?

Concordo em parte, a revisão precisa de um gatilho claro, e o prazo é, tá, a parte que mais atrasa. Discordo quando se espera o erro aparecer no fechamento para só então revisar. Na nossa logística, a equipe adotou uma amostra periódica de pedidos para checar a parametrização, e isso pegou desvio cedo. Esse caminho vale para operação grande com muito volume. Para operação pequena, a conferência por evento costuma ser suficiente.

Quem garante que a versão atual está certa, Kátia? Esse ponto é o que mais pesa no meu dia a dia. A sacada é, tá, guardar o motivo junto da regra e não em arquivo à parte. Eu completaria com um ponto novo: antes de cada alteração, a regra deve ser comparada com o pedido de teste que motivou a mudança, e isso dá rastreabilidade sem guardar cópia solta. Assim a dúvida de qual versão valeu fica resolvida pelo próprio registro, e não por arquivo espalhado.

Na minha rotina de FI, em agro, o caso concreto é a versão anterior ficar guardada e alguém usar a errada na consulta de auditoria. De qualquer forma, né, discordo com educação da Ana quando ela propõe guardar a versão anterior para voltar. Essa cópia pode virar a origem de uma nova dúvida, e o auditor passa a perguntar qual versão valeu em cada nota. Eu prefiro registrar a alteração com o motivo e o responsável e manter a versão atual sempre como a única ativa.

Nelson, concordo e acrescento. Aqui na empresa, a regra só vira padrão depois que o relatório novo bate com o antigo por algum tempo, e isso evita a correção em cascata. Também vale guardar a versão anterior da parametrização, para voltar sem refazer tudo se a conferência falhar. Assim a revisão deixa de ser aposta e vira procedimento com volta.

O resultado que importa é não mexer em produção sem uma cópia testada, mesmo para ajuste pequeno. Bem, o plano é testar primeiro, mas discordo com educação da Débora quando ela diz que correção pontual pode ir direto. No nosso caso, migrando de outro ERP, um ajuste pequeno na tela de imposto mudou o resultado de uma família inteira de pedidos. Pequeno no cadastro não é pequeno no fiscal. Eu manteria a cópia para qualquer alteração de regra, por menor que seja.

O risco que já vi mais é a revisão sair sem registro do motivo, e aí ninguém sabe depois por que mudou. Vanessa, o x da questão para mim é como você decide que o erro é de regra e não de dado. No nosso caso de alimentos, a tela mostra a mesma regra correta em um pedido e errada em outro, sem diferença visível no cadastro. Como você separa isso antes de mexer? Eu preciso desse critério para a minha equipe.

Concordo em parte com a Yara, porque revisar sem mapear é arriscado. Então, um alerta: discordo de esperar o problema aparecer para só então corrigir. Na nossa siderurgia, a equipe montou uma cópia de configuração para testar a mudança antes de aplicar, e comparou a tela de cada cenário. Esse caminho vale quando a mudança é grande e afeta muitos documentos. Para ajuste pequeno e pontual, a correção direta na produção, com registro, costuma bastar.

Revisar, e aí, em outras palavras, é a mesma coisa que corrigir? Vanessa, eu completaria o que você disse com um ponto de cautela: em obra, a alteração de regra pode afetar pedidos já faturados e, se isso não estiver mapeado, o retrabalho é grande. Por isso eu separaria a revisão em duas partes, o que muda para pedidos novos e o que precisa ser tratado nos já emitidos. Antes de decidir, eu registraria a relação dos documentos afetados e o impacto de cada um.

Quando a diferença aparece só em um tipo de pedido, a revisão tem que começar pela regra desse tipo. Como sempre, ó, eu revisaria a parametrização só quando o teste em ambiente de qualidade reproduzir o erro. Se o erro não se repete no teste, o problema costuma ser de dado, e mexer na regra só cria outra diferença. Quanto ao responsável, a decisão precisa ficar com quem responde pelo resultado fiscal e não com quem executa a correção.