Como fica o GUEPARDO Tax em um projeto de conversão do tipo brownfield para S/4HANA?

Discordo em um ponto: eu não deixaria o teste do fechamento antigo só para o início, porque o dado mestre ainda não está migrado e o resultado engana. Então, a questão é que o teste só vale com dado mestre e extensões já convertidos. Faça uma rodada leve no início, só para mapear, e a validação de verdade depois da carga. Pelo que tenho visto em projeto, o primeiro fechamento real em produção é o teste definitivo. O material que temos não afirma a ordem exata no produto; confirme com a NTT.

Minha leitura, tá, é que o ponto técnico mais concreto está na contabilidade. A documentação da NTT diz que, em S/4HANA, os lançamentos ficam na ACDOCA e por isso o produto tem a interface de busca ACDOCA. Na conversão, confirme que a configuração do produto aponta para a interface certa, e não para a usada no ECC, e compare o saldo de um período fechado nos dois ambientes. O material não detalha como a troca é feita; teste no ambiente.

E aí, olhando o log, outra forma: em vez de validar o produto só no fim, rodamos o fechamento de um período antigo no ambiente convertido logo no início e comparamos com o que já foi entregue. As diferenças aparecem cedo e ainda dá tempo de ajustar. Nas notas de projeto, a migração traz decisão registrada por obrigação (manter, substituir, não replicar), e a lista oficial de obrigações encerradas não foi lida; confirme com o fiscal da empresa quais obrigações seguem.

Não presuma que migra sozinha. Agora, a conta é: nas notas de projeto, numa 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. Na conversão, faça um inventário do que existe hoje, decida por item se replica, reconfigura ou descontinua e só depois planeje os testes. O material não traz versão mínima de S/4HANA para o produto; confirme com a NTT.