Zbuduj aplikację sugerującą ponowne zamówienia, która przechowuje min/max dla każdego SKU, oblicza ilości do zamówienia i tworzy roboczą listę zakupów do przeglądu zespołu.
Prowadzenie sklepu zwykle oznacza balansowanie między dwoma kosztownymi błędami: brak towaru na szybko rotujących produktach (utraty sprzedaży, niezadowoleni klienci) albo kupowanie za dużo (zamrożone środki w wolno rotującym zapasie). Codzienny problem nie brzmi „czy mamy zapas?” lecz „co powinniśmy następnym razem zamówić i w jakiej ilości?”, bez spędzania godziny na arkuszach kalkulacyjnych.
Konfiguracja min/max upraszcza tę decyzję. Dla każdego SKU przechowujesz dwie liczby:
Jeśli SKU ma 6 sztuk, min to 10, a max to 25, sugerowana ilość wynosi 19. Nie zgadujesz z pamięci. Stosujesz jasną regułę, która pozostaje spójna tydzień do tygodnia.
Aplikacja sugerująca ponowne zamówienia bierze aktualne stany magazynowe (i opcjonalnie to, co już jest na zamówieniu), stosuje reguły min/max dla każdego SKU i tworzy roboczą listę zakupów. Ten szkic to główny wynik: krótka, możliwa do przeglądu lista odpowiadająca na pytanie „co powinniśmy zamówić i ile?” zanim ktoś zaloguje się do portalu dostawcy lub napisze maila.
Co ona nie robi, to automatyczne składanie zamówień. To ważne, bo rzeczywiste zakupy mają wyjątki: dostawca może być wyprzedany, wielkości opakowań wymuszają zaokrąglenia, sezonowy produkt może być pominięty albo nadciąga promocja. Aplikacja powinna generować sugestie szybko, a potem pozwolić człowiekowi zatwierdzić, edytować lub usunąć pozycje.
Tego typu narzędzie zazwyczaj używają kierownicy sklepów, liderzy operacji i dział zakupów. Przydaje się też w małych zespołach, gdzie jedna osoba pełni wiele ról i potrzebuje solidnego punktu wyjścia.
Dobre sugestie zaczynają się od nudnych, spójnych danych SKU. Jeśli podstawy są chaotyczne, Twoja robocza lista będzie wyglądała losowo i ludzie przestaną jej ufać.
Celuj w rekord SKU, który zachowa ten sam „kształt” w czasie, nawet jeśli proces się zmieni.
Aby działało od pierwszego dnia, potrzebujesz:
Min i Max to szyny bezpieczeństwa. Osobny punkt ponownego zamówienia jest opcjonalny, ale przydatny, gdy chcesz zamawiać wcześniej niż przy Min z powodu długich czasów realizacji lub zawodnego zaopatrzenia.
Te szczegóły zamieniają „ile kupić” w „co faktycznie można zamówić”:
Bądź konkretny co do źródła wartości „on hand”. Jeśli zaczynasz od ręcznego wpisu, przechowuj datę ostatniego liczenia. Jeśli później zsynchronizujesz z POS lub narzędziem magazynowym, przechowuj czas ostatniej synchronizacji. Ta jedna informacja odpowiada na wiele pytań „dlaczego to zasugerowano?”.
Min/max to prosta reguła: zamawiasz tylko, gdy zapas jest niski, i zamawiasz tyle, aby wrócić do bezpiecznego poziomu. Wynik to robocza lista, która jest czytelna i łatwa do audytu.
Wybierz jeden mechanizm wyzwalający i trzymaj się go. Najczęstszy to:
To unika hałaśliwych rekomendacji dla produktów, które są już w dobrym stanie.
Gdy pozycja kwalifikuje się, podstawowy pomysł to „zamów do Max”. Prosty wzór to:
base_suggested = max - on_hand
suggested = max(0, base_suggested)
Przykład: Min = 10, Max = 40, On Hand = 14.
Jeśli On Hand spadnie do 8:
Po podstawowym obliczeniu dodaj kilka drobnych zasad, aby dopasować się do praktyki zakupowej:
Złe dane dają złe sugestie, więc te sytuacje zrób widocznymi:
Najlepszy przepływ to ten, którego faktycznie będzie używał zespół. Utrzymaj prostotę: zapisz co masz, potem wygeneruj sugestie. Dodatki (etykiety, dashboardy, analityka) mogą przyjść później.
Typowa sesja wygląda tak: użytkownik robi szybki spis, wybiera lokalizację (jeśli potrzeba), wpisuje stany dla SKU, zapisuje, a potem naciska przycisk, by stworzyć roboczą listę zakupów. Kupiec przegląda szkic i koryguje go przed zatwierdzeniem.
Aby ekran był przejrzysty, dodaj jedno praktyczne filtrowanie: pokaż tylko SKU poniżej min, albo pokaż wszystkie SKU z czytelnym statusem. „Tylko poniżej min” jest szybsze w gorących dniach. „Pokaż wszystko” pomaga, gdy chcesz upewnić się, że nic nie zostało pominięte.
Prosty flow, który działa dla większości małych zespołów:
Nadpisania są ważne, bo rzeczywistość jest nieuporządkowana. Kupiec może zamówić więcej na promocję albo mniej z powodu braku gotówki czy opóźnionego dostawcy. Traktuj sugerowaną ilość jako punkt wyjścia, a nie regułę.
Kilka małych kontrolek zapobiega frustracji:
Na koniec zapisz snapshot, kiedy szkic został wygenerowany: znacznik czasu, użyte stany on-hand, wartości min/max w tym momencie oraz sugerowane ilości przed nadpisaniami. Gdy ktoś zapyta „dlaczego zamówiliśmy 24 tego?”, możesz otworzyć szkic i zobaczyć dokładne dane wejściowe, które go wygenerowały.
Dobra aplikacja do zamówień zaczyna się od małego zestawu tabel, którym możesz ufać. Celem nie jest perfekcyjne ERP, lecz czysta baza, która może rosnąć, gdy dodasz dostawców, lokalizacje czy mądrzejsze reguły.
Dla jednego sklepu oddziel „co to za produkt” od „ile go masz” i „jak go uzupełniać”:
To pozostaje elastyczne, bo możesz zmieniać reguły uzupełniania bez przepisywania listy SKU, a szkice zamówień zachowasz jako zapis tego, co zasugerowano i co zatwierdzono.
Jeśli masz dziś tylko jeden sklep, nie rozbudowuj lokalizacji na zapas. Przechowuj zapas jako jedną liczbę na SKU. Gdy dodasz drugi sklep lub magazyn, wprowadź tabelę Locations i przejdź do zapasów per SKU per lokalizacja.
Proste reguły walidacji zapobiegają temu, że błędne dane zamienią się w złe zamówienia. Dodaj kontrole jak: min musi być mniejszy niż max, punkt ponownego zamówienia nie może być ujemny, a wielkość opakowania nie może być zerem. Zdecyduj, co się stanie, gdy brakuje ustawień: blokujesz sugestie, czy oznaczasz SKU jako „wymaga konfiguracji”.
Role pomagają, gdy kilka osób liczy stany i zmienia ustawienia:
Zaplanuj też sposób wysyłki zamówień. Nawet jeśli później zautomatyzujesz zakupy, większość zespołów zaczyna od prostego eksportu: plik CSV lub lista przygotowana dla dostawcy, którą można skopiować ze strony szkicu zamówienia.
Zacznij od dwóch prostych list: katalogu SKU i listy dostawców. Każde SKU powinno mieć nazwę rozpoznawalną przez ludzi, domyślnego dostawcę i jednostkę zakupu (szt., case, karton). Trzymaj to praktyczne. To ta lista, której zespół będzie szukał codziennie.
Następnie dodaj ustawienia uzupełniania do rekordu SKU. Min i Max to podstawa, ale lepsze sugestie uzyskasz, jeśli zapiszesz też wielkość opakowania i lead time. Jeśli kupujesz ten sam przedmiot od dwóch dostawców, wybierz jednego jako domyślnego i pozwól na zmianę na etapie szkicu zamówienia.
Dla wpisów stanów zbuduj szybki ekran, który faworyzuje szybkość nad perfekcją. Szybka siatka edycji sprawdza się dobrze: filtruj po alejce lub kategorii, wpisz policzoną ilość i zapisz.
Większość zespołów potrzebuje tych podstawowych ekranów:
Potem zaimplementuj logikę sugestii: dla każdego SKU porównaj „on hand” (i opcjonalnie „on order”) z regułami uzupełniania, oblicz sugerowaną ilość, aby wrócić w kierunku max, i zastosuj zaokrąglenie do wielkości opakowania, aby nie sugerować 13 sztuk, gdy dostawca sprzedaje tylko case po 12.
Wygeneruj robocze zamówienie do przeglądu i traktuj je jak dokument ze statusami takimi jak Draft, Approved, Sent. Gdy użytkownik tworzy szkic, skopiuj linie sugestii do linii zamówienia pogrupowanych według dostawcy, a potem pozwól ludziom edytować ilości, zmieniać dostawców lub usuwać pozycje.
Zakończ czystym krokiem eksportu. Niektóre zespoły drukują szkic i realizują zamówienia ręcznie. Inne eksportują plik. W każdym przypadku zapisz, co zostało zatwierdzone, aby później porównać „sugerowano vs. zamówiono” i ulepszyć reguły na podstawie rzeczywistych danych.
Matematyka uzupełniania jest prosta. To, co psuje zaufanie, to chaotyczne ustawienia. Większość problemów pokazuje się jako szkic zamówienia, który „nie pasuje”, nawet jeśli wzór jest poprawny.
Klasycznym problemem są mieszane jednostki. Liczysz „szt.”, ale zamawiasz w „case’ach”, albo otrzymujesz w „opakowaniach”. Jeśli jednostka SKU jest niejasna, aplikacja może zasugerować 24, mając na myśli 24 case'y. Wybierz jedną jednostkę bazową na SKU (często „szt.”) i zapisz konwersję, np. „1 case = 24 szt.”, aby końcowa ilość zamówienia była przeliczona poprawnie.
Min i Max często ustawiane są na wyczucie. Jeśli ignorujesz tempo sprzedaży i lead time dostawcy, reguły będą wyglądać schludnie, ale zawiodą w praktyce. Wolno rotujący produkt z wysokim max zamraża kapitał, a szybko rotujący z niskim min powoduje braki.
Inne powszechne błędy:
Prosty scenariusz: sprzedajesz kapsułki do kawy. Na półce widać 6 pudełek, w zapleczu 18, a w drugim sklepie 12. Jeśli śledzisz tylko jedną liczbę „on hand”, ktoś policzy 6 i system zasugeruje zamówienie, mimo że naprawdę masz 36. Pola lokalizacji rozwiązują to szybko.
System min/max jest prosty, ale szkic jest tylko tak dobry, jak dane za nim stojące. Zanim wyślesz cokolwiek do dostawcy, poświęć minutę na szybkie sprawdzenie cichych błędów, które sprawiają, że sugestie brzmią przekonująco, ale są błędne.
Zacznij od konfiguracji: każdy reorderowalny SKU potrzebuje min, max i poprawnej wielkości opakowania. Jeśli którekolwiek z tych pól brakuje, aplikacja powinna oznaczyć SKU i pominąć je lub oznaczyć jako „wymaga konfiguracji”. Jedno puste pole może cicho wygenerować ogromne zamówienie lub żadne zamówienie.
Następnie sprawdź sensowność stanów on-hand. Ujemny zapas się zdarza (zwroty przetworzone z opóźnieniem, przyjęcia niezaksięgowane, pomyłki jednostek), ale powinien być rzadki. Jeśli widzisz -12 dla wolno rotującego produktu, traktuj sugestię jako „do wyjaśnienia”, a nie „kupować natychmiast”. Ponowne policzenie lub szybki przegląd transakcji jest tańszy niż rozplątywanie nadmiaru później.
Krótka lista kontrolna, która łapie większość problemów:
Zasady pakowania zasługują na szczególną uwagę. Jeśli dostawca sprzedaje w case’ach po 24, a szkic sugeruje 13, system powinien dostosować według polityki (często zaokrąglenie w górę). To samo dotyczy MOQ: pokaż oryginalną sugestię i liczbę po korekcie, aby recenzent zrozumiał zmianę.
Zdecyduj też, co znaczy „wystarczająco dobre” dla Twojego zespołu. Zamawianie do max jest agresywne i może zamrozić gotówkę. Bardziej konserwatywny cel (np. do midpoint dla wolniej rotujących produktów) może zmniejszyć nadmiary, podczas gdy budujesz zaufanie.
Na koniec trzymaj ślad audytu. Nawet proste „Ostatnio zmienione przez” i „Ostatnio zmienione o” na każdej linii buduje zaufanie i pomaga w rozwiązywaniu sporów.
Wyobraź sobie mały sklep sąsiedzki z 30 SKU. Właściciel robi fizyczny spis co poniedziałek i chce, żeby aplikacja tworzyła roboczą listę zakupów, którą szybko sprawdzi.
Kupuje od dwóch dostawców: Supplier A (przekąski i napoje) oraz Supplier B (artykuły gospodarstwa domowego).
SKU 1: Sparkling Water 12-pack (Supplier A)
On hand: 8 packs. Min: 10. Max: 30. Pack size: 6.
Ponieważ 8 jest poniżej min (10), aplikacja sugeruje uzupełnienie do max.
Potrzeba, aby osiągnąć max = 30 - 8 = 22 packs.
Zaokrąglając do pack size (6): 22 -> 24.
Sugerowane zamówienie: 24 packs.
SKU 2: Potato Chips (Supplier A)
On hand: 14 bags. Min: 12. Max: 36. Pack size: 12.
Ponieważ 14 jest powyżej min, sugestia to 0. Mimo że nie ma max, jest zdrowy i nie wymaga uzupełnienia w tym tygodniu.
SKU 3: Dish Soap 500 ml (Supplier B)
On hand: 3 bottles. Min: 6. Max: 18. Pack size: 6.
Ponieważ 3 jest poniżej min, zamawiamy do max.
Potrzeba, aby osiągnąć max = 18 - 3 = 15 bottles.
Zaokrąglając do pack size (6): 15 -> 18.
Sugerowane zamówienie: 18 bottles.
Szkic to punkt wyjścia, a nie rozkaz. W tym tygodniu właściciel ma mniejszy budżet i wie też, że sprzedaż wody gazowanej spowalnia, gdy pada deszcz.
Dostosowuje Sparkling Water z 24 packs do 18 packs (wciąż wielokrotność 6). Chips pozostają 0. Dish soap zostaje 18, bo to stabilny sprzedawca i wygląda ryzykownie.
Ten krok przeglądu i korekty jest powodem, dla którego szkic jest często bardziej użyteczny niż automatyczne wysyłanie zamówień.
Supplier A
Supplier B
Przy 30 SKU ten tygodniowy cykl może zająć około 10 minut: policzyć, przejrzeć sugestie, wprowadzić kilka edycji, a potem udostępnić pogrupowany szkic dostawcom.
Najszybszy sposób na uzyskanie wartości to start w wąskim zakresie. Wybierz jeden sklep (lub jedną lokalizację) i jedną grupę dostawców z zarządzalną liczbą SKU. Więcej nauczysz się z czystej, sprawdzonej listy niż starając się uwzględnić wszystkie przypadki od pierwszego dnia.
Zdecyduj wcześnie, jak będziesz zbierać stany on-hand. Ręczny wpis jest w porządku na start, jeśli tylko jest konsekwentny. Prosta zasada jak „stany aktualizowane w każdy czwartek przed zamówieniem” jest lepsza niż skomplikowana konfiguracja, której nikt nie będzie stosował.
Praktyczny plan wdrożenia:
Gdy podstawy działają, ulepszaj matematykę powoli. Dwa ulepszenia, które często szybko się zwracają: estymata średniego popytu (np. średnia tygodniowa sprzedaż z ostatnich 4 tygodni) i dodanie zapasu bezpieczeństwa w zależności od lead time. Jeśli dostawca potrzebuje 10 dni, podniesienie punktu ponownego zamówienia o dodatkowy tydzień popytu może pomóc uniknąć reakcji na opóźnienia.
Ustal rytm utrzymywania reguł: co tydzień przeglądaj sugerowane zamówienie i koryguj oczywiste błędy. Co miesiąc koryguj min/max, skupiając się na top moverach i największych ryzykach nadmiaru.
Jeśli budujesz to jako aplikację no-code, AppMaster (appmaster.io) jest jedną z opcji pasujących do workflow: zamodeluj SKU i dostawców w bazie, wrzuć logikę min/max do procesu wizualnego i generuj robocze zamówienia, które personel może przeglądać i zatwierdzać zanim cokolwiek zostanie wysłane.
What is a min/max reorder system in plain terms?System min/max przechowuje dwa poziomy dla każdego SKU: minimum, poniżej którego nie chcesz schodzić, oraz maksimum, do którego chcesz uzupełnić zapas. Gdy stan magazynowy osiągnie lub spadnie poniżej minimum, aplikacja sugeruje ilość do zamówienia, aby doprowadzić zapas z powrotem w kierunku maksimum.
When should the app actually suggest reordering an item?Stosuj jedną jasną zasadę i trzymaj się jej: wygeneruj sugestię, gdy stan magazynowy jest równy lub niższy niż min (lub Twój punkt ponownego zamówienia, jeśli go używasz). Jeśli stan jest powyżej tego progu, sugerowana ilość powinna wynosić zero, aby lista robocza pozostała czytelna i łatwa do przeglądu.
How do you calculate the suggested quantity?Najprostsze obliczenie to suggested = max(0, max_level - on_hand) po tym, jak przedmiot kwalifikuje się do ponownego zamówienia. To utrzymuje wyniki proste do wyjaśnienia, bo po prostu uzupełniasz do ustalonego celu.
Should I include items already on order in the math?Tak — jeśli rzetelnie śledzisz "on order", odejmij je od zapotrzebowania, aby nie dublować zamówień. Częstym podejściem jest traktowanie dostępnego zapasu jako on_hand + on_order, a następnie obliczanie potrzebnej ilości z użyciem tej sumy.
How do case packs and rounding work in a reorder app?Zaokrąglaj sugestie do tego, co faktycznie można kupić, i pokaż wyraźnie liczbę po korekcie. Na przykład, jeśli dostawca sprzedaje w opakowaniach po 12, obliczona potrzeba 32 powinna stać się 36, jeśli polityka to zaokrąglanie w górę, żeby uniknąć braków.
What should happen if a SKU is missing min/max settings?Nie zgaduj i nie twórz cichych zamówień. Jeśli brakuje min lub max, ustaw sugestię na 0 i oznacz SKU jako wymagające konfiguracji, tak żeby ktoś poprawił dane zanim wpłyną one na zakupy.
How should the app handle negative inventory counts?Traktuj ujemny stan jako sygnał ostrzegawczy, a nie normalne wejście. Nadal możesz policzyć sugestię, aby kupiec zobaczył ryzyko, ale interfejs powinien wyróżnić ten wpis, sugerując przeliczenie lub sprzątnięcie transakcji.
Do I need to track inventory by location (back room vs shelf, multiple stores)?Jeśli masz więcej niż jedno miejsce, w którym może znajdować się zapas, śledź je oddzielnie; w przeciwnym razie Twoje sugestie będą błędne nawet przy poprawnych min/max. Minimum to rozdzielenie półki i zaplecza, a później rozszerzenie do oddzielnych lokalizacji sklepów i magazynów.
How do I make reorder suggestions auditable and trustworthy?Zapisz snapshot danych użytych do wygenerowania roboczej listy — wartości on-hand, min/max w tym momencie i kto zatwierdził edycje. Dzięki temu pytanie „dlaczego zamówiliśmy 24 sztuki tego?” da się łatwo rozstrzygnąć i zwiększa to zaufanie do systemu.
Can this workflow stay manual but still save time, and can I build it in AppMaster?Zachowaj zatwierdzanie zakupów wykonywane przez ludzi jako domyślny proces: generuj robocze zamówienie, pozwól edytować ilości, potem oznacz jako zatwierdzone i wyeksportuj lub skopiuj finalną listę. Taką logikę można zbudować w AppMaster (appmaster.io) modelując SKU i robocze zamówienia w bazie i wkładając logikę min/max do procesu biznesowego, który tworzy pogrupowane linie zamówienia do przeglądu.
21 sty 2026
8 min
20 sty 20268 min
20 sty 20268 minEksperymentuj z AppMaster z darmowym planem.
Kiedy będziesz gotowy, możesz wybrać odpowiednią subskrypcję.
