Se a transição vai até 2033, por que a equipe de SAP não pode esperar até 2032 para começar?

Discordo de decidir só pelo calendário. De qualquer forma, ó, do lado de vendas o que atrasa não é configuração, é cadastro de produto e de cliente incompleto. Faça uma amostra pequena de itens e meça quantos têm classificação faltando; esse número, medido por você, vale mais que qualquer prazo estimado. Se a amostra mostrar muita pendência, o plano começa já, mesmo que a regra ainda possa mudar. Se mostrar pouca, a espera é defensável.

Complementando para quem usa produto fiscal de terceiros no SAP, como nós. Agora, aqui por perto, a primeira coisa que fiz foi perguntar qual versão o produto exige para cada mudança. A documentação que consultamos não registra versão mínima exigida pelo Tax; isso não quer dizer que não exista, quer dizer que não está lá. Confirme com a NTT por escrito e anexe a resposta ao plano. Sem essa versão, a conta de prazo do passo 3 da Camila fica incompleta.

Aqui a gente fez diferente: em vez de uma data, definimos gatilhos. O projeto começa quando qualquer um deles aparecer: um módulo do fiscal com dependência de versão, uma equipe de dados sem folga, ou uma regra publicada que muda campo do documento. Fiz um quadro simples para a diretoria, com colunas de gatilho, dono e evidência. No mês passado, pois é, um dos gatilhos disparou antes do esperado e já tínhamos o responsável definido. Ainda estou aprendendo, mas gatilho com dono evita discussão de calendário.

O critério não é o fim da transição, é quanto tempo o trabalho leva até ficar testado. Bem, batendo o olho no seu caso, eu faria assim:

1. Liste as entregas: dado mestre, parametrização, extensões próprias, interfaces.
2. Estime cada uma com base nos seus últimos projetos fiscais.
3. Some o tempo de teste e de correção.
4. Subtraia da data em que você precisa estar pronto.

O que sobrar é a data limite de início, e ela quase sempre vem antes do que o gestor imagina.