Proces statusów zamówień w PrestaShop: dostosowanie i automatyzacja

To ta część PrestaShop, która po cichu napędza całe zaplecze sklepu, choć prawie nikt nie konfiguruje jej świadomie: status zamówienia. Każde zamówienie ma w danym momencie dokładnie jeden status, a ta jedna wartość decyduje o tym, co klient widzi na swoim koncie, czy stan magazynowy został pomniejszony, czy istnieje faktura i który e-mail właśnie trafił do jego skrzynki. Zostaw domyślne ustawienia bez zmian, a przy większym ruchu sklep zacznie działać na domysłach. Dopasuj statusy do tego, jak naprawdę realizujesz zamówienia, a ten sam panel administracyjny zacznie podpowiadać zespołowi kolejny krok — i informować klientów, co się dzieje, zanim zdążą napisać z pytaniem. Ten poradnik pokazuje, jak zrobić to konkretnie w PrestaShop: co naprawdę uruchamia każdy domyślny status, jak zbudować własny w Parametry sklepu → Statusy, co kryje się pod spodem w tabeli ps_order_state i jak automatyzować przejścia, żeby członkowie zespołu przestali pełnić rolę żywego wyzwalacza bazy danych.

Ostatnia aktualizacja: czerwiec 2026.

Czym naprawdę jest status zamówienia w PrestaShop

Status zamówienia w PrestaShop to nie tylko etykieta. Każdy status jest wierszem w tabeli ps_order_state (z tłumaczalną nazwą w ps_order_state_lang), a ten wiersz zawiera zestaw flag logicznych, które mówią rdzeniowi, co ma zrobić, gdy zamówienie wejdzie w ten stan: wygenerować fakturę lub nie, oznaczyć zamówienie jako opłacone, oznaczyć je jako wysłane, udostępnić PDF dostawy, wysłać e-mail. (Pomniejszenie stanu magazynowego nie jest jedną z tych flag — PrestaShop zmniejsza dostępny stan, gdy zamówienie zostaje zatwierdzone/utworzone, a nie wtedy, gdy uruchamia się flaga statusu; więcej o tym poniżej). Bieżący status zamówienia znajduje się w ps_orders.current_state, a dodatkowo PrestaShop dopisuje nowy wiersz do ps_order_history za każdym razem, gdy status się zmienia, więc zamówienie zachowuje także pełną, opatrzoną datami historię audytową wszystkich stanów, przez które przeszło. „Bieżący status” widoczny w panelu administracyjnym to wartość w current_state, a ps_order_history zapisuje, jak zamówienie do niej doszło.

Praktyczny wniosek dla właściciela sklepu: lista statusów to miejsce, w którym mieszka logika operacyjna. Ustaw flagi raz i poprawnie, a PrestaShop będzie egzekwować je dla każdego kolejnego zamówienia — nikt z zespołu nie musi pamiętać, że „fakturę generujemy po zaksięgowaniu płatności, nie wcześniej”. Ustaw je źle, a możesz po cichu wystawiać faktury do zamówień, których nikt nie opłacił. Do tej pułapki wrócimy niżej.

Domyślne statusy zamówień — i co każdy z nich naprawdę uruchamia

PrestaShop dostarcza gotowy zestaw statusów. Wielu sprzedawców traktuje je jak dekorację; w praktyce każdy z nich uruchamia konkretne działania w bazie danych w chwili, gdy zamówienie na niego trafia. Oto co naprawdę dzieje się pod spodem.

Oczekiwanie na płatność czekiem

Stosowany, gdy klient wybiera płatność czekiem przy kasie. Zamówienie istnieje, ale pieniądze jeszcze nie dotarły. Zamówienie zostaje zatwierdzone przy złożeniu, więc dostępny stan magazynowy jest wtedy obsługiwany zgodnie z ustawieniami magazynu — ten status nie „rezerwuje” go osobno — faktura nie jest generowana, a zamówienie czeka tutaj, aż ręcznie potwierdzisz zaksięgowanie czeku. Nic nie przechodzi dalej samo — tak ma być.

Oczekiwanie na przelew bankowy

