Stany dostępne vs stany fizyczne: jak je liczyć w integracji z ERP

Po co w ogóle rozróżniać stan fizyczny i stan dostępny?

Magazynier widzi palety, klient widzi „dostępne sztuki”

Dla magazynu kluczowe jest to, co faktycznie stoi na półkach: kartony, palety, pojedyncze sztuki. To jest stan fizyczny magazynowy – da się go policzyć ręcznie, zeskanować kolektorem, zobaczyć gołym okiem. Tymczasem klient w sklepie internetowym nie interesuje się tym, ile masz palet, tylko czy może kupić produkt teraz i kiedy go dostanie.

W integracji ERP–e‑commerce te dwie perspektywy muszą zostać przełożone na język systemów. ERP trzyma informacje o stanach w wielu miejscach: na dokumentach przyjęć, wydań, zamówieniach, rezerwacjach, zleceniach produkcyjnych. Sklep widzi najczęściej tylko jedną liczbę – stan dostępny ERP przeliczony na potrzeby sprzedaży. Reszta to logika, którą trzeba ustawić pomiędzy tymi światami.

Jeżeli sprzedawca utożsamia „stan w magazynie” z „stanem, który może pokazać klientowi”, szybko wpada w problemy. Część towaru jest już zarezerwowana pod zamówienia B2B, część pod produkcję, część leży uszkodzona na reklamacjach. Z punktu widzenia magazynu – to wszystko są sztuki fizycznie na półkach. Z punktu widzenia sklepu – tylko część z nich naprawdę można bezpiecznie sprzedać.

Konsekwencje mylenia pojęć stanów w integracji ERP

Jeśli integracja wysyła do sklepu internetowego „goły” stan fizyczny z ERP, bez uwzględnienia rezerwacji i blokad, pojawia się klasyczny scenariusz: sprzedajesz powietrze. Klient kupuje, bo widzi „12 sztuk dostępnych”, a tak naprawdę produkt jest już przeznaczony pod duże zamówienie hurtowe albo czeka w strefie jakościowej. Efekt: telefony do biura obsługi, tłumaczenie się z opóźnień, korekty zamówień, zaniżone oceny na marketplace’ach.

Z drugiej strony, zbyt zachowawcze ustawienie stanów dostępnych także potrafi zaboleć. Jeżeli do stanu dostępnego nie doliczasz żadnych potwierdzonych dostaw ani produkcji w toku, a na dodatek odejmujesz każdy najmniejszy rodzaj rezerwacji, to blokujesz sprzedaż. Towar jest w drodze, przyjedzie jutro, ale sklep pokazuje „0” – klient kupuje u konkurencji.

Różnica między stanem fizycznym a stanem dostępnym to nic innego jak decyzja, jakie ryzyko jesteś gotów przyjąć. Zbyt optymistyczne liczenie kończy się overbookingiem magazynowym. Zbyt zachowawcze – marnowaniem potencjału sprzedaży.

ERP jako „źródło prawdy”, sklep jako „twarz” tych danych

W dobrze ustawionej architekturze systemów ERP jest systemem wiodącym dla stanów magazynowych. To tam powstają i są rozliczane dokumenty przyjęcia (PZ), wydania (WZ), zamówienia sprzedaży, zlecenia produkcyjne, przesunięcia między magazynami. Sklep internetowy, marketplace czy system B2B nie powinny liczyć stanów na własną rękę, tylko korzystać z danych dostarczonych z ERP lub z warstwy pośredniej (OMS, integrator).

Rola e‑commerce polega raczej na tym, by dane z ERP odpowiednio pokazać: w formie liczby sztuk, komunikatu „na zamówienie”, „wysyłka w 48h”, „przedsprzedaż” albo „ostatnie sztuki”. Logika „co jest dostępne” powinna więc w pierwszej kolejności powstać w ERP lub w dedykowanej warstwie integracyjnej, a nie w kodzie sklepu.

Im więcej kanałów sprzedaży dochodzi (kolejne sklepy, marketplace’y, sprzedaż telefoniczna, B2B), tym bardziej widać, jak kluczowe jest to rozróżnienie. Jedna zła decyzja – i nagle te same sztuki towaru sprzedawane są równocześnie przez trzy różne kanały.

Skalowanie sprzedaży potęguje problem stanów dostępnych

Na początku, przy kilku zamówieniach dziennie, wiele firm „ratuje się” ręczną kontrolą. Ktoś co jakiś czas zerka do ERP, koryguje stany w sklepie, dogaduje się z magazynem. Przy większym wolumenie i wielokanałowości to po prostu przestaje działać.

Gdy:

• masz kilkaset zamówień dziennie,
• sprzedajesz jednocześnie w sklepie, na Allegro, Amazonie i w kanale B2B,
• korzystasz z kilku magazynów własnych i zewnętrznych,

różnica między stanem fizycznym a stanem dostępnym staje się jednym z głównych elementów, które trzeba precyzyjnie zdefiniować i zautomatyzować. Bez tego nawet najlepsza integracja ERP z e‑commerce będzie jedynie przesyłała błędne liczby szybciej i w większej skali.

Kluczowe definicje: jakie stany w ogóle występują w ERP i e‑commerce

Przed ustawieniem jakichkolwiek algorytmów integracji warto jednoznacznie nazwać pojęcia. W praktyce wiele sporów między działem IT, logistyki i e‑commerce wynika z tego, że każdy używa tych samych słów, ale rozumie je inaczej.

Stan fizyczny a stan ewidencyjny w ERP

Stan fizyczny to ilość produktu, którą można fizycznie znaleźć w magazynie. To realne sztuki, które da się policzyć podczas inwentaryzacji. W idealnym świecie stan fizyczny równy jest temu, co widzi ERP, jednak w praktyce pojawiają się rozjazdy: błędne przyjęcia, pomyłki w wydaniach, niezaksięgowane dokumenty.

