Zaplanowane rabaty: promocje, które włączają się i kończą automatycznie

Ostatnia aktualizacja: czerwiec 2026. Zweryfikowano dla PrestaShop 1.7, 8 i 9. Uwaga dotycząca PS9: zaplecze rabatów jest ujednolicane do czterech typów rabatów (Catalog, Cart, Free-Shipping, Free-Gift) za flagą funkcji, ale każdy typ nadal ma zakres dat, na którym opiera się ten poradnik.

Jest 23:00 w czwartek, a Ty przypominasz sobie, że promocja na Black Friday miała wystartować o północy. W pośpiechu tworzysz reguły koszyka i zmieniasz ceny, licząc, że pod presją nie pomylisz miejsca po przecinku. Albo spokojniejsza wersja tego samego błędu: ustawiasz w piątek rabat „tylko na weekend”, zapominasz o nim w poniedziałek i przez kolejne trzy dni oddajesz marżę, zanim ktokolwiek to zauważy. Obie sytuacje mają tę samą przyczynę. Człowiek jest przełącznikiem włącz/wyłącz.

PrestaShop może być tym przełącznikiem za Ciebie. Oba mechanizmy rabatowe platformy, reguły koszyka i ceny specyficzne, mają własne znaczniki czasu rozpoczęcia i zakończenia, a sklep sprawdza je przy każdym wczytaniu strony. Ustawiasz daty raz, a promocja sama się włącza i wyłącza, niezależnie od tego, czy akurat czuwasz. Ten poradnik dotyczy właśnie tej warstwy planowania: gdzie znajdują się pola dat, jak PrestaShop decyduje, czy rabat jest w danej chwili „aktywny”, jaka pułapka strefy czasowej potrafi po cichu przesunąć start oraz jakie treści trzeba zaplanować razem z ceną. Jeśli chcesz najpierw ustalić, który typ rabatu wybrać, zobacz prowadzenie wyprzedaży w PrestaShop; jeśli interesuje Cię, kiedy w roku je uruchamiać, sprawdź kalendarz wyprzedaży sezonowych.

Jak PrestaShop naprawdę decyduje, że rabat jest „aktywny”

Warto wiedzieć, co dzieje się pod spodem, bo od tego zależy wszystko, co następuje dalej. PrestaShop nie uruchamia o północy zadania harmonogramu, które przełącza promocję. Nie ma zadania cron, nie ma kolejki. Zamiast tego zarówno reguły koszyka, jak i ceny specyficzne przechowują w bazie danych pola date_from i date_to, a cena jest przeliczana w chwili żądania: gdy klient otwiera stronę produktu albo odświeża koszyk, rdzeń porównuje te znaczniki czasu z teraz i uwzględnia rabat tylko wtedy, gdy bieżąca chwila mieści się w tym oknie.

Co to oznacza w praktyce? Trzy rzeczy. Po pierwsze, aktywacja jest natychmiastowa i niezawodna. Nie ma zadania, które mogłoby się nie uruchomić, więc promocja ustawiona na 00:00 faktycznie startuje o 00:00. Po drugie, „teraz” jest oceniane według konfiguracji strefy czasowej sklepu/środowiska PHP, a nie lokalnej strefy czasowej odwiedzającego (o tej pułapce niżej). Po trzecie, ponieważ cena jest liczona na żywo, a potem cache'owana, promocja, która powinna już wystartować, może nadal pokazywać starą cenę do czasu przebudowania cache strony. Dlatego agresywny cache pełnych stron i zaplanowane rabaty trzeba ze sobą pogodzić, co omawiamy dalej.

Planowanie reguły koszyka (Katalog → Rabaty)

Reguły koszyka to silnik kuponów w PrestaShop, zarówno kodów wpisywanych przez klienta, jak i automatycznych rabatów, które stosują się po cichu po spełnieniu warunków. Utworzysz je w Katalog → Rabaty → Nowa reguła koszyka (w PrestaShop 1.6 ścieżka to Reguły cenowe → Reguły koszyka). Aby ją zaplanować, otwórz kartę Warunki i ustaw pola Ważny od / Ważny do:

• Ważny od, data i godzina, od której reguła staje się dostępna. Przechowywana jako date_from.
• Ważny do, data i godzina wygaśnięcia reguły. Przechowywana jako date_to.

