Sieć odzieżowa premium dowiedziała się o naruszeniu Omnibus dziewiętnaście miesięcy po fakcie. Nie z dashboardu, nie z alertu, nie od merchandisera. Z pisma kancelarii prawnej. Decyzja UOKiK: 340 tys. zł za pojedynczą kampanię z listopada 2023.

Mechanizm wpisuje się w schemat, który Prezes UOKiK przedstawił w sprawozdaniu rocznym 2024 jako jeden z trzech najczęściej powtarzanych w postępowaniach o naruszenie dyrektywy 2019/2161. Cztery miesiące przed Black Friday sklep przeprowadził migrację z autorskiego CMS na Shopera. Plugin Omnibus zainstalowano w dniu go-live, certyfikat zgodności od integratora podpisał kierownik IT, checklista odhaczona. Historii cen sprzed migracji nie przeniesiono — bo nikt o nią nie poprosił w przetargu.

Promocja „minus trzydzieści procent" odnosiła się więc do ceny regularnej sprzed trzech tygodni. UOKiK liczy inaczej. Liczy najniższą cenę z trzydziestu dni przed obniżką, a w tym oknie SKU miało jeszcze starą wartość z poprzedniego systemu. Faktyczna obniżka mieściła się w przedziale 8–14 procent. Komunikowana była dwa razy większa.

Plugin świecił na zielono przez cały listopad. Tak działa to w praktyce.

Według danych z analizy 250 sklepów w ramach koordynowanej kontroli sieci Consumer Protection Cooperation z 2023 roku (CPC Sweep) około 30 procent uczestniczących e-commerce wykazywało naruszenia Omnibus. Polski UOKiK uczestniczył jako jeden z aktywniejszych regulatorów. Izba Handlu Elektronicznego w komunikacie z lutego 2025 oszacowała, że 40–60 procent polskich sklepów z formalnie wdrożonym Omnibus realnie nie ma procesu walidacji bazy 30-dniowej po operacjach katalogowych. Liczby pokrywają się z tym, co dziś trafia do postępowań.

Wdrożenie zamyka projekt. Compliance otwiera proces.

Wdrożenie Omnibus ma datę startu, kierownika, ticket w Jira i sign-off od integratora. Compliance Omnibus nie ma żadnego z tych elementów. Projekt zamyka się w cztery do ośmiu tygodni; proces trwa bez końca, najczęściej bez właściciela i bez linijki w budżecie. To rozróżnienie, którego polskie e-commerce nie odrobiło. Branża zrobiła projekt i zapomniała o procesie.

Naruszenia compliance nie ujawniają się przy go-live. QA przechodzi, dział prawny podpisuje protokół, integrator wystawia fakturę. Pojawiają się sześć do osiemnastu miesięcy później — przy migracji platformy, zmianie ERP, sezonowym przeindeksowaniu katalogu po Black Friday, split lub merge wariantów. Operacje rutynowe. Żadna z nich nie wraca do działu pricing z flagą „uwaga, Omnibus".

Potem przychodzi pismo. Kara w przedziale 200 tys. – 2 mln zł na podstawie art. 106 ust. 1 pkt 4 ustawy o ochronie konkurencji i konsumentów, plus obowiązek zwrotu różnicy ceny każdemu klientowi, który kupił w promocji. Wystarczy jedna skarga przez formularz online, żeby uruchomić postępowanie wyjaśniające. Decyzje wobec średnich sklepów (przychód roczny 20–80 mln zł) z 2024 i 2025 roku mieszczą się w przedziale 200–700 tys. zł. To nie jest maksimum ustawowe. To środek rozkładu realnych decyzji.

Test trzech SKU

Otwarcie arkusza z top 10 sprzedaży zajmuje minutę. Wybór trzech SKU — drugą. Sprawdzenie w bazie cen platformy, czy najniższa wartość przy ostatniej aktywnej promocji to faktycznie minimum z trzydziestu dni przed startem obniżki, a nie cena „poprzednia", „regularna" lub „katalogowa" — trzecią. Jeśli odpowiedź brzmi „sprawdzałem przy wdrożeniu w 2023" — luka istnieje. Żaden dashboard jej nie pokaże. UOKiK znajdzie przy pierwszej kontroli.

