Magento 2, MSI en inventory_reservation na ERP-integratie

Magento 2 met MSI kan multi-source voorraad, reserveringen en salable quantity heel goed beheren. Het probleem begint wanneer dit mechanisme terechtkomt in een implementatie waar de echte bron van waarheid over voorraad niet Magento is, maar een ERP of een extern WMS. In dat model werkt de reserveringslogica technisch vaak nog wel, maar zakelijk gezien is die niet meer nodig. In plaats van te helpen, begint die het beeld van beschikbaarheid te verstoren.

Dit is een van die problemen die lang onschuldig lijken. De webshop werkt, orders komen binnen, voorraadimports verlopen correct, en toch ontstaan er na verloop van tijd vragen:

• waarom salable quantity niet overeenkomt met de voorraad uit ERP
• waarom een product niet beschikbaar is terwijl ERP wel beschikbaarheid toont
• waarom er honderdduizenden of miljoenen records in inventory_reservation staan
• waarom het diagnosticeren van voorraadproblemen in Magento steeds moeilijker wordt

In de praktijk is dit een heel gebruikelijk scenario in shops die op integratievlak al volwassen zijn en volgens een ERP-first model werken.

Waar het probleem begint

In standaard Magento 2 met MSI worden records in inventory_reservation aangemaakt wanneer bestellingen worden geplaatst en later gecompenseerd door volgende handelingen zoals verzending of annulering. In theorie is alles consistent. In de praktijk, als de shop voorraad regelmatig overschrijft vanuit ERP, is Magento niet meer de enige bron van waarheid en beheert het voorraad niet meer zelfstandig.

Dat betekent dat twee logica’s parallel gaan werken:

• ERP bepaalt de werkelijke beschikbaarheid
• Magento onderhoudt nog steeds zijn eigen reserveringslaag

Als die architectuur niet bewust is opgeruimd, ontstaan er afwijkingen. Niet altijd meteen, maar na verloop van tijd bijna altijd.

Symptomen die we in projecten zien

Meestal komt het probleem naar voren in een van enkele vormen.

1. salable quantity is lager dan de voorraad uit ERP

Dit is het meest voorkomende geval. Het team van de webshop ziet dat ERP beschikbaarheid toont, terwijl Magento de verkoop toch blokkeert of het aantal koopbare stuks verlaagt.

2. De tabel inventory_reservation blijft groeien

In shops met een hoger ordervolume kan deze tabel heel snel groeien. Groei op zich is nog geen bug, maar in een ERP-first model wordt het vaak gewoon een onnodige onderhoudslast en nog een plek die het echte voorraadbeeld vertroebelt.

3. Moeilijkere diagnose van voorraadproblemen

Wanneer productbeschikbaarheid tegelijk afhangt van ERP-import, Magento-indexering en opgeslagen MSI-reserveringen, is diagnose niet meer eenvoudig. Het team moet analyseren of het probleem zit in de import, de index, de stock, de source assignment of juist in de tabel inventory_reservation.

4. Conflicten tussen import en de huidige Magento-logica

In sommige implementaties gedraagt Magento zich correct volgens zijn eigen regels, maar niet volgens de verwachtingen van het bedrijf. Dat is een belangrijk onderscheid. Een systeem hoeft technisch niet stuk te zijn om in een bepaald operationeel model toch verkeerd te werken.

Waarom de standaardaanpak niet altijd voldoende is

In theorie zou je kunnen zeggen: als Magento MSI heeft, laat het dan gewoon zijn werk doen. Het probleem is dat MSI niet speciaal ontworpen is voor elk ERP-integratiemodel. In sommige implementaties is het de ideale architectuur. In andere gevallen is bewuste vereenvoudiging nodig.

Het gaat er niet om tegen Magento te vechten. Het gaat erom die onderdelen uit het proces te verwijderen die in een bepaalde implementatie geen waarde meer toevoegen en juist problemen beginnen te veroorzaken.

In een ERP-first omgeving zijn meestal belangrijker:

• consistentie met voorraad uit ERP
• voorspelbaar gedrag
• snelle automatisering
• zo weinig mogelijk plekken waar afwijkingen kunnen ontstaan

Als MSI-reserveringen niet echt gebruikt worden als beschermingsmechanisme voor voorraad, dan is regelmatig opschonen vaak gewoon de meest praktische oplossing.

Hoe wij de oplossing benaderen

In dit soort projecten proberen wij niet "MSI te repareren" of reserveringshistorie opnieuw op te bouwen. Dat leidt meestal tot onnodige complexiteit. In plaats daarvan beginnen we met de vraag welk operationeel model de shop werkelijk heeft.

Als de shop werkt met:

• ERP als bron van waarheid
• cyclische import van voorraad naar Magento
• acceptatie van een korte vertraging tussen ERP en de shop
• geen noodzaak om blijvende reserveringen in Magento te onderhouden

dan is een gecontroleerde, snelle en veilige opschoning van inventory_reservation de meest logische richting.

Wat belangrijk is in zo’n oplossing

Alleen maar "records verwijderen" is niet genoeg. Zo’n oplossing moet operationeel voorspelbaar zijn.

Daarom letten we op een aantal elementen:

• mogelijkheid om automatisch via CRON te draaien
• mogelijkheid om handmatig via CLI te starten
• beveiliging tegen parallelle uitvoering
• diagnostische modus zonder gegevens te verwijderen
• optionele herindexering na het proces
• mogelijkheid om alleen in specifieke omgevingen te draaien
• een verstandig performancemodel voor grote tabellen

