Polityka to nazwana kampania usługowa - Twoje dodatki świąteczne, przywileje VIP, stos gwarancji elektroniki. Każda polityka zawiera drzewo warunków (kto kwalifikuje się) i jedną lub więcej reguł usług (co oferujesz i za ile). Twórz nieograniczoną liczbę polityk, sortuj priorytet przez przeciąganie, aktywuj lub wstrzymuj pojedynczo bez dotykania kodu.

Każda reguła definiuje: kod usługi, wielojęzyczną etykietę i opis koszyka (conorderservices_rule_lang), typ wartości (stały, procentowy, progowy), bazę wartości (produkty, koszyk, wysyłka, waga), limity min/max opłaty, grupę reguł podatkowych, ikonę lub wgrany obraz, typ UI (checkbox lub radio), opcjonalną grupę radio i etykietę, flagę wstępnego zaznaczenia, priorytet, daty harmonogramu (ważne od / ważne do) i opcjonalne warunki na poziomie reguły.

Stop on first match kończy ocenę po pierwszej kwalifikującej polityce - przydatne, gdy kampanie nie mogą się nakładać. Strategia łączenia na politykę kontroluje, jak wiele reguł w jednej polityce się łączy: nakładaj wszystkie usługi, wygrywa pierwsze dopasowanie, kaskada priorytetów, tylko najwyższa opłata lub unikalne kody usług. Globalna domyślna strategia łączenia w Ustawieniach dotyczy nowych polityk.

Widok listy polityk pokazuje status, strategię łączenia, liczbę reguł i szybkie akcje. Duplikuj, eksportuj JSON, importuj z pliku lub przełącz aktywność - wszystko z panelu polityk, każda zmiana trafia do dziennika audytu.

Konstruktor warunków to edytor zagnieżdżonego drzewa AND/OR - ten sam wzorzec co w profesjonalnych silnikach reguł, renderowany jako grupy przyjazne przeciąganiu w back office. Dodaj grupę, wybierz pole, operator, ustaw wartość. Zagnieżdżaj grupy dla logiki typu: (grupa VIP LUB 5+ zamówień) AND (suma koszyka ≥ 100 EUR) AND (kategoria Wyprzedaż letnia ma 3+ pozycje).

35 pól warunków obejmuje pełny kontekst koszyka: suma koszyka, subtotal produktów, koszt wysyłki, liczba produktów, liczba unikalnych SKU, waga, liczba reguł koszyka, liczba zamówień klienta, łączne wydatki, dzień tygodnia, godzina, data, kod pocztowy, waluta, kraj, kraj faktury, strefa, grupa klienta, przewoźnik, moduł płatności, status zalogowany/gość, produkty, kategorie, producenci, dostawcy, flagi wirtualne/fizyczne, personalizacja i wykrywanie istniejącej zniżki.

Pola złożone łączą encję + próg w jednym warunku - np. produkt #123 ilość ≥ 3, kategoria #45 suma linii ≥ 50 EUR. Operatory obejmują równość, nierówność, większe/mniejsze, między, na liście, poza listą, zawiera, zaczyna się od, regex, puste i niepuste.

Referencja typów warunków

Każdy wiersz odpowiada dokładnie temu, co wybierasz w rozwijanej liście konstruktora. Pola numeryczne obsługują =, ≠, <, ≤, ≥, > i between. Pola logiczne używają Tak/Nie. Pola wyszukiwania obsługują in i not in z wielokrotnym wyborem. Pola tekstowe dodają contains, starts with i regex. Łącz dowolne pola w zagnieżdżonych grupach AND/OR - silnik sprawdza je przy każdej aktualizacji koszyka.

Pickery produktów, kategorii, producentów i grup używają wbudowanego autouzupełniania. Zdanie podglądu na żywo wyjaśnia, co dopasowuje drzewo. Zaawansowani użytkownicy mogą przełączyć surowy JSON do kopiowania między środowiskami. Warunki są ponownie oceniane przy każdej synchronizacji koszyka - dodanie do koszyka, zmiana ilości, logowanie, zmiana adresu - silnik reaguje natychmiast.

Referencja operatorów

14 operatorów dostępnych w konstruktorze. Typ pola decyduje, które operatory się pojawiają - pola logiczne używają tylko = i ≠; numeryczne mają pełny zestaw porównań.