Dziewiętnaście miesięcy między naruszeniem a decyzją to standard, nie wyjątek.

Sześć miejsc, w których psuje się compliance

Sześć mechanizmów psuje się w tych samych miejscach niezależnie od platformy. Trzy z nich UOKiK opisał wprost w wytycznych z 2023 roku. Pozostałe trzy znaleziono w postępowaniach i decyzjach z lat 2024–2025. Wszystkie razem występują w katalogu, który ma więcej niż 200 SKU.

Baza 30 dni liczona z niewłaściwego pola

Artykuł 4 ust. 2a ustawy o informowaniu o cenach definiuje bazę Omnibus jako najniższą cenę z trzydziestu dni przed wprowadzeniem obniżki. Nie cenę poprzednią, nie regularną, nie katalogową z systemu PIM. Plugin często pobiera pole previous_price z tabeli produktu zamiast wykonać agregat na historii. Test integratora używa danych syntetycznych z pełną historią i nie wykrywa różnicy. Produkcyjny log cenowy wykrywa, ale nikt go nie przegląda.

Sklep odzieżowy z audytu wewnętrznego z lutego 2025: cena 199 zł przez trzy miesiące, cicha obniżka do 189 zł na piętnaście dni, Black Friday z komunikatem „minus dwadzieścia procent" sprowadzającym cenę do 151 zł. Poprawna baza wynosiła 189 zł. Sklep komunikował obniżkę liczoną od 199. Różnica per sztuka — cztery złote. Skala przy kilku tysiącach transakcji wystarczyła, żeby UOKiK zaczął zadawać pytania.

Zestawy, warianty, cross-sell

Zestaw sprzedawany pod osobnym SKU ma własną historię cen. Nie jest sumą historii składników. Jeśli SKU zestawu powstało dwanaście dni przed promocją, baza trzydziestodniowa formalnie nie istnieje — każda obniżka w pierwszych trzydziestu dniach jest naruszeniem.

Split wariantu (jedno SKU dzielone na cztery kolory) lub merge (cztery warianty zwijane w jeden master) resetuje historię cen, bo platforma traktuje nowe ID jako nowy produkt. Okno trzydziestodniowe startuje od zera w dniu operacji. To najczęstsze źródło naruszeń wykrywanych przy kontroli, ponieważ żaden zespół nie loguje split/merge jako zdarzenia pricingowego.

Cross-sell typu „kup X, dostaniesz minus piętnaście procent na Y" wymaga, żeby baza Y była liczona dla Y osobno. Sklep elektroniczny w drugim kwartale 2024 dostał wezwanie wyjaśniające — algorytm liczył bazę dla konfiguracji X+Y, nie dla samego Y. Postępowanie pozostaje w toku.

Kody rabatowe i flash sale

UOKiK w wyjaśnieniach z 2022 i 2023 roku potwierdził, że kod rabatowy jest obniżką ceny w rozumieniu Omnibus. Cena finalna po kodzie nie może być niższa od bazy trzydziestodniowej. Wiele sklepów wyłącza kody z logiki Omnibus, bo wewnętrznie traktuje je jako rabat klienta, a nie zmianę ceny produktu. To interpretacja, której organ nie potwierdza.

Krytyczna kombinacja: flash sale, który po trzydziestu dniach staje się nową bazą, plus kod rabatowy obniżający tę bazę dalej. Plugin Omnibus tego nie złapie, ponieważ moduł kodów i moduł flash sale to dwa osobne systemy, które nie czytają wzajemnie swoich logów.

Migracja platformy

Historia cen przy migracji rzadko jest przenoszona razem z danymi produktowymi. W przetargu IT nikt o nią nie pyta. Po przejściu z Magento na Shopify w marcu 2024 sklep może legalnie ogłosić promocję wyłącznie od najniższej ceny po pierwszym marca. Jeśli komunikat odnosi się do wartości z lutego, naruszenie jest formalne. Wykrycie następuje rok później, przy okazji innej kontroli. To ten sam mechanizm, który dał sieci odzieżowej z otwarcia karę 340 tys. zł.