W tym oknie reguła działa; poza nim kod zostanie odrzucony komunikatem „ten kupon jest nieważny”, a reguła automatyczna po prostu się nie zastosuje. Dwa pola, które sprzedawcy często pomijają, warto ustawić świadomie:

• Łącznie dostępne i Łącznie dostępne dla każdego użytkownika, limity użycia. Zaplanowany zakres dat odpowiada na pytanie „kiedy”; te pola odpowiadają na pytanie „ile razy”, czyli pomagają zatrzymać nadużycia, jeśli kod wycieknie w trakcie całego okna promocji.
• Wyróżnij i Częściowe użycie, na karcie Akcje. Wyróżnienie podpowiada klientowi w koszyku pasujący kupon; częściowe użycie decyduje, czy niewykorzystana reszta kuponu kwotowego przechodzi na kolejne zamówienie.

Jedna rzecz, przed którą zaplecze Cię nie zatrzyma: ustawienie „Ważny do” wcześniej niż „Ważny od”. Nie ma zabezpieczenia, reguła po prostu nigdy się nie aktywuje, a dowiesz się o tym dopiero z maila od klienta pytającego, dlaczego EARLY20 nie działa. Przeczytaj obie daty jeszcze raz przed zapisaniem.

Planowanie obniżki ceny produktów (ceny specyficzne)

Reguły koszyka obniżają wartość koszyka. Jeśli chcesz pokazać na stronie produktu przekreśloną cenę, klasyczną prezentację wyprzedaży, stara cena przekreślona, nowa cena na czerwono, używasz ceny specyficznej, ustawianej dla produktu w Katalog → Produkty → [your product] → Ceny → Ceny specyficzne → Dodaj cenę specyficzną. To samo okno pojawia się przy masowym przypisywaniu katalogowej reguły cenowej w Katalog → Rabaty → Katalogowe reguły cenowe, czyli wtedy, gdy planujesz rabat od razu dla całej kategorii albo dostawcy, zamiast produkt po produkcie.

Okno ma własne pola daty i godziny Od oraz Do, te same kolumny from/to w tabeli ps_specific_price, oraz kontrolki, których nie mają reguły koszyka:

• Dla (grupa klientów), ogranicza zaplanowaną cenę do grupy, dzięki czemu „tydzień hurtowy, −20% dla resellerów” może istnieć w tym samym oknie równolegle z normalnymi cenami detalicznymi.
• Dostępna ilość / Od ilości. Pozwala stopniować rabat według liczby kupowanych sztuk i przypisać go do zakresu dat.
• Zostaw daty puste. Wtedy cena specyficzna jest stała. To właśnie pola dat zmieniają zwykłą obniżoną cenę w promocję czasową; wyczyszczenie ich to sposób, żeby świadomie „przykleić” cenę promocyjną na stałe.

Widoczna dla kupującego różnica jest głównym powodem wyboru jednego mechanizmu zamiast drugiego: cena specyficzna pojawia się w katalogu i na stronie produktu, zanim cokolwiek trafi do koszyka, więc reklamuje okazję; reguła koszyka zwykle ujawnia się dopiero w koszyku. Jeśli nie masz pewności, którego mechanizmu potrzebuje dana promocja, porównanie reguł koszyka i cen specyficznych daje ramy do podjęcia decyzji.

Audyt zaplanowanych okien jednym zapytaniem

Gdy przygotujesz z wyprzedzeniem promocje na cały kwartał, warto odczytać je w jednym miejscu, zamiast przeklikiwać każdy produkt. To kontrole tylko do odczytu, niczego nie zmieniają. Aby zobaczyć każdą regułę koszyka, której okno otwiera się w przyszłości albo jest obecnie aktywne (dostosuj prefiks ps_ do swojej instalacji):

-- Cart rules with their scheduled windows, soonest first.
SELECT id_cart_rule, code, active, date_from, date_to,
       quantity, quantity_per_user
FROM ps_cart_rule
WHERE date_to >= NOW()
ORDER BY date_from;

Aby wyłapać klasyczny błąd „Ważny do wcześniej niż Ważny od” we wszystkich regułach naraz, zanim znajdzie go klient:

-- Any rule whose window can never open (to is before from).
SELECT id_cart_rule, code, date_from, date_to
FROM ps_cart_rule
WHERE date_to < date_from;

