Como planejar a janela de atualização do GUEPARDO Tax fora do fechamento fiscal?

Veja, o pulo do gato é que discordo de achar que a janela depois das entregas resolve tudo. As extensões Z em torno do fiscal são a parte que mais quebra na atualização. A regra que costuma funcionar é parametrização antes de desenvolvimento, ponto de extensão previsto antes de alterar objeto padrão, inventário vivo com dono, e análise de impacto antes e regressão depois. Sem o inventário, a janela fica boa e o fechamento seguinte pode aparecer quebrado.

Uma ressalva, viu, que responde à dúvida do Murilo: quem valida é o cliente. O teste técnico da consultoria não prova que a apuração do mês está certa, então o aceite da regressão é do fiscal da empresa, com o contábil. Na prática:

1. A TI entrega o transporte e o resultado técnico.
2. O fiscal compara apuração, guia e contabilidade com um período já fechado.
3. Só com a comparação aceita, o transporte segue para produção.

Olhando o log, tá, uma lacuna para registrar: o material que temos não afirma o que cada NTG ou release muda, nem a política de suporte da NTT por versão. Então, antes de fechar a janela, peça à NTT por escrito o que a atualização traz e se a versão instalada continua suportada, e guarde a resposta com data. Sem isso, a regressão testa no escuro: você sabe que comparou, mas não sabe o que deveria ter mudado.

A janela costuma ser depois que as obrigações do mês estiverem geradas e entregues, porque atualizar é decisão de risco e de calendário fiscal, não só de Basis.

Então, na minha área, o roteiro é: desenvolvimento, homologação e produção, nessa ordem; regressão comparando com evidência de períodos fechados; e o primeiro fechamento real depois da atualização como o teste que conta. Sou gerente fiscal, não do fiscal em si, e peço desculpa se a ordem estiver básica, mas é o que organiza a conversa com a TI.