Strony firmowe, landing page i serwisy w WordPress oraz Next.js – projektujemy je pod konwersję i widoczność w Google.
Tworzenie stron WWWProjektowanie UX/UIStrony dla firmLanding pageRedesign strony
Przepisy wdrażające dyrektywę Omnibus mogą wymagać informacji o najniższej cenie z okresu poprzedzającego ogłoszenie obniżki. W PrestaShop potrzebujesz mechanizmu historii cen, konfiguracji pod realne promocje i testów. Kwalifikację scenariuszy oraz wyjątków potwierdź z prawnikiem.
Wdrożenie Omnibus w PrestaShop nie kończy się na instalacji modułu. Trzeba połączyć historię cen z początkiem konkretnej obniżki, uwzględnić źródła aktualizacji katalogu i sprawdzić komunikaty w motywie. Ten poradnik pomaga wybrać rozwiązanie i przygotować odbiór techniczny, również gdy ceny przychodzą z hurtowni lub ERP.
Według wyjaśnień UOKiK o informowaniu o obniżkach przy ogłaszaniu obniżki konsumentowi podaje się obok ceny aktualnej minimum z 30 dni poprzedzających obniżkę. Dla oferty młodszej niż 30 dni punktem odniesienia jest okres od rozpoczęcia sprzedaży. Towary szybko psujące się mają odmienną regułę: cenę sprzed pierwszej obniżki. Nie są to powody do automatycznego ukrycia informacji. Obowiązek obejmuje także internet i reklamę.
Reguły dotyczące ogłaszania obniżek odwołują się do ceny stosowanej w okresie przed obniżką, ale wynik zależy m.in. od sposobu komunikacji, rodzaju produktu, historii oferty i wyjątków przewidzianych w aktualnych przepisach. Poniższa lista służy do zinwentaryzowania mechanik cenowych; nie przesądza, że każda z nich podlega tej samej regule.
Nie zakładaj, że sama wersja PrestaShop zapewnia kompletną historię cen i poprawny komunikat dla wszystkich mechanik promocji. Sprawdź faktyczne pola, reguły cenowe, moduły i szablon w swojej instalacji. Jeżeli brakuje danych lub wyświetlania potrzebnego w scenariuszach zatwierdzonych prawnie, trzeba dobrać moduł albo implementację niestandardową.
Zaloguj się do panelu administracyjnego PrestaShop i zanotuj dokładną wersję core, motyw, aktywne moduły cenowe oraz sposób tworzenia promocji. Sam numer wersji nie rozstrzyga zakresu wdrożenia.
Edytuj produkt testowy i sprawdź, jakie pola ceny oraz historii są faktycznie dostępne, skąd pobierają dane i gdzie pojawia się komunikat na karcie oraz listingu. Następnie przetestuj regułę katalogową, kod rabatowy i wariant produktu używane w sklepie.
Jeżeli istniejący mechanizm nie zapisuje danych lub nie renderuje komunikatu dla zatwierdzonych scenariuszy, porównaj moduł z implementacją niestandardową. Decyzję podejmij po teście, a nie na podstawie ogólnej etykiety wersji.
Najpierw spisz wymagania, potem porównuj licencje. Darmowy moduł, płatny dodatek i kod niestandardowy mogą różnić się źródłami historii, obsługą wariantów i kosztem utrzymania. Cena zakupu nie mówi, ile pracy zajmie dopasowanie motywu.
Kryterium 1 — zgodność z wersją PS: sprawdź deklarację producenta, datę ostatniego wydania i wynik testu na kopii Twojego sklepu. Brak świeżego wydania jest sygnałem do weryfikacji, ale sama data nie rozstrzyga kompatybilności.
Kryterium 2 — historia cen: ustal, od kiedy moduł zapisuje dane, jakie źródła zmiany ceny obejmuje i jak wylicza wartość referencyjną. Sama cena przekreślona nie jest dowodem poprawnie zebranej historii.
Kryterium 3 — integracja z cennikami i promocjami: sprawdź, czy moduł obsługuje katalogowe zasady cenowe (price rules), kody rabatowe i promocje grupowe — nie tylko ręczne zmiany ceny produktu.
| Pytanie do dostawcy | Dowód potrzebny przed zakupem | Kiedy wstrzymać wdrożenie |
|---|---|---|
| Czy działa w moim sklepie? | Dokładne core, PHP, motyw, wersja modułu i wynik na stagingu | Deklaracja tylko 'PrestaShop 8/9', bez sprawdzenia konfliktów |
| Skąd pobiera historię? | Log ręcznej zmiany, integracji API i importera używanego w sklepie | Importer aktualizuje bazę poza mechanizmem rejestrowania |
| Jak obsługuje warianty i kanały? | Osobny test cen wariantów, walut i sklepów objętych zakresem | Jedna wartość wyświetlana dla różnych cen bez potwierdzonej reguły |
| Kto utrzymuje rozwiązanie? | Warunki licencji, aktualizacji, wsparcia oraz eksportu historii | Nie wiadomo, jak odzyskać dane po zmianie modułu |
Zacznij na zabezpieczonej kopii sklepu, z wyłączonymi rzeczywistymi płatnościami, wiadomościami i synchronizacją do systemów produkcyjnych. W menedżerze modułów prześlij paczkę ZIP od dostawcy. Nazwy ekranów mogą różnić się między wersjami. Zachowaj log instalacji i błędy.
Po instalacji moduł pojawi się na liście zainstalowanych modułów. Kliknij Konfiguruj, żeby otworzyć panel ustawień.
To kluczowy krok techniczny. Moduł powinien rejestrować źródła zmian ceny objęte zatwierdzonym zakresem sklepu. Bez kompletnej historii dla danego scenariusza nawet poprawnie wyglądający komunikat może opierać się na niepełnych danych.
W panelu konfiguracji potwierdź aktywne rejestrowanie historii i datę pierwszego rzeczywistego zapisu. Nie wypełniaj poprzednich 30 dni dzisiejszą ceną. Import historyczny ma sens tylko z rzeczywistymi wartościami i datami, których pochodzenie można wykazać. Brak danych jest brakiem danych, nie historią ceny stałej.
Sprawdź, czy moduł śledzi również: cenniki katalogowe (catalog price rules), cenniki dla grup klientów i specyficzne ceny (specific prices). Sama cena produktu to nie wszystko — promocje w PrestaShop działają przez warstwy.
Moduł powinien pokazać cenę odniesienia w miejscach i scenariuszach wskazanych w zaakceptowanej polityce promocji. Sprawdź kartę produktu, listing, warianty i każdy customowy blok, w którym sklep komunikuje obniżkę.
W standardowym scenariuszu etykieta powinna jednoznacznie wskazywać okres przed obniżką, np. 'Najniższa cena z 30 dni przed obniżką: X zł'. Sam napis 'cena Omnibus' albo ruchome 'ostatnie 30 dni' nie wyjaśnia właściwego punktu odniesienia. Inne okresy wymagają odpowiadającej im etykiety.
Sprawdź czytelność na desktopie i mobile oraz relację komunikatu do ceny bieżącej i przekreślonej. Test techniczny potwierdza renderowanie, ale ocena prawna widoczności i treści pozostaje osobnym krokiem.
Wszystkie próby wykonaj na stagingu. Zapisz datę początku obniżki, strefę czasową, historię produktu i oczekiwany komunikat. Nie zmieniaj zegara ani cen produkcyjnych, żeby skrócić test. Dane syntetyczne muszą pozostać w odizolowanej bazie testowej.
Przykład testowy, nie historia klienta: produkt sprzedawany ponad 30 dni miał w okresie przed obniżką ceny 120 i 100 zł, a kampania zaczyna się od 90 zł. Dla standardowej reguły oczekujesz odniesienia 100 zł, nie 120 zł. Następnie sprawdzasz kolejne dni tej samej niezmienionej kampanii: odniesienie nie może przesuwać się mechanicznie razem z codziennym oknem historii.
Jeżeli moduł zaczyna rejestrować dane dopiero po instalacji, może nie mieć historii potrzebnej do wyliczenia ceny odniesienia dla wcześniejszego okresu. Nie traktuj tego automatycznie jako bezpiecznego stanu przejściowego: ustal z prawnikiem, jak prowadzić promocje i komunikację do czasu zebrania danych.
Dlaczego testować dni tej samej kampanii i różne widoki? Komunikat UOKiK z 12 stycznia 2026 r. opisuje m.in. zmieniającą się cenę odniesienia podczas niezmienionej obniżki oraz niespójności między listingiem, kartą, koszykiem, wariantami i urządzeniami. To uzasadnienie poniższych testów regresji, nie ocena prawna Twojego sklepu.
| Scenariusz | Co porównać | Dowód odbioru |
|---|---|---|
| Zmiana ceny w panelu, API i importerze | Rzeczywisty zapis każdego źródła z datą oraz identyfikatorem produktu | Wyciąg historii i log operacji bez danych klientów |
| Kampania przekracza północ / działa kilka dni | Początek obniżki i niezmienione odniesienie dla tej samej kampanii | Wynik scenariusza z kontrolowanymi datami na stagingu |
| Wariant oraz grupa cenowa | Wybrany wariant, cenę końcową i regułę dla danego odbiorcy | Zrzut dwóch wariantów i zapis konfiguracji |
| Mobile, desktop, listing, karta i blok promocyjny | Spójność wartości i obecność komunikatu przy ogłaszanej obniżce | Adresy, szerokości ekranu i zrzuty przed/po |
| Cache po aktualizacji ceny | Widok bez cache i z aktywnym cache, także dla innej sesji | Czas aktualizacji i wynik powtórnego odczytu |
| Zmiana lub odinstalowanie modułu | Eksport historii, backup i możliwość odtworzenia | Sprawdzony plik eksportu oraz próba przywrócenia na kopii |
Poniższe punkty to techniczne tryby awarii, które warto objąć testami. Ich wystąpienie nie przesądza samodzielnie oceny prawnej, ale może oznaczać, że komunikat korzysta z niepełnych danych albo nie pojawia się w uzgodnionym miejscu.
Przy technicznym wdrożeniu historii cen ujawniają się też inne obszary interfejsu konsumenckiego. Poniższą listę potraktuj jako pytania do osobnego audytu prawnego, nie jako kompletną interpretację obowiązków:
Jeśli publikujesz opinie klientów, zinwentaryzuj sposób ich pozyskiwania, weryfikacji i oznaczania. Moduł PrestaShop może dostarczyć znacznik 'zweryfikowany zakup', ale sam znacznik nie zastępuje prawidłowego procesu ani opisu przyjętego przez sklep. Zakres informacji wymaganych w Twoim modelu potwierdź prawnie.
Naruszenia obowiązków informacyjnych lub zbiorowych interesów konsumentów mogą prowadzić do działań właściwych organów i sankcji zależnych od podstawy prawnej oraz okoliczności sprawy. Ten poradnik nie wylicza progu kary ani nie ocenia ryzyka konkretnego sklepu. Aktualne przepisy, komunikaty organów i możliwe konsekwencje zweryfikuj z prawnikiem na dzień analizy.
Jeśli Twój sklep potrzebuje nie tylko modułu Omnibus, ale też optymalizacji stron produktowych pod kątem konwersji — sprawdź naszą ofertę SXO i optymalizacji konwersji. Kompleksową ofertę modułów i integracji dla PrestaShop znajdziesz w sekcji modułów i integracji PrestaShop.
Marketplace może stosować własne mechanizmy gromadzenia i prezentacji danych cenowych, a ich zakres oraz podział odpowiedzialności ze sprzedawcą mogą się zmieniać. Sprawdź aktualną dokumentację platformy i ustalenia prawne dla swojego konta. Przy synchronizacji przez BaseLinker lub inny moduł przetestuj, jakie dane są faktycznie przesyłane; nie zakładaj, że historia z PrestaShop trafia do marketplace razem z aktualną ceną.
Instalację, konfigurację i odbiór uzgodnionych promocji opisuje oferta wdrożenia modułu Omnibus dla PrestaShop. Utrzymanie techniczne modułu, staging i kolejne testy możemy prowadzić w ramach stałej opieki technicznej PrestaShop. Zakres opieki nie obejmuje porady prawnej ani gwarancji zgodności; politykę promocji i komunikaty zatwierdza właściciel sklepu ze swoim doradcą.
W WebAlpha instalujemy i konfigurujemy moduły Omnibus dla PrestaShop oraz testujemy historię i wyświetlanie cen na uzgodnionych scenariuszach katalogowych. Nie zastępuje to analizy prawnej polityki promocji i komunikatów sklepu.
Wdrożenie modułu Omnibus w PrestaShopStrony firmowe, landing page i serwisy w WordPress oraz Next.js – projektujemy je pod konwersję i widoczność w Google.
Tworzenie stron WWWProjektowanie UX/UIStrony dla firmLanding pageRedesign strony
Sklepy na PrestaShop i WooCommerce – wdrażamy, migrujemy i piszemy dedykowane moduły w zespole senior developerów.
Tworzenie sklepówNowy sklep PrestaShopMigracja na PrestaShopModuły PrestaShopŁączymy sklep z hurtowniami
Pozycjonujemy, naprawiamy techniczne SEO i optymalizujemy konwersję. Widoczność, kliknięcia i zarejestrowane konwersje porównujemy z bazą wyjściową.
SEO dla firmlokalne SEOcontent SEOAudyt SEOSEO techniczne
Utrzymujemy, aktualizujemy i stale rozwijamy projekt – bierzemy odpowiedzialność za techniczną stronę nawet po uruchomieniu.
Opieka nad stronąaktualizacje i serwerSupport w pakietach godzinRozwój stronyWdrożenia niestandardowe
Bezpłatna konsultacja
Opisz, czego potrzebujesz — zaproponujemy zakres, technologię i realny harmonogram. Bez zobowiązań.
Następny krok
Krótka rozmowa albo wiadomość — wrócimy z konkretną propozycją zakresu.
Formularz kontaktowyOpisz, czego potrzebujesz — strony, sklepu, integracji czy wsparcia technicznego. Odpowiemy z konkretnymi propozycjami i orientacyjną wyceną, zwykle w ciągu 24–48 godzin roboczych.
ul. Henryka Pachońskiego 7a
31-223 Kraków
Biuro czynne: pon.–pt., 9:00–17:00
Webalpha
NIP: 6562340974
REGON: 385895790