Sap drc public cloud

Sérgio, concordo que o fechamento do cadastro é crucial antes da transição para a nuvem, mas acho que simplificar demais ao focar apenas no campo de cabeçalho pode não capturar a totalidade das dificuldades. Quando migramos de um ambiente legado para o novo, o problema transcende a simples existência ou não do dado; envolve a coerência e a granularidade com que essa informação foi estruturada no sistema antigo, o que frequentemente nos surpreende ao tentar replicar no novo cenário.

Quem ganhou aqui foi a abordagem de manter um espelho do cadastro no ERP novo, com validação em lote antes de cada envio, em vez de corrigir caso a caso. Mas, bem, minha ressalva é que isso só compensa quando o volume de pedidos é alto e o cadastro muda pouco; se o cliente altera dados toda semana, o espelho vira mais um problema. Para volumes baixos, eu deixaria a validação manual na tela, que é mais lenta, mas fácil de explicar numa auditoria. Na public cloud, a escolha depende de quem vai operar o DRC no dia a dia.

Sérgio, isso faz sentido aqui. No meu caso, o cadastro passa por aprovação, mas o campo de cabeçalho ainda vem vazio quando o pedido nasce no ERP novo. Você falou em regra de preenchimento na origem. Essa regra fica no próprio cadastro ou precisa de um ajuste de validação, e aí, na sustentação, quem cuida disso depois da virada?

Renato, a resposta curta é que o cadastro do cliente precisa estar fechado antes do DRC entrar em produção. Eu vi isso de perto, e então, na última auditoria que acompanhei, o problema não estava na nota em si, e sim no campo de cabeçalho que a public cloud valida e o ECC deixava em branco. A saída que funcionou foi tratar o dado na origem, com regra de preenchimento obrigatório, e só depois liberar a integração. Antes de testar a nuvem, eu faria uma conferência do cadastro com o time comercial.