S/4HANA n'est pas ECC avec un nouveau nom

Beaucoup d’équipes abordent le passage à S/4HANA comme une montée de version : même périmètre, même logique, un moteur plus rapide. Ce cadrage peut sous-estimer l’effort et les risques de la reprise. S/4HANA n’est pas ECC accéléré. Son modèle de données comporte des changements qui demandent de vérifier les correspondances, les transformations et les contrôles de reprise.

On ne charge pas des données dans S/4HANA. On charge des données qualifiées pour S/4HANA.

Le schéma a changé là où on ne regarde pas

Les écrans se ressemblent. Les tables, non. Trois changements suffisent à faire dérailler une reprise mal préparée :

• MATDOC devient le stockage des documents matière, auparavant répartis entre MKPF et MSEG. Des mécanismes de compatibilité maintiennent certains accès historiques ; leur comportement doit être vérifié pour la version et le mode d’accès utilisés ;
• ACDOCA, le journal universel, réunit des données de comptabilité générale et analytique auparavant réparties entre plusieurs structures ;
• BSEG, contrairement à une idée répandue, ne disparaît pas. Il coexiste avec ACDOCA : leur rôle et leurs correspondances doivent être pris en compte dans les contrôles de reprise.

SAP documente le stockage des documents matière dans MATDOC et les contrôles de correspondance entre BSEG et ACDOCA.

Ces changements doivent figurer dans le cadrage technique et fonctionnel. Il faut définir les règles de transformation et de réconciliation selon le scénario de transition, la version et les interfaces utilisées. Un audit de données prépare ce travail dès le début du projet.

Une donnée valide n’est pas une donnée qualifiée

Une donnée peut être parfaitement correcte dans ECC et inutilisable dans S/4HANA. Un mouvement de stock cohérent côté source peut violer une contrainte du document matière. Une écriture équilibrée dans l’ancien plan comptable peut ne pas se projeter proprement dans le journal universel.

Dans cet article, la validité désigne l’acceptation par le système d’origine. La qualification ajoute la conformité aux contraintes cibles et la conservation du sens métier attendu. Une donnée acceptée par la cible peut encore porter une mauvaise unité, une référence incorrecte ou un rattachement comptable erroné.

Qualifier chaque enregistrement et ses relations

Chaque enregistrement doit avoir un résultat de contrôle traçable. Cela n’impose pas un traitement technique isolé par ligne : des traitements par lots peuvent appliquer les mêmes contrôles. Les objets liés demandent aussi des vérifications de cohérence à l’échelle du document, de la structure ou du processus métier.

Une architecture event-driven avec suivi et rejeu peut organiser ce travail. Les écarts sont diagnostiqués, corrigés ou arbitrés, puis rejoués ; les objets dépendants attendent les prérequis nécessaires. Un statut de chargement accepté reste une preuve technique partielle.

Avant la bascule, il faut aussi réconcilier les valeurs transformées, vérifier les relations et exécuter les processus métier concernés, puis répéter la chaîne dans la fenêtre prévue. Ce sont des preuves complémentaires, décrites dans notre article sur les niveaux de test d’une migration. Le Go-Live se décide sur leurs résultats et sur le traitement explicite des écarts restants.