Magento 2, MSI et inventory_reservation après intégration ERP

Magento 2 avec MSI sait très bien gérer le stock multi-source, les réservations et la salable quantity. Le problème apparaît lorsque ce mécanisme se retrouve dans un déploiement où la véritable source de vérité sur les stocks n’est pas Magento, mais un ERP ou un WMS externe. Dans ce modèle, la logique de réservation continue souvent à fonctionner techniquement, mais elle n’a plus de vraie utilité métier. Au lieu d’aider, elle commence à brouiller la vision de la disponibilité.

C’est l’un de ces problèmes qui semblent mineurs pendant longtemps. La boutique fonctionne, les commandes arrivent, les imports de stock se déroulent correctement, et pourtant, avec le temps, des questions apparaissent :

• pourquoi la salable quantity ne correspond pas au stock de l’ERP
• pourquoi un produit est indisponible alors que l’ERP le montre disponible
• pourquoi il y a des centaines de milliers ou des millions de lignes dans inventory_reservation
• pourquoi le diagnostic des problèmes de stock dans Magento devient de plus en plus difficile

En pratique, c’est un scénario très courant dans les boutiques déjà matures sur le plan de l’intégration et opérant dans un modèle ERP-first.

Là où le problème commence

Dans Magento 2 standard avec MSI, des entrées dans inventory_reservation sont créées lors de la prise de commande, puis compensées par des opérations suivantes comme l’expédition ou l’annulation. En théorie, tout est cohérent. En pratique, si la boutique écrase régulièrement les stocks depuis l’ERP, Magento n’est plus la seule source de vérité et ne gère plus le stock de manière autonome.

Cela signifie que deux logiques commencent à fonctionner en parallèle :

• l’ERP définit la disponibilité réelle
• Magento maintient toujours sa propre couche de réservations

Si cette architecture n’a pas été volontairement simplifiée, des écarts apparaissent. Pas toujours immédiatement, mais avec le temps, presque systématiquement.

Les symptômes que nous voyons dans les projets

Le plus souvent, le problème se manifeste sous l’une de plusieurs formes.

1. La salable quantity est inférieure au stock de l’ERP

C’est le cas le plus fréquent. L’équipe de la boutique voit que l’ERP affiche de la disponibilité, alors que Magento bloque encore la vente ou réduit le nombre d’unités achetables.

2. La table inventory_reservation grandit en permanence

Dans les boutiques avec un volume de commandes plus élevé, cette table peut croître très rapidement. Sa croissance n’est pas en soi une erreur, mais dans un modèle ERP-first elle devient souvent simplement un coût de maintenance inutile et un point supplémentaire qui brouille la vision réelle du stock.

3. Diagnostic plus difficile des problèmes de stock

Quand la disponibilité d’un produit dépend en même temps de l’import ERP, de l’indexation Magento et des réservations MSI enregistrées, le diagnostic cesse d’être simple. L’équipe doit analyser si le problème vient de l’import, de l’index, du stock, du source assignment ou de la table inventory_reservation elle-même.

4. Conflits entre l’import et la logique actuelle de Magento

Dans certains déploiements, Magento se comporte correctement du point de vue de ses propres règles, mais pas selon les attentes métier. C’est une distinction importante. Un système n’a pas besoin d’être techniquement cassé pour se comporter de façon inadaptée dans un modèle opérationnel donné.

Pourquoi l’approche standard ne suffit pas toujours

En théorie, on pourrait dire : si Magento a MSI, il suffit de le laisser fonctionner. Le problème, c’est que MSI n’a pas été conçu spécifiquement pour chaque modèle d’intégration ERP. Dans certains projets, c’est l’architecture idéale. Dans d’autres, elle demande une simplification consciente.

Il ne s’agit pas de lutter contre Magento. Il s’agit de retirer du processus les éléments qui, dans un déploiement donné, n’apportent plus de valeur et commencent au contraire à poser problème.

Dans un environnement ERP-first, les priorités sont généralement :

• la cohérence avec le stock de l’ERP
• la prévisibilité du comportement
• une automatisation rapide
• peu d’endroits où des écarts peuvent apparaître

Si les réservations MSI ne sont pas réellement utilisées comme mécanisme de protection du stock, leur nettoyage régulier est souvent tout simplement la solution la plus pratique.

Notre approche de la solution

Dans ce type de projet, nous n’essayons pas de "réparer MSI" ni de reconstruire l’historique des réservations. Cela mène généralement à une complexité inutile. À la place, nous partons d’une question simple : quel est le modèle de fonctionnement réel de la boutique ?

Si la boutique fonctionne avec :

• un ERP comme source de vérité
• un import cyclique du stock dans Magento
• l’acceptation d’un léger décalage entre l’ERP et la boutique
• aucun besoin de maintenir des réservations persistantes côté Magento

alors la direction la plus raisonnable consiste à mettre en place un nettoyage contrôlé, rapide et sûr de inventory_reservation.

Ce qui est important dans ce type de solution

Le simple fait de "supprimer des enregistrements" ne suffit pas. Une telle solution doit rester prévisible sur le plan opérationnel.

C’est pourquoi nous prêtons attention à plusieurs éléments :

• possibilité d’exécution automatique via CRON
• possibilité d’exécution manuelle via CLI
• protection contre les exécutions parallèles
• mode diagnostic sans suppression de données
• réindexation optionnelle après le processus
• possibilité de n’exécuter le traitement que dans certains environnements
• modèle de performance cohérent pour les grandes tables

