Zarządzanie stanem magazynowym w małych sklepach internetowych: kiedy arkusze kalkulacyjne przestają wystarczać

Sprawdzono i zaktualizowano w czerwcu 2026 — natywne pola stanów magazynowych i nazwy tabel zweryfikowane w PrestaShop 1.7, 8 i 9.
Każdy sklep internetowy zaczyna zarządzać stanem magazynowym w ten sam sposób: od arkusza kalkulacyjnego. Przy 20 produktach i kilku zamówieniach dziennie to naprawdę działa. Po każdej sprzedaży wpisujesz nową ilość, utrzymujesz bieżące saldo i porównujesz je z półką, gdy liczby zaczynają się rozjeżdżać. Na tym etapie arkusz nie jest problemem — jest właściwym narzędziem, a sięganie po „prawdziwe” oprogramowanie magazynowe dla 20 SKU to przerost formy nad treścią.
Kłopot polega na tym, że nic nie informuje Cię, kiedy przekraczasz granicę. Pewnego dnia masz już 200 produktów, sprzedajesz w sklepie PrestaShop i na marketplace, część towaru leży w biurze, część u partnera fulfillmentowego, arkusz ma 40 kolumn, a nikt nie ufa ani jednej zapisanej w nim liczbie. Ten wpis dotyczy właśnie tego momentu przejścia: jak rozpoznać, że arkusz przestał działać, co własny silnik magazynowy PrestaShop robi za Ciebie od chwili, gdy przestajesz podwójnie wprowadzać dane do Excela, i jak go skonfigurować, żeby liczby faktycznie były dokładne. Głębsze podtematy — obliczanie progów ponownego zamówienia, zachowanie przy braku towaru, masowy import danych — mają swoje osobne poradniki, więc odsyłamy do nich tam, gdzie ma to sens, zamiast streszczać je tu po łebkach.
Pięć oznak, że arkusz kalkulacyjny przestał wystarczać
Dokładny punkt krytyczny różni się w zależności od sklepu, ale objawy są powtarzalne. Jeśli rozpoznajesz dwa lub więcej z nich, arkusz nie oszczędza już czasu — kosztuje Cię zamówienia:
- Sprzedałeś więcej, niż masz na stanie. Klient kupił produkt, którego nie było na półce, bo arkusz nie został zaktualizowany po poprzedniej sprzedaży. Finał to zwrot pieniędzy, przeprosiny i klient, który raczej nie wróci.
- Bestseller spadł do zera bez ostrzeżenia. Alert niskiego stanu był regułą formatowania warunkowego, którą ktoś nadpisał trzy tygodnie temu, a nikt tego nie zauważył, dopóki nie przyszła zdenerwowana wiadomość od klienta.
- Stan w arkuszu nie zgadza się z półką. Arkusz pokazuje 47, na półce są 32 sztuki, a popołudnie znika na szukaniu, gdzie podziało się 15 jednostek.
- Kanały sprzedaży pokazują różne liczby. Trzy sztuki sprzedały się na stronie, dwie na marketplace, ale do pliku trafiła tylko sprzedaż ze strony, bo zamówienia z marketplace były „czyjąś inną robotą”.
- Aktualizacja arkusza trwa dłużej niż realizacja zamówienia. Każda sprzedaż, dostawa i zwrot to ręczna edycja, a narzut administracyjny rośnie szybciej niż przychody.
Wspólnym mianownikiem wszystkich pięciu problemów jest podwójne wprowadzanie danych: PrestaShop już wie, co się sprzedało, a Ty ręcznie przepisujesz to do drugiego systemu. Pierwszym realnym usprawnieniem nie jest nowe narzędzie — tylko usunięcie arkusza i zaufanie silnikowi magazynowemu, za który już zapłaciłeś.
Co już potrafi wbudowane zarządzanie stanem magazynowym w PrestaShop

