Un projet d'entrepôt se vend sur la préparation de commandes. Il se bloque sur l'intégration.
La démonstration a plu, le scan a convaincu, la décision est prise. Et six semaines plus tard, un vendredi en fin d'après-midi, trois personnes essaient de comprendre pourquoi une commande de vente est descendue deux fois, pourquoi une unité de mesure a transformé douze pièces en douze cartons, et qui doit corriger quoi. Rien de cela ne concerne la préparation de commandes.
En bref
L'ERP détient la donnée commerciale. Le logiciel WMS détient l'exécution physique. La donnée de référence et la demande descendent ; les confirmations remontent. Chaque champ a un seul système de référence, et le dire avant la mise en service évite l'essentiel des difficultés.
Ce qui décide du résultat n'est pas le connecteur. C'est la qualité des données, la version de l'ERP et ce qui arrive à un message en échec.
Faites défiler latéralement pour voir toute la figure.
Ce qui descend : de l'ERP vers le WMS
La fiche article. Référence, désignation, unités de mesure et conversions de colisage, poids et dimensions, règles de lot, de numéro de série et de date de péremption. C'est le flux le plus important et le plus négligé.
Les partenaires. Fournisseurs et clients, avec les adresses de livraison et les conditions qui s'appliquent.
Les commandes d'achat. Ce qui est attendu, de qui, et quand. C'est ce contre quoi la réception se contrôle.
Les commandes de vente. Ce qui est à préparer, pour qui, avec quelles contraintes de service.
Les corrections de stock décidées par la comptabilité. Elles existent et il faut qu'elles aient un chemin, sinon elles se feront à la main des deux côtés.
Ce qui remonte : du WMS vers l'ERP
Les réceptions. Ce qui est réellement arrivé, par lot et par emplacement, avec l'écart par rapport au document attendu.
Les confirmations de prélèvement et d'expédition. Ce qui est sorti, pour quelle commande, avec quel colis et quel transporteur. C'est souvent le message qui déclenche la facturation, et c'est pour cela qu'il ne supporte pas d'attendre.
Les régularisations de stock. Les résultats de comptage et les corrections constatées sur le terrain.
Les retours entrés. Ce qui est revenu, dans quel état, et ce qui redevient vendable.
Le détail de ce que le stock porte à ce niveau — emplacement, numéro de lot, numéro de série, état — est décrit sur système de gestion des stocks, et la liste des raccordements existants sur la page du connecteur ERP.
Les quatre questions qui décident de la conception
1. À qui appartient le stock
Un seul des deux systèmes détient la position physique. En pratique, c'est le WMS dès la mise en service : il sait l'emplacement, le lot et l'engagement, ce que l'ERP n'a jamais prétendu savoir. L'ERP garde le total par article et la valeur.
Si les deux détiennent la position, vous aurez deux vérités et un travail de rapprochement permanent. Ce n'est pas un défaut de l'interface, c'est un choix qui n'a pas été fait.
2. Temps réel ou par lots, message par message
La question se tranche par message et non une fois pour toute l'interface. Une fiche article peut descendre la nuit. Une confirmation d'expédition qui déclenche une facture ne peut pas attendre le lendemain matin. Une commande de vente prise à quinze heures pour une expédition le jour même ne peut pas descendre par un traitement nocturne.
Faites écrire, pour chaque message, s'il part à l'événement ou à l'heure, et laquelle.
3. Que fait un message en échec
C'est la question la plus importante du projet et la moins posée à l'achat.
Trois réponses existent et elles ne se valent pas. Le message est rejeté silencieusement, et vous découvrirez l'écart à la fin du mois. Le message est mis en attente avec une alerte, et quelqu'un le rejoue. Ou le message bloque le flux suivant, ce qui est parfois exactement ce qu'il faut et parfois insupportable.
Demandez laquelle s'applique, pour quel message, et qui reçoit l'alerte. Une interface sans comportement d'échec défini n'est pas terminée.
4. Qui réserve
Quand une commande est saisie, est-ce l'ERP qui affecte le stock, ou le WMS ? Si c'est l'ERP, il affecte une quantité sans savoir où elle est, et le WMS devra parfois dire non. Si c'est le WMS, l'ERP doit accepter de ne pas promettre seul.
Les deux modèles fonctionnent. Celui qui ne fonctionne pas est celui où personne n'a tranché.
Les cinq endroits où ça casse réellement
Les données d'articles. Références en double, désignations divergentes, codes-barres absents. Un raccordement propre sur des données sales produit des écarts propres.
L'écart de version de l'ERP. Deux installations du même produit n'exposent pas les mêmes fonctions. C'est particulièrement net entre une ligne en nuage et une ligne installée : comparez Exact Online, accessible par interface de l'éditeur, et une installation sur site, qui demande un intergiciel. Même famille, projet différent.
Les unités de mesure. La discordance classique : l'ERP compte en cartons, l'entrepôt prélève à la pièce, et la conversion est fausse sur trois références. Cela se découvre en troisième semaine de production, sur un écart de stock que personne n'explique.
Les livraisons partielles et les reliquats. Qui décide qu'une commande part incomplète ? Que devient le reste ? Est-ce une nouvelle commande ou une ligne en attente ? Les règles existent dans l'ERP et doivent être connues du WMS.
Le moment de la coupure. Une commande qui descend après l'heure de coupure part le lendemain. Si l'ERP et le WMS n'ont pas la même heure de coupure, la promesse faite au client ne correspond pas au flux.
Les six questions à poser avant de signer
- Quelles versions de notre ERP votre connecteur couvre-t-il, précisément, et depuis quand ?
- Quels messages sont standards et lesquels seront un développement de projet ?
- Lesquels partent à l'événement, lesquels à l'heure, et à quelle heure ?
- Que fait un message en échec, qui est averti, et comment on le rejoue ?
- Quel système détient quel champ, par écrit, champ par champ ?
- Que coûte la deuxième année : un nouveau message, un changement de version chez l'éditeur de l'ERP, un transporteur de plus ?
Ces six questions appartiennent au cahier des charges WMS, et les réponses se demandent écrites. Si votre chaîne passe par l'échange de documents normalisés avec vos clients, les messages EDI forment un module à part, avec ses propres questions.
Comment nous le traitons
La plateforme se configure au lieu de se développer, et les connecteurs vers les ERP de la liste — Business Central, Exact Online, Exact Globe, SAP Business One, AFAS, Uniconta, Cegid et les autres — sont construits et maintenus avec l'éditeur concerné.
Nous ne publions pas de durée type pour cette partie, parce que la propreté des données d'articles n'est pas la même d'un client à l'autre et que c'est elle qui fixe le calendrier. Ce qui se dit honnêtement : le nettoyage commence avant le projet. Le déroulé complet est sur la page du projet WMS.
Ce qu'il faut retenir sur l'intégration WMS ERP
Deux systèmes, un seul propriétaire par champ. La donnée descend, les confirmations remontent, et chaque message a un rythme et un comportement d'échec décidés à l'avance.
Et la question à poser à tout éditeur n'est pas « intégrez-vous mon ERP », à laquelle tout le monde répond oui. C'est « quelle version, quels messages, et que se passe-t-il quand l'un échoue ».