Stan ewidencyjny (czasem nazywany księgowym lub systemowym) to ilość w systemie ERP, wynikająca z wszystkich zaksięgowanych i będących w trakcie księgowania dokumentów. Może się zdarzyć, że:

• ERP pokazuje 100 sztuk, ale fizycznie jest 95 – bo 5 sztuk się zgubiło albo nie zostało poprawnie przyjęte,
• ERP pokazuje 90 sztuk, a fizycznie jest 100 – bo PZ zostało zrealizowane fizycznie, ale jeszcze nie zaksięgowane.

Integracja e‑commerce niemal zawsze opiera się na stanie ewidencyjnym, bo tylko ten jest dostępny przez API.

Stan dostępny / wolny dla sprzedaży

Stan dostępny (czasem nazywany też stanem wolnym) to ilość, którą możesz bezpiecznie pokazać w sklepie jako „do kupienia”. To nie jest już czysty stan fizyczny z ERP. Najczęściej to:

stan dostępny = stan fizyczny (ewidencyjny) – rezerwacje – blokady + wybrane dostawy w drodze

W zależności od systemu i ustaleń firmy, do stanu dostępnego mogą być:

• wliczane dostawy od dostawców z potwierdzoną datą,

<liwliczane produkty w produkcji, które będą gotowe przed wysyłką,

• niewliczane towary w kontroli jakości,
• niewliczane sztuki przeznaczone na ekspozycję lub jako części serwisowe.

ERP bardzo często pozwala zdefiniować różne warianty stanu dostępnego, np. osobno dla sprzedaży hurtowej i detalicznej. W integracji z e‑commerce musisz świadomie zdecydować, który wariant chcesz wysyłać.

Rezerwacje stanów: zamówienia, produkcja, serwis, zestawy

Rezerwacje to temat, który najmocniej miesza w głowie przy liczeniu stanów. W uproszczeniu, rezerwacja to obietnica złożona innemu procesowi niż aktualna sprzedaż w e‑commerce. ERP może rezerwować towar m.in. dla:

• zamówień sprzedaży – szczególnie B2B i kluczowych klientów,
• dokumentów WZ przygotowywanych do wysyłki,
• produkcji – surowce pod konkretne zlecenia produkcyjne,
• serwisu – części na naprawy gwarancyjne,
• zestawów/promocji – komponenty przypisane do bundle’i.

Nie każda rezerwacja musi być od razu odejmowana od stanu dostępnego w sklepie. Przykład: miękka rezerwacja pod ofertę handlową B2B, która wygasa po kilku dniach, może być potraktowana inaczej niż twarda rezerwacja pod opłacone zamówienie.

Stany „w drodze”: dostawy, przesunięcia, produkcja w toku

W wielu branżach kluczowe znaczenie mają stany w drodze. To sytuacje, w których towar jeszcze nie znajduje się fizycznie w magazynie gotowym do wysyłki, ale jest na tyle pewny, że część firm chce go pokazywać w e‑commerce jako „dostępny”. Typowe przypadki:

• Potwierdzone dostawy od dostawców – zamówienia zakupu z potwierdzoną datą dostawy,
• Przesunięcia między magazynami – towar jedzie z magazynu centralnego do sklepu stacjonarnego,
• Produkcja w toku – produkty w trakcie wytwarzania, mające zaplanowany termin zakończenia.

W zależności od branży i tolerancji ryzyka, część firm wlicza te ilości do stanu dostępnego (np. od pewnej daty), a część traktuje je wyłącznie informacyjnie i opiera się tylko na stanie fizycznym.

Pojęcia typowo „sklepowe”: prezentacja stanów i komunikaty

Systemy e‑commerce wprowadzają dodatkowe pojęcia, które nie istnieją lub wyglądają inaczej w ERP:

• Stan prezentowany – liczba, którą faktycznie widzi klient na karcie produktu,
• Stan minimalny – poziom, poniżej którego system zaczyna pokazywać np. „ostatnie sztuki”,
• Bufor bezpieczeństwa stanów – ilość odjęta od danych z ERP, żeby zostawić margines na pomyłki,
• Stan wirtualny – dodatkowa ilość „na górce”, np. przy przedsprzedażach lub produktach na zamówienie.

Implementując integrację, dobrze jest odróżnić te pojęcia od stanów w ERP. To, co nazywasz „stanem w sklepie”, może być tak naprawdę funkcją kilku liczb: stanu dostępnego z ERP, bufora, stanów w drodze i dodatkowych reguł marketingowych.

Jak ERP liczy stany: typowe modele obliczeń „dostępności”

Ogólna formuła stanu dostępnego w ERP

Większość systemów ERP stosuje zbliżony schemat, nawet jeśli nazewnictwo się różni. Podstawowa formuła wygląda mniej więcej tak:

stan dostępny = stan ewidencyjny (fizyczny) – rezerwacje + wybrane stany w drodze – blokady

Każdy składnik tej formuły można modyfikować w zależności od konfiguracji:

• jakie typy rezerwacji wchodzą do odjęcia,
• czy zamówienia sprzedaży rezerwują od razu, czy dopiero po statusie „opłacone”,
• czy produkcja w toku dolicza się do dostępności po określonej dacie,
• czy strefa jakościowa lub zwroty trafiają do stanu dostępnego.

Integracja powinna oprzeć się na polu lub raporcie ERP, który już uwzględnia tę logikę, albo tę logikę wiernie odtworzyć w warstwie integracyjnej.

Typy rezerwacji: twarde, miękkie, ręczne i automatyczne

