Dyrektywa Omnibus w PrestaShop: jak pokazać najniższą cenę z 30 dni

Przy każdej obniżce ceny sklep musi podać najniższą cenę produktu z trzydziestu dni poprzedzających obniżkę. Tak brzmi wymóg z dyrektywy Omnibus, wdrożonej w Polsce nowelizacją ustawy o informowaniu o cenach. Przepis wygląda prosto, ale wdrożenie ma kilka miejsc, w których łatwo się pomylić.

Dlaczego PrestaShop nie umie tego z pudełka

PrestaShop przechowuje aktualną cenę produktu i aktywne ceny promocyjne. Nie przechowuje historii. Kiedy zmienisz cenę w ps_product, poprzednia wartość znika bezpowrotnie i nie ma tabeli, z której dałoby się ją odtworzyć.

Warto o tym wiedzieć przed zakupem jakiegokolwiek modułu do Omnibusa: historia zaczyna się w dniu instalacji. Żaden moduł nie odtworzy cen sprzed swojego wdrożenia, bo nie ma z czego. Przez pierwsze trzydzieści dni podpis pod ceną opiera się na niepełnych danych.

Cztery miejsca, w których cena się zmienia

Moduł, który ma poprawnie prowadzić historię, musi nasłuchiwać wszystkich zdarzeń zmieniających cenę, a nie tylko zapisu produktu:

• actionProductUpdate – zapis produktu w panelu,
• actionObjectSpecificPriceAddAfter – dodanie ceny promocyjnej,
• actionObjectSpecificPriceUpdateAfter – jej zmiana,
• actionObjectSpecificPriceDeleteAfter – jej usunięcie.

Jeśli moduł nasłuchuje tylko pierwszego z nich, promocje ustawiane regułami cenowymi w ogóle nie trafią do historii. Przed zakupem warto o to zapytać sprzedawcę wprost, bo z opisu modułu rzadko to wynika.

Import cen omija hooki

Jeżeli aktualizujesz ceny importem CSV albo integracją z hurtownią, która pisze prosto do bazy, hooki PrestaShopa nie zostaną wywołane. Historia będzie miała dziury dokładnie w tych dniach, w których ceny faktycznie się zmieniały. Ratuje to zadanie cron, które raz na dobę zapisuje aktualny stan cen niezależnie od hooków.

Promocja na promocji

Jeśli do historii wpadają także ceny promocyjne, każda kolejna promocja obniża punkt odniesienia. Po trzech obniżkach z rzędu „najniższa cena z 30 dni” zrówna się z ceną aktualną i komunikat straci sens, choć formalnie nadal będzie prawdziwy.

Dlatego warto mieć przełącznik, który zapisuje do historii wyłącznie ceny podstawowe. Wtedy punktem odniesienia jest realna cena regularna, a nie dno poprzedniej wyprzedaży.

Warianty, czyli jak nie zapchać bazy

W katalogu z wieloma kombinacjami historia zapisywana osobno dla każdego wariantu przy każdej zmianie ceny potrafi urosnąć do milionów wierszy w kilka miesięcy. Jeśli warianty nie mają własnych cen, a najczęściej nie mają, historia liczona per produkt w zupełności wystarcza i zmniejsza tabelę o rząd wielkości.

Zaokrąglenia

Podpis pod ceną powinien być liczony w tej samej precyzji co waluta sklepu. Jeżeli waluta ma zero miejsc po przecinku, a moduł liczy do grosza, klient zobaczy dwie kwoty różniące się o kilkadziesiąt groszy i będzie miał rację, uznając to za błąd.

Gdzie ten komunikat ma być

Przepis mówi o informacji przy cenie obniżonej, czyli w praktyce na karcie produktu. Tam musi być zawsze. Na listingach i w wynikach wyszukiwania bywa zbędny i psuje układ kafelków, więc dobrze mieć osobny przełącznik, który go tam wyłącza.

Nasz moduł nasłuchuje wszystkich czterech zdarzeń, ma zapasowe zadanie cron, przełącznik cen promocyjnych, przełącznik wariantów i liczy w precyzji waluty. Dokumentacja opisuje każdą opcję, a karta modułu zawiera szczegóły i cenę. Wdrożenie zajmuje kilkanaście minut, ale historię warto zacząć zbierać, zanim ogłosisz najbliższą wyprzedaż.