Każda reguła usługi wybiera typ kwoty: stały, procentowy lub progowy. Stały używa jednej wartości dziesiętnej. Procentowy używa stawki plus bazę wartości - suma produktów, suma koszyka, koszt wysyłki lub waga koszyka. Progowy otwiera tabelę stopniową zapisaną jako JSON (tiers_json) z przedziałami od/do i opłatą na przedział.

Min opłata i max opłata ograniczają obliczenia procentowe, aby ubezpieczenie nigdy nie spadło poniżej 2 EUR ani nie przekroczyło 50 EUR. Grupa reguł podatkowych na regułę zapewnia poprawne VAT na pozycji usługi. Pola harmonogramu (date_from / date_to) ograniczają oferty sezonowe bez wyłączania całej polityki.

Za UI stoi ConorderservicesEngine, który rozwiązuje kwalifikujące reguły, oblicza każdą opłatę z kontekstu koszyka na żywo, stosuje strategię łączenia i zapisuje łączną kwotę do dynamicznego SpecificPrice na wspólnym produkcie usługowym. Chipy podsumowania reguł w adminie pokazują aktywny cennik na pierwszy rzut oka bez otwierania edytora.

Konstruktor progów w adminPolicyRules.js wizualnie dodaje/usuwa wiersze. Powrót z progowego na stały zachowuje pozostałe ustawienia reguły. Importuj politykę ze stagingu, otwórz kartę reguły, zmień jeden próg, zapisz - dane strukturalne pozostają spójne.

Kwalifikujące usługi renderują się w dedykowanym panelu kasy przez displayShoppingCart, displayShoppingCartFooter lub displayCheckoutSummaryTop - pozycja konfigurowalna w Ustawieniach. Każdy wiersz oferty pokazuje checkbox lub radio, opcjonalną ikonę/obraz, nazwę, opis i obliczoną etykietę ceny.

Klient przełącza usługi przez front AJAX controller (checkout.js + endpoint ajax modułu). Sumy koszyka i etykiety pozycji aktualizują się bez przeładowania strony. Panel odświeża się też przy zmianie ilości w koszyku. Zdarzenia wyboru trafiają do audytu (service_selected, service_deselected). Zdarzenia wyświetlenia logują się, gdy panel jest pokazany (deduplikowane per zestaw kwalifikujących).

Wybrane usługi synchronizują się do jednego ukrytego produktu katalogowego (CONORDERSVC-SERVICE) z dynamicznym SpecificPrice na koszyk. Wiele wyborów pojawia się jako jedna pozycja koszyka z wielojęzycznymi etykietami rozdzielonymi przecinkami i łączną kwotą. Stan koszyka trwa w conorderservices_cart z migawką kwalifikujących, JSON wybranych usług i migawką zastosowanych dla idempotentnej synchronizacji.

Hooki actionCartSave, hooki usuwania produktu z koszyka, actionPresentCartProduct i actionProductPriceCalculation utrzymują pozycję usługi w sync, gdy koszyk się zmienia. Kompatybilne z motywami PrestaShop 9, 8, 1.7, w tym miniaturki koszyka Hummingbird przez actionPresentProduct.

Każda reguła usługi wspiera wizualną tożsamość w kasie: wgraj JPG/PNG/GIF/WebP do views/img/services/ lub wklej zewnętrzny URL HTTPS. ConorderservicesRuleImage obsługuje walidację uploadu, storage, rozwiązywanie publicznego URL i bezpieczne usuwanie przy wymianie lub usunięciu obrazów.

Dedykowany UI edytora obrazów (adminPolicyRuleImage.js) pokazuje podgląd na żywo, kontrolki usuń/zamień i fallback poprzedniego obrazu przy zapisie. Przy duplikacji lub imporcie polityki obrazy są klonowane lub referencjonowane bezpiecznie, aby transfer staging-produkcja nie psuł wizualiów kasy.

Rozmiar ikony (1-256 px), pozycja ikony (lewo/środek/prawo) i wyrównanie kontrolek to globalne Ustawienia - jeden sklep może pokazywać duże ikony pakowania prezentowego po lewej, inny kompaktowe checkboxy po prawej. Przełączniki pokaż/ukryj nazwę, opis, cenę i ikonę per sklep domykają warstwę prezentacji.

