Que análise de impacto fazer antes de trocar a versão do GUEPARDO Tax?

Então, a questão é que o teste técnico da consultoria não prova que a apuração do mês está certa. Quem valida é o cliente, o fiscal. Discordo de tratar como duplicado: o técnico confere se roda, o fiscal confere se o resultado está certo.

E o teste que conta é o primeiro fechamento real depois da atualização, então marque o fechamento seguinte com acompanhamento reforçado.

Pelo que vi, viu, o que mais quebra numa atualização são as extensões Z em torno do fiscal. Monte o inventário: cada extensão com dono, objetivo e o que assume do produto, e um teste para cada uma antes de atualizar.

A regra de decisão do material que consultei é parametrização antes de desenvolvimento e ponto de extensão previsto antes de alterar objeto padrão.

E aí, no rollout a gente fez de outra forma: aprovação em duas etapas. Primeiro a versão sobe só em homologação com cópia de dados de um período fechado, e o fiscal aprova com a comparação. Só depois sai o pedido de produção, para uma data logo após a entrega das obrigações.

Se o primeiro fechamento real der diferença, a regra é parar e investigar, não ajustar à mão.

Veja, o ponto é que, a decisão é de risco e de calendário fiscal, não só técnica. Janela depois que as obrigações do mês foram geradas e entregues, ordem desenvolvimento, homologação e produção, e regressão contra períodos já fechados.

Na prática: escolha dois ou três períodos fechados, reprocesse a apuração na versão nova e compare valor a valor com o que foi entregue.