Odpowiednik dla obniżek cen produktów odczytuje tabelę ps_specific_price, kolumny from i to to te same pola harmonogramu, które zapisuje okno dialogowe, a wiersz z obiema wartościami ustawionymi na 0000-00-00 00:00:00 oznacza cenę stałą (bez dat), a nie zaplanowaną.

Pułapka strefy czasowej, która przesuwa start

To najczęstszy sposób, w jaki zaplanowany rabat potrafi się wyłożyć, a problem pozostaje niewidoczny aż do momentu, gdy zaboli. PrestaShop ocenia date_from / date_to względem strefy czasowej skonfigurowanej w sklepie, ustawianej w Międzynarodowe → Lokalizacja → Strefa czasowa (wewnętrznie zapisywanej jako PS_TIMEZONE). Która nie musi być taka sama jak zegar systemowy hostingu i prawie nigdy nie jest taka sama jak lokalny czas klienta przeglądającego sklep z innego kraju.

Awaria wygląda tak: strefa czasowa sklepu została na domyślnej wartości wybranej przez hosting albo na UTC, a Twoja firma i klienci działają w CET (UTC+1). Ustawiasz start wyprzedaży na 00:00. Dla klientów w Europie Środkowej promocja faktycznie rusza o 01:00, a „północna okazja”, o której wszyscy dostali mailing, przez pierwszą godzinę nie działa. Godziny zakończenia przesuwają się tak samo: limit „niedziela 23:59” w UTC kończy się lokalnie o 00:59 w poniedziałek, oddając dodatkową godzinę, której nie planowałeś.

Przed każdym ważnym startem najpierw potwierdź strefę czasową sklepu, a potem czytaj godzinę rozpoczęcia jako „00:00 w tej strefie czasowej”, nie jako „00:00 mojego czasu”.

Szczegół, o którym prawie wszyscy zapominają: cache i warstwa wizualna

Między poprawnie zaplanowanym rabatem a tym, że klient faktycznie go zobaczy, stoją dwie rzeczy.

Cache. Ponieważ ceny są obliczane w chwili żądania, a potem cache'owane, sklep korzystający z cache pełnych stron, cache Smarty albo CDN może nadal podawać cenę sprzed wyprzedaży po upływie date_from, i nadal pokazywać cenę promocyjną po zakończeniu promocji. Przy wyprzedaży z twardym startem bezpieczny wzorzec jest prosty: zaplanuj daty normalnie, a następnie wyczyść cache w momencie startu (Parametry zaawansowane → Wydajność → Wyczyść cache), żeby pierwszy render przeliczył cenę od nowa. Jeśli używasz długiego cache na brzegu sieci, uwzględnij jego TTL przy planowaniu faktycznego czyszczenia.

Jeśli godzina startu wyprzedaży jest naprawdę sztywna (północna okazja), możesz usunąć człowieka także z czyszczenia cache. PrestaShop nie planuje aktywacji rabatu jako zadania, ale Twój serwer może zaplanować wyczyszczenie cache, jednowierszowy cron, który uruchamia konsolowe polecenie czyszczenia cache w chwili startu, tak aby pierwszy render po uruchomieniu promocji przeliczył ceny bez Twojego logowania:

# crontab entry: clear PrestaShop's cache at 00:00 on 27 Nov 2026,
# the minute a hard-start sale opens. Run as the web user.
# (path to the PrestaShop root; --no-debug for prod)
0 0 27 11 * cd /var/www/html && php bin/console cache:clear --env=prod --no-debug

To nie aktywuje rabatu, robi to sam zakres dat, tylko gwarantuje, że cache'owana strona sprzed promocji znika dokładnie w chwili otwarcia okna. Przy CDN albo cache na brzegu sieci połączysz to z czyszczeniem po stronie dostawcy w tej samej minucie. Traktuj to jako dodatkowe zabezpieczenie dla wyprzedaży, w których liczy się pierwsza minuta, a nie wymóg przy codziennym planowaniu.

Warstwa wizualna. Rabat jest zaplanowany; slider na stronie głównej nadal mówi „Summer Sale”, gdy aktywna jest jesienna promocja, albo banner reklamujący kod wygasł trzy dni przed samym kodem. Planowanie ceny i planowanie treści to w PrestaShop osobne systemy, a drugi z nich nie ma natywnych pól dat w domyślnym sliderze. Połącz każdy zaplanowany rabat z zaplanowaną podmianą kreacji, żeby komunikat i cena zmieniły się w tej samej minucie, nasze podejście do bannerów promocyjnych pokazuje, jak przygotować je bez udziału projektanta.