Odpowiednik dla przelewu bankowego. Klient widzi Twój IBAN/BIC i numer zamówienia, dostępny stan magazynowy jest obsługiwany podczas zatwierdzania zamówienia zgodnie z ustawieniami magazynu, a zamówienie pozostaje tutaj, dopóki nie oznaczysz go jako opłacone — zwykle po jednym do trzech dni roboczych, gdy przelew dotrze. To status, który najbardziej warto zautomatyzować (więcej w sekcji o automatyzacji), bo ręczne potwierdzanie przelewów to czysta, powtarzalna administracja.

Płatność zaakceptowana

To status kluczowy. Gdy zamówienie osiąga Płatność zaakceptowana, PrestaShop:

• Generuje fakturę (jeśli status ma flagę faktury — domyślnie ma);
• Oznacza zamówienie w bazie danych jako opłacone;
• Wysyła klientowi e-mail statusowy.

Zwróć uwagę, czego ten status nie robi: nie pomniejsza stanu magazynowego. Dostępny stan zostaje zmniejszony, gdy zamówienie jest tworzone/zatwierdzane przy kasie — co dzieje się nawet dla zamówień pozostających w Oczekiwaniu na płatność — więc ruch magazynowy zwykle nastąpił już zanim zamówienie kiedykolwiek trafi do Płatność zaakceptowana.

Przy płatnościach przez bramki — PayPal, Stripe, Mollie — moduł płatności ustawia ten status automatycznie w chwili, gdy bramka potwierdzi obciążenie. Nie dotykasz go ręcznie. Właśnie takie automatyczne, sterowane kodem przejście warto odtworzyć dla ręcznych metod płatności.

W trakcie realizacji / W trakcie przygotowania

Opcjonalny status pośredni, który mówi: „magazyn kompletuje i pakuje zamówienie”. Nie uruchamia żadnych automatycznych działań — cała jego wartość polega na koordynacji ludzi. Niektóre sklepy go pomijają; sklepy o dużej liczbie zamówień uznają go za niezbędny, bo pozwala od razu odróżnić kolejkę do pakowania od kolejki zamówień nieopłaconych.

Wysłane

Stosowany, gdy paczka opuszcza sklep. Uruchamia e-mail z potwierdzeniem wysyłki (w tym numer śledzenia, jeśli został podany) i udostępnia dokument dostawy. Kolejność ma znaczenie: wpisz numer śledzenia w sekcji Przewoźnicy zamówienia zanim przełączysz status na Wysłane, inaczej e-mail wyjdzie bez linku do śledzenia, a i tak dostaniesz wiadomość „gdzie jest moja paczka?”.

Dostarczone

Oznacza, że klient otrzymał towar — ustawiane ręcznie albo przez integrację z API przewoźnika. W UE to moment, od którego zaczyna biec 14-dniowy termin zwrotu przy sprzedaży na odległość, więc dokładne daty doręczenia nie są kosmetyką; to zegar, według którego działa Twoja polityka zwrotów.

Anulowane

Anulowanie zamówienia może ponownie zwiększyć dostępny stan magazynowy produktów z zamówienia (w ramach normalnego mechanizmu zarządzania magazynem PrestaShop, ponieważ stan został już zmniejszony przy złożeniu zamówienia), a klient otrzymuje e-mail o anulowaniu. Dwie rzeczy, których ten status nie robi automatycznie: nie zwraca pieniędzy (to wykonujesz osobno) i nie usuwa faktury, jeśli została już wygenerowana. Jeśli faktura istnieje, wystaw korektę zamiast udawać, że faktura nigdy się nie wydarzyła — księgowość Ci za to podziękuje.

Zwrócone

Stosowany po obsłużeniu zwrotu środków. Samo nadanie tej etykiety statusu nie tworzy korekty — jest ona generowana przez proces zwrotu (panel Zwrot standardowy / Zwrot częściowy / Zwróć produkty), gdy zaznaczysz opcję jej wygenerowania. To, czy produkty wrócą do stanu nadającego się do sprzedaży, również zależy od tego, jak obsłużysz zwrot w tym panelu.

Błąd płatności

Ustawiany, gdy próba płatności się nie powiedzie — odrzucona karta, niewystarczające środki, nieudany etap 3-D Secure. Stan magazynowy nie jest pomniejszany, faktura nie jest generowana. To, czy klient zostanie o tym poinformowany, zależy wyłącznie od modułu płatności.

Na zamówienie (opłacone / nieopłacone)

