Generix nomme Jimmy Anidjar Président non exécutif du Conseil d’administration Lire le communiqué de presse
Points essentiels à retenir
Le système maître est l’application autorisée à créer ou modifier une donnée pour une finalité définie ; une copie synchronisée n’acquiert pas cette autorité. L’intégration WMS SAP commence donc par une répartition explicite des responsabilités, et non par le choix d’un protocole.
Documentez votre environnement avant tout mapping : SAP ECC, SAP S/4HANA sur site, Cloud Private ou Cloud Public, version installée, périmètre activé et extensions existantes. Generix recommande de vérifier chaque interface dans cet environnement : une disponibilité documentée pour Cloud Public ne prouve pas sa disponibilité sur ECC, ni l’inverse.
Le scénario SAP 1ZQ d’intégration avec un entrepôt tiers, vérifié le 19 octobre 2026, décrit pour Cloud Public des échanges par API SOAP asynchrones. SAP y porte notamment les processus commerciaux et la gestion quantitative ; le WMS tiers exécute les mouvements physiques et logiques de l’entrepôt.
Attribuez un responsable aux articles, unités, lots, statuts qualité, documents et ajustements. Précisez qui décide, qui exécute et qui valide. Distinguez notamment emplacement physique, magasin SAP, quantité disponible et quantité valorisée : ces notions ne constituent pas un stock unique interchangeable.
Notre analyse des responsabilités respectives du WMS et de l’ERP complète ce cadrage sans remplacer la matrice du projet. Pour le vocabulaire général, consultez notre définition détaillée du WMS ; le présent guide traite le contrat d’échange et sa validation.
Le mapping des flux SAP-WMS décrit la correspondance entre données sources et cibles, leurs transformations et les effets attendus. Generix recommande d’associer chaque ligne à une preuve métier et à une règle de reprise avant de développer ou paramétrer l’interface.
La matrice suivante est un modèle à compléter, pas un catalogue de connecteurs garantis. Les services d’entrepôt cités figurent dans le catalogue SAP Delivery Management, édition Cloud Public 2608, vérifié le 19 octobre 2026. Leur activation, leurs restrictions et leur couverture doivent être confirmées sur votre cible.
| Objet ou événement | Maître et responsable de validation | Source → cible | Déclencheur et cadence | Clés et champs à mapper | Interface candidate avec édition SAP | Résultat métier et accusé attendu | Règle de rejet/reprise |
|---|---|---|---|---|---|---|---|
| Articles et unités | SAP pour le référentiel retenu ; responsable données | SAP → WMS | Chargement initial, puis mises à jour selon mécanisme disponible | Article, unité de base, conversions, attributs logistiques | Cloud Public 2608 : lecture via Product (Version 2), selon entités ; ECC et autres éditions : interface à vérifier | Article exploitable dans le WMS ; statut d’intégration et contrôle des conversions | Rejet explicite des références incohérentes ; reprise après correction |
| Livraison sortante et confirmation | SAP pour la livraison ; WMS pour l’exécution ; responsables expédition et SAP | SAP → WMS → SAP | Création ou libération selon scénario, puis événement d’exécution | Livraison, poste, article, quantité, unité, lot, destination | Cloud Public 1ZQ : Warehouse Shipping Order – Send to Warehouse (B2B) ; Warehouse Shipping Advice – Receive from Warehouse (B2B) | Document exécutable dans le WMS ; livraison et mouvement attendus dans SAP ; résultat corrélé | Contrôler l’état du document avant reprise ; aucune seconde comptabilisation |
| Livraison entrante ou attendu et réception | SAP pour le document ; WMS pour le réalisé ; responsables réception et SAP | SAP → WMS → SAP | Distribution du document, puis réception selon scénario | Livraison, poste, fournisseur, article, quantité, unité, lot, statut | Cloud Public 1ZQ : Warehouse Stock Transfer Shipment Advice – Send to Warehouse (B2B) ; Warehouse Stock Transfer Receipt Advice – Receive from Warehouse (B2B) | Attendu reconnu ; réception et entrée de marchandises rapprochées | Gérer partiels et références absentes ; rejouer après vérification du réalisé |
| Mouvement affectant une dimension de stock SAP | WMS pour l’événement physique ; SAP pour la comptabilisation ; responsable stocks | WMS → SAP | Événement pertinent ; cadence approuvée selon besoin et capacité | Événement, article, quantité, unité, magasin, lot, catégorie de stock | Cloud Public 2608 : API_MATERIAL_DOCUMENT, si adaptée et hors opération déjà comptabilisée par confirmation | Document matériel attendu et référence retournée | Bloquer le double circuit de comptabilisation ; rapprocher avant rejeu |
| Comptages et écarts | WMS pour le comptage ; responsable inventaire pour validation ; SAP pour l’ajustement retenu | WMS → SAP ; retour de décision | Comptage terminé, puis validation autorisée | Document, poste, exercice, article, lot, quantité, unité, motif | Cloud Public 2608 : API_PHYSICAL_INVENTORY_DOC_SRV ; opérations à sélectionner séparément | Comptage enregistré ; ajustement distinctement approuvé et traçable | Distinguer comptage nul, absent et rejeté ; reprise selon état et habilitation |
Dans notre méthode, chaque ligne renvoie à une spécification versionnée : champs obligatoires, valeurs autorisées, conversions, arrondis, gestion des valeurs absentes, ordre des événements et compatibilité des versions. Fixez la cadence selon le besoin métier et la capacité réelle, sans imposer un « temps réel » uniforme. Si le scénario exécute des livraisons, ne transmettez pas systématiquement les commandes commerciales brutes.
Le choix d’une interface dépend de l’objet métier, du sens d’échange et de l’édition SAP. IDoc, API et middleware ne sont pas trois alternatives équivalentes : le middleware constitue une couche de médiation pouvant prendre en charge des échanges IDoc ou API.
Pour un IDoc, vérifiez le type de message, le type de base, les segments, les extensions et les statuts exploités. Pour une API, contrôlez les opérations, le sens entrant ou sortant du point de vue SAP, le protocole, le mode synchrone ou asynchrone et le statut de dépréciation. Generix recommande de conserver ces références dans le dossier d’architecture.
Le référentiel SAP des API produit, édition 2608, vérifié le 19 octobre 2026, recommande Product (Version 2), en OData V4, pour les entités autres que les textes explicitement conservés sur Product Master (A2X). Ne généralisez donc pas API_PRODUCT_SRV à tout le référentiel.
Dans 1ZQ, Warehouse Intermediate Update – Receive from Warehouse (B2B) est une mise à jour intermédiaire, pas une confirmation universelle de préparation. De même, le libellé Stock Transfer ne permet pas d’étendre un service à tous les déplacements internes.
Notre guide des échanges EDI et API prolonge cette distinction. Ne dupliquez pas les règles métier dans plusieurs couches.
Une interface fiable doit distinguer transport réussi et traitement métier réussi. Un message accepté par une passerelle, livré au middleware ou reçu en HTTP ne prouve pas que la livraison, la réception ou le mouvement attendu existe dans SAP et dans le WMS.
Définissez pour chaque flux l’accusé disponible, le résultat métier à contrôler et la procédure de rapprochement. Reliez identifiant de message, événement, document et poste ; conservez les statuts, erreurs et horodatages. Generix recommande de qualifier les états « reçu », « en traitement », « rejeté » et « terminé » sans les confondre.
La documentation Material Documents — Read, Create, édition 2608 décrit API_MATERIAL_DOCUMENT pour lire, créer et annuler des documents matériels. Si une confirmation de livraison comptabilise déjà l’opération, interdisez son second enregistrement par ce service.
L’idempotence garantit qu’un même événement rejoué ne produit pas d’effet métier supplémentaire. Prévoyez une clé stable, la détection du résultat déjà enregistré et une trace des tentatives. La documentation SAP sur la qualité de service Exactly Once, vérifiée le 19 octobre 2026, explicite des conditions dépendant de l’émetteur, de la médiation et du récepteur : le middleware seul ne suffit pas.
Notre recommandation est de documenter l’ordre requis par document, la rétention des messages, l’autorité de rejeu et la reprise du retard. Si un accusé est perdu, recherchez d’abord le résultat métier. Pour les incidents déjà constatés en production, notre guide de diagnostic des écarts ERP-WMS traite l’investigation après incident.
La recette d’interface est une validation reproductible des échanges et de leurs effets métier, à partir de données, d’étapes et de résultats attendus définis. Elle doit prouver le fonctionnement nominal, les exceptions et la reprise, pas seulement la conformité du message.
Generix recommande d’utiliser la même fiche pour chaque scénario. Notre trame comprend les rubriques suivantes, à renseigner avant l’exécution :
La documentation des opérations d’inventaire SAP, édition 2608 distingue notamment comptage et comptabilisation des différences. Faites approuver par le projet les seuils de délai, de charge et de résorption du retard, sans valeur standard inventée. L’acceptation exige un résultat métier prouvé, aucune double comptabilisation et des rejets maîtrisés.
La mise en production de l’interface nécessite une acceptation conjointe métier et technique. Le contrat doit préciser comment un événement validé devient exploitable par les équipes ERP, entrepôt, transport, fournisseurs et prestataires logistiques, sans créer des versions contradictoires de la même opération.
Generix recommande de joindre au procès-verbal d’acceptation la matrice approuvée, les fiches exécutées, les anomalies restantes et les procédures de reprise. Nommez les responsables SAP, WMS, intégration et exploitation : diagnostic, correction des données, autorisation de rejeu, surveillance et escalade doivent être attribués.
La décision concerne ici l’interface, pas toute la bascule du site. Vérifiez aussi les accès aux journaux, la conservation des preuves et la gestion des évolutions. Les scripts SAP 1ZQ demandent d’ajouter les étapes propres au projet : leur exécution seule ne couvre donc pas votre configuration complète.
Un événement partagé doit conserver sa référence, son statut et sa signification jusqu’aux destinataires autorisés. Notre article sur la coordination WMS-TMS développe ce prolongement vers le transport.
Notre WMS propose des API d’intégration et appartient à une gamme intégrée comprenant WMS, TMS et OMS. Cette option permet d’envisager une coordination de l’exécution autour de SAP, sans imposer son remplacement ni présumer la compatibilité de toutes ses versions. Si une médiation est nécessaire, nous pouvons également examiner le périmètre de notre plateforme TradeXpress Infinity pour l’intégration interapplications et interentreprises.
Vous préparez une interface entre SAP et votre entrepôt ? Présentez à nos équipes votre édition SAP, vos flux prioritaires et vos cas de recette via le formulaire de notre page Generix WMS pour cadrer le périmètre d’intégration, les paramétrages et les adaptations éventuelles.
En résumé
Commencez par des contrats de données communs, puis vérifiez les interfaces standard disponibles et le besoin de médiation. Generix recommande de soumettre les échanges à une recette commune démontrant leurs effets dans chaque application. Des interfaces réutilisables peuvent limiter les développements spécifiques ; elles ne suppriment ni le mapping, ni le paramétrage, ni les tests, ni les adaptations propres au projet.
Oui, dans les scénarios documentés et compatibles avec l’édition concernée. Pour SAP S/4HANA Cloud Public, le scénario 1ZQ décrit une intégration avec un WMS tiers par API SOAP asynchrones. Cette disponibilité ne doit pas être extrapolée à toutes les éditions, versions et fonctions : chaque flux doit être confirmé sur l’environnement cible et confronté aux capacités du WMS.
Le périmètre comprend généralement articles et unités, documents d’entrée et de sortie, confirmations, mouvements pertinents pour SAP et résultats d’inventaire. Distinguez la commande commerciale, la livraison transmise pour exécution et la confirmation de l’opération. Dans le scénario 1ZQ, les échanges d’exécution reposent notamment sur les livraisons ; transmettre systématiquement toutes les commandes brutes n’est donc pas une règle.
Il n’existe pas de réponse universelle : partez de l’édition SAP, des objets métier, des opérations requises et des interfaces publiées. Une API peut être SOAP et asynchrone, comme dans le scénario Cloud Public 1ZQ ; elle n’est pas nécessairement REST ou synchrone. Le middleware est un choix d’architecture complémentaire pour transporter, transformer ou superviser ces échanges.
Décomposez la responsabilité par donnée et finalité plutôt que de désigner un maître unique du « stock ». Le scénario 1ZQ attribue notamment les processus commerciaux et la gestion quantitative à SAP, et l’exécution des mouvements physiques et logiques au WMS tiers. Le contrat doit préciser les règles de validation ; une copie synchronisée ne devient pas une source de décision autonome.
Conservez une clé métier stable, vérifiez si le résultat a déjà été enregistré et autorisez le rejeu selon une procédure tracée. Si l’accusé est perdu, contrôlez le document cible avant toute nouvelle comptabilisation. La garantie de traitement unique dépend des mécanismes de l’émetteur, du récepteur et de la médiation ; la présence d’un middleware ne l’établit pas à elle seule.
Testez unités et arrondis, lots, qualité, partiels, annulations, inventaires, doublons, messages désordonnés, accusés perdus et coupures réseau. Pour chaque cas, fixez un résultat métier et conservez sa preuve dans SAP comme dans le WMS. Ajoutez les tests propres au projet aux scripts standard, puis rejouez la non-régression après modification du mapping ; faites approuver les critères de délai et de charge.
Non, une réplication systématique n’est pas un principe à imposer. Distinguez un déplacement entre emplacements d’un événement modifiant une dimension de stock gérée dans SAP, comme le magasin ou la catégorie de stock. Le mapping doit préciser les événements nécessaires à la gestion, leur granularité et leur preuve de traitement, sans assimiler tout mouvement physique à une comptabilisation ERP.
Préparez votre sortie d’un contrat SaaS avec un modèle de clause commenté et un protocole de restitution. Vérifiez qu’un tiers peut reprendre vos données, comprendre vos règles métier et maintenir les échanges partenaires.
Mesurez les erreurs de préparation de commandes, identifiez leurs causes et chiffrez les coûts réellement supportés. Comparez les contrôles et calculez leur seuil de rentabilité à partir de vos données et d’un pilote représentatif.
Travaillez avec nos équipes pour concevoir et mettre en œuvre la Supply Chain qui accompagnera votre croissance, adaptée à vos spécificités métier.
