Como proteger o fiscal na migração para S/4HANA com a reforma acontecendo ao mesmo tempo?

Discordo em um ponto: não dá para separar os dois como se o teste fosse o mesmo. Puxando o fio, né, a bateria fiscal precisa rodar no modo atual e no modo novo, com conciliação contábil. Na prática de projeto, teste só no modo atual não basta para a virada. Se a reforma ficar para depois, deixe previsto o segundo ciclo de testes, com data e dono, para não virar promessa.

Agora, meu ponto é o dado: NCM, classificação e regra de crédito. Se a migração de materiais carrega NCM ruim, a reforma herda o erro. Separe uma checagem de dado por onda, com amostra de materiais. No lado SAP, o manual que temos lista SAP Notes da reforma e um Support Package mínimo para mudanças legais do Brasil (nota 3563053); confirme a versão vigente no SAP, porque a lista é de uma data de compilação.

Aqui a gente resolveu de outro jeito: o corte fiscal ganhou janela própria e a reforma só entra na onda seguinte. Veja, como de costume, juntar tudo no mesmo corte aumenta o que pode dar errado e dificulta saber qual mudança causou a diferença no primeiro fechamento. Isso só vale se a data da reforma permitir, e essa conta é do tributário e do gestor do projeto. Segundo o material que temos, cutover com janela própria do fiscal e realização por ondas fazem parte do desenho de migração.

No meu time, pois é, o que protege o fiscal é transformar os testes fiscais em critério de saída de cada onda: se não passam, a onda não vira. Antes disso, faça um inventário das obrigações que o sistema gera e das extensões Z. Segundo uma nota de projeto que temos, na migração de ECC para S/4HANA apuração, livros e contabilização dependem de parametrização, extensões Z e dado mestre que não migram sozinhos, e isso costuma ser descoberto tarde. É julgamento de projeto, não medição. O inventário serve para descobrir cedo.