Dla sklepów, które przyjmują zamówienia, choć nie mogą ich jeszcze wysłać. Zamówienie jest przyjęte, ale realizacja czeka na uzupełnienie zapasów. Warianty „opłacone” i „nieopłacone” pozwalają uczciwie prowadzić stan płatności, gdy towar dopiero do Ciebie jedzie.

Odczytywanie statusów w bazie danych

Nie musisz dotykać SQL, żeby prowadzić sklep, ale znajomość kształtu danych pomaga zrozumieć ekrany administracyjne — i to na niej opiera się każda automatyzacja. Liczą się trzy tabele:

Ponieważ każda zmiana statusu dopisuje nowy wiersz ps_order_history (równolegle z aktualizacją current_state w zamówieniu), historia nigdy nie jest destrukcyjnym nadpisaniem — to ślad audytowy. Dlatego zawsze widzisz, przez co przeszło zamówienie, i dlatego nieostrożna masowa aktualizacja SQL statusów zamówień jest groźna: zapisując bezpośrednio do tabel, omijasz każdą flagę, e-mail i ruch magazynowy, które normalnie uruchomiłby rdzeń. Wspierany sposób przeniesienia zamówienia w kodzie prowadzi przez obiekt zamówienia, a nie surowe UPDATE-y. Do właściwych hooków wrócimy w sekcji dla deweloperów.

Tworzenie własnych statusów zamówień

Przejdź do Parametry sklepu → Statusy (w PrestaShop 1.6 ten ekran znajdował się w Zamówienia → Statusy). Kliknij Dodaj nowy status zamówienia, a konfigurujesz jeden z tych wierszy ps_order_state z poziomu interfejsu. Najważniejsze pola:

• Nazwa statusu: to, co Twój zespół czyta na liście zamówień. „Oczekiwanie na dostawcę” zawsze wygrywa ze „Status 7” — jasność w tym miejscu usuwa całą kategorię pytań „co ten status właściwie znaczy?”.
• Ikona i kolor: wizualna wskazówka na liście zamówień. Wybierz konwencję i trzymaj się jej: zielony dla spraw w porządku, pomarańczowy dla oczekujących, czerwony dla problemów. Sprzedawca powinien móc wstępnie ocenić listę zamówień po kolorach nawet z drugiego końca pokoju.
• Flagi zachowania — to prawdziwy silnik:
  • Uznaj powiązane zamówienie za zatwierdzone: wlicza zamówienie do statystyk sprzedaży.
  • Pozwól klientowi pobierać i przeglądać wersje PDF faktur: kontroluje widoczność faktury na koncie klienta.
  • Ustaw zamówienie jako opłacone: informuje resztę PrestaShop, że pieniądze zostały otrzymane.
  • Pokaż PDF dostawy / Ustaw zamówienie jako wysłane: oznacza towar jako wysłany i udostępnia dokument dostawy.
  • Wygeneruj fakturę: tworzy PDF faktury przy tym przejściu.
  • Wyślij e-mail do klienta, gdy status zamówienia się zmieni: wyzwalacz, który zmienia status w powiadomienie dla klienta.
• Szablon e-maila: która wiadomość zostanie wysłana, gdy flaga e-maila jest włączona.

Co z tego wynika? Te flagi są różnicą między statusem, który jest tylko kolorem, a statusem, który po cichu robi porządek w operacjach i księgowości. Ustaw je świadomie, a PrestaShop zrobi właściwą rzecz przy każdym przyszłym zamówieniu bez nadzoru z czyjejkolwiek strony.

Własne statusy, które widujemy najczęściej

W codziennej pracy ze sklepami PrestaShop najczęściej na swoje miejsce zasługują takie własne statusy:

• Oczekiwanie na dostawcę: zamówienie opłacone, ale jeden z produktów trzeba zamówić. Bez e-maila do klienta — to flaga wewnętrzna, nie informacja, której klient potrzebuje.
• Gotowe do odbioru: dla odbioru osobistego. E-mail włączony, z adresem, godzinami odbioru i informacją, co zabrać ze sobą.
• Częściowo wysłane: część produktów wyszła, część jeszcze czeka. W e-mailu poinformuj klienta, co zostało wysłane i co pozostaje do realizacji.
• Do weryfikacji: zamówienia o wysokiej wartości lub oznaczone jako podejrzane, zatrzymane do ręcznego sprawdzenia. Bez e-maila do klienta.
• Oczekiwanie na odpowiedź klienta: skontaktowałeś się z klientem (poprawka adresu, pytanie o produkt), a zamówienie czeka na jego odpowiedź.
• Zwrot zgłoszony / Zwrot otrzymany: dwie połowy RMA — klient zgłosił zwrot, a później paczka wróciła do Ciebie do sprawdzenia.