W ERP występują różne typy rezerwacji. Zrozumienie ich charakteru jest kluczowe przy decyzji, co odejmować od stanu dostępnego ERP wysyłanego do sklepu.

• Rezerwacje twarde – powiązane z konkretnym dokumentem, który na pewno będzie realizowany (np. opłacone zamówienie, zatwierdzone zlecenie produkcyjne). Najczęściej powinny być w całości odjęte od stanu dostępnego.
• Rezerwacje miękkie – np. pod oferty handlowe, wstępne zamówienia, koszyki B2B czekające na akceptację. Część firm uwzględnia je w całości, część tylko w procentach, a część w ogóle ich nie odejmuje.
• Rezerwacje ręczne – wprowadzane przez użytkownika „na wszelki wypadek”, np. towar odkładany dla konkretnego klienta. Tutaj często potrzebna jest polityka firmowa: kto ma prawo je założyć i na jak długo.
• Rezerwacje automatyczne – zakładane przez system po spełnieniu warunków (np. po zmianie statusu zamówienia na „opłacone”).

Jeśli integracja ERP–sklep nie rozróżnia tych typów rezerwacji, zwykle prowadzi to do dwóch ekstremów: albo sprzedajesz towar przeznaczony już gdzie indziej, albo rezerwujesz zbyt dużo i hamujesz sprzedaż online.

Dokumenty a stany: zamówienia, WZ, PZ i ich wpływ na dostępność

ERP podejmuje decyzje o stanie fizycznym na podstawie dokumentów magazynowych i handlowych. Dla integracji ważne jest, w którym momencie dokument zmienia stan towaru z dostępnego na wydany lub z zamówionego na dostępny.

Typowy ciąg zdarzeń po stronie sprzedaży:

1. Zamówienie sprzedaży – powstaje dokument handlowy, powstaje rezerwacja (twarda lub miękka), ale stan fizyczny jeszcze się nie zmienia.
2. Dokument WZ / wydanie – w zależności od ERP, po zatwierdzeniu WZ aktualizuje się stan fizyczny (towar znika z magazynu).
3. Faktura – zwykle nie wpływa już na stan fizyczny, a jedynie na rozrachunki.

Po stronie zakupu:

Jak dokumenty zakupu „dokładają” towar do dostępności

Po stronie zakupów logika bywa podobna, ale przesunięta w czasie. Dla sprzedaży internetowej kluczowe jest, kiedy towar z „obietnicy dostawy” staje się realną ilością, którą możesz pokazać klientowi.

1. Zamówienie zakupu (ZZ) – rejestruje planowaną dostawę od dostawcy. Stan fizyczny się nie zmienia, pojawia się natomiast „ilość zamówiona” lub „w drodze”. Część firm już na tym etapie dolicza część ilości do stanu dostępnego (np. jeśli dostawca jest bardzo pewny).
2. Przyjęcie zewnętrzne (PZ) – po przyjęciu i zatwierdzeniu dokumentu stan fizyczny rośnie. W niektórych ERP poprzedza je „przyjęcie wstępne” lub strefa kontroli jakości, które jeszcze nie dokładają ilości do stanu dostępnego.
3. Faktura zakupu – zwykle nie zmienia stanów magazynowych, jedynie rozrachunki z dostawcą.

Jeżeli integracja z ERP pobiera tylko „surowy” stan magazynowy bez ilości w drodze, sklep nie widzi przyszłych dostaw i może niepotrzebnie wygaszać ofertę. Jeżeli natomiast do stanu dostępnego ślepo doliczysz każdą zamówioną ilość, wpadniesz w pułapkę „sprzedaży marzeń” – klient kupi coś, co być może nigdy nie dojedzie.

Strefy magazynowe a dostępność: kompletacja, pakowanie, jakość

W nowocześniejszych ERP stan towaru jest dzielony pomiędzy strefy magazynowe. To, że coś leży „na magazynie”, nie znaczy jeszcze, że można to spokojnie pokazać w sklepie jako dostępne od ręki.

Najczęstsze strefy, które mieszają w dostępności:

• Strefa kompletacji/pakowania – towar zdjęty z półki i przypisany do konkretnych wysyłek. Formalnie często jeszcze „na magazynie”, ale w praktyce już na drodze do klienta.
• Strefa jakościowa – produkty w kontroli jakości, po reklamacjach, w weryfikacji. Raz wrócą do pełnej sprzedaży, a raz pójdą do likwidacji.
• Strefa serwisowa – części zarezerwowane pod naprawy, instalacje, montaże u klienta.
• Strefa ekspozycji – towar na salonach pokazowych lub w sklepach stacjonarnych, który „teoretycznie” da się sprzedać, ale w praktyce pełni inną funkcję.

W dobrze zaprojektowanej integracji masz jasno zdefiniowane, z których stref ERP liczysz stan dostępny dla e‑commerce. Przykład z życia: firma odejmuje z dostępności wszystko, co trafiło do strefy pakowania, aby uniknąć podwójnej sprzedaży w szczycie sezonu wysyłek.

Jak sklep internetowy i marketplace „rozumieją” stany

Prosty model sklepu: jeden numer, wiele znaczeń

Większość platform sklepów internetowych wprowadza jedno główne pole liczby sztuk – „ilość w magazynie” albo „stan”. Dla systemu to często po prostu liczba całkowita, bez rozróżnienia na rezerwacje, dostawy w drodze czy strefy.

Na tej jednej liczbie opiera się kilka zachowań:

• pokazywanie produktu jako „dostępny / niedostępny”,
• umożliwienie zakupu tylko do określonej ilości,
• uruchamianie komunikatów „mało sztuk”,
• włączanie lub wyłączanie przedsprzedaży.