Nakładające się rabaty: co wygrywa, gdy dwie reguły się zderzają

Gdy tylko zaplanujesz więcej niż jedną promocję, możesz przypadkiem je zestackować. Produkt z ceną specyficzną obniżoną o 20%, który jednocześnie wpada w automatyczną regułę koszyka na 15%, nie zawsze zachowa się tak, jak oczekuje klient (albo Twoja marża). PrestaShop rozstrzyga to przez priorytety i ustawienia łączenia, a nie przez proste dodanie wszystkiego do siebie:

• Ceny specyficzne, gdy może zadziałać kilka naraz, konflikty są rozwiązywane według reguł priorytetu cen specyficznych PrestaShop i pasujących kryteriów (sklep/waluta/kraj/grupa plus ilość i dopasowanie dat); przetestuj wynikową cenę produktu.
• Reguły koszyka mają własny Priorytet oraz przełącznik na poziomie reguły, który określa, czy można ją łączyć z innymi kuponami w tym samym koszyku.
• Obniżka z ceny specyficznej i rabat z reguły koszyka są liczone na różnych etapach (cena pozycji vs. suma koszyka), więc mogą się kumulować, jeśli tego nie wykluczysz.

Ta logika jest naprawdę niewygodna i nie warto rozważać jej abstrakcyjnie. Przed każdym oknem, w którym promocje się nakładają, zrób jeden test, który rozstrzyga sprawę: złóż rzeczywiste zamówienie testowe z aktywnymi zaplanowanymi rabatami i sprawdź końcową kwotę. Jeśli rabat jest głębszy, niż planowałeś, dostosuj priorytet/zgodność reguł koszyka, ograniczenia produktów albo wyklucz produkty już przecenione, a potem przetestuj ponownie. Głębsze mechanizmy nakładania obniżek opisuje poradnik o strategiach wyprzedaży; dla produktów, które powinny być odgrodzone od jakiegokolwiek zaplanowanego rabatu, zobacz wykluczanie produktów z rabatów.

Lista kontrolna przed startem każdej zaplanowanej promocji

Skonfiguruj każdą promocję mniej więcej tydzień przed startem, żeby spokojnie sprawdzać ustawienia, a nie robić to o 23:00. Zanim promocja ruszy, przejdź przez tę listę:

• Daty są poprawne. „Ważny do” rzeczywiście jest po „Ważny od”, a oba czasy są w strefie czasowej Twojego sklepu, nie zegara na ścianie.
• Zakres jest właściwy, reguła „20% rabatu na akcesoria”, która po cichu obejmuje cały katalog, potrafi kosztować bardzo drogie popołudnie. Potwierdź kategorię, grupę albo warunek produktu.
• Limity użycia ustawione, łączna dostępność i limit na użytkownika dla każdego kodu, który może wyciec.
• Nakładanie przetestowane, jedno rzeczywiste zamówienie testowe przez zaplanowane rabaty; sprawdź końcową sumę.
• Plan cache, wiesz, czy czyścisz cache przy starcie i przy zakończeniu.
• Kreacje zaplanowane, banner, slider i ewentualny e-mail ustawione na to samo okno co cena.

Gdy kalendarz robi się większy niż zaplecze sklepu

Natywne pola dat dobrze obsługują jedną promocję. Przeciążenie zaczyna się wtedy, gdy prowadzisz kroczący kalendarz, sezonowe wyprzedaże jedna po drugiej, cykliczne oferty weekendowe, krótkie akcje flash, i ręcznie edytujesz dziesiątki reguł koszyka oraz cen specyficznych, każdą z własnym rozumowaniem o strefie czasowej i czyszczeniu cache. Właśnie taką pracę mają zdejmować z Ciebie nasze moduły automatyzacji. Sales Revolution uruchamia zaplanowane, automatycznie wygasające okazje flash jako zarządzaną kampanię, a nie stos ręcznych reguł, ustawiasz okno, produkty i głębokość rabatu, a moduł obsługuje rozpoczęcie i zakończenie akcji; opisaliśmy go we wpisie o automatycznych okazjach flash dla PrestaShop. Korzyść jest ta sama, o której mówi cały ten artykuł, tylko w większej skali: przełącznikiem włącz/wyłącz nie jest już człowiek siedzący przy komputerze o północy. O psychologii uczciwego prowadzenia takich krótkich akcji, z prawdziwymi licznikami, bez fałszywie resetowanych timerów, przeczytasz w tekście o sprzedaży flash bez manipulacji.