Wyzwalacze e-maili dla poszczególnych statusów

Gdy status ma włączoną flagę e-maila, PrestaShop wysyła klientowi szablon przypisany do tego statusu. Szablony znajdują się w /mails/LANGUAGE_CODE/ jako pary plików HTML i TXT (wersja tekstowa jest zapasowa dla klientów pocztowych blokujących HTML, więc obie muszą istnieć).

Podpinanie e-maila do własnego statusu

Włącz e-mail dla własnego statusu, a odpowiadasz za szablon — inaczej wysyłka po cichu zakończy się błędem w logach. Żeby podpiąć go poprawnie:

• Utwórz pasujące pliki HTML i TXT w każdym folderze językowym pod /mails/ — nazwa szablonu musi zgadzać się z tym, czego oczekuje status.
• Użyj ponownie zmiennych, które rdzeń już udostępnia: {firstname}, {lastname}, {order_name}, {id_order}, {shipping_number} dla śledzenia przesyłki i pozostałych.
• Ustaw wygląd raz w Wygląd → Motyw e-maili, zamiast ręcznie edytować każdy plik.

Jeśli wolisz w ogóle nie tworzyć szablonów, naprawdę częsty przypadek to po prostu ponowne wysłanie e-maila z zamówieniem, który klient zgubił. PrestaShop potrafi ponownie wysłać istniejące potwierdzenie bezpośrednio ze strony zamówienia — dokładnie pokazujemy, gdzie jest ten przycisk, w poradniku jak ponownie wysłać e-mail z potwierdzeniem zamówienia.

Wysyłaj właściwe e-maile, nie wszystkie

• Nie zalewaj klientów e-mailami. Klienci nie chcą wiadomości przy każdym wewnętrznym przeskoku. „W trakcie przygotowania” jest dla Twojego zespołu, nie dla ich skrzynki. Zostaw e-maile na momenty, które naprawdę ich obchodzą: płatność potwierdzona, wysyłka (ze śledzeniem), doręczenie.
• Każdy e-mail powinien prowadzić do działania. E-mail o wysyłce zawiera numer śledzenia i link; e-mail o gotowości do odbioru zawiera adres, godziny i informację, co zabrać. Wiadomość bez następnego kroku zwykle tylko generuje odpowiedź.
• Ustaw oczekiwania. Przy zamówieniu oczekującym na dostawę towaru podaj czas oczekiwania. Mgliste „status zamówienia się zmienił” bez szczegółów to zgłoszenie do obsługi klienta, które dopiero czeka na utworzenie.

Automatyzowanie zmian statusów

Ręczne zarządzanie statusami działa przy dziesięciu czy dwudziestu zamówieniach dziennie. Powyżej tego poziomu każde ręczne przejście to czas, za który płacisz, i szansa, że ktoś zapomni kroku. Możliwości, z grubsza według opłacalności:

Potwierdzenie płatności

Bramki kartowe już to automatyzują — PayPal, Stripe i Mollie przenoszą zamówienie do Płatność zaakceptowana po potwierdzeniu, bez udziału człowieka. Luka dotyczy przelewów bankowych i czeków, gdzie zostaje ręczne potwierdzanie, integracja z wyciągiem bankowym dopasowująca przychodzące przelewy do zamówień po tytule albo zaplanowana kontrola względem webhooka bramki. Zamknięcie tej luki to zwykle największa pojedyncza oszczędność czasu w całym procesie zamówienia.

Wysyłka

Moduł integracji z przewoźnikiem (Colissimo, DHL, Mondial Relay i podobne) powinien przełączyć zamówienie na Wysłane i zapisać numer śledzenia w chwili wydruku etykiety. Jeśli Twój moduł tego nie robi, ustawienie, które to włącza, prawie zawsze istnieje w module — po prostu domyślnie jest wyłączone.

Potwierdzenie doręczenia