Cała ERP‑owa złożoność musi zostać zredukowana do jednej prostej wartości. Dlatego tak ważne jest, aby po stronie integracji policzyć właściwy stan dostępny i dopiero ten wysłać do sklepu.

Stany w marketplace’ach: prościej, ale ostrzej

Marketplace’y (Allegro, Amazon, itp.) patrzą na stany jeszcze bardziej zero‑jedynkowo. Dla nich interesujące są:

• ilość możliwa do sprzedaży – ile sztuk można faktycznie kupić,
• czas realizacji – ile dni roboczych potrzebujesz na wysyłkę.

Nie obchodzi ich, czy miałeś rezerwację pod B2B, czy towar jedzie z magazynu centralnego. Dla platformy liczy się to, żebyś nie sprzedawał więcej, niż możesz wysłać w zadeklarowanym terminie. Zaniżysz stany – oddasz konkurencji sprzedaż. Zawyżysz – narazisz konto na blokady i kary.

Dlatego przy integracji z marketplace’ami często stosuje się jeszcze dodatkowy bufor bezpieczeństwa ponad to, co idzie do sklepu własnego. To trochę jak zostawianie zapasu paliwa w baku – na wszelki wypadek.

Rezerwacje po stronie sklepu: koszyk, zamówienie, płatność

Sklepy internetowe wprowadzają też własne „rezerwacje”, które mają luźny związek z tymi ERP‑owymi. Zazwyczaj wygląda to tak:

• Koszyk – domyślnie nie rezerwuje towaru, ilość nadal jest dostępna dla innych klientów.
• Zamówienie złożone, nieopłacone – część platform pozwala zarezerwować na chwilę ilość, aby klient nie został „wyprzedany” w trakcie płatności.
• Zamówienie opłacone – w wielu sklepach ilość jest zdejmowana z „dostępnych” jeszcze zanim ERP to potwierdzi.

Jeśli jednocześnie ERP rezerwuje towar po swojej stronie, łatwo o podwójne odjęcie tej samej ilości. Dlatego integracja powinna jasno określić: kto jest „źródłem prawdy” o dostępności – ERP czy sklep – i które rezerwacje są nadrzędne.

Tryby sprzedaży a interpretacja stanu: od ręki, na zamówienie, przedsprzedaż

Ta sama liczba sztuk w polu „stan” może oznaczać zupełnie różne rzeczy, w zależności od tego, jak skonfigurujesz typ sprzedaży produktu:

• Sprzedaż z magazynu – liczba = ilość sztuk gotowych do natychmiastowej wysyłki.
• Sprzedaż na zamówienie – liczba może być stała (np. 999) i oznaczać, że produkt jest produkowany lub sprowadzany pod klienta.
• Przedsprzedaż – stan jest często „wirtualny”, a w tle liczony jest zupełnie inny „prawdziwy” stan z ERP, który może być nawet zerowy.

W praktyce daje to ciekawy efekt: dwa produkty w sklepie mają „stan 10 sztuk”, ale w ERP dla jednego masz fizyczne 10 na półce, a dla drugiego 0 plus pewną dostawę w drodze. Jeśli integracja bezrefleksyjnie wrzuci do sklepu „10”, klient nie zauważy różnicy, ale logistyka już tak.

Stany dostępne vs fizyczne w wielokanałowej sprzedaży

Wspólna pula czy osobne „kieszenie” stanów?

Gdy sprzedajesz w wielu kanałach naraz (sklep własny, marketplace’y, B2B, salony), pojawia się kluczowe pytanie: czy wszystkie te kanały mają korzystać z jednej wspólnej puli stanów, czy przypisać im osobne „kieszenie”?

Najczęstsze podejścia:

• Wspólna pula stanów – wszystkie kanały sprzedają z tej samej ilości. Prosto w utrzymaniu, ryzykowne przy dużym ruchu i braku szybkiej synchronizacji.
• Alokacja ilości na kanały – np. 60% puli na B2B, 30% na sklep, 10% na marketplace’y. Więcej konfiguracji, za to mniejsze ryzyko, że jeden kanał „wyczyści” magazyn innym.
• Priorytety kanałów – ERP odgórnie rezerwuje ilości pod określone kanały (np. zawsze priorytet dla sprzedaży własnej lub kontraktów długoterminowych), a integracja wysyła do e‑commerce jedynie „resztówkę”.

Przykład z praktyki: producent, który ma umowę z kilkoma kluczowymi partnerami B2B, często najpierw rezerwuje w ERP ściśle określone ilości pod te kontrakty. Dopiero nadwyżka (np. 20% prognozowanej produkcji) jest udostępniana w sklepie i marketplace’ach.

Synchronizacja stanów między kanałami: częstotliwość i konflikt

Przy wielokanałowej sprzedaży ważne stają się dwie rzeczy: jak często aktualizujesz stany i co robisz, gdy różne kanały „naraz” sprzedają ten sam ostatni egzemplarz.

Najczęściej spotykane rozwiązania:

• Aktualizacje cykliczne – np. co 5–10 minut. Proste, ale przy dużym ruchu nadal grozi wyprzedażą „ponad stan”.
• Aktualizacje zdarzeniowe – po każdej zmianie dokumentu w ERP lub zamówienia w sklepie. Bezpieczniejsze, ale bardziej obciążające i wymagające lepszej architektury.
• Blokada „ostatniej sztuki” – np. system zostawia bufor 1 sztuki, której nie pokazuje w żadnym kanale, po to, by mieć margines na takie kolizje.

Gdy kolizja jednak wystąpi, polityka firmy decyduje: czy anulujesz zamówienie z marketplace’u, czy z własnego sklepu, czy może podnosisz koszt logistyczny, dokupując towar „na cito”. ERP samo tej decyzji nie podejmie – integracja powinna być na to przygotowana.

