Dyrektywa Omnibus wygląda prosto tylko na pierwszy rzut oka. Jeżeli sklep pokazuje obniżkę, klient powinien zobaczyć także najniższą cenę z 30 dni przed jej wprowadzeniem. W praktyce oznacza to jednak coś więcej niż dodatkową linijkę pod ceną.
Trzeba wiedzieć, kiedy zacząć liczyć 30 dni. Trzeba odróżnić cenę katalogową od promocyjnej. Trzeba zadbać o zgodność metki, kasy i sklepu internetowego. Trzeba też mieć historię zmian, której da się bronić podczas kontroli.
Największy problem polega na tym, że wiele systemów traktuje Omnibus jak prosty zapis ceny w tabeli. Cena się zmieniła, więc zapisujemy ją w historii. Teoretycznie działa. W realnym sklepie bardzo szybko zaczynają się problemy.
W Motion podchodzimy do Omnibusa inaczej — nie jako do pojedynczego pola przy produkcie, ale jako do całego procesu, który musi działać poprawnie w POS, WebPOS, e-commerce i integracjach.
Omnibus nie pyta o dzisiejszą cenę
Pierwsza pułapka dotyczy tego, od kiedy liczyć okres 30 dni. Brzmi banalnie, ale właśnie tutaj pojawia się wiele błędów.
Jeżeli produkt kosztował 100 zł, a potem został przeceniony na 80 zł, informacja dla klienta nie powinna być liczona od dowolnego dnia trwania promocji. Liczy się okres przed obniżką. To szczególnie ważne przy długich promocjach.
Wyobraźmy sobie produkt, który przez kilka miesięcy kosztował 100 zł. Następnie sklep uruchamia promocję i obniża cenę do 80 zł. Promocja trwa dłużej niż 30 dni. Jeżeli system po miesiącu sprawdzi tylko ostatnie 30 dni od dzisiaj, może dojść do błędnego wniosku, że najniższa cena wynosiła 80 zł.
To zły kierunek myślenia. Klient powinien zobaczyć informację odnoszącą się do okresu przed obniżką, a nie do przypadkowego wycinka czasu w trakcie trwania promocji.
Dwa algorytmy zamiast jednego uproszczenia
W Motion stosujemy dwa podejścia do liczenia danych Omnibus, ponieważ jeden prosty algorytm nie wystarcza do wszystkich sytuacji.
- Analiza historii cen w okresie
- Podsumowania i kontrola danych
- Perspektywa administracyjna
- Najniższa cena z 30 dni przed obniżką
- Stabilny komunikat przy długiej promocji
- To, co widzi klient przy cenie
Algorytm dla raportów
Pierwszy algorytm służy do raportów i podsumowań. Pozwala analizować historię cen i sprawdzać, jakie wartości pojawiały się w określonym okresie. To perspektywa administracyjna, przydatna dla osób zarządzających cenami, promocjami i kontrolą danych.
Taki widok pomaga zrozumieć, co działo się z produktem w czasie. Jest ważny dla audytu, analizy i wewnętrznej kontroli.
Algorytm dla klienta
Drugi algorytm odpowiada za to, co widzi klient przy cenie promocyjnej. Tutaj najważniejsza jest cena z 30 dni przed obniżką. Jeżeli promocja trwa dłużej niż 30 dni, ta wartość nie powinna zmieniać się tylko dlatego, że minął kolejny dzień promocji.
To właśnie ten mechanizm chroni sklep przed błędem, w którym długa promocja zaczyna sama dla siebie tworzyć nową historię odniesienia.
Dzięki temu komunikat przy cenie pozostaje stabilny, czytelny i zgodny z logiką Omnibusa.
Dlaczego 30 minut opóźnienia ma znaczenie
Druga pułapka jest mniej oczywista, ale bardzo praktyczna. Chodzi o moment zapisania ceny do historii Omnibus.
W idealnym świecie każda zmiana ceny jest przemyślana i poprawna. W prawdziwym sklepie zdarzają się pomyłki:
- 9 zł zamiast 99 zł
- Pomyłka przy procencie rabatu
- Zapis cennika przed weryfikacją
Jeżeli taka cena od razu trafi do historii Omnibus, zwykła pomyłka może stać się problemem na kolejne 30 dni. System będzie pamiętał wartość, której sklep wcale nie chciał komunikować klientom.
Dlatego w Motion stosujemy 30 minut opóźnienia przy zapisie ceny do historii Omnibus. Przez ten czas cena może być traktowana jako kandydat do zapisu. Jeżeli była pomyłką i zostanie szybko poprawiona, nie powinna niepotrzebnie zanieczyścić historii.
Jeżeli cena zostanie utrzymana, trafia do historii i staje się częścią audytowalnego procesu.
Metka musi mówić jasno
Omnibus nie działa tylko w panelu administracyjnym. Jego sens pojawia się dopiero wtedy, gdy klient widzi cenę w zrozumiały sposób.
Przy promocji powinny być pokazane właściwe informacje. Cena regularna, cena promocyjna i najniższa cena z 30 dni przed obniżką muszą tworzyć spójny komunikat. Nie mogą walczyć ze sobą wizualnie ani wprowadzać klienta w błąd.
W praktyce najczęściej pojawia się prosty układ:
- Cena regularna — przekreślona
- Cena promocyjna — główna cena zakupu
- Najniższa cena z 30 dni przed obniżką — dodatkowa informacja przy promocji
Najtrudniejsza jest trzecia linia. Klient może zobaczyć, że najniższa cena z 30 dni była niższa niż dzisiejsza cena promocyjna i uznać to za błąd. Tymczasem taka sytuacja może być całkowicie poprawna, jeśli wcześniej była inna krótkotrwała promocja.
Insert GT nie prowadzi historii Omnibus
W wielu sklepach Insert GT jest źródłem cen katalogowych. To naturalne, ponieważ pełni rolę systemu księgowo-magazynowego. Nie oznacza to jednak, że powinien odpowiadać za całą logikę Omnibus.
W architekturze Motion historia Omnibus jest prowadzona przez WebPOS. Insert GT może być źródłem ceny katalogowej, ale promocje, polityki cenowe i historia najniższych cen są obsługiwane po stronie Motion i WebPOS. Szczegóły kart produktu: lista produktów.
To rozdzielenie jest ważne:
- Cena katalogowa i promocja nie są tym samym.
- Sklep może mieć cenę bazową pobieraną z Insert GT, a jednocześnie prowadzić promocję w Motion.
- WebPOS odpowiada za logikę Omnibus i za to, aby klient widział właściwą informację przy obniżce.
Dzięki temu system sprzedaży nie udaje, że księgowo-magazynowe źródło ceny rozumie każdy scenariusz promocyjny. Każde narzędzie odpowiada za tę część procesu, do której zostało zaprojektowane.
POS i e-commerce muszą mieć tę samą historię
Omnibus bardzo szybko obnaża niespójność między kanałami sprzedaży. Jeżeli sklep internetowy pokazuje jedną najniższą cenę z 30 dni, a POS w sklepie stacjonarnym inną, klient może zauważyć rozbieżność natychmiast.
To nie jest tylko problem techniczny. To problem zaufania.
Klient nie rozróżnia systemów wewnętrznych. Dla niego marka jest jedna. Jeżeli cena na stronie, przy kasie i na metce nie pasują do siebie, sklep wygląda na chaotyczny albo nieuczciwy, nawet jeśli powodem jest zwykła niespójność danych.
Dlatego historia Omnibus powinna być prowadzona w jednym, kontrolowanym miejscu i synchronizowana tam, gdzie jest potrzebna. POS, WebPOS i e-commerce powinny korzystać z tej samej logiki, a nie z trzech niezależnych interpretacji ceny.
Audit log jest ważniejszy niż zrzut ekranu
Przy Omnibusie nie wystarczy wiedzieć, jaka cena jest widoczna dzisiaj. Trzeba wiedzieć, jak do niej doszło.
- Kto zmienił cenę i kiedy
- Wartość przed i po zmianie
- Czy cena trafiła do historii po okresie korekcyjnym
- Czy była częścią promocji
- Czy została pokazana tak samo w POS i e-commerce
To wszystko powinno być zapisane w logu audytowym.
Bez takiej historii sklep zostaje z pojedynczą wartością na ekranie. Przy pytaniu o źródło ceny trudno wtedy odtworzyć pełną ścieżkę. Z historią zmian można pokazać, skąd wzięła się dana informacja i dlaczego została zaprezentowana klientowi.
To różnica między nerwowym szukaniem dowodów a spokojnym pokazaniem procesu.
Najczęstsze błędy przy Omnibusie
Najwięcej problemów pojawia się nie dlatego, że sklepy ignorują Omnibus. Częściej próbują go wdrożyć zbyt prosto.
Liczenie 30 dni od dzisiaj
To jeden z najczęstszych błędów. Przy długiej promocji system zaczyna traktować cenę promocyjną jako punkt odniesienia, chociaż powinien patrzeć na okres przed obniżką.
Brak okna korekcyjnego
Jeżeli każda pomyłka w cenniku od razu trafia do historii, sklep może sam stworzyć sobie problem. Krótkie opóźnienie zapisu pomaga odróżnić realną cenę od błędu operacyjnego.
Inna historia w POS i sklepie online
Jeżeli kanały sprzedaży korzystają z różnych danych, klient szybko zauważy niespójność. Omnibus wymaga spójnego komunikatu, nie kilku wersji tej samej ceny.
Brak historii zmian
Sama aktualna cena nie wystarcza. Sklep powinien mieć zapis zmian, który pokazuje pełną drogę ceny od wartości katalogowej przez promocję aż do komunikatu widocznego dla klienta.
Jak Motion porządkuje Omnibus
Motion traktuje Omnibus jako proces, który łączy ceny, promocje, historię zmian, POS, WebPOS i e-commerce.
System:
- rozdziela algorytm raportowy od algorytmu prezentowanego klientowi,
- stosuje 30 minut opóźnienia przy zapisie ceny do historii,
- prowadzi historię Omnibus w WebPOS,
- zachowuje logiczny podział między cenami katalogowymi z Insert GT a promocjami obsługiwanymi w Motion.
Dzięki temu sklep nie musi opierać się na przypadkowych wyliczeniach ani ręcznym pilnowaniu historii cen. Ma spójny mechanizm, który wspiera codzienną sprzedaż i jednocześnie zostawia ślad potrzebny do kontroli.
Najważniejsze wnioski
Omnibus wymaga więcej niż jednej ceny przy produkcie
Sklep musi pokazać klientowi właściwą informację o najniższej cenie z 30 dni przed obniżką.
Długie promocje wymagają poprawnego algorytmu
Cena z 30 dni nie powinna być liczona naiwnie od dzisiejszej daty, jeśli promocja trwa dłużej.
30 minut opóźnienia pomaga uniknąć błędów operacyjnych
Krótkie okno korekcyjne chroni historię Omnibus przed przypadkowymi pomyłkami w cenniku.
WebPOS prowadzi historię Omnibus
Insert GT może być źródłem cen katalogowych, ale logika promocji i historii cen działa po stronie Motion i WebPOS.
POS i e-commerce muszą mówić tym samym językiem
Klient powinien widzieć spójny komunikat niezależnie od kanału sprzedaży.
Audit log jest konieczny dla kontroli procesu
Historia zmian pozwala odtworzyć, skąd wzięła się dana cena i kiedy została zapisana.
FAQ
To najniższa cena produktu z 30 dni przed wprowadzeniem obniżki.