W stanie magazynowym jest 40 sztuk. Handlowiec A obiecuje 30 klientowi z Poznania. Godzinę później handlowiec B obiecuje 25 klientowi z Krakowa. Obaj patrzyli w ten sam raport i obaj mieli rację — w chwili patrzenia w systemie było 40 sztuk. Problem w tym, że ERP nie wiedział o pierwszej obietnicy, kiedy druga trafiała do systemu. Efekt: jeden z klientów za dwa dni dostanie telefon z przeprosinami.
Ten wpis jest o tym, dlaczego „stan magazynowy" w ERP nie wystarcza do sprzedaży, czym różni się rezerwacja twarda od miękkiej i jak w dwutygodniowym projekcie poukładać rezerwacje tak, żeby handlowcy przestali kłamać klientom w dobrej wierze.
Dlaczego sam stan magazynowy to za mało
Prawie każdy ERP w MŚP — Comarch Optima, Comarch ERP XL, enova365, Subiekt GT/nexo, Streamsoft — ma pole „stan magazynowy" w kartotece towaru. To liczba, która pokazuje, ile fizycznie leży w magazynie. Jest dokładna do momentu, w którym coś zjedzie z półki albo przyjedzie dostawa.
Problem polega na tym, że proces sprzedaży nie działa w tej skali czasu. Między złożeniem obietnicy klientowi a wydaniem z magazynu mijają godziny, dni, czasem tygodnie. W tym czasie ten sam „stan" jest widoczny dla wszystkich handlowców, dla e-sklepu, dla kierownika magazynu i dla działu zakupów. Każdy z nich widzi tę samą liczbę i każdy podejmuje decyzje, jakby był jedynym, który z niej korzysta.
To działa, dopóki firma ma dwóch handlowców i jeden magazyn. Przestaje działać w momencie, w którym równolegle procesują ofertowanie, zamówienia telefoniczne, e-sklep, sieć B2B i produkcję, która też sięga po ten sam materiał. Typowe objawy, po których wiadomo, że firma dorosła do rezerwacji:
- „Sprzedałeś, czego nie mamy" — regularne telefony z reklamacjami, że towar obiecany na wtorek pojedzie w piątek.
- Handlowcy dzwonią do magazynu przed każdą ofertą — bo raport w ERP im nie wystarcza. Kierownik magazynu odbiera 15 telefonów dziennie.
- E-sklep sprzedaje, czego zabrakło — dopiero przy pakowaniu widać, że dostępny towar poszedł już zamówieniem B2B.
- Zakupy zamawiają za dużo — bo widzą stan 0, nie widząc, że 20 sztuk już przyjechało pod inne zamówienie w drodze.
- Produkcja stoi, bo materiał „poszedł na sprzedaż" — technolog zaplanował partię pod materiał, którego rano nie było, bo w nocy poszedł listem przewozowym.
Każdy z tych objawów kosztuje. Nie dramatycznie na sztukę, ale codziennie — a przez rok to jedne wakacje dyrektora zjedzone na obsługę reklamacji, których nie musiało być.
Rezerwacja twarda vs miękka
W praktycznym słowniku ERP-owca funkcjonują dwa pojęcia, które warto rozdzielić, zanim wejdzie się w konfigurację systemu.
Rezerwacja twarda to blokada konkretnego towaru w konkretnym magazynie na konkretne zamówienie. Kiedy handlowiec potwierdza zamówienie klientowi X na 30 sztuk, w ERP-ie te 30 sztuk fizycznie znika z „dostępnych do sprzedaży" dla wszystkich innych. Nie ma dyskusji, nie ma „a może się dogadamy". Ten stan jest przypisany do dokumentu.
Rezerwacja miękka to sygnał, że ktoś ma zamiar wziąć towar, ale jeszcze nie potwierdził. Typowo: oferta wysłana, ale niepotwierdzona przez klienta. Miękka rezerwacja ma zawsze datę wygaśnięcia — po 7 dniach bez potwierdzenia, blokada schodzi, towar wraca do puli sprzedażowej.
Podstawowa zasada: każdy dokument w procesie sprzedaży musi mieć jasno przypisany typ rezerwacji. Oferta = miękka, zamówienie potwierdzone przez klienta = twarda, dokument WZ = wydanie (już nie rezerwacja, tylko fizyczne zejście ze stanu).
W ERP w MŚP jest to zwykle jedno pole checkbox przy nagłówku dokumentu i drugie — data ważności rezerwacji. Cała reszta to konfiguracja: który typ dokumentu tworzy jaki typ rezerwacji domyślnie, kto może zmieniać, kiedy blokada schodzi automatycznie.
Stan dostępny to nie stan magazynowy
Kiedy w ERP włączasz rezerwacje, w kartotece towaru zamiast jednej liczby pojawiają się cztery, które trzeba nauczyć czytać cały zespół:
- Stan magazynowy — ile fizycznie leży (nie zmienia się od rezerwacji, tylko od dokumentów PZ/WZ/MM).
- Zarezerwowane — ile jest zablokowane na już potwierdzone zamówienia (rezerwacje twarde).
- W drodze — ile jest zamówione od dostawcy, ale jeszcze nie przyjechało (zamówienia zakupu bez PZ).
- Dostępne do sprzedaży = stan magazynowy − zarezerwowane + w drodze (z opcjonalnym filtrem po dacie dostawy).
Handlowiec nigdy nie patrzy na „stan magazynowy". Patrzy na „dostępne do sprzedaży". E-sklep pobiera przez API „dostępne do sprzedaży", nie „stan magazynowy". Kierownik magazynu patrzy na „stan magazynowy" i „zarezerwowane", bo jego zmartwieniem jest, czy fizycznie leży to, co ma leżeć.
Ta pojedyncza zmiana — nauczenie zespołu, że sprzedaje się z „dostępne", a nie ze „stanu" — rozwiązuje 80% problemu podwójnej sprzedaży. Reszta to konfiguracja typów dokumentów i dyscyplina wygaszania miękkich rezerwacji.
Konfiguracja w typowym ERP MŚP
Pokazane na przykładzie Comarch Optima i Comarch ERP XL, bo to najczęstsze w polskich firmach 15-50 osobowych. W enova365, Subiekcie i Streamsoft mechanizm jest bardzo podobny, tylko nazwy pól inne.
Krok 1 — włącz rezerwacje na wybranych magazynach. W konfiguracji magazynu odznacz „ignoruj rezerwacje". W firmie z jednym magazynem to jedna zmiana. W firmie z magazynem głównym i magazynem detalicznym warto zostawić rezerwacje tylko na głównym.
Krok 2 — ustaw domyślne typy rezerwacji dla dokumentów. Zamówienie sprzedaży (ZS) potwierdzone przez klienta = rezerwacja twarda. Oferta (OF) = rezerwacja miękka, 7 dni. Faktura pro forma = rezerwacja twarda do momentu opłacenia albo do daty ważności (typowo 3 dni).
Krok 3 — zdefiniuj, kto może zdejmować rezerwacje ręcznie. Handlowiec — tylko swoje. Kierownik sprzedaży — wszystkie. Ważne, żeby to było w uprawnieniach, inaczej każdy zdejmuje każdemu i po całości.
Krok 4 — cykliczne wygaszanie miękkich rezerwacji. Codzienny job w tle albo funkcja w harmonogramie ERP-a: „wszystkie oferty starsze niż 7 dni bez zamówienia → zdejmij rezerwację, wyślij mail do handlowca".
Krok 5 — widoczność w kartotece. W kartotece towaru pokaż listę wszystkich rezerwacji z numerem dokumentu, klientem, ilością i datą ważności. Kiedy handlowiec widzi „30 sztuk zarezerwowane na ZS/2026/1234 dla klienta X do 15.09", wie, czy rozmawiać z klientem X o skróceniu, czy szukać towaru gdzie indziej.
Krok 6 — integracja z e-sklepem i EDI. Jeśli e-sklep pobiera stan przez API, przełącz go na stan dostępny. Jeśli wysyłasz katalogi do sieci handlowych przez EDI, upewnij się, że w plikach INVRPT idzie stan dostępny, nie magazynowy. Inaczej sieć zamawia to, co już zablokowałeś dla kogoś innego.
Konkretny przykład z życia
18-osobowy dystrybutor materiałów instalacyjnych spod Łodzi. Comarch ERP XL kupiony 6 lat temu, moduł magazynowy skonfigurowany domyślnie — rezerwacje nikomu nie zostały włączone przy wdrożeniu, bo „to skomplikowane". Sprzedaż przez 5 handlowców w biurze, sklep B2B i EDI do dwóch sieci hurtowych. Magazyn na 2400 indeksów, dzienna rotacja 300-400 pozycji na dokumentach.
Powód, dla którego zadzwonili: kierownik sprzedaży zliczył reklamacje za pierwsze półrocze — 84 przypadki „obiecali, nie dowieźli", w tym 11 utraconych klientów, którzy przeszli do konkurencji. Właściciel policzył utraconą marżę: około 340 tysięcy zł w skali roku, plus obciążenie księgowości i logistyki fakturami korygującymi.
Co zrobiliśmy w 3 tygodniach:
- Audyt procesu sprzedaży — 2 dni z kierownikiem sprzedaży, jednym handlowcem i kierownikiem magazynu. Zmapowaliśmy 6 kanałów sprzedaży (telefon, mail, sklep B2B, EDI, przedstawiciele w terenie, sprzedaż z magazynu detalicznego). Kluczowe odkrycie: przedstawiciele w terenie „zaklepywali" towar SMS-em do biura, biuro robiło notatkę w Outlooku — w ERP nie było śladu.
- Włączenie rezerwacji na magazynie głównym — jedna zmiana w konfiguracji Comarch ERP XL, ale trzeba było przejść 32 otwarte zamówienia z ostatnich 6 tygodni i wystawić na nie rezerwacje wstecznie, żeby nie zaburzyć stanu dostępnego.
- Konfiguracja typów rezerwacji — oferta = miękka 5 dni, zamówienie potwierdzone = twarda, faktura pro forma = twarda 3 dni. Cykl codzienny o 6:00 rano wygasza miękkie po terminie i wysyła handlowcowi listę „coś, co ci wygasło wczoraj".
- Zmiana raportu w e-sklepie B2B — sklep dotąd pokazywał klientom stan magazynowy. Zmieniliśmy zapytanie API na stan dostępny (magazyn − twarde rezerwacje + zamówienia zakupu z dostawą w ciągu 7 dni). Kilku klientów zauważyło zmianę i zapytało, dlaczego „nagle mniej", tłumaczyliśmy: „bo teraz nie sprzedajemy, czego nie mamy".
- Zmiana pliku EDI dla sieci — plik INVRPT dla dwóch sieci hurtowych dostał inny widok na ten sam towar, dostawnie dostępny, nie magazynowy. Sieci nie zauważyły różnicy w formacie, ale przestały składać zamówienia na towar, który już był zarezerwowany.
- Aplikacja mobilna dla przedstawicieli — mały dodatek, dostęp do sklepu B2B z telefonu. Zamiast SMS-a do biura, przedstawiciel z klientem na spotkaniu składa ofertę, która tworzy miękką rezerwację od razu w ERP.
- Nowe raporty dla handlowców — dashboard „moje aktywne rezerwacje" z terminami wygaśnięcia, żeby każdy handlowiec dbał o swoje przed terminem, nie po fakcie.
Efekt po 3 miesiącach: reklamacje „obiecali, nie dowieźli" spadły z 14-16 na miesiąc do 2-3. Te 2-3 to głównie problemy z opóźnieniami u dostawców, nie z podwójną sprzedażą. Handlowcy przestali dzwonić do magazynu przed ofertami — w miesiącu kierownik magazynu ocenił oszczędność na około 40 godzin swojego czasu. Dwie utracone sieci wróciły w kwartał, bo przedstawiciel handlowy zadzwonił z konkretem: „teraz mamy pewny stan dostępny w EDI, nie zmarnujecie zamówienia".
Koszt projektu: około 18 tysięcy zł — 3 dni audytu, 4 dni konfiguracji Comarch ERP XL, 2 dni pracy nad integracją API do sklepu i pliku EDI, 1 dzień szkolenia handlowców i kierownika magazynu, aplikacja mobilna dla przedstawicieli oparta o istniejący portal B2B (nie budowaliśmy nowej — tylko widok mobilny). Zwrot: dwa miesiące, licząc odzyskanych klientów i uwolniony czas kierownika magazynu.
Pułapki, na które warto uważać
Kilka rzeczy, które potrafią rozłożyć projekt rezerwacji:
- Rezerwacja bez daty ważności to bomba z opóźnionym zapłonem — po pół roku okazuje się, że 30% stanu jest „zarezerwowane" na oferty, o których nikt nie pamięta. Data ważności obowiązkowa dla każdej rezerwacji miękkiej.
- Rezerwacja twarda na fakturę pro forma bez zapłaty — jeśli klient nie płaci pro formy w 3 dni, rezerwacja schodzi. Inaczej klient „rezerwuje sobie" i nigdy nie odbiera.
- Rezerwacje na dokumentach zewnętrznych bez powiązania w ERP — SMS, mail, notatka w Outlooku, kartka pod klawiaturą. Jeśli nie ma tego w ERP, nie ma tego wcale. Zasada: rezerwuje ten, kto wpisuje w ERP.
- Ignorowanie „w drodze" w stanie dostępnym — jeśli w kartotece nie widać 100 sztuk zamówionych od dostawcy z dostawą jutro, handlowiec traci sprzedaż mimo że towar jest praktycznie „za rogiem". Zamówienia zakupu muszą wchodzić w kalkulację stanu dostępnego (z filtrem po dacie dostawy).
- Rezerwacje między magazynem produkcyjnym a handlowym — jeśli produkcja pobiera materiał, który był zarezerwowany do sprzedaży, kończy się awanturą. Osobne magazyny logiczne i osobne kolejki zapotrzebowania rozwiązują to raz na zawsze.
- Zbyt swobodne uprawnienia do zdejmowania rezerwacji — jeśli handlowiec A zdejmuje rezerwację handlowca B, żeby wystawić własne, po tygodniu jest wojna handlowców. Zdejmowanie cudzych — tylko kierownik.
- Brak komunikacji do klienta — kiedy klient wcześniej dostawał „mamy 40 sztuk", a teraz dostaje „mamy 12 sztuk dostępne, 28 zarezerwowane", warto to wytłumaczyć na 3 zdania w mailu. Inaczej klient myśli, że mu odmawiasz.
Kiedy nie warto
Rezerwacje mają sens od pewnej skali. Jeśli firma ma dwóch handlowców, jeden magazyn, sprzedaje z dnia na dzień i praktycznie nie ma otwartych zamówień na przyszłość — dodawanie rezerwacji jest przeinżynierowaniem. Wystarczy Excel z listą „obiecane w tym tygodniu" i codzienna 5-minutowa odprawa handlowców.
Rezerwacje zaczynają się opłacać, kiedy:
- Otwartych zamówień jest więcej niż 20-30 w danym momencie.
- Sprzedaż idzie równolegle przez 3+ kanały (telefon, mail, e-sklep, EDI, przedstawiciele).
- Cykl od oferty do wydania trwa dłużej niż 24 godziny.
- Reklamacji „obiecali, nie dowieźli" jest więcej niż 2-3 na miesiąc.
Poniżej tych progów rezerwacje są narzutem administracyjnym bez wyraźnej korzyści. Powyżej — brak rezerwacji kosztuje więcej niż ich wprowadzenie.
Co dalej
Rezerwacje w ERP to jedna z tych zmian, które wyglądają technicznie, ale są przede wszystkim zmianą sposobu, w jaki firma myśli o stanie magazynowym. „Ile mam" przestaje wystarczać — trzeba nauczyć się pytać „ile mam dostępne dla nowej sprzedaży". To pytanie, na które prawidłowo skonfigurowany ERP odpowiada w sekundę, a ręcznie prowadzony magazyn — nie odpowiada wcale.
Jeśli u Ciebie handlowcy dzwonią do magazynu przed ofertami albo reklamacje „obiecali, nie dowieźli" wracają co tydzień — pół godziny rozmowy zwykle wystarczy, żeby ocenić, czy rezerwacje są tym, co Twojej firmie brakuje.
Handlowiec, który dzwoni do magazynu przed każdą ofertą, nie robi tego z uprzejmości. Robi to, bo raport w ERP mu kłamie — a kłamie, bo nikt nie włączył rezerwacji.