Stany per magazyn a kanały sprzedaży

Wiele ERP prowadzi stany w rozbiciu na magazyny: centralny, regionalne, sklepy stacjonarne. E‑commerce natomiast zwykle widzi jedną liczbę.

Typowe scenariusze:

• Sumowanie wszystkich magazynów – do sklepu wysyłasz sumę stanów z magazynu centralnego i sklepów stacjonarnych. Dobre, jeśli masz sprawną logistykę wewnętrzną (szybkie przesunięcia).
• Tylko magazyn wysyłkowy – sklep widzi wyłącznie stany z magazynu głównego, a sklepy stacjonarne „żyją swoim życiem”. Mniej konfliktów, ale możesz mieć sytuację, że produkt stoi na półce w salonie, a w e‑commerce jest „brak”.
• Wielomagazynowość w sklepie – bardziej zaawansowane platformy potrafią pokazać stany per lokalizacja (np. sklep X ma 3 sztuki, sklep Y ma 5 kultowych sztuk). Wtedy integracja musi rozbić dane z ERP per magazyn.

Jeżeli planujesz odbiór osobisty w wielu punktach, samo „sumowanie” przestaje wystarczać. Trzeba wtedy zdecydować, czy stan dostępny do wysyłki kurierskiej to inna liczba niż stan dla „odbioru w sklepie”.

Marketplace jako osobny „konsument” stanów

Marketplace potrafi w kilka minut ściągnąć zapas produktu, który w sklepie własnym sprzedawałby się tygodniami. To zupełnie inna dynamika zużycia stanów.

Dlatego firmy często traktują marketplace jako kanał o osobnej logice dostępności:

• stosują niższy stan maksymalny (np. do Allegro wysyłają maksymalnie 50% tego, co jest w ERP),
• ustawiają większe bufory bezpieczeństwa,
• wprowadzają priorytety anulacji – jeśli brakuje towaru, w pierwszej kolejności przycinane są zamówienia z kanału o niższym priorytecie.

To wszystko musi być odzwierciedlone w logice liczenia stanu dostępnego, a nie dopiero „ręcznie” w panelu marketplace’u. Inaczej którąś sobotę spędzisz na ręcznym zmienianiu ilości na kilkudziesięciu aukcjach.

Ustalanie logiki: jakie stany liczyć i wysyłać do sklepu / marketplace

Najpierw decyzje biznesowe, potem techniczne

Zanim programista napisze choć jedną linijkę integracji, potrzebny jest prosty, ale konkretny zestaw odpowiedzi – najlepiej spisany na jednej kartce. ERP i e‑commerce dają mnóstwo możliwości, ale to biznes decyduje, jak ryzykownie chcesz grać stanami.

Najprościej zacząć od kilku pytań:

• czy sklep ma pokazywać wyłącznie ilości faktycznie na półce, czy również pewne dostawy w drodze,
• jak traktujesz rezerwacje miękkie – odejmujesz w całości, częściowo czy wcale,
• czy chcesz mieć inne bufory dla sklepu własnego i dla marketplace’ów,
• czy któryś kanał ma priorytet i powinien „wygrać” w konflikcie o ostatnią sztukę.

Odpowiedzi na te pytania przekładają się na konkretną formułę, którą programista może zaimplementować w integracji. Bez nich skończysz w trybie „gaszenia pożarów” – raz stany za niskie, raz za wysokie.

Wybór źródła danych w ERP: pola standardowe vs widoki i raporty

Większość ERP oferuje kilka pól związanych ze stanami: „stan bieżący”, „stan dostępny”, „stan zamówiony”, „stan wolny”, „rezerwacje”. Kuszące jest wzięcie jednego prostego pola „stan dostępny” i wysyłanie go 1:1 do sklepu. Czasem to dobre rozwiązanie, ale tylko jeśli:

• rozumiesz, jak dokładnie to pole jest liczone w ERP,
• masz pewność, że uwzględnia właściwe rezerwacje i dostawy,
• wiesz, że nie jest wykorzystywane w inny, specyficzny sposób (np. pod produkcję).

W bardziej skomplikowanych przypadkach lepiej przygotować w ERP dedykowany widok lub raport, który policzy stan według Twojej logiki, np.:

• sumuje wybrane magazyny,
• odlicza tylko twarde rezerwacje,
• dolicza dostawy z potwierdzonym terminem do określonej daty,

Bufory, zaokrąglenia i limity prezentacji stanów

Nawet jeśli w ERP liczysz stan dostępny bardzo precyzyjnie (czasem z przecinkami, bo jednostki miary bywają nietypowe), do e‑commerce zwykle wysyłasz prostą, „marketingową” liczbę. Tu zaczyna się zabawa w bufory i limity.

Najczęstsze mechanizmy, które dobrze zaplanować od razu:

• Bufor bezpieczeństwa – odliczenie kilku sztuk „na wszelki wypadek”, np. awarie, pomyłki inwentaryzacyjne, zwroty w drodze. Integracja może więc brać z ERP 100 sztuk, a do sklepu wysyłać 95.
• Zaokrąglanie w dół – szczególnie przy jednostkach przeliczeniowych (kartony, metry bieżące). ERP liczy 10,7 mb, a sklep widzi 10. Te 0,7 ratuje skórę, gdy trzeba dociąć towar z rolki.
• Limit maksymalny na kanał – nawet jeśli ERP pokazuje 1 000 sztuk, na marketplace wysyłasz 50. To ogranicza ryzyko „wystrzałów” sprzedaży, na które produkcja czy zakupy nie były gotowe.

Dobrą praktyką jest, by te parametry (bufor, limity) były konfigurowalne, a nie zaszyte na stałe w kodzie integracji. Wtedy gdy zmienia się sezon, popyt czy pewność dostaw, nie trzeba przepisywać logiki – wystarczy zmienić kilka wartości w ustawieniach.