Zakładka Symulator to trzyetapowy workflow na prawdziwych danych w bazie - nie mock koszyka. Krok 1: wyszukaj koszyki po ID, nazwisku lub e-mailu klienta. Krok 2: wybierz koszyk z listy na żywo (pokazuje klienta, e-mail, sumę koszyka, ostatnią aktualizację). Krok 3: uruchom ocenę i przeczytaj pełny breakdown wyników.

Wyniki pokazują, które polityki pasowały, które pominięto (i dlaczego), obliczone opłaty per reguła, stan kwalifikujących vs wybranych, rozstrzygnięcie grup radio i podgląd pozycji koszyka z łączną etykietą i kwotą. Opcjonalny filtr klienta zawęża listę koszyków do jednego konta - idealne do odtworzenia ticketu supportu.

Każde uruchomienie symulacji trafia do dziennika audytu z typem zdarzenia simulation_run, ID koszyka, aktorem (pracownikiem) i migawką wyniku. Merchandising może zweryfikować kampanię przed włączeniem. Support może wyjaśnić, dlaczego konkretny koszyk klienta widział lub nie widział pakowania prezentowego - bez składania testowego zamówienia na żywym sklepie.

Używaj symulatora po każdej edycji polityki, przed startem świątecznym i przy imporcie polityk ze stagingu. To siatka bezpieczeństwa, która oddziela enterprise zarządzanie usługami od „zmień i miej nadzieję”.

Zakładka Panel to centrum dowodzenia opcjonalnymi usługami. Karty KPI za wybierany okres (30 / 90 / 180 / 365 dni) pokazują: wyświetlenia panelu, wybory w kasie, zamówienia z usługami, współczynnik zakupu i przychód z usług w walucie sklepu. Liczby pochodzą z dziennika audytu - prawdziwe zdarzenia, nie szacunki.

Wykresy trendów Chart.js wizualizują lejek przychodów w trzech granularnościach: dziennie (konfigurowalne okno), tygodniowo i miesięcznie. Linie śledzą wyświetlenia, wybory, opłacone zamówienia i przychód z usług na drugiej osi. Przełącz domyślny typ wykresu w Ustawieniach. Wykres kołowy rozbija opłacony przychód według kodu usługi, abyś widział, które dodatki faktycznie konwertują.

Tabela per usługa listuje każdy kod usługi z wyświetleniami, wyborami, zamówieniami, przychodem i współczynnikiem zakupu. Wybory to krok lejka - zamówienia i przychód to prawda KPI (unika metryk próżności z przełączeń checkboxów, które nigdy nie konwertują). Ostatnie wpisy audytu pojawiają się na panelu do szybkiej diagnostyki.

Dla agencji i operatorów multistore: panel odpowiada na pytanie merchandisingu - „Czy nasze dodatki w kasie faktycznie się sprzedają?” - danymi, nie przeczuciem.

Dedykowana zakładka Dziennik audytu to pełny dziennik zdarzeń - nie plik debug ukryty w logach serwera. Każdy wiersz przechowuje znacznik czasu, typ zdarzenia, aktora (nazwa pracownika, klienta lub SYSTEM), czytelne podsumowanie, powiązane zamówienie, kod usługi, kwotę opłaty, ID koszyka i ID polityki/reguły.

20+ typów zdarzeń jest śledzonych:

• service_impression - panel kasy pokazany koszykowi
• service_selected / service_deselected - klient przełącza usługę
• service_applied - usługi zsynchronizowane do pozycji koszyka
• order_services - zamówienie złożone z przychodem z usług (per linia)
• order_validated - hook walidacji zamówienia uruchomiony
• policy_created, policy_updated, policy_deleted, policy_toggled
• policy_duplicated, policy_imported, policy_exported
• rule_created, rule_updated, rule_deleted, rule_toggled
• preset_applied - preset warunków załadowany do konstruktora
• settings_updated - zmiana konfiguracji modułu
• simulation_run / simulation - ocena koszyka w back office

Kliknij Pokaż na dowolnym wierszu, aby otworzyć modal szczegółów z pełną migawką JSON - zastosowane linie usług, diff polityki, wynik symulacji lub payload zmiany ustawień. Zastosowania usług przechowują fee_snapshot, aby odtworzyć dokładnie to, co klient widział w kasie.

