Como planejar a virada fiscal da migração para S/4HANA sem travar o fechamento?

Discordo de usar o primeiro fechamento como único marco: pelo que testei, tá, esperar até lá deixa o erro chegar ao arquivo oficial. Eu acrescentaria um ensaio antes da virada: apurar no ambiente novo um período já fechado e comparar saldo por conta e valor por obrigação com o que foi entregue. Se o ensaio não bate, a virada não acontece. O primeiro fechamento real entra depois como confirmação, não como descoberta.

Agora, no meu dia a dia, a gente fez de outro jeito: empurramos a virada para o início do mês seguinte, depois de entregues as obrigações do trimestre. O raciocínio é o mesmo que se usa em atualização de versão do produto fiscal: janela depois que as obrigações estiverem geradas e entregues. Comparação:

1. Pró: o fechamento do trimestre fica inteiro no ambiente antigo.
2. Contra: a virada cai numa semana em que o time já está cansado, e o fechamento do mês seguinte vem logo.
3. Decisão da diretoria, com os dois cenários escritos lado a lado.

A virada no fim do trimestre é viável se o fiscal tiver janela própria e se as entregas do período estiverem fechadas antes. Bem, minha leitura, vindo de outra área, é que o risco maior não é técnico, é de calendário. Liste todas as obrigações e guias que vencem entre o congelamento e o primeiro fechamento no ambiente novo e decida quais fecham no antigo. O que não couber nessa janela vira a lista de riscos para a diretoria.

E aí, de perto, o que costuma dar problema é a descoberta tardia: o projeto passa nos testes e o primeiro fechamento mostra diferença de saldo, obrigação rejeitada ou nota que não contabiliza. É um padrão que aparece em sínteses de projeto, não uma medição. Por isso, peça à diretoria que aprove o primeiro fechamento real como marco de aceite, e não o fim dos testes. Aprove também, antes, quem tem a palavra para adiar a virada se um critério falhar.