Różne formuły na różne grupy produktów

Produkty „szybkie” (np. akcesoria, materiały eksploatacyjne) wymagają innego podejścia niż towary produkowane na zamówienie czy sprowadzane z długim terminem. Jedna globalna formuła dla całego asortymentu zwykle kończy się frustracją działu sprzedaży.

Przy planowaniu logiki opłaca się rozróżnić co najmniej trzy klasy towarów:

• Typ A – wysyłka od ręki – stan dostępny ≈ stan fizyczny − rezerwacje twarde − bufor. Tu każda sztuka na półce ma znaczenie, a opóźnienie w synchronizacji boli najbardziej.
• Typ B – na zamówienie – stan dostępny może być stałą liczbą lub wynikać z mocy przerobowych. Sklep często pokazuje „na stanie” mimo że fizycznie w ERP jest 0, a dopiero termin realizacji pokazuje prawdę.
• Typ C – limitowane lub strategiczne – np. serie kolekcjonerskie albo kluczowe komponenty do produkcji. Tu stan dostępny dla e‑commerce może być jedynie procentem rzeczywistego stanu, bo reszta jest zabezpieczona pod inne procesy.

ERP zwykle pozwala oznaczyć produkty grupami, cechami, klasami ABC lub innymi atrybutami. Integracja może z nich skorzystać, by stosować różne formuły, np. „dla grupy A licz tak, dla B inaczej”. Bez tej segmentacji jedne produkty są „przepraszane” za brak, a inne zalegają na magazynie, bo bałeś się pokazać ich dostępność.

Warunkowe liczenie stanów po dacie dostawy

Przy towarach z długim lub niepewnym łańcuchem dostaw kluczowe jest pytanie: czy chcesz sprzedawać to, czego jeszcze nie ma fizycznie, ale ma potwierdzony termin dostawy? Odpowiedź rzadko jest zero-jedynkowa – zależy od horyzontu czasowego.

Typowy, rozsądny kompromis wygląda tak:

• dla zamówień z dostawą potwierdzoną na najbliższe dni – doliczasz część lub całość do stanu dostępnego,
• dla dostaw powiedzmy za kilka tygodni – pozwalasz na sprzedaż w trybie „na zamówienie” z dłuższym terminem, ale nie wliczasz ich do stanu „od ręki”,
• dostawy bez potwierdzonej daty – pozostają w ERP jako informacja dla zakupów/produkcji, ale integracja je ignoruje w wyliczaniu stanów wysyłanych do sklepu.

Technicznie można to zapisać jako formułę typu: „stan dostępny = stan fizyczny + zamówienia przychodzące z datą ≤ X dni − rezerwacje”. Granicę X dobierasz do branży – dla części motoryzacyjnych to może być kilka dni, dla mebli kilka tygodni.

Mapowanie typów rezerwacji na „świat e‑commerce”

ERP zna często więcej rodzajów rezerwacji niż jest to potrzebne sklepowi. Masz rezerwacje produkcyjne, pod projekty, oferty, zamówienia wstępne, serwis, a do e‑commerce interesują Cię tak naprawdę dwie informacje: czy klient może kupić teraz i kiedy dostanie towar.

Dobrze sprawdza się podejście, w którym każdemu typowi rezerwacji w ERP przypisujesz prostą kategorię na potrzeby integracji:

• „Odejmuje zawsze” – np. zamówienia potwierdzone, zlecenia produkcyjne w toku. Te ilości są dla klienta „niewidzialne”.
• „Odejmuje warunkowo” – rezerwacje miękkie, oferty, koszyki. Można je częściowo pomijać lub brać z wagą (np. 50%), jeśli statystycznie część z nich wygasa.
• „Ignorowane” – wewnętrzne blokady techniczne, rezerwacje serwisowe o małym wolumenie, które nie mają znaczenia dla sprzedaży online.

Takie mapowanie warto opisać prostą tabelą, zrozumiałą dla księgowości, logistyki i IT. Gdy pojawia się nowy rodzaj rezerwacji w ERP (np. pod nowy proces produkcyjny), łatwo wtedy ocenić, czy i jak powinna wpływać na stan dostępny wysyłany do sklepu.

Priorytety kanałów a formuły stanów

Samo ustalenie, który kanał jest „ważniejszy”, to dopiero początek. Trzeba jeszcze przełożyć to na konkretne mechanizmy liczenia ilości.

Prosta, a skuteczna metoda to przypisanie kanałom wag lub limitów w formule stanu dostępnego. Przykładowo:

• własny sklep: stan = (ERP stan dostępny − bufor globalny) × 1,0,
• marketplace A: stan = (ERP stan dostępny − bufor globalny) × 0,4,
• kanał B2B: stan = „to, co zostanie” po kanałach priorytetowych.

Inna logika polega na „rezerwacji wstępnej” pod kanały: ERP utrzymuje osobne pule (np. przez magazyny wirtualne lub cechy dokumentów), a integracja po prostu odczytuje właściwą pulę dla danego kanału. To bezpieczniejsze, ale wymaga większej dyscypliny po stronie operacyjnej – każde ręczne przesunięcie czy korekta musi trafić do właściwej „kieszeni”.

Obsługa wyjątków: produkt bez stanu, ale wciąż w ofercie

Niemal każdy sklep ma grupę produktów „dziwnych” z punktu widzenia stanów: zestawy, części zamienne, końcówki serii, towary pod indywidualną wycenę. Jeśli integracja traktuje je jak zwykłe SKU, pojawiają się błędy typu „0 na stanie, a produkt dalej się sprzedaje”.

Można temu zaradzić, definiując osobną logikę dla takich przypadków:

• Produkty „zawsze dostępne na zapytanie” – niezależnie od stanów w ERP, w sklepie są oznaczone jako „na zamówienie” i nie podlegają automatycznej synchronizacji ilości (lub mają sztucznie wysoki stan, np. 999).
• Zestawy złożone – stan dostępny zależy od najsłabszego ogniwa, czyli minimalnego stanu komponentów w ERP. Integracja zamiast czytać jedno pole „stan”, musi policzyć go z listy materiałowej (BOM).
• Końcówki serii – dla niektórych firm lepiej, by ostatnie sztuki były widoczne tylko w jednym kanale (np. sklepie własnym), a w marketplace zostały wyłączone automatycznie po zejściu poniżej określonego progu.

Tu przydaje się nadawanie produktom flag lub atrybutów, na podstawie których integracja rozpoznaje, że ten towar liczymy inaczej. Bez tego zawsze znajdzie się asortyment, który „nie pasuje” do głównej logiki i psuje statystyki.

Testowanie logiki na małej próbce asortymentu

Najlepsza formuła policzona na tablicy przestaje być idealna, gdy zderza się z realnymi danymi. Dlatego zanim włączysz automatyczną synchronizację dla całego katalogu, opłaca się przeprowadzić testy na niewielkiej grupie produktów.

Dobry zestaw testowy obejmuje:

• produkt prosty, szybko rotujący,
• produkt z długim terminem dostawy,
• zestaw lub komplet,
• produkt sprzedawany w wielu kanałach naraz,
• coś z „trudnej” kategorii – np. z podwójną jednostką miary lub nietypową rezerwacją.

Dla takiej grupy można przez kilka dni porównywać stan w ERP, stan „policzony” przez integrację i stan widoczny w sklepie. Dobrze przygotowana integracja pozwala włączyć tryb podglądu: zamiast od razu wysyłać ilości do e‑commerce, generuje raport „jak by to policzyła”. Dopiero gdy te liczby przestaną zaskakiwać magazyn i sprzedaż, warto przełączyć się na tryb produkcyjny.

Transparentność dla użytkowników wewnętrznych

Kompleksowa logika liczenia stanów ma jedną wadę: jeśli zostanie „ukryta” w integracji, po miesiącu nikt już nie wie, skąd w sklepie biorą się konkretne liczby. A gdy pojawią się rozbieżności, zaczyna się polowanie na czarownice: „ERP źle liczy”, „integracja coś psuje”, „sklep nie aktualizuje”.

Żeby tego uniknąć, przydaje się kilka prostych narzędzi:

• Opis formuły w krótkim dokumencie – nie techniczne SQL-e, tylko zrozumiały opis: „stan w sklepie = stan fizyczny − rezerwacje X, Y + dostawy Z do daty…”.
• Raport porównawczy w ERP lub BI – pokazujący na jednej liście: stan fizyczny, rezerwacje, dostawy, bufor, wynikowy stan dostępny „dla sklepu”.
• Log zmian – kto, kiedy zmienił parametry buforów, limitów, mapowanie rezerwacji. Gdy coś zaczyna się „rozjeżdżać”, łatwiej skojarzyć to z konkretną modyfikacją.

Dzięki temu, gdy handlowiec widzi w sklepie 7 sztuk, może w kilka kliknięć sprawdzić, jak ta siódemka się wyliczyła z danych w ERP. Znika magia, pojawia się przewidywalność – a o to w gruncie rzeczy chodzi przy rozróżnianiu stanu fizycznego i dostępnego.

Najczęściej zadawane pytania (FAQ)

Co to jest stan fizyczny, a co stan dostępny w integracji ERP ze sklepem?

Stan fizyczny to towar, który faktycznie leży na półce w magazynie: można go policzyć, zeskanować, dotknąć. Stan dostępny (wolny dla sprzedaży) to tylko ta część tego towaru, którą możesz bezpiecznie pokazać klientowi jako „do kupienia teraz”.

Najczęściej liczysz go według uproszczonego wzoru: stan dostępny = stan ewidencyjny w ERP – rezerwacje – blokady + wybrane, pewne dostawy w drodze lub produkcja w toku. Dzięki temu nie sprzedajesz ani „powietrza”, ani nie blokujesz sprzedaży towaru, który za chwilę będzie na stanie.

Dlaczego nie mogę po prostu wysłać do sklepu stanu fizycznego z ERP?

Bo stan fizyczny nie uwzględnia tego, co już jest „przyklejone” do innych zobowiązań. Część towaru bywa zarezerwowana pod duże zamówienia B2B, część leży na reklamacjach, część czeka na kontrolę jakości. Dla magazynu to wszystko sztuki na półce, ale dla e‑commerce spora część z nich jest już „zajęta”.

Jeśli do sklepu wysyłasz goły stan fizyczny, kończy się to overbookingiem magazynu: sklep pokazuje „12 sztuk”, klient kupuje, a ty po chwili dzwonisz i tłumaczysz, że jednak nie wyślesz. Ilekroć pojawia się sprzedaż na wielu kanałach (sklep, marketplace, B2B), ten problem potrafi urosnąć do skali kryzysu.

Jak prawidłowo liczyć stan dostępny w integracji ERP–e‑commerce?

Podstawą jest jasny, „po imieniu” nazwany wzór, uzgodniony między logistyką, e‑commerce i IT. Najczęściej wygląda tak: stan dostępny = stan ewidencyjny w ERP – wszystkie rezerwacje pod potwierdzone zamówienia – blokady jakościowe – reklamacje + wybrane dostawy w drodze i/lub produkcja w toku.

