Magento 2, MSI i inventory_reservation po integracji z ERP

Magento 2 z MSI potrafi bardzo dobrze obsługiwać wieloźródłowy magazyn, rezerwacje i salable quantity. Problem zaczyna się wtedy, gdy ten mechanizm trafia do wdrożenia, w którym realnym źródłem prawdy o stanach nie jest Magento, ale ERP albo zewnętrzny WMS. W takim modelu logika rezerwacji często nadal działa, ale biznesowo przestaje być potrzebna. Zamiast pomagać, zaczyna zaburzać obraz dostępności.

To jeden z tych problemów, które przez długi czas wyglądają niepozornie. Sklep działa, zamówienia wpadają, importy stanów przebiegają poprawnie, a mimo to z czasem pojawiają się pytania:

• dlaczego salable quantity nie zgadza się ze stanem z ERP
• dlaczego produkt jest niedostępny, skoro ERP pokazuje dostępność
• dlaczego w inventory_reservation są setki tysięcy albo miliony wpisów
• dlaczego diagnoza problemów stockowych w Magento staje się coraz trudniejsza

W praktyce to bardzo częsty scenariusz w sklepach, które są już dojrzałe integracyjnie i działają w modelu ERP-first.

Gdzie zaczyna się problem

W standardowym Magento 2 z MSI wpisy do inventory_reservation pojawiają się przy składaniu zamówień, a później są kompensowane przez kolejne operacje, takie jak wysyłka czy anulowanie. W teorii wszystko jest spójne. W praktyce, jeśli sklep regularnie nadpisuje stany z ERP, Magento nie jest jedynym źródłem prawdy i nie zarządza stanem magazynowym samodzielnie.

To oznacza, że dwie logiki zaczynają działać równolegle:

• ERP ustala faktyczny stan dostępności
• Magento nadal utrzymuje własną warstwę rezerwacji

Jeżeli taka architektura nie została świadomie uporządkowana, pojawiają się rozjazdy. Nie zawsze od razu, ale z czasem niemal zawsze.

Objawy, które widzimy w projektach

Najczęściej problem wychodzi na jaw w jednej z kilku postaci.

1. salable quantity jest niższe niż stan z ERP

To najczęstszy przypadek. Zespół po stronie sklepu widzi, że ERP pokazuje dostępność, a Magento nadal blokuje sprzedaż albo zaniża liczbę sztuk możliwych do kupienia.

2. Tabela inventory_reservation stale rośnie

W sklepach z większym wolumenem zamówień ta tabela potrafi rosnąć bardzo szybko. Sam wzrost nie jest jeszcze błędem, ale w modelu ERP-first bardzo często staje się po prostu zbędnym kosztem utrzymania i kolejnym miejscem, które zaciemnia realny obraz stanu magazynowego.

3. Trudniejsza diagnostyka problemów magazynowych

Gdy dostępność produktu zależy jednocześnie od importu ERP, indeksacji Magento i zapisanych rezerwacji MSI, diagnoza przestaje być prosta. Zespół musi analizować, czy problem jest po stronie importu, indeksu, stocka, source assignment czy właśnie tabeli inventory_reservation.

4. Konflikty między importem a bieżącą logiką Magento

W niektórych wdrożeniach Magento zachowuje się poprawnie z punktu widzenia własnych reguł, ale niezgodnie z oczekiwaniami biznesu. To ważne rozróżnienie. System nie musi być zepsuty technicznie, żeby działał nieprawidłowo w danym modelu operacyjnym.

Dlaczego standardowe podejście nie zawsze wystarcza

W teorii można powiedzieć: skoro Magento ma MSI, to wystarczy pozwolić mu działać. Problem w tym, że MSI nie zostało zaprojektowane specjalnie pod każdy model integracji ERP. W części wdrożeń jest to architektura idealna. W innych wymaga świadomego uproszczenia.

Nie chodzi o to, żeby walczyć z Magento. Chodzi o to, żeby usunąć z procesu te elementy, które w danym wdrożeniu nie niosą już wartości, a zaczynają szkodzić.

W środowisku ERP-first zwykle ważniejsze są:

• zgodność ze stanem z ERP
• przewidywalność działania
• szybka automatyzacja
• mała liczba miejsc, w których mogą powstawać rozjazdy

Jeżeli rezerwacje MSI nie są realnie wykorzystywane jako mechanizm ochrony stanów, ich regularne czyszczenie bywa po prostu najbardziej praktycznym rozwiązaniem.

Jak podchodzimy do rozwiązania

W takich projektach nie próbujemy "naprawiać MSI" ani odtwarzać historii rezerwacji. To zwykle prowadzi do nadmiarowej złożoności. Zamiast tego wychodzimy od pytania, jaki model działania ma sklep.

Jeżeli sklep działa w modelu:

• ERP jako źródło prawdy
• cykliczny import stanów do Magento
• akceptacja krótkiego opóźnienia między ERP a sklepem
• brak potrzeby utrzymywania trwałych rezerwacji po stronie Magento

to najrozsądniejszym kierunkiem jest kontrolowane, szybkie i bezpieczne czyszczenie inventory_reservation.

Co jest ważne w takim rozwiązaniu

Samo "usunięcie rekordów" to za mało. Takie rozwiązanie musi być przewidywalne operacyjnie.

Dlatego zwracamy uwagę na kilka elementów:

• możliwość uruchamiania automatycznie z CRON
• możliwość ręcznego uruchamiania z CLI
• blokada przed równoległym wykonaniem
• tryb diagnostyczny bez usuwania danych
• opcjonalna reindeksacja po procesie
• możliwość uruchamiania tylko w określonych środowiskach
• sensowny model wydajnościowy dla dużych tabel