Marketplace

Allegro nie weryfikuje poprawności bazy Omnibus u sprzedawców. Odpowiedzialność spoczywa na ofercie sprzedawcy, nie na platformie. Centrum Zgodności Allegro flaguje wybrane naruszenia od 2023 roku, ale korzysta z niego mniejszość aktywnych sellerów. Synchronizacja cen przez BaseLinker tworzy dodatkową warstwę rozjazdu — historia cen u Allegro to to, co tam trafiło, niekoniecznie to, co jest w ERP.

Konkurencja z błędnym Omnibus

Konkurent windujący cenę z 199 do 299 zł na trzydzieści sześć godzin przed Black Friday, a następnie ogłaszający „minus czterdzieści procent" do 179 zł, formalnie nie spełnia Omnibus. Realnie zbiera ruch z displayu, dopóki UOKiK nie odpowie na skargę — co trwa osiem do osiemnastu miesięcy. Brak monitoringu compliance u konkurencji to nie tylko ryzyko prawne. To także oddanie rynkowej przewagi na zasadach, których uczciwy sprzedawca nie może replikować legalnie.

Kary 2024–2025: środek rozkładu, nie maksimum

Maksimum ustawowe (10 procent obrotu rocznego) trafia do nagłówków. Realne decyzje wobec sklepów średniej wielkości plasują się w przedziale 200–700 tys. zł. To rząd wielkości, na którym CFO zaczyna pytać o procedury, nie tylko o zapłatę. Większość decyzji z 2025 roku dotyczy promocji z 2023. Lag między naruszeniem a karą wynosi standardowo szesnaście do dwudziestu miesięcy.

Ścieżka standardowa wygląda tak: konsument składa skargę przez formularz online na uokik.gov.pl. Urząd wszczyna postępowanie wyjaśniające. Wezwanie trafia do działu prawnego spółki. Dział pricing dowiaduje się trzy lub cztery tygodnie po wezwaniu — czyli osiem do osiemnastu miesięcy po samym naruszeniu. Pracownik dostający w maju 2025 forward dotyczący kampanii Black Friday 2023 nie pamięta szczegółów: którego dnia ruszyła obniżka na konkretne SKU, jakie były ustawienia repricera, kto autoryzował zmianę bazy, czy między datami była migracja platformy.

UOKiK przedstawia w postępowaniu zrzuty z własnego monitoringu, screeny od skarżącego, dane z porównywarek, Wayback Machine. Brak własnych logów po stronie spółki oznacza domniemanie winy de facto — nie negocjuje się wysokości kary, dostaje się decyzję nakazującą plus pełną kwotę. To samo postępowanie z pełnym audit trail kończy się w około sześćdziesięciu procentach przypadków obniżeniem kary lub umorzeniem części zarzutów (na podstawie analizy decyzji z 2024–2025 publikowanych w bazie UOKiK).

Trzy interpretacje spoza ustawy

Flash sale poniżej dwudziestu czterech godzin. Ustawa milczy, wytyczne UOKiK z 2023 roku — nie. Czterogodzinny Happy Hour na newsletter wymaga bazy trzydziestodniowej. Brak wyjątku czasowego.

Cena klubowa wyświetlana publicznie. Komunikat „dla członków klubu Pro minus dwadzieścia procent" widoczny na stronie produktowej dla osób zalogowanych liczy się jako cena prezentowana publicznie. Wymóg posiadania konta nie ma znaczenia; znaczenie ma widoczność na liście produktów.

Wyprzedaż sezonowa. Baza trzydziestodniowa liczona jest od daty ogłoszenia komunikatu „minus X procent", nie od logistycznego startu kampanii. Banner ruszył piątego lutego, ceny realnie spadły dziewiętnastego. Kontrolny zakres trzydziestu dni cofa się o czternaście dalej, niż liczy to dział marketingu.

Minimum operacyjne audit trail