Kluczowa decyzja dotyczy tego, co doliczasz „na plus” (np. tylko dostawy z potwierdzoną datą dostawy) i co odejmujesz „na minus” (np. czy rezerwacje wstępne z koszyka B2B już blokują stan). To nie jest wyłącznie kwestia techniczna, ale również biznesowa – chodzi o to, ile ryzyka overbookingu jesteś w stanie zaakceptować.

Gdzie powinna być liczona logika stanów dostępnych – w ERP czy w sklepie?

Najbezpieczniej jest liczyć stany w ERP lub w dedykowanej warstwie integracyjnej (OMS, integrator), a do sklepu wysyłać już gotowy stan dostępny. ERP jest wtedy „źródłem prawdy”: zbiera przyjęcia, wydania, rezerwacje, produkcję, przesunięcia między magazynami i na tej podstawie wylicza, co możesz sprzedać.

Sklep, marketplace czy panel B2B pełnią rolę „twarzy” tych danych. Na tej samej liczbie sztuk mogą wyświetlić różne komunikaty: „wysyłka jutro”, „na zamówienie”, „ostatnie sztuki”. Jeśli każdy kanał zacznie sobie liczyć stany po swojemu, integracja zamieni się w chaos, a te same produkty zaczną się sprzedawać równolegle w kilku miejscach.

Jakie są najczęstsze błędy przy ustawianiu stanów w integracji ERP z e‑commerce?

Najczęściej powtarzają się trzy scenariusze. Po pierwsze: wysyłanie do sklepu czystego stanu fizycznego bez odjęcia rezerwacji i blokad – wtedy sprzedajesz towar, który „już ma właściciela”. Po drugie: zbyt zachowawcze liczenie, w którym nie doliczasz żadnych pewnych dostaw ani produkcji w toku, więc sklep świeci zerami, mimo że ciężarówka z towarem jest w drodze.

Po trzecie: brak wspólnych definicji między zespołami. Dla e‑commerce „stan”, dla magazynu „stan” i dla księgowości „stan” potrafią oznaczać trzy różne rzeczy. Jedno spotkanie, na którym spiszecie definicje (fizyczny, ewidencyjny, dostępny, zarezerwowany), często rozwiązuje połowę konfliktów na etapie wdrożenia integracji.

Jak rozróżnić stan fizyczny od ewidencyjnego w ERP i który wysyłać do sklepu?

Stan fizyczny to to, co znajdziesz na regale. Stan ewidencyjny to to, co pokazuje ERP po uwzględnieniu wszystkich zaksięgowanych i będących w trakcie księgowania dokumentów (PZ, WZ, przesunięcia, korekty). W idealnym świecie te wartości są identyczne, ale w praktyce rozjazdy są normą: opóźnione księgowanie PZ, pomyłki w wydaniach, niezamknięte dokumenty.

Integracje z e‑commerce prawie zawsze bazują na stanie ewidencyjnym, bo to on jest dostępny przez API ERP. Jeżeli różnice między fizycznym a ewidencyjnym są duże, problem leży w procesach magazynowo‑księgowych i żadna integracja tego za ciebie „magicznie” nie naprawi – trzeba zadbać o porządek w dokumentach i inwentaryzacjach.

Jak liczyć stany dostępne przy sprzedaży wielokanałowej (sklep, Allegro, Amazon, B2B)?

Kluczem jest jedno centralne miejsce liczenia stanów, najlepiej ERP lub OMS, i jedna, spójna definicja stanu dostępnego dla wszystkich kanałów. Tam powstaje „jeden numer” stanu dostępnego, który następnie jest dystrybuowany do sklepu, marketplace’ów i systemu B2B. Dzięki temu każda sztuka towaru jest „zaliczona” tylko raz.

Przy dużym wolumenie zamówień ręczne poprawianie stanów przestaje mieć sens. Automatyczna, częsta synchronizacja (nawet co kilka minut przy szybko rotującym towarze) oraz jasne reguły rezerwacji pod każde zamówienie to jedyny sposób, by nie obudzić się z sytuacją, w której ten sam produkt został sprzedany równocześnie przez trzy różne kanały.

Kluczowe Wnioski

• Stan fizyczny to to, co faktycznie stoi na półkach, a stan dostępny to ta część towaru, którą można bezpiecznie sprzedać – klienta interesuje wyłącznie to drugie.
• Wysyłanie do sklepu „gołego” stanu fizycznego z ERP kończy się sprzedażą towaru, który jest już zarezerwowany lub zablokowany, więc rodzi reklamacje, korekty i spadek ocen.
• Zbyt zachowawcze liczenie stanów dostępnych (bez dostaw w drodze, z nadmiarem blokad) blokuje sprzedaż – realnie masz towar, ale system uparcie pokazuje „0”.
• Różnica między stanem fizycznym a stanem dostępnym to świadoma decyzja o poziomie ryzyka: im bardziej optymistyczny algorytm, tym większe ryzyko overbookingu, im bardziej ostrożny – tym większa strata potencjału sprzedaży.
• ERP powinien być „źródłem prawdy” dla stanów, a sklep i marketplace’y jedynie prezentować przeliczony stan dostępny (np. „wysyłka w 48h”, „ostatnie sztuki”), zamiast samodzielnie liczyć zapasy.
• Przy większej skali (wiele kanałów, magazynów, setki zamówień dziennie) ręczne pilnowanie stanów przestaje działać – bez automatycznego, spójnego algorytmu stanów dostępnych każdy kanał sprzedaje „po swojemu”.
• Stan ewidencyjny w ERP może różnić się od fizycznego przez błędy i opóźnienia w dokumentach, dlatego integracja e‑commerce zwykle bazuje właśnie na stanie ewidencyjnym, a stan dostępny to jego przeliczenie: stan ewidencyjny – rezerwacje – blokady + wybrane dostawy w drodze.