Dlaczego sklep internetowy i ERP pokazują inne stany magazynowe?

Źródła sprawdzone 9 listopada 2026.

Ten poradnik jest dla osoby odpowiedzialnej za e-commerce albo operacje u dystrybutora lub producenta, która widzi, że sklep pokazuje inną dostępność niż ERP. Celem jest znalezienie przyczyny dla konkretnej pozycji, a nie wybór nowego systemu.

Rozbieżność może wynikać między innymi z jednej z czterech rzeczy: systemy liczą inną wielkość, dane trafiają do niewłaściwego magazynu, wariantu lub jednostki, aktualizacja dociera z opóźnieniem albo wcale, albo wyjątek (anulowanie, zwrot, ręczna korekta) nie zmienia rezerwacji tak, jak zakłada zespół. Każdą z tych przyczyn da się sprawdzić na jednym SKU, zanim zacznie się większy projekt.

Dwie osoby mogą widzieć różne liczby bez żadnego błędu danych, jeśli jedna patrzy na zapas fizyczny, a druga na towar dostępny do nowej sprzedaży. Zanim zaczniesz szukać błędu w integracji, zapisz, którą wielkość pokazuje każdy ekran.

Przykładowo Shopify rozróżnia ilość na stanie, dostępną, przypisaną do zamówień, niedostępną i przychodzącą, a ilość na stanie to suma przypisanej, niedostępnej i dostępnej. Opis: Shopify: stany magazynowe. To ilustracja jednej platformy, a nie definicja obowiązująca w każdym ERP.

Uzgodnij też magazyn lub lokalizację, jednostkę miary (sztuka, opakowanie, paleta) i wariant produktu. Ta sama liczba w innej jednostce albo dla innego wariantu wygląda jak rozbieżność, choć dane są poprawne.

Wybierz jedną pozycję, przy której rozbieżność jest widoczna teraz, i jedno niedawne zamówienie z tą pozycją. Mały, konkretny przypadek szybciej pokaże przyczynę niż przegląd całego katalogu.

1. Zapisz obie liczby z czasem odczytu: wartość w sklepie, wartość w ERP i dokładną godzinę każdego odczytu.
2. Nazwij wielkość: przy każdej liczbie zapisz, czy to stan fizyczny, dostępny czy przypisany.
3. Sprawdź źródło wartości w sklepie: z którego systemu i z której lokalizacji sklep pobiera stan tego SKU.
4. Znajdź ostatnią udaną aktualizację: kiedy sklep ostatnio otrzymał nową wartość i czy ta wymiana zakończyła się sukcesem.
5. Prześledź jedno zamówienie: kiedy zostało zapisane, kiedy powstała rezerwacja i w którym systemie, kiedy sklep dostał zmienioną dostępność.
6. Sprawdź wyjątki dla tego SKU: anulowania, zwroty, korekty ręczne i błędy integracji z ostatnich dni.
7. Zapisz hipotezę i dowód: którą przyczynę podejrzewasz, co ją potwierdza i co jeszcze pozostaje nieustalone.

To przykład hipotetyczny, a nie opis projektu klienta. W magazynie została jedna sztuka. Pierwszy klient ją zamawia, a drugi wciąż widzi produkt jako dostępny i też składa zamówienie.

Różnica czasów w tabeli jest wskazówką do sprawdzenia, a nie dowodem przyczyny. Może oznaczać harmonogram wymiany, kolejkę komunikatów, nieudaną próbę albo regułę, według której rezerwacja powstaje dopiero po płatności. Właściwy wniosek zależy od faktycznych systemów i umówionego procesu.

Poniższa lista pomaga ułożyć hipotezy. Nie każda pozycja dotyczy każdego połączenia sklepu z ERP, a kilka przyczyn może występować jednocześnie.

• Różne definicje: sklep pokazuje dostępne, a ERP fizyczne, albo jedna strona odejmuje bufor bezpieczeństwa, a druga nie.
• Mapowanie: SKU, wariant, magazyn lub jednostka wskazują inny rekord niż zakłada zespół.
• Czas i kolejność: aktualizacje przychodzą zbiorczo co pewien czas albo w innej kolejności niż zdarzenia.
• Nieobsłużone błędy: wymiana się nie udała, nikt nie dostał informacji, a sklep pokazuje ostatnią znaną wartość.
• Rezerwacje: anulowanie, zwrot albo nieopłacone zamówienie nie zwalnia lub nie tworzy rezerwacji tak, jak zakłada proces.
• Korekty ręczne: inwentaryzacja lub poprawka w jednym systemie nie trafia do drugiego.
• Kilka kanałów: marketplace, sprzedaż hurtowa i sklep korzystają z tej samej puli towaru bez wspólnej reguły.

Rozbieżność może ujawnić się dopiero przy wyjątku, a nie przy zwykłym zamówieniu. Co dzieje się po anulowaniu, zwrocie, błędzie integracji albo ręcznej korekcie? Kto dostaje informację, że dane nie dotarły, i jak bezpiecznie je uzgadnia?

Warto zapisać to wprost, zanim zmieni się cokolwiek w systemach. Szczegóły zależą od faktycznych narzędzi i umówionego procesu, dlatego lista poniżej to pytania, a nie gotowe odpowiedzi.

• Który system jest źródłem prawdy dla stanu tego SKU i w której lokalizacji.
• Kto jest właścicielem reguły rezerwacji i jej zmian.
• Jak zespół sprawdza czas i wynik ostatniej udanej aktualizacji.
• Kto dostaje informację o nieudanej wymianie i w jakim czasie reaguje.
• Jak wygląda bezpieczne uzgodnienie stanu po awarii, bez podwójnego odjęcia towaru.

Zakres zmiany powinien wynikać z diagnozy. Istniejąca platforma SaaS nie musi być wymieniana tylko dlatego, że wystąpiła rozbieżność, a szersza modernizacja ma sens dopiero wtedy, gdy mniejsze zmiany nie usuwają przyczyny.

Te materiały skracają rozmowę i pozwalają ocenić zakres bez zgadywania. Nie musisz mieć wszystkich; brak informacji też jest użytecznym wynikiem.

Jeśli przy okazji rozważasz nowy kanał zamówień dla klientów firmowych, zobacz poradnik portal czy aplikacja do zamówień B2B.

1. Nazwy i wersje sklepu oraz ERP, a także narzędzi pośredniczących, jeśli występują.
2. Jedno SKU z rozbieżnością, obie liczby i czasy odczytu.
3. Przebieg jednego zamówienia z godzinami zapisu, rezerwacji i aktualizacji sklepu.
4. Opis reguły rezerwacji, anulowań i zwrotów, tak jak działa dziś.
5. Informację, kto i jak dowiaduje się o nieudanej wymianie danych.