API przewoźników może raportować doręczenie. Zaplanowane zadanie, które codziennie odpytuje API i przenosi potwierdzone paczki do Dostarczone, utrzymuje unijny zegar zwrotów w porządku bez ręcznego śledzenia przesyłek. To klasyczny teren dla zadań cron — ustawiasz raz, a potem działa, gdy śpisz.

Automatyzacja procesu oparta na regułach

Dla logiki „jeśli to, wtedy tamto”, której rdzeń nie obejmuje — jeśli metodą płatności jest przelew bankowy, a suma przekracza 500 EUR, ustaw Do weryfikacji i powiadom administratora — lepsza jest automatyzacja statusów oparta na regułach niż własny kod, który rozsypie się przy kolejnej aktualizacji. Właśnie do takich warunkowych procesów nasz zespół buduje moduły na mypresta.rocks: definiujesz warunki i działania z panelu administracyjnego, a PrestaShop sam prowadzi każde zamówienie właściwą ścieżką. Korzyścią nie jest „automatyzacja” jako modne hasło — chodzi o to, że wąskim gardłem przestaje być osoba, która musi siedzieć przy biurku.

Hooki statusów zamówień dla deweloperów

Jeśli budujesz automatyzację samodzielnie, PrestaShop uruchamia hooki wokół każdej zmiany statusu, więc nigdy nie musisz pisać bezpośrednio do tabel:

• actionOrderStatusUpdate: uruchamia się w trakcie stosowania zmiany statusu. To hook o charakterze powiadomienia, więc traktuj go jako miejsce na własną walidację i logikę modułu wokół przejścia, a nie jako gwarantowany, wspierany przez rdzeń sposób na czyste zablokowanie przejścia.
• actionOrderStatusPostUpdate: uruchamia się po zatwierdzeniu zmiany — dobre miejsce na dalsze działania, takie jak synchronizacja zamówienia z ERP albo platformą wysyłkową.
• actionOrderHistoryAddAfter: uruchamia się po zapisaniu nowego wiersza ps_order_history — przydatne do własnego logowania i ścieżek audytowych.

Typowy wzorzec: przy przejściu do Wysłane wyślij webhook do API partnera realizacyjnego; przy przejściu do Dostarczone zaplanuj e-mail z prośbą o opinię na siedem dni później. Ponieważ przenosisz zamówienie przez jego obiekt i nasłuchujesz tych hooków, każda flaga, e-mail i ruch magazynowy należące do rdzenia nadal uruchamiają się poprawnie — i właśnie dlatego sięgasz po hooki zamiast surowego SQL UPDATE na ps_order_state.

Edytowanie i poprawianie zamówień po drodze

Statusy opisują, gdzie zamówienie jest; równie często musisz zmienić to, co jest w zamówieniu — poprawić ilość, podmienić adres, dodać rabat po fakcie. PrestaShop pozwala edytować złożone zamówienie z jego strony szczegółów, z realnymi ograniczeniami po utworzeniu faktury. Pełny opis tego, co i kiedy można bezpiecznie zmienić, znajdziesz w poradniku jak edytować zamówienie po jego złożeniu, a szerszą codzienną pracę z listą zamówień — filtrowanie, akcje masowe, statusy w kontekście — omawiamy w naszym kompletnym przewodniku po zarządzaniu zamówieniami w PrestaShop.

Obsługa częściowych wysyłek

Częściowe wysyłki to najtrudniejszy proces, jaki domyślne mechanizmy PrestaShop są w stanie obsłużyć. Rdzeń po cichu zakłada, że jedno zamówienie oznacza jedną wysyłkę: natywna obsługa częściowych wysyłek jest ograniczona, a dokumenty dostawy są dokumentami na poziomie zamówienia — PrestaShop nie modeluje czysto częściowych wysyłek na poziomie pozycji od razu po instalacji. Działające podejście ręczne wygląda tak:

• Utwórz własny status Częściowo wysłane;
• Zapisz numer śledzenia dla produktów wysyłanych teraz;
• Gdy reszta będzie gotowa, wyślij ją pod nowym numerem śledzenia;
• Przenieś zamówienie do Wysłane dopiero wtedy, gdy wszystko opuści magazyn.