C’est précisément à partir de cette approche qu’est né notre module.

Kowal Reservation Cleaner pour Magento 2

Pour les projets où le problème des réservations MSI revenait régulièrement, nous avons créé notre propre module : Kowal Reservation Cleaner pour Magento 2.

Nous avons conçu cet outil pour les déploiements ERP-first, où inventory_reservation doit rester propre ou au moins totalement sous contrôle.

Le module ne supprime pas MSI de Magento et ne modifie pas le core. Son objectif est d’organiser la couche de réservations de manière à ce que la boutique conserve :

• la cohérence avec le modèle de synchronisation de stock adopté
• un comportement prévisible après l’import ERP
• un diagnostic plus simple de la disponibilité
• un risque réduit de salable quantity sous-évaluée

Comment fonctionne notre module

Le module prend en charge trois modes de fonctionnement principaux.

full_reset

C’est le mode le plus simple et généralement le plus pratique. Si le nettoyage doit couvrir tous les stocks, le module utilise le très rapide :

TRUNCATE TABLE inventory_reservation

C’est important, car dans les grandes boutiques avec de grosses tables, un DELETE massif classique peut être inutilement lourd.

log_only

Ce mode sert au diagnostic. Il ne supprime pas les données, mais permet d’observer la vitesse de croissance de la table de réservations et de vérifier si le déploiement nécessite réellement un nettoyage automatique.

clean_after_erp_sync

Cette variante est destinée aux équipes qui veulent lier clairement le moment du nettoyage au planning d’import ERP. Exemple : l’ERP synchronise le stock à 02:00, puis le module nettoie les réservations à 02:10.

Nettoyage uniquement pour certains stocks

C’est l’une des fonctionnalités qui fonctionne particulièrement bien dans les déploiements multi-stock plus complexes.

Toutes les boutiques ne veulent pas nettoyer toute la table inventory_reservation. Parfois, le problème ne concerne que certains stocks, certains canaux ou un modèle logistique distinct. Dans ces cas, le module permet de limiter le nettoyage aux seuls stock_id indiqués.

Cela signifie :

• pour tous les stocks, on peut utiliser le très rapide TRUNCATE
• pour certains stocks, le module passe à un DELETE sélectif

C’est un compromis entre performance et contrôle. Et dans de nombreux projets, c’est exactement ce compromis qui est nécessaire.

CRON, CLI et sécurité du processus

Le module peut être exécuté automatiquement via Magento CRON ou manuellement via CLI. C’est important, car différents magasins ont différents modèles d’intégration.

En pratique, nous rencontrons surtout deux scénarios :

• nettoyage lancé à une heure précise depuis le planning Magento
• nettoyage déclenché directement après l’import ERP par un script d’intégration

Le module comprend :

• un mécanisme de lock
• une journalisation dans un fichier
• un contrôle du temps d’exécution
• un mode dry-run
• une réindexation optionnelle
• un cache clean optionnel

Ce sont des détails qui paraissent techniques dans une description produit, mais qui, en production, déterminent si la solution peut être exploitée sans stress.

Ce que cela apporte côté métier

D’un point de vue opérationnel, les bénéfices les plus importants sont très concrets :

• moins de problèmes de disponibilité produit
• une meilleure cohérence entre Magento et l’ERP
• moins de temps perdu à diagnostiquer les stocks
• un modèle plus simple de maintenance de MSI dans la boutique
• possibilité d’automatiser le processus sans modifier le core

Ce n’est pas un module "pour toutes les boutiques Magento". Et c’est justement son avantage. Il a été conçu pour un type précis de déploiement qui rencontre réellement ce problème.

Quand envisager une telle solution

Si dans votre boutique :

• les stocks sont régulièrement écrasés depuis l’ERP
• Magento ne doit pas être la couche principale de gestion du stock
• inventory_reservation grossit et complique l’analyse
• la salable quantity s’écarte du stock réel
• l’équipe a besoin d’un modèle de fonctionnement plus simple

alors un nettoyage régulier des réservations peut être une direction raisonnable.

Bien sûr, pas toujours. Dans les boutiques qui s’appuient sur la logique native de MSI comme mécanisme principal de contrôle du stock, cette approche ne sera pas la bonne. Il faut donc d’abord comprendre le modèle métier, puis seulement choisir la solution.

Résumé

Le problème de inventory_reservation dans Magento 2 ne vient généralement pas du fait que MSI serait "mauvais". Il vient du fait qu’un mécanisme conçu pour un modèle de fonctionnement est utilisé dans un autre, le plus souvent fortement intégré à un ERP.

Dans ce type de déploiement, la priorité n’est pas la complexité maximale, mais la prévisibilité et la cohérence avec le vrai processus de stock. C’est pourquoi, dans certaines boutiques, la meilleure solution n’est pas d’étendre la logique MSI, mais de la simplifier de manière consciente.

Si vous cherchez une solution prête à l’emploi pour ce scénario, découvrez notre module : Kowal Reservation Cleaner pour Magento 2.

Si vous souhaitez d’abord évaluer si votre boutique rencontre réellement ce problème, il vaut mieux commencer par analyser le modèle de synchronisation de stock, la manière dont MSI est utilisé et le comportement de la salable quantity après l’import ERP.

Sources

• Page produit Kowal Reservation Cleaner dla Magento 2 : https://kowal.store/kowal-reservation-cleaner-dla-magento-2