Właśnie z tego podejścia powstał nasz moduł.

Kowal Reservation Cleaner dla Magento 2

Dla projektów, w których problem z MSI reservations wracał regularnie, przygotowaliśmy własny moduł: Kowal Reservation Cleaner dla Magento 2.

To narzędzie stworzyliśmy z myślą o wdrożeniach ERP-first, gdzie inventory_reservation ma być utrzymywane w stanie czystym albo przynajmniej pod pełną kontrolą.

Moduł nie usuwa MSI z Magento i nie modyfikuje core. Jego zadaniem jest uporządkowanie warstwy rezerwacji w taki sposób, aby sklep zachował:

• zgodność z przyjętym modelem synchronizacji stanów
• przewidywalne działanie po imporcie ERP
• prostszą diagnostykę dostępności
• mniejsze ryzyko zaniżonego salable quantity

Jak działa nasz moduł

Moduł wspiera trzy podstawowe tryby pracy.

full_reset

To tryb najprostszy i zwykle najbardziej praktyczny. Jeśli czyszczenie ma objąć wszystkie stocki, moduł wykorzystuje bardzo szybkie:

TRUNCATE TABLE inventory_reservation

To ważne, bo przy dużych sklepach i dużych tabelach zwykły masowy DELETE potrafi być niepotrzebnie ciężki.

log_only

Ten tryb służy do diagnostyki. Nie usuwa danych, ale pozwala obserwować, jak szybko rośnie tabela rezerwacji i czy wdrożenie rzeczywiście wymaga automatycznego czyszczenia.

clean_after_erp_sync

To wariant dla zespołów, które chcą jasno powiązać moment czyszczenia z harmonogramem importu ERP. Przykładowo: ERP synchronizuje stany o 02:00, a moduł czyści rezerwacje o 02:10.

Czyszczenie tylko dla wybranych stocków

To jedna z funkcji, które szczególnie dobrze sprawdzają się w bardziej złożonych wdrożeniach multi-stock.

Nie każdy sklep chce czyścić całą tabelę inventory_reservation. Czasem problem dotyczy tylko wybranych stocków, konkretnych kanałów albo wydzielonego modelu logistycznego. W takich sytuacjach moduł pozwala ograniczyć czyszczenie tylko do wskazanych stock_id.

To oznacza, że:

• dla wszystkich stocków można użyć bardzo szybkiego TRUNCATE
• dla wybranych stocków moduł przechodzi na selektywne DELETE

To kompromis między wydajnością i kontrolą. W wielu wdrożeniach właśnie taki kompromis jest potrzebny.

CRON, CLI i bezpieczeństwo procesu

Moduł można uruchamiać automatycznie z Magento CRON lub ręcznie przez CLI. To ważne, bo różne sklepy mają różne modele integracyjne.

W praktyce spotykamy dwa najczęstsze scenariusze:

• czyszczenie uruchamiane o konkretnej godzinie z harmonogramu Magento
• czyszczenie wywoływane bezpośrednio po imporcie ERP przez skrypt integracyjny

Moduł został wyposażony w:

• mechanizm locka
• logowanie do pliku
• kontrolę czasu wykonania
• możliwość dry-run
• opcjonalną reindeksację
• opcjonalny cache clean

To są drobiazgi, które na etapie opisu produktu wyglądają technicznie, ale na produkcji decydują o tym, czy rozwiązanie da się utrzymać bez nerwów.

Co daje to biznesowo

Z perspektywy operacyjnej najważniejsze korzyści są dość konkretne:

• mniejsza liczba problemów z dostępnością produktów
• lepsza zgodność między Magento i ERP
• mniej czasu traconego na diagnozę stanów
• prostszy model utrzymania MSI w sklepie
• możliwość zautomatyzowania procesu bez modyfikacji core

To nie jest moduł "dla każdego sklepu Magento". I właśnie to jest jego zaletą. Został zaprojektowany dla konkretnego typu wdrożeń, które naprawdę zmagają się z tym problemem.

Kiedy warto rozważyć takie rozwiązanie

Jeżeli w Twoim sklepie:

• stany są regularnie nadpisywane z ERP
• Magento nie powinno być główną warstwą zarządzania zapasem
• inventory_reservation rośnie i utrudnia analizę
• salable quantity rozjeżdża się z realnym stanem
• zespół potrzebuje prostszego modelu działania

to regularne czyszczenie rezerwacji może być rozsądnym kierunkiem.

Oczywiście nie zawsze. W sklepach, które polegają na natywnej logice MSI jako kluczowym mechanizmie kontroli stanów, takie podejście nie będzie właściwe. Dlatego najpierw trzeba zrozumieć model biznesowy, a dopiero potem dobierać rozwiązanie.

Podsumowanie

Problem z inventory_reservation w Magento 2 nie wynika zwykle z tego, że MSI jest "złe". Wynika z tego, że mechanizm zaprojektowany do jednego modelu działania bywa używany w innym modelu, najczęściej mocno zintegrowanym z ERP.

W takich wdrożeniach najważniejsza nie jest maksymalna złożoność, ale przewidywalność i spójność z realnym procesem magazynowym. Dlatego w części sklepów najlepszym rozwiązaniem okazuje się nie rozbudowa logiki MSI, ale jej świadome uproszczenie.

Jeżeli szukasz gotowego rozwiązania dla tego scenariusza, zobacz nasz moduł: Kowal Reservation Cleaner dla Magento 2.

Jeśli natomiast najpierw chcesz ocenić, czy Twój sklep rzeczywiście ma ten problem, warto zacząć od analizy modelu synchronizacji stanów, sposobu wykorzystania MSI i zachowania salable quantity po imporcie ERP.

Źródła

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