Cały urok zaplanowanych rabatów jest celowo przyziemny: decydujesz raz, za dnia, mając przed sobą daty i zakres, a sklep egzekwuje je dokładnie. Ustaw właściwą strefę czasową, uwzględnij cache, zaplanuj kreacje razem z ceną i przetestuj nakładanie, a potem pozwól promocji działać. Twoja przyszła wersja o 23:00 w czwartek nie będzie musiała w ogóle o tym myśleć.

Zaplanowane rabaty: częste pytania

Czy PrestaShop potrzebuje zadania cron, żeby włączyć rabat o godzinie startu?

Nie. Aktywacja nie jest zadaniem harmonogramu. Nie ma zadania cron, które przełącza promocje. PrestaShop zapisuje date_from/date_to przy każdej regule koszyka i cenie specyficznej, a następnie przelicza cenę w chwili żądania, uwzględniając rabat tylko wtedy, gdy „teraz” mieści się w oknie. Dlatego wyprzedaż ustawiona na 00:00 naprawdę startuje o 00:00, bez zadania, które mogłoby się nie uruchomić. Cron przydaje się tylko do czyszczenia cache w momencie startu, nie do samego rabatu.

Data wyprzedaży już minęła, ale stara cena nadal się wyświetlała, dlaczego?

Cache. Ceny są obliczane w chwili żądania, a potem cache'owane, więc cache pełnych stron, cache Smarty albo CDN może nadal podawać cenę sprzed promocji po otwarciu okna. Wyczyść cache w momencie startu (Parametry zaawansowane → Wydajność → Wyczyść cache), a jeśli używasz cache na brzegu sieci albo CDN, wyczyść również go i uwzględnij jego TTL. Przy wyprzedaży ze sztywnym startem zaplanuj to czyszczenie, żeby pierwszy render po starcie przeliczył ceny.

Promocja wystartowała godzinę za późno, co się stało?

Pułapka strefy czasowej. PrestaShop ocenia okno względem skonfigurowanej strefy czasowej sklepu (PS_TIMEZONE, w Międzynarodowe → Lokalizacja → Strefa czasowa), a nie zegara serwera ani lokalnego czasu odwiedzającego. Jeśli sklep zostanie na UTC, a Twój rynek działa w CET, start „00:00” uruchomi się dla klientów o 01:00. Ustaw strefę czasową sklepu na swój główny rynek, a potem czytaj każdą godzinę promocji jako „północ w tej strefie czasowej”.

Czy mogę ustawić okno rabatu bez daty końcowej?

Tak, zostaw puste pole Do / Ważny do. Przy cenie specyficznej wyczyszczenie obu pól dat sprawia, że cena staje się stała (trwała obniżka zamiast promocji czasowej). Przy regule koszyka otwarte pole Ważny do oznacza, że reguła pozostaje dostępna, dopóki jej nie wyłączysz albo nie wyczerpią się limity użycia. To właśnie pola dat zmieniają stałą cenę w czasową, więc puste wartości są świadomą decyzją, a nie przeoczeniem.

Jak powstrzymać dwa zaplanowane rabaty przed zsumowaniem się w stratę?

Nie rozstrzygaj tego abstrakcyjnie, przetestuj. Złóż jedno rzeczywiste zamówienie z aktywnymi oboma zaplanowanymi rabatami i sprawdź końcową sumę. Jeśli rabat jest głębszy niż planowany, masz do dyspozycji: Priorytet reguły koszyka, przełącznik „łącz z innymi kuponami” na poziomie reguły oraz „Wyklucz przecenione produkty” w procentowej regule koszyka, żeby ignorowała wszystko, co ma już cenę specyficzną. Dostosuj i przetestuj ponownie. Dla SKU, których nigdy nie powinna dotknąć żadna promocja, zobacz wykluczanie produktów z rabatów.