Pierwsze pytanie kontroli UOKiK brzmi zwykle tak: „Prosimy o przedstawienie historii cen SKU XYZ za okres pierwszego do trzydziestego października 2024 wraz z dziennymi snapshotami". Odpowiedź „sprawdzę w systemie" oznacza brak postępowania. Odpowiedź „wysyłam CSV w dwadzieścia minut" oznacza, że gra trwa dalej.

Pięć typów zdarzeń musi być logowanych z timestampem co do sekundy i identyfikatorem operatora.

  1. Zmiana ceny regularnej. Rekord: {timestamp, sku, cena_stara, cena_nowa, operator, source}. Zmiana z repricera, importu PIM, ręcznej edycji w panelu — wszystko ląduje w jednym strumieniu.
  2. Uruchomienie promocji. Rekord: {timestamp, sku, procent_obnizki, baza_omnibus, cena_wynikowa}. Baza Omnibus musi być zamrożona w momencie startu, nie wyliczana ex post.
  3. Operacja na wariancie (split, merge, zmiana ID) z flagą RESET_HISTORII = TRUE. Jedyne zdarzenie wymagające ręcznej weryfikacji następnego dnia.
  4. Zastosowanie kodu rabatowego do SKU. Rekord: {timestamp, kod, sku, cena_po_kodzie, baza_omnibus}. Bez tego wpisu nie da się odtworzyć, dlaczego klient zapłacił 89 zamiast 99 zł.
  5. Dzienny snapshot pełnego cennika. Eksport CSV o 23:59 dla aktywnych SKU. Retencja: 90 dni gorąca baza, 12 miesięcy w cold storage (S3 Glacier lub Backblaze B2, koszt rzędu 5–10 zł miesięcznie za 50 GB).

Pole, które bywa pomijane, a jest kluczowe: czy_w_promocji (bool). Bez niego nie da się jednym zapytaniem wyciągnąć minimum cen regularnych z trzydziestu dni.

SELECT MIN(cena)
FROM historia_cen
WHERE sku = ?
  AND data >= CURRENT_DATE - 30
  AND czy_w_promocji = FALSE;

Platformy — co loguje natywnie, co dorzucają zespoły

PlatformaLogowanie natywneDo dorzucenia
ShoperModuł Omnibus od 6.x, baza wyświetlana na karcie produktuAktywacja modułu (domyślnie OFF), eksport CSV z timestampem, alert gdy cena_promo < baza_omnibus
IdoSellWłasna logika Omnibus, baza wyliczana automatycznieRęczna weryfikacja historii po każdym split/merge wariantu — historia może nie przenieść się na nowe ID
MagentoBrak natywnego modułu Omnibus — wymaga rozszerzenia lub własnego koduAudit trail po stronie własnej: observer na catalog_product_save_after plus tabela price_history

Niezależnie od platformy zespół dorzuca dwie rzeczy: zewnętrzny monitoring cen (Dealavo, Pricelytics, Omnia Retail; koszt 500–2500 zł miesięcznie) oraz alert progu „cena wynikowa < baza Omnibus" dla TOP 100 SKU. Ręcznie taki monitoring to około sześciu godzin tygodniowo na pracownika; z narzędziem — kilkanaście minut dziennie.

Monitoring Omnibus u konkurencji

Wtorek, godzina czternasta. Konkurent uruchamia kampanię na pięciu SKU z pokrywającego się katalogu — duża pralka, segment 1899–2199 zł. Komunikat: „Black Week, minus czterdzieści procent od 2999 zł, dziś 1799 zł". Oferta sklepu zgodna z Omnibus: minus dwadzieścia pięć procent od bazy trzydziestodniowej, cena wynikowa 1849 zł.

Klient widzi dwie liczby. 1799 versus 1849. Pięćdziesiąt złotych różnicy obok dużego czerwonego komunikatu o czterdziestoprocentowej obniżce. Konwersja na karcie produktu w Allegro spada z 4,1 procent do 2,6 procent w czterdzieści osiem godzin.

