Depuis le passage à S/4HANA, la question « comment synchroniser les données entre SAP ERP et EWM » n’a plus la même réponse, et beaucoup de projets s’y trompent encore en cherchant à activer le Core Interface par réflexe.
La synchronisation des données entre SAP ERP et EWM dépend en réalité d’un seul choix d’architecture : l’EWM est-il embedded ou décentralisé ? Dans un cas, il n’y a rien à synchroniser parce que les données de base sont partagées. Dans l’autre, le CIF est devenu inutilisable et ce sont l’ALE puis le DRF qui prennent le relais. Ce guide démêle les deux scénarios et, surtout, dit qui crée quoi, comment, et à quel moment.
- L’ERP reste le système leader des données de base : le flux va dans un seul sens, ERP vers EWM.
- En embedded EWM (S/4HANA), rien n’est synchronisé : EWM réutilise les données partagées de l’ERP. Le SCM Product est créé en background, les Supply Chain Units à la main.
- En décentralisé, le transfert est réel : jusqu’à EWM 9.5 via le Core Interface (CIF), puis en S/4HANA via un ALE distribution model (IDocs) ou le DRF.
- Le CIF n’est pas utilisable pour un EWM décentralisé S/4HANA : il ne crée que des données de base SCM.
Données de base dans SAP EWM : un seul système leader, l’ERP
Avant de parler de transfert, un rappel qui évite la moitié des malentendus : les données de base (master data) sont maintenues centralement dans l’ERP. L’ERP est le système leader, et le flux vers EWM va toujours dans un seul sens. « Synchroniser » laisse croire à un échange bidirectionnel, ce qui n’est pas le cas ici.
Le Material master de l’ERP devient le Product master côté EWM. Concrètement, le transfert des données de base de SAP ERP vers SAP EWM reprend surtout les descriptions, les unités de mesure, le material group, le poids et le volume. Le Plant, le shipping point, le customer master et le vendor master existent des deux côtés, mais les objets EWM ne sont pas identiques à ceux de l’ERP : seuls les champs pertinents sont copiés vers les locations et les business partners correspondants. La Supply Chain Unit (SCU), enfin, est un sous-ensemble d’informations d’une location, requis spécifiquement pour EWM.
En embedded, les données sont partagées : un seul jeu de données de base, lu par les deux composants. En décentralisé, elles sont répliquées : un transfert physique copie les données de l’ERP vers la base séparée de l’EWM. Confondre les deux fausse l’estimation de charge d’un projet.
Embedded EWM (S/4HANA) : il n’y a rien à synchroniser
Dans un EWM embedded, l’EWM et l’ERP vivent dans le même système S/4HANA et partagent la même base de données. Aucune distribution de données de base n’est nécessaire : EWM réutilise directement les données de la part ERP. La question du transfert ne se pose donc pas.
Deux nuances pratiques que les key users confondent souvent :
| Objet | En embedded EWM |
|---|---|
| Données de base ERP (matériel, partenaires) | Partagées, lues directement, rien à transférer |
| SCM Product (Warehouse Product) | Créé automatiquement en background |
| Supply Chain Unit (SCU) | À créer manuellement |
| Location | Non utilisée en embedded |
Le SCM Product est généré en arrière-plan, sans intervention. En revanche, la Supply Chain Unit reste à créer à la main : c’est l’oubli le plus fréquent au démarrage. Et contrairement au décentralisé, les Locations ne sont pas utilisées en embedded, ce qui simplifie le modèle.
EWM décentralisé : du CIF à l’ALE puis au DRF
Dans un EWM décentralisé, l’EWM tourne sur un système séparé, avec sa propre base de données. Là, le transfert des données de base est bien réel, toujours de l’ERP vers EWM. Et la méthode a changé de génération en génération.
Jusqu’à SAP EWM 9.5, basé sur la plateforme SCM, la distribution des données de base depuis l’ERP passait par le Core Interface (CIF). Le CIF servait historiquement à alimenter les systèmes SCM, et il était réutilisé pour les besoins EWM.
Avec un EWM décentralisé sur S/4HANA, la donne change : le CIF n’est pas utilisable pour les données de base. La raison est précise et c’est elle qui piège les projets. Le CIF ne sait créer que des données de base de type SCM, or la part EWM d’un système décentralisé S/4HANA réutilise des données de base de type ERP, exactement comme un embedded. Le transfert passe donc par un ALE distribution model (avec des IDocs) ou par le Data Replication Framework (DRF, via des services). Pour la première release du décentralisé S/4HANA, seul l’ALE était disponible ; il est remplacé progressivement par le DRF. Côté création manuelle, le Plant et les Supply Chain Units (pour l’entrepôt et les shipping points) doivent être saisis à la main.
Embedded ou décentralisé : la décision en un coup d’œil
Le choix entre embedded et décentralisé se fait pour des raisons d’architecture globale, pas seulement pour la question des données de base. Mais la charge d’intégration des données de base est un critère concret qui pèse dans la balance.
Embedded EWM
- Un seul système S/4HANA, base partagée
- Aucun transfert de données de base à configurer
- SCM Product automatique, SCU manuelle
- Couplage fort avec l’ERP, intégration PP simple
- Driver typique : simplicité, périmètre intégré
EWM décentralisé
- Système séparé, base de données propre
- Transfert à configurer : ALE ou DRF (CIF jusqu’à 9.5)
- Plant et SCU à créer manuellement
- Découplage de l’ERP, montée en charge entrepôt
- Driver typique : automatisation, haute volumétrie, indépendance
En résumé : l’automatisation poussée de l’entrepôt et le besoin de découpler la cadence EWM de l’ERP orientent vers le décentralisé ; la simplicité et l’intégration étroite avec la production poussent vers l’embedded. La synchronisation des données de base est une conséquence de ce choix, pas son critère premier. Si vous hésitez sur le mode de déploiement lui-même, le guide pour choisir entre WM, Stock Room Management et EWM pose le cadre.
Quoi est créé automatiquement, quoi à la main
Reste la question la plus concrète, et la moins souvent traitée : par objet et par déploiement, qu’est-ce qui est partagé, créé automatiquement, ou à saisir manuellement ?
| Objet | Embedded S/4HANA | Décentralisé S/4HANA |
|---|---|---|
| Données de base ERP (matériel, partenaires) | Partagées | Transférées (ALE ou DRF) |
| SCM Product (Warehouse Product) | Auto (background) | Transféré puis enrichi |
| Supply Chain Unit (SCU) | Manuelle | Manuelle |
| Plant | Partagé | Manuel |
| Location | Non utilisée | Utilisée (détermination de route) |
Trois réflexes utiles. La Supply Chain Unit est toujours manuelle, dans les deux modes : un warehouse number doit obligatoirement être rattaché à une SCU, et l’oublier bloque les premiers mouvements. La distinction données de base contre customizing reste nette : ce tableau ne parle que de données de base, le paramétrage suit ses propres règles. Et l’autre moitié du contrat entre les deux systèmes, côté stock cette fois, repose sur les availability groups et les storage locations ROD et AFS.
FAQ : synchronisation des données entre SAP ERP et EWM
Faut-il synchroniser les données de base en embedded EWM ?
Non. En embedded EWM (S/4HANA), aucune distribution n’est nécessaire : l’EWM réutilise directement les données de base partagées de la part ERP du même système. Le SCM Product est créé automatiquement en background, mais les Supply Chain Units restent à créer manuellement.
Pourquoi le CIF n’est-il plus utilisable en EWM décentralisé sur S/4HANA ?
Parce que le Core Interface ne sait créer que des données de base de type SCM, alors qu’un EWM décentralisé sur S/4HANA réutilise des données de base de type ERP, comme un embedded. Le transfert passe donc par un ALE distribution model ou par le DRF. Le CIF restait la voie jusqu’à SAP EWM 9.5.
Quelle est la différence entre l’ALE et le DRF pour le transfert ?
L’ALE distribution model transfère les données via des IDocs ; le Data Replication Framework (DRF) les transfère via des services. Sur le décentralisé S/4HANA, la première release ne proposait que l’ALE, progressivement remplacé par le DRF.
Quelles données faut-il créer manuellement dans EWM ?
Les Supply Chain Units (pour l’entrepôt et les shipping points) dans tous les cas, et le Plant en décentralisé. Le SCM Product, lui, est créé automatiquement. Les Locations ne sont pas utilisées en embedded.
Le Material master de l’ERP est-il copié à l’identique dans EWM ?
Non. Le Product master EWM reprend les champs pertinents du Material master ERP : descriptions, unités de mesure, material group, poids et volume. Pour le Plant, le shipping point, le customer et le vendor, les deux côtés existent sans être identiques, seuls les champs utiles sont copiés.
La leçon tient en une phrase : « synchroniser » est le bon mot uniquement en décentralisé, et même là, le moyen dépend de votre release. En embedded, il n’y a rien à synchroniser, juste des Supply Chain Units à ne pas oublier. Une fois les données de base en place, l’étape suivante est l’exécution des mouvements en entrepôt, pilotée par le RF framework.
À lire ensuite
RF Framework dans SAP EWM : navigation, profils d’écran et configuration mobile
Le RF framework SAP EWM expliqué : transaction /SCWM/RFUI, navigation, touches de fonction, profils d'écran et menus personnalisés par opérateur.
Michael A.
Numéro de série SAP : guide de décision OIS2, 6 procédures et arbitrage matériel vs équipement PM
Quand activer la sérialisation SAP, comment paramétrer le profil OIS2, choisir parmi les 6 serializing procedures et arbitrer entre numéro de série matériel et équipement PM.
Pierre B.
SAP PRT (Production Resources/Tools) : guide des outillages réutilisables
Comprendre les PRT dans SAP : les 4 catégories (Material, Miscellaneous, Document, Equipment), la création MM01, l’assignation gamme et le contrôle de disponibilité, expliqués pas à pas.
Pierre B.
SAP WM 2-step picking : configurer la cascade pick / allocation pour les entrepôts à fort volume
SAP WM 2 Step Picking : cascade picking-allocation, configuration SPRO 3 niveaux, cas concret end-to-end, pièges hypercare et migration EWM.
Michael A.