Punkt tarcia: domyślna strona szczegółów zamówienia nie śledzi natywnie, które produkty trafiły do której paczki, a wygenerowanie dokumentu dostawy dla pojedynczej wysyłki obejmującego tylko produkty z tej paczki nie jest natywną operacją. Sklepy, które regularnie dzielą zamówienia, potrzebują własnego procesu albo modułu do prawdziwego śledzenia wysyłek per produkt i dokumentów ponad możliwościami rdzenia — inaczej historia zamówienia mówi, że coś wysłano, ale nie mówi co.

Procesy zamówień B2B

Realizacja B2B nie idzie ścieżką B2C, a lista statusów to miejsce, w którym zapisujesz tę różnicę:

• Oferta i akceptacja: zamówienia wymagające zatwierdzenia przed płatnością, modelowane jako „Oferta wysłana” → „Oferta zaakceptowana” → „Oczekiwanie na płatność” → „Płatność zaakceptowana”.
• Zamówienia zakupu: terminy Net 30/60/90 oznaczają, że realizacja i pobranie płatności mają dwa osobne zegary; statusy muszą śledzić oba, nie mieszając ich ze sobą.
• Częściowe wysyłki: wielopozycyjne zamówienia B2B z różnymi terminami dostępności rutynowo opierają się na opisanej wyżej konfiguracji częściowych wysyłek, nie tylko w wyjątkowych przypadkach.
• Egzekwowanie minimum zamówienia: zamówienia poniżej progu mogą przechodzić przez „Do weryfikacji”, zanim ktokolwiek zacznie je kompletować.

Raportowanie na podstawie statusów

Ponieważ każde przejście jest datowanym wierszem w ps_order_history, dane statusów są Twoim raportowaniem operacyjnym — za darmo, jeśli tylko na nie spojrzysz:

• Czas w każdym statusie: to, jak długo zamówienia pozostają w Płatność zaakceptowana przed Wysłane, jest dosłownie szybkością realizacji.
• Rozkład statusów: rosnąca sterta w „Oczekiwaniu na dostawcę” to problem z zaopatrzeniem widoczny wcześniej, niż dostawca się do niego przyzna.
• Anulowania według etapu: jeśli zamówienia nieproporcjonalnie często odpadają na jednym statusie, ten etap procesu ma nieszczelność.
• Pełny cykl życia: od złożenia do doręczenia, śledzony w czasie, pokazuje, czy działasz szybciej, czy po cichu zwalniasz.

Najczęstsze błędy, których warto unikać

• Za dużo statusów. Powyżej mniej więcej tuzina nikt ich nie pamięta, a lista przestaje pomagać w selekcji. Jeśli zespół nie potrafi ich wyrecytować, masz ich za dużo.
• Niejasne nazwy. „Status A” i „Status B” nikomu nic nie mówią. Nazywaj statusy według tego, co znaczą.
• Własny status z włączonym e-mailem, ale bez szablonu. To przypadek cichej awarii — wysyłka umiera w logach, a klient nie słyszy nic.
• Nieprzeszkolony zespół. Najczystszy proces jest bezużyteczny, jeśli zespół nie wie, kiedy zastosować który status. Jednostronicowa ściąga szybko się zwraca.
• Pułapka flagi faktury. Włącz Wygeneruj fakturę dla statusu, który nie oznacza potwierdzonej płatności, a zaczniesz wystawiać faktury do zamówień, za które nikt nie zapłacił — realny bałagan księgowy i podatkowy do odkręcenia. Sprawdź tę flagę dwa razy przed zapisem.

Uwaga o zamówieniach testowych

Gdy będziesz to wszystko budować, będziesz składać zamówienia testowe, żeby zobaczyć, jak uruchamiają się statusy i e-maile — a każde z nich zaśmieca statystyki, numerację faktur i ps_order_history, jeśli je zostawisz. Usuń je przed startem sprzedaży; bezpieczny sposób ich usuwania (i wyjaśnienie, dlaczego nie warto po prostu robić DELETE na wierszach) znajdziesz w poradniku jak usunąć zamówienia testowe w PrestaShop.

Najczęściej zadawane pytania

Gdzie dodać własny status zamówienia w PrestaShop?

Przejdź do Parametry sklepu → Statusy, a następnie kliknij Dodaj nowy status zamówienia. W PrestaShop 1.6 ten sam ekran znajdował się w Zamówienia → Statusy. Każdy utworzony status jest wierszem w tabeli ps_order_state, a pola wyboru w tym formularzu (opłacone, wysłane, wygeneruj fakturę, wyślij e-mail) są flagami zachowania, które rdzeń uruchamia za każdym razem, gdy zamówienie trafi na ten status.