Vanuit precies die aanpak is onze module ontstaan.

Kowal Reservation Cleaner voor Magento 2

Voor projecten waarin het probleem met MSI-reservaties regelmatig terugkwam, hebben we onze eigen module ontwikkeld: Kowal Reservation Cleaner voor Magento 2.

Deze tool is gemaakt voor ERP-first implementaties waarin inventory_reservation schoon moet blijven, of in elk geval volledig onder controle moet staan.

De module verwijdert MSI niet uit Magento en wijzigt de core niet. Het doel is om de reserveringslaag op te ruimen zodat de webshop het volgende behoudt:

• consistentie met het gekozen synchronisatiemodel voor voorraad
• voorspelbaar gedrag na ERP-import
• eenvoudiger diagnose van beschikbaarheid
• minder risico op te lage salable quantity

Hoe onze module werkt

De module ondersteunt drie basisstanden.

full_reset

Dit is de eenvoudigste modus en meestal ook de meest praktische. Als de opschoning alle stocks moet omvatten, gebruikt de module het zeer snelle:

TRUNCATE TABLE inventory_reservation

Dat is belangrijk, want in grote shops en met grote tabellen kan een gewone massale DELETE onnodig zwaar zijn.

log_only

Deze modus is bedoeld voor diagnose. Hij verwijdert geen data, maar laat wel zien hoe snel de reserveringstabel groeit en of de implementatie echt geautomatiseerde opschoning nodig heeft.

clean_after_erp_sync

Dit is de variant voor teams die het opschoonmoment duidelijk willen koppelen aan het ERP-importschema. Bijvoorbeeld: ERP synchroniseert voorraad om 02:00 en de module ruimt reserveringen op om 02:10.

Alleen geselecteerde stocks opschonen

Dit is een van de functies die bijzonder goed werkt in complexere multi-stock implementaties.

Niet elke shop wil de volledige tabel inventory_reservation opschonen. Soms betreft het probleem alleen bepaalde stocks, specifieke kanalen of een apart logistiek model. In zulke gevallen kan de module de opschoning beperken tot opgegeven stock_id waarden.

Dat betekent:

• voor alle stocks kun je de zeer snelle TRUNCATE gebruiken
• voor geselecteerde stocks schakelt de module over op selectieve DELETE

Dit is een compromis tussen performance en controle. In veel implementaties is juist dat compromis nodig.

CRON, CLI en procesveiligheid

De module kan automatisch via Magento CRON of handmatig via CLI worden gestart. Dat is belangrijk omdat verschillende shops verschillende integratiemodellen hebben.

In de praktijk zien we meestal twee scenario’s:

• opschoning wordt op een vast tijdstip gestart vanuit de Magento-planning
• opschoning wordt direct na ERP-import gestart door een integratiescript

De module bevat:

• een lock-mechanisme
• logging naar bestand
• controle van uitvoeringstijd
• dry-run
• optionele herindexering
• optionele cache clean

Dat lijken technische details in een productbeschrijving, maar in productie bepalen ze of een oplossing zonder stress te onderhouden is.

Wat dit zakelijk oplevert

Vanuit operationeel perspectief zijn de belangrijkste voordelen heel concreet:

• minder problemen met productbeschikbaarheid
• betere consistentie tussen Magento en ERP
• minder tijdverlies aan voorraaddiagnose
• een eenvoudiger onderhoudsmodel voor MSI in de shop
• mogelijkheid om het proces te automatiseren zonder core-aanpassingen

Dit is geen module "voor elke Magento-shop". En juist dat is het voordeel. De module is ontworpen voor een specifiek type implementatie dat dit probleem echt heeft.

Wanneer het zinvol is om dit te overwegen

Als in jouw shop:

• voorraad regelmatig wordt overschreven vanuit ERP
• Magento niet de primaire laag voor voorraadbeheer moet zijn
• inventory_reservation blijft groeien en analyse moeilijker maakt
• salable quantity afwijkt van de echte voorraad
• het team een eenvoudiger operationeel model nodig heeft

dan kan het regelmatig opschonen van reserveringen een verstandige richting zijn.

Natuurlijk niet altijd. In shops die vertrouwen op native MSI-logica als kernmechanisme voor voorraadcontrole, is deze aanpak niet geschikt. Daarom moet je eerst het businessmodel begrijpen en pas daarna de oplossing kiezen.

Samenvatting

Het probleem met inventory_reservation in Magento 2 komt meestal niet doordat MSI "slecht" is. Het komt doordat een mechanisme dat voor één operationeel model is ontworpen, wordt gebruikt in een ander model, meestal sterk geïntegreerd met ERP.

In zulke implementaties draait het niet om maximale complexiteit, maar om voorspelbaarheid en consistentie met het echte magazijnproces. Daarom blijkt in sommige shops niet uitbreiding van MSI-logica de beste oplossing, maar juist bewuste vereenvoudiging ervan.

Als je een kant-en-klare oplossing zoekt voor dit scenario, bekijk dan onze module: Kowal Reservation Cleaner voor Magento 2.

Als je eerst wilt beoordelen of jouw shop dit probleem echt heeft, is het verstandig te beginnen met een analyse van het voorraadsynchronisatiemodel, de manier waarop MSI wordt gebruikt en het gedrag van salable quantity na ERP-import.

Bronnen

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