Zanim sięgniesz po jakikolwiek moduł, warto wiedzieć, ile PrestaShop obsługuje natywnie, bo dla sklepu z jedną lokalizacją często to wystarcza. Każdy produkt i każda kombinacja ma własną ilość, a ta ilość zmienia się automatycznie wraz z przechodzeniem zamówień przez kolejne statusy — bez edytowania arkusza.
Konfigurujesz to osobno dla każdego produktu w sekcji Katalog → Produkty, na karcie Ilości (w PrestaShop 1.6 jest to podkarta Ilości na stronie produktu). Najważniejsze pola:
- Ilość — jednostki dostępne na stanie. To ta liczba zmniejsza się po złożeniu i zatwierdzeniu zamówienia — dokładny moment zależy od ustawień magazynowych i cyklu życia zamówienia, a nie od prostego przełącznika opłacone kontra wysłane — i rośnie ponownie, jeśli anulujesz zamówienie albo wykonasz zwrot z włączonym przywróceniem stanu.
- Minimalna ilość do sprzedaży — najmniejsza ilość, jaką klient może kupić w jednym zamówieniu (zostaw 1, chyba że sprzedajesz w pakietach).
- Niski poziom stanu magazynowego — ustaw tu próg i zaznacz Wyślij mi e-mail, gdy ilość spadnie poniżej tego poziomu, a PrestaShop wyśle wiadomość zamiast zmuszać Cię do obserwowania koloru komórki w arkuszu. To najbardziej niedoceniana natywna funkcja: zamienia „zapomniałem sprawdzić” w proaktywny alert bez dodatkowych kosztów.
- Gdy brak na stanie — Odmów zamówień, Zezwól na zamówienia (backordery) albo Użyj domyślnego zachowania. To, czy produkt ukryć, wyszarzyć, czy nadal sprzedawać, jest realną decyzją z kompromisami po obu stronach — omawiamy ją dokładniej w Brak towaru: ukrywać czy nie ukrywać?, a konkretny przypadek sprzedaży przed pojawieniem się dostawy w Przedsprzedaż i backordery.
Domyślne zachowanie przy braku towaru dla całego sklepu znajdziesz w Parametry sklepu → Ustawienia produktu (albo Preferencje → Produkty w 1.6), a etykiety dostępności widoczne dla klientów („Brak na stanie”, „Dostępne na zamówienie”) ustawia się dla produktu w Katalog → Produkty na karcie Ilości. Warto jasno powiedzieć jedną rzecz: rdzeń PrestaShop nie ma natywnego ustawienia, które pozwala wybrać opłacenie zamówienia albo wysyłkę jako moment fizycznego zejścia towaru ze stanu. Stan zmniejsza się, gdy zamówienie zostaje zatwierdzone, a resztą zarządza cykl życia zamówienia: anulowanie, zwrot, ponowne wprowadzenie na stan. Jeśli naprawdę potrzebujesz reguły zmniejszania stanu przy płatności albo przy wysyłce, to jest obszar własnego procesu lub modułu — nie przełącznik w panelu administracyjnym.
I co z tego wynika? W sklepie z jedną lokalizacją poprawna konfiguracja tych pól i wyłączenie nawyku przepisywania e-maili do arkusza eliminuje cztery z pięciu opisanych wyżej źródeł problemów już pierwszego dnia — bez kupowania czegokolwiek. Natywny silnik zaczyna nie wystarczać dopiero wtedy, gdy dochodzi prawdziwa złożoność: wiele fizycznych lokalizacji, zamówienia zakupu do dostawców albo szczegółowa historia ruchów magazynowych. Wtedy warto rozszerzyć PrestaShop, zamiast z nim walczyć.
Gdzie natywny magazyn dochodzi do ściany: wiele lokalizacji
Natywne pole ilości zakłada jedną pulę towaru. W chwili, gdy produkty znajdują się w więcej niż jednym miejscu — w biurze, magazynie, u dostawcy dropshippingowego, u partnera komisowego — pojedyncza liczba przestaje opisywać rzeczywistość. Musisz wiedzieć nie tylko ile masz sztuk, ale też gdzie one są, bo od tego zależy, która lokalizacja wysyła zamówienie, ile kosztuje dostawa i co naprawdę możesz obiecać klientowi.
Historyczne „Zaawansowane zarządzanie magazynem” w PrestaShop (moduł w stylu WMS w sekcji Magazyn) próbowało to rozwiązać, ale było znane z dużej sztywności, zależności od konkretnych statusów zamówień i oderwania od współczesnego procesu składania zamówienia — większość sprzedawców, którzy je włączyli, później tego żałowała. Nasz moduł Warehouse Revolution wypełnia tę lukę śledzeniem stanów według lokalizacji, które działa ze standardowym procesem zakupowym, a nie obok niego:
- Ilości według magazynu — rzeczywisty stan w każdej lokalizacji, a nie jedna zsumowana liczba ukrywająca, gdzie towar faktycznie leży.
- Reguły przypisywania magazynu — automatyczne kierowanie każdego zamówienia do lokalizacji z towarem (albo najbliższej klientowi), dzięki czemu nie musisz ręcznie decydować, kto co wysyła.
- Rejestr przesunięć — zapisywanie ruchów między lokalizacjami, aby ślad audytowy pozostał czytelny, zamiast sytuacji, w której towar znika z jednego miejsca i pojawia się w drugim bez żadnego potwierdzenia.
- Progi ponownego zamówienia według lokalizacji — każdy magazyn ma własny próg niskiego stanu, bo pustka w biurze nie oznacza, że pusty jest też magazyn.
I co z tego wynika? Z poziomu panelu administracyjnego PrestaShop dostajesz jeden uczciwy obraz stanów we wszystkich lokalizacjach, co definitywnie eliminuje nadmierną sprzedaż typu „arkusz mówi, że mamy, ale ten magazyn jest pusty”.
Audytowalność: wiedzieć, dlaczego liczba się zmieniła
Arkusze tracą zaufanie, bo nie mają pamięci. Komórka zmienia się z 47 na 32 i nie ma śladu, kto to zrobił ani dlaczego. Porządne zarządzanie zapasami utrzymuje historię ruchów: każde zwiększenie i zmniejszenie ze znacznikiem czasu oraz powodem — sprzedaż, zwrot, korekta ręczna, przesunięcie, przyjęcie towaru.
Jeśli chcesz tylko szybki przekrojowy podgląd całego katalogu i produktów, którym kończy się stan — raportu, którego natywny panel administracyjny nie pokazuje na jednym ekranie — możesz odczytać go bezpośrednio z bazy danych zapytaniem tylko do odczytu w Zaawansowane → Baza danych → Menedżer SQL. To zapytanie pokazuje każdy produkt podstawowy (bez kombinacji) z ilością równą 10 sztuk lub mniejszą, od najniższego stanu:
SELECT sa.id_product,
pl.name,
sa.quantity
FROM ps_stock_available sa
JOIN ps_product_lang pl
ON pl.id_product = sa.id_product
AND pl.id_lang = 1
WHERE sa.id_product_attribute = 0
AND sa.quantity <= 10
ORDER BY sa.quantity ASC;
Dostosuj id_lang do swojego języka, a 10 do progu, który Cię interesuje. Zapytanie tylko odczytuje dane — niczego nie zmienia — więc możesz je uruchamiać tak często, jak chcesz. Aby uwzględnić każdą kombinację osobno, usuń linię id_product_attribute = 0. To ręczny zrzut stanu, a nie alert; następne sekcje mówią o tym, jak sprawić, żeby próg pilnował się sam.
W PrestaShop bieżące dostępne ilości znajdują się w ps_stock_available — to magazyn ilości, nie dziennik ruchów ani log audytowy. Natywna historia ruchów jest ograniczona i zależna od wersji; dedykowane tabele ruchów magazynowych (ps_stock_mvt) należą raczej do kontekstu historycznego Zaawansowanego zarządzania magazynem niż do zwykłych sklepów z prostym magazynem. Tak czy inaczej, rdzeń panelu administracyjnego pokazuje niewiele z tych danych dla sklepu z prostymi stanami. Gdy pojawia się rozbieżność, pytanie jest zawsze takie samo — „co stało się z tymi sztukami?” — a odpowiedzią powinno być jedno sprawdzenie, nie śledztwo na całe popołudnie. Właśnie dlatego rejestr ruchów wygrywa z arkuszem jeszcze zanim dodasz lokalizacje: arkusz powie Ci, że stan jest błędny, ale nigdy nie pokaże, jak do tego doszło.
Utrzymanie cyfrowego stanu w zgodzie z rzeczywistością: liczenie cykliczne
Nawet idealny system z czasem rozmija się z fizyczną rzeczywistością, bo rzeczywistość bywa chaotyczna — produkty się psują, trafiają w złe miejsce albo są błędnie liczone przy przyjęciu. Odpowiedzią nie jest jeden budzący grozę roczny remanent, tylko małe, częste liczenia, ważone znaczeniem produktu. Praktyczny rytm wygląda tak:
| Klasa produktu | W przybliżeniu | Częstotliwość liczenia | Dlaczego |
|---|---|---|---|
| A — Twoje bestsellery | Górne ~20% produktów, większość przychodu | Co tydzień | Błąd tutaj oznacza nadmierną sprzedaż najbardziej pożądanych produktów — najdroższe pomyłki. |
| B — produkty sprzedające się regularnie | Kolejne ~30% | Co miesiąc | Warto je kontrolować, ale odchylenia bolą mniej i korygują się przy następnym liczeniu. |
| C — długi ogon | Dolne ~50%, niewielka część przychodu | Co kwartał | Liczenie akcesorium za 2 € co tydzień kosztuje więcej pracy niż potencjalny błąd. |
To zasada ABC: poświęcaj uwagę tam, gdzie są pieniądze. Powyższe procenty to klasyczny podział orientacyjny, nie prawo — zanim zaufasz koszykom, pobierz własny raport sprzedaży i zaklasyfikuj produkty według ich faktycznego udziału w przychodach. Gdy wynik liczenia się nie zgadza, wyjaśnij to tego samego dnia; rozbieżność jest objawem, a przyczynę (kradzież, błąd przy przyjęciu, nieprzetworzony zwrot, pomyłkę przy kompletacji) z każdą godziną coraz trudniej odtworzyć.
Ponowne zamawianie, zanim zabraknie towaru
Dokładny stan to tylko połowa pracy — druga połowa to działanie zanim zapas spadnie do zera. Mechanika tego, kiedy zamówić ponownie, sprowadza się do małej, niezawodnej formuły zbudowanej z tempa sprzedaży, czasu realizacji dostawcy i bufora bezpieczeństwa, plus pytania, ile zapasu bezpieczeństwa jest ubezpieczeniem, a ile martwym kapitałem. Zamiast upychać to w jednym akapicie, rozpisaliśmy wzory, przykłady i sposób odczytywania danych sprzedażowych z PrestaShop w osobnym poradniku: Kiedy ponownie zamawiać towar: proste wzory, które zapobiegają brakom. Połącz opisane tam punkty ponownego zamówienia z progami według lokalizacji powyżej i e-mailem o niskim stanie, który PrestaShop już wysyła, a ponowne zamawianie stanie się zadaniem wyzwalanym przez dane, nie zgadywaniem.
Martwy zapas: towar, który po cichu kosztuje
Przeciwieństwem braku towaru jest zapas, który w ogóle się nie rusza. Martwy zapas zamraża kapitał, zajmuje opłacaną przestrzeń i z czasem traci wartość. Prosta reguła wieku utrzymuje go w polu widzenia:
- Brak sprzedaży przez 90 dni — oznacz do przeglądu, rozważ umiarkowaną obniżkę.
- Brak sprzedaży przez 180 dni — zwiększ rabat albo połącz produkt w zestaw z czymś, co dobrze się sprzedaje.
- Brak sprzedaży przez 365 dni — wyprzedaj, przekaż albo odpisz; pełna cena już nie wróci.
Koszt utrzymywania produktu, który przez rok leży niesprzedany, prawie zawsze przewyższa marżę, z której zrezygnujesz, sprzedając go za pół ceny. Stopniowe obniżki możesz zautomatyzować zamiast wpisywać je ręcznie do kalendarza dzięki naszemu modułowi Smart Dynamic & Scheduled Discounts — ustaw pogłębianie rabatu wraz z wiekiem produktu, a wolno rotujący towar będzie schodził zgodnie z harmonogramem.
Kiedy rozważyć synchronizację wielu kanałów
Jeśli sprzedajesz wyłącznie w swoim sklepie PrestaShop, traktuj go jako jedno źródło prawdy i przejdź do następnej sekcji. Gdy dodajesz drugi kanał — marketplace, kasę w sklepie stacjonarnym, drugi front sklepu — stany muszą pozostawać zsynchronizowane we wszystkich miejscach, bo sprzedaż ponad stan w kanale B na podstawie nieaktualnej liczby z kanału A to najszybsza droga do negatywnych opinii. Trzy realistyczne podejścia:
- PrestaShop jako system nadrzędny — utrzymuj autorytatywny stan w sklepie i wypychaj aktualizacje do każdego kanału. Najprostsze, gdy większość sprzedaży odbywa się w sklepie.
- Middleware — warstwa synchronizacji pomiędzy wszystkimi kanałami, która uzgadnia stany w obie strony. Warta abonamentu, gdy żonglujesz trzema lub więcej kanałami.
- Konserwatywna alokacja — jeśli synchronizacja nie działa w czasie rzeczywistym, celowo publikuj w każdym kanale mniej sztuk, niż faktycznie posiadasz, zostawiając bufor pochłaniający opóźnienie. Prymitywne, ale zapobiega sprzedaży ponad stan, dopóki nie wdrożysz lepszego rozwiązania.
Aby zasilić dowolne narzędzie zewnętrzne, potrzebujesz czystych danych masowo wyprowadzonych z PrestaShop — zarówno bieżącego katalogu, jak i historii zamówień, która napędza prognozowanie popytu. Eksport i import danych produktowych (CSV, XML i API) omawiamy w Import i eksport produktów, a pobieranie danych zamówień i sprzedaży do analizy w Eksport CSV zamówień i faktur. W przypadku cyklicznych eksportów zamówień nasz moduł Orders CSV List Exporter zamienia przefiltrowaną listę zamówień w zaplanowany, powtarzalny plik.
Liczby, które warto obserwować, gdy magazyn jest już pod kontrolą
Działający system magazynowy generuje dane, których arkusz nigdy nie mógł dostarczyć. Nie potrzebujesz wszystkich od pierwszego dnia, ale to właśnie te wskaźniki mówią, czy trzymasz zbyt dużo, zbyt mało, czy gdzieś gubisz sztuki:
- Rotacja zapasów — jak szybko sprzedajesz zapasy. Wyższa oznacza mniej kapitału zamrożonego na półkach.
- Dni zapasu — przy obecnym tempie sprzedaży, ile dni zostało do zera. To właśnie realnie steruje terminem ponownego zamówienia.
- Wskaźnik wyprzedaży dostawy — udział przyjętego towaru, który sprzedaje się w pełnej cenie. Utrzymująco niski wynik wskazuje na nadmierne zamawianie albo błędną cenę.
- Ubytki magazynowe — różnica między oczekiwanym a policzonym stanem, śledzona jako procent wartości zapasów. Rosnąca liczba oznacza, że proces traci sztuki.
Najczęściej zadawane pytania
Czy PrestaShop ma wbudowane alerty niskiego stanu magazynowego?
Tak, osobno dla każdego produktu. Na karcie Ilości ustawiasz niski poziom stanu i zaznaczasz „Wyślij mi e-mail, gdy ilość spadnie poniżej tego poziomu”. PrestaShop wysyła wtedy wiadomość na adres powiadomień sprzedawcy, gdy ilość dostępna przekroczy ten próg w dół. To najbardziej niedoceniana natywna funkcja — zamienia „zapomniałem sprawdzić” w proaktywny alert bez dodatkowych kosztów. Nie daje natomiast jednego ekranu z listą wszystkich produktów poniżej progu; tu swoje miejsce ma panel magazynowy albo pokazany wyżej zrzut SQL.
Gdzie PrestaShop przechowuje ilości magazynowe?
Bieżące dostępne ilości znajdują się w tabeli ps_stock_available, po jednym wierszu na produkt (i kombinację), zarządzanej przez klasę StockAvailable. To magazyn ilości, nie dziennik ruchów — mówi, jaki jest stan teraz, ale nigdy jak do niego doszło. Historyczne tabele ruchów magazynowych (ps_stock_mvt, ps_stock) należą do starego kontekstu Zaawansowanego zarządzania magazynem, nie do zwykłego sklepu z prostymi stanami.
Czy PrestaShop może śledzić stany w wielu magazynach?
Nie natywnie w użyteczny sposób. Historyczne „Zaawansowane zarządzanie magazynem” próbowało obsługi wielu lokalizacji, ale było sztywne, powiązane z konkretnymi statusami zamówień i oderwane od współczesnego procesu składania zamówienia. Do rzeczywistych ilości według lokalizacji działających ze standardowym procesem zakupowym — plus reguł przypisywania magazynu, rejestru przesunięć i progów ponownego zamówienia według lokalizacji — służy Warehouse Revolution.
Kiedy warto przestać używać arkusza kalkulacyjnego?
Gdy pojawią się dwa lub więcej opisanych wyżej trybów awarii: sprzedaż ponad stan, cichy brak towaru, liczba niezgodna z półką, kanały pokazujące różne stany albo czas administracyjny rosnący szybciej niż przychody. Pierwszym usprawnieniem nie jest nowe oprogramowanie — tylko usunięcie równoległego arkusza i zaufanie natywnym ilościom PrestaShop, które już wiedzą, co się sprzedało.
Czy anulowanie albo zwrot zamówienia przywróci towar na stan?
Może, jeśli dla tego procesu włączone jest ponowne wprowadzenie na stan. Ilość zmniejsza się po zatwierdzeniu zamówienia i rośnie ponownie przy anulowaniu lub zwrocie z włączonym przywróceniem stanu. Nie ma natywnego przełącznika „zmniejszaj stan przy wysyłce zamiast przy zamówieniu” — ta decyzja należy do cyklu życia zamówienia, a nie do pojedynczego przełącznika.
Rozsądna kolejność wdrożenia
Nie wdrażasz tego wszystkiego naraz — i nie powinieneś. Przejście z arkuszy to sekwencja, w której każdy krok usuwa jeden tryb awarii:
- Najpierw poprawnie skonfiguruj natywne ilości PrestaShop, e-mail o niskim stanie i zachowanie przy braku towaru — a potem przestań równolegle prowadzić arkusz. Już samo to rozwiązuje sprzedaż ponad stan i ciche braki w sklepie z jedną lokalizacją.
- Następnie ustaw punkty ponownego zamówienia dla produktów klasy A, korzystając z wzorów ponownego zamawiania, i zaplanuj cotygodniowe liczenie cykliczne tych samych bestsellerów.
- Potem raz na kwartał przeglądaj martwy zapas i pozwól zaplanowanym rabatom go czyścić.
- Później, tylko jeśli tego potrzebujesz, dodaj śledzenie wielu lokalizacji za pomocą Warehouse Revolution, zarządzanie dostawcami i synchronizację kanałów.
Celem nigdy nie był idealny magazyn — taki nie istnieje. Chodzi o stan na tyle dokładny, żeby przestać sprzedawać ponad stan, nie zostawać bez kluczowych produktów i nie zakopywać gotówki w towarze, który się nie rusza. PrestaShop daje Ci więcej od razu po instalacji, niż wielu sprzedawców sądzi; ostatnią użyteczną rolą arkusza jest uświadomić Ci, jak dobry silnik już masz.
Komentarze
Brak komentarzy. Bądź pierwszy!
Bądź pierwszy: zadaj pytanie albo podziel się przydatną opinią.
Dodaj komentarz
Dodaj pytanie, szczegół montażu albo opinię, która może pomóc innemu czytelnikowi.