Faktyczna najniższa cena z trzydziestu dni u konkurenta wynosiła 2199 zł. Prawdziwa baza Omnibus to 2199, deklarowane minus czterdzieści powinno wynosić minus osiemnaście. Naruszenie jest jawne, ale tymczasowo opłacalne — do momentu, w którym UOKiK odpowie na skargę.

Allegro pogłębia problem. Algorytm sortowania nie weryfikuje poprawności bazy Omnibus u sprzedawców; sprawdza cenę wynikową, koszty wysyłki, ocenę sprzedawcy. Oferta z błędnym Omnibus, ale niską ceną finalną, awansuje w rankingu nad ofertę zgodną. To strata konwersji w czasie rzeczywistym, opłacona przez sklep zgodny.

Operacyjny minimum

Zbierane są historie cen TOP 100 SKU nakładających się z własnym katalogiem — daty zmian, poziomy cen, daty ogłoszonych promocji z deklarowanym procentem obniżki. Nie cały katalog konkurenta; tylko produkty, na których faktyczna konkurencja o klienta ma miejsce. Dla każdej promocji dwa pytania weryfikacyjne. Pierwsze: czy cena bazowa wyświetlana w komunikacie równa najniższej z trzydziestu dni przed datą ogłoszenia? Drugie: czy procent obniżki wyliczony z bazy zgadza się z deklarowanym?

Rozjazd między tymi dwiema wartościami oznacza naruszenie do udokumentowania. Dealavo i Pricelytics przechowują historie cen z polskich sklepów i marketplace'ów minimum sześćdziesiąt dni wstecz; retrospektywna analiza dostępna bez własnej infrastruktury. Koszt 1500–4500 zł miesięcznie za katalog 500–2000 SKU. Własny scraper z archiwum działa do około pięciuset SKU nakładających się — Python z Playwright i Postgres, około osiemdziesięciu godzin developera na MVP plus 200–400 zł miesięcznie za proxy rotujące.

Materiał dowodowy do UOKiK: timeline cen konkurenta w CSV, zrzut ekranu wyświetlanej obniżki z datą i godziną, URL kampanii. Skarga przez formularz uokik.gov.pl/skarga. Postępowanie wyjaśniające trwa dwa do czterech miesięcy; w tym czasie urząd może wystosować wezwanie do korekty kampanii. Konkurent dostaje wybór: wycofać reklamę albo ryzykować decyzję 200–700 tys. zł.

Publicznie dostępne ceny ze stron internetowych to dane faktyczne, nie utwór. Orzecznictwo TSUE w sprawie C-30/14 (Ryanair przeciwko PR Aviation) i polskie prawo autorskie wykluczają ich ochronę. Mechanizm legalności jest ten sam, co przy scrapingu danych publicznych z CEIDG — publiczna dostępność plus brak twórczego wkładu w samym cenniku. Ograniczenia: rate limiting (bez obciążania serwera konkurenta) oraz przestrzeganie ToS w zakresie rejestracji konta.

Checklist audytu: 15 pytań, godzina pracy

Godzina czasu, dostęp do panelu pricing i do logów platformy. Tyle wystarczy, żeby wyjść z konkretną listą — piętnaście zielonych odpowiedzi albo osiem zielonych i siedem czerwonych z priorytetami na następne czternaście dni. Audyt prawny zewnętrzny za 35 tys. zł nie jest tu potrzebny.

Zasada jedna: każde „nie wiem" liczy się jak „nie". Nie wymaga natychmiastowej naprawy, wymaga weryfikacji przed następną kampanią promocyjną. Pytania 3, 9, 13 i 15 są najczęstszymi lukami w polskim e-commerce; „nie wiem" na każde z nich to odrębne ryzyko postępowania.

Blok A. Baza i algorytm

P1. Baza 30 dni jest liczona jako MIN(cena) z okna trzydziestu dni przed datą uruchomienia promocji — nie z pola „cena poprzednia", „katalogowa" ani „z ostatniej akcji"?

P2. Algorytm obsługuje wielokrotne zmiany ceny w oknie trzydziestu dni? Cena spadała 199 → 189 → 175 → 189, ruszyła promocja. Baza = 175. Nie 189, nie 199.