Lista wspiera natywny eksport CSV PrestaShop do przeglądów finansowych i compliance. Połączone kolumny pokazują referencję zamówienia, nazwę klienta i pracownika bez ręcznego cross-referencingu. Na stronie zamówienia w back office (hook displayAdminOrder) panel pokazuje, które opcjonalne usługi wniosły wkład w zamówienie - nazwa usługi, kod, kwota i migawka.

Polityki to przenośne dokumenty JSON. Eksport pobiera pełną politykę - drzewo warunków, wszystkie reguły, konfiguracje cennika, strategię łączenia, metadane obrazów usług, pozycje - gotowe do kontroli wersji lub przekazania innemu sklepowi. Import wgrywa plik JSON i tworzy nową politykę z wpisem policy_imported w dzienniku audytu.

Duplikacja klonuje politykę jednym kliknięciem z menu akcji listy przez ConorderservicesPolicyDuplicator - kopiuje każdą regułę, zmienia nazwę z sufiksem, bezpiecznie klonuje obrazy, loguje policy_duplicated. Idealne do tworzenia „Święta v2” z „Święta v1” bez ręcznego odtwarzania 10 reguł.

Typowy workflow agencji: zbuduj i symuluj na stagingu → eksportuj JSON → importuj na produkcję → uruchom symulator ponownie → włącz. Sezonowe konfiguracje usług przenoszą się między sklepami klientów w minuty. Każdy transfer jest śledzony w dzienniku audytu.

Zakładka Ustawienia centralizuje zachowanie całego sklepu. Główny przełącznik włącz/wyłącz. Globalna strategia łączenia domyślna dla nowych polityk. Domyślna grupa reguł podatkowych dla nowych reguł usług. ID produktu usługowego - wybierz, który produkt katalogowy reprezentuje pozycję koszyka, lub użyj auto-utworzonego ukrytego produktu CONORDERSVC-SERVICE.

Pozycja wyświetlania kontroluje, gdzie renderuje się panel kasy: zintegrowany blok podsumowania koszyka, tylko strona koszyka, tylko podsumowanie kasy, hooki motywu koszyk i kasa, lub poniżej listy produktów koszyka. Ustawienia wyświetlania ofert kontrolują pokaż/ukryj nazwę, opis, cenę i ikonę; rozmiar ikony (1-256 px); pozycję ikony (lewo/środek/prawo); wyrównanie kontrolek checkbox/radio.

Log debug zapisuje szczegółowe ślady silnika dla supportu. Sekcja analityki konfiguruje domyślny okres wykresu (30/90/180/365 dni), okna wykresów dziennych/tygodniowych/miesięcznych i domyślny typ wykresu. Podgląd na żywo w Ustawieniach pokazuje, jak wiersze ofert będą wyglądać przy bieżących opcjach wyświetlania.

Każdy zapis ustawień loguje settings_updated do dziennika audytu z migawką przed/po. Bez cichego dryfu konfiguracji.

Usługi materializują się jako prawdziwa pozycja koszyka na wspólnym ukrytym produkcie z dynamiczną ceną i wielojęzyczną etykietą. Pojawiają się w podsumowaniu koszyka, kasie, potwierdzeniu zamówienia, fakturach i widoku zamówienia w back office - dokładnie jak normalna pozycja produktu, bez hacków motywu ani fałszywych ujemnych kwot.

Silnik podpina się pod actionCartSave, dodawanie/usuwanie produktu, init front controller, walidację zamówienia (actionValidateOrder, actionValidateOrderBefore na PS 8.1+) i prezentację koszyka - przeliczając przy każdej zmianie kontekstu koszyka. Kolumny tabeli zamówień conorderservices_service_amount i conorderservices_service_snapshot przechowują historyczne sumy usług na rekordzie zamówienia.

Polityki są ograniczone do sklepu (id_shop) dla multistore. Każdy sklep w grupie może prowadzić niezależne stosy usług. PrestaShop 9, 8 i 1.7 dzielą jedną bazę kodu przez lib/prestashop9compatibility.php i ConorderservicesCompatibility.

Wielojęzyczne etykiety kasy per reguła (conorderservices_rule_lang) zapewniają poprawny odczyt pozycji usługi w każdym aktywnym języku sklepu. 30 gotowych pakietów tłumaczeń obejmuje back office i front office przez PrestaShop l() - od angielskiego, niemieckiego i polskiego po hiszpański, francuski, włoski i rynki w całej Europie i Azji.