Czy zmiana statusu zamówienia na „Płatność zaakceptowana” pomniejsza stan magazynowy?

Nie. Dostępny stan magazynowy jest zmniejszany, gdy zamówienie zostaje zatwierdzone/utworzone przy kasie — co dzieje się nawet wtedy, gdy zamówienie pozostaje w „Oczekiwaniu na płatność” — a nie wtedy, gdy uruchamia się flaga opłacenia. Zanim zamówienie trafi do Płatność zaakceptowana, ruch magazynowy zwykle już nastąpił. Status opłacenia generuje fakturę, oznacza zamówienie jako opłacone i wysyła e-mail statusowy; nie dotyka magazynu.

Dlaczego e-mail z mojego własnego statusu nigdy nie został wysłany?

Prawie zawsze brakuje szablonu. Gdy włączasz flagę e-maila dla statusu, PrestaShop szuka plików HTML i TXT o pasującej nazwie w /mails/LANGUAGE_CODE/ w każdym folderze językowym. Jeśli te pliki nie istnieją, wysyłka po cichu kończy się błędem w logach, a klient nie dostaje nic. Utwórz sparowane szablony HTML/TXT dla każdego języka, zanim zaczniesz polegać na tym e-mailu.

Czy mogę zmienić status zamówienia z kodu bez pisania SQL?

Tak — i właśnie tak należy to robić. Przenieś zamówienie przez jego obiekt zamówienia, żeby każda flaga, e-mail i ruch magazynowy nadal się uruchamiały, i nasłuchuj hooków, które udostępnia PrestaShop: actionOrderStatusUpdate (gdy zmiana jest stosowana), actionOrderStatusPostUpdate (po zatwierdzeniu zmiany — dobre do synchronizacji z ERP/wysyłką) oraz actionOrderHistoryAddAfter (po zapisaniu wiersza historii). Surowy UPDATE na ps_order_state omija to wszystko i tak kończy się fakturami oraz e-mailami niespójnymi ze stanem zamówienia.

Jak uniknąć generowania faktur dla nieopłaconych zamówień?

Pilnuj flagi Wygeneruj fakturę. Jeśli włączysz ją dla statusu, który nie oznacza potwierdzonej płatności, PrestaShop zacznie wystawiać faktury do zamówień, za które nikt nie zapłacił — realny bałagan księgowy i podatkowy do odkręcenia. Powiąż generowanie faktury wyłącznie ze statusem potwierdzonej płatności i sprawdź to pole dwa razy przed zapisaniem nowego statusu.

Czy mogę automatyzować zmiany statusów dla przelewów bankowych i reguł warunkowych?

Bramki kartowe już automatycznie przenoszą zamówienia do Płatność zaakceptowana; luka dotyczy przelewów bankowych, czeków i logiki warunkowej typu „jeśli przelew bankowy i suma powyżej 500 EUR, ustaw Do weryfikacji”. Właśnie taki proces oparty na regułach obsługuje nasz moduł automatyzacji procesu zamówień z poziomu panelu administracyjnego, dzięki czemu wąskim gardłem przestaje być osoba, która musi siedzieć przy biurku i ręcznie przełączać statusy.

Dobrze ułożony proces statusów zamówień to kręgosłup spokojnego zaplecza: zespół wie, co zrobić dalej, klient słyszy właściwą informację we właściwym momencie, a księgowość pozostaje czysta, bo to flagi — nie zmęczony człowiek o 18:00 — decydują, kiedy istnieje faktura i kiedy rusza magazyn. Zaplanuj proces, zanim go podepniesz, bo gdy zamówienia zaczną już przepływać przez statusy, zmienianie ich w trakcie działania będzie znacznie bardziej uciążliwe niż dobre ustawienie ich od początku. Gdy ręczne przejścia przestaną wystarczać, automatyzacja oparta na regułach z mypresta.rocks zdejmie z zespołu powtarzalne przełączanie statusów, żeby każde zamówienie szło tą samą ścieżką od złożenia do doręczenia — za każdym razem, niezależnie od tego, czy ktoś akurat na nie patrzy.