P3. Split lub merge wariantów (kolor, rozmiar, pakiet) zachowuje historię cen? Większość platform tworzy nowe SKU z pustą historią po splicie — to technicznie resetuje Omnibus do dnia utworzenia wariantu.

P4. Cena po zastosowaniu kodu rabatowego (np. RABAT15) jest porównywana z bazą Omnibus tego SKU obowiązującą w momencie aktywacji kodu? Kody personalne i masowe podlegają tej samej logice.

P5. Flash sale krótszy niż dwadzieścia cztery godziny jest traktowany jako obniżka z zapisem do logu zdarzeń?

Blok B. Zakres

P6. Zestawy mają własne SKU z własną historią cen, a nie sumę historii składników?

P7. Subskrypcje i abonamenty wyświetlane publicznie na stronie produktowej mają przypisaną bazę Omnibus?

P8. Omnibus działa poprawnie na marketplace'ach (Allegro, Ceneo)? Niezsynchronizowana baza między CMS a Allegro oznacza osobne naruszenie i osobną karę.

P9. W ciągu ostatnich dwudziestu czterech miesięcy nie było migracji platformy, zmiany ERP ani re-importu PIM bez przeniesienia historii cen?

P10. Baza Omnibus przy wyprzedaży sezonowej liczona jest od daty pierwszej ekspozycji komunikatu promocyjnego, nie od dnia logistycznego startu wysyłek?

Blok C. Audit trail i monitoring

P11. Każda zmiana ceny regularnej jest logowana w formacie {timestamp, sku, cena_stara, cena_nowa, operator, source}, append-only, bez nadpisywania wstecz?

P12. Każda promocja zapisuje obliczoną bazę Omnibus jako osobne pole w logu, nie tylko cenę wynikową?

P13. Codzienny snapshot pełnego cennika jest archiwizowany — retencja dziewięćdziesiąt dni gorąca plus dwanaście miesięcy zimna, format CSV gotowy do przedstawienia UOKiK?

P14. Działa automatyczny alert, gdy cena promocyjna lub kod rabatowy schodzi poniżej bazy Omnibus?

P15. Zespół pricing weryfikował ręcznie TOP 10 SKU w ciągu ostatnich trzydziestu dni roboczych?

Punktacja

13–15 odpowiedzi twierdzących oznacza solidny compliance. 9–12 to luki operacyjne; priorytet na pytania z odpowiedzią „nie", najczęściej P3, P9, P13. Poniżej dziewięciu — ekspozycja finansowa jest realna i czas na techniczny audit. Najpierw Blok C, dopiero potem reszta.

Jeśli równolegle pojawia się twierdząca odpowiedź na pytanie „czy w ostatnich dwunastu miesiącach wpłynęło zapytanie lub wezwanie UOKiK dotyczące Omnibus" — postępowanie już trwa. Checklist wtedy nie wystarczy; pierwszy telefon idzie do kancelarii, nie do dostawcy narzędzia.

Format roboczy: arkusz z kolumnami TAK, NIE, W TRAKCIE, plus właściciel i deadline. Gotowy do zabrania na spotkanie z IT i działem prawnym. Nie PDF prezentowy, tylko dokument operacyjny.

Następne czternaście dni

Pierwszy krok: checklist 15 pytań na trzech wybranych SKU w tym tygodniu. Trzy lub więcej wpisów „nie wiem" w Bloku C oznacza materiał na rozmowę z IT i z działem prawnym, nie z kolejnym dostawcą pluginu.

Drugi krok, jeśli warto delegować zewnętrznie: weryfikacja 100 SKU z archiwum cen własnych i konkurentów w pięć dni roboczych. Wynik dostarczany jako arkusz z zielonymi i czerwonymi pozycjami plus harmonogramem naprawy. Kontakt: wojtek@dataminers.pl, w wiadomości branża, wielkość katalogu, informacja o migracjach platformy lub ERP w ostatnich dwudziestu czterech miesiącach. Odpowiedź w dwadzieścia cztery godziny.