Osoba pobiera 10 dolarów, ale 9.87 dolara zostaje odliczone. Nikt nie jest w błędzie. Wózek działa dokładnie tak, jak został zaprojektowany. Powód leży zaledwie kilka warstw pod ekranem.
Jak działa proces finalizacji zamówienia w PrestaShop? Pytania zazwyczaj sprowadzają się do tej samej odpowiedzi: co jest uruchamiane i jaki jest jego priorytet. Po wykonaniu tej czynności, błędne wyniki stają się przewidywalne. Poniżej przedstawiono przebieg procesu finalizacji zamówienia w PrestaShop, od koszyka do zamówienia, wykorzystując kod wysyłki, a nie to, co sugeruje ekran ustawień.
1.0 Co dzieje się wewnętrznie podczas procesu realizacji zamówienia w PrestaShop
Zapytaj koszyk o jego wartość, a PrestaShop odda to zadanie w ręce klasy kalkulatora. Nie pojedyncza formuła. Trzy oddzielne przebiegi, zawsze w tej samej kolejności, każdy bazujący na poprzednim.
Rzędy, potem opłaty, a potem rabaty. Zmiana ich kolejności nie wchodzi w grę.
Najpierw rzędy. Każda linia ma swoją cenę, ilość i stawkę podatku, co jest szczegółem wyjaśniającym większość poniższych informacji. Opłaty są na drugim miejscu: wysyłka i pakowanie prezentów, obliczone i celowo oddzielone od towarów, aby kupon mógł usunąć jeden z nich bez dotykania drugiego. Zniżki naliczane są na końcu.
Ta trzecia pozycja ma znaczenie. Rozwiązuje większość problemów z kalkulacją koszyka PrestaShop , ponieważ kupon nigdy nie zmienia pierwotnych cen. Dotyczy to zarówno wierszy, jak i kodów kuponów zastosowanych przed nim.
2.0 W jaki sposób PrestaShop oblicza całkowitą wartość koszyka?
Suma nie jest kwotą, którą sklep gdzieś przechowuje. Jest obliczana na żądanie, a dzwoniący podaje, jakie części chce: tylko produkty, tylko rabaty, wszystko lub wszystko oprócz wysyłki.
Warto wiedzieć, ponieważ części nie zawsze pokrywają się z oczekiwaniami. Weźmy pod uwagę próg darmowej wysyłki. Wymaga on podania kwoty całkowitej bez kosztów wysyłki, ale z uwzględnieniem rabatów. Jeśli zadajesz inne pytanie, otrzymasz inną odpowiedź. Obie odpowiedzi są poprawne.
Zatem liczba na ekranie może się różnić od liczby w raporcie. Żadna z nich nie jest błędna. Mogą po prostu prosić o różne części tego samego wózka, więc sprawdź, która część jest uszkodzona, zanim założysz, że coś jest zepsute.
3.0 Jak działają zasady koszyka w PrestaShop?
Reguły koszyka PrestaShop składają się w rzeczywistości zarówno z kuponu wprowadzanego przez klienta, jak i automatycznych rabatów, które naliczają się bez kodu. W zapleczu oba elementy stanowią ten sam obiekt. Dlatego dzielą jeden ekran w zapleczu i jedną ścieżkę przez kod.
Reguły są stosowane pojedynczo, sortowane według priorytetu, od najniższego. Priorytet to po prostu liczba ustawiana w regule. Robi więcej niż tylko je porządkuje: gdy dwóch reguł nie da się połączyć, priorytet decyduje, która z nich zostanie zachowana.
Każda reguła traktuje koszyk tak, jak go zostawiła poprzednia. Zatem dwa kupony 10% na koszyku o wartości 100 nie odejmują 20. Pierwszy pobiera 10. Drugi pobiera 10% z pozostałych 90, a klient oszczędza 19. Standardowe zachowanie, a nie artefakt zaokrąglania.
Same warunki są znane większości sprzedawców: zakresy dat, minimalna kwota, limity dla każdego klienta oraz wyłączenia według kraju, grupy, firmy spedycyjnej lub produktu. Własna dokumentacja reguł koszyka PrestaShop szczegółowo opisuje każde pole, więc nie ma sensu ich ponownie opisywać.
4.0 Jak stosowane są kupony w PrestaShop?
Właśnie w tym miejscu system kuponów PrestaShop staje się interesujący. Stąd też bierze się ta cena 9.87. Rabaty procentowe i rabaty o stałej kwocie są traktowane zupełnie inaczej, a różnica nie jest kosmetyczna.
Procent jest prosty. Każdy wiersz traci swój procent, więc kupon na 10% zniżki obniża cenę książki o 10% i słuchawki o 10%. Każdy wiersz zachowuje swoją własną stawkę podatku, nikt nie musi się nad tym zastanawiać.
Stała kwota nie może działać w ten sposób, ponieważ koszyk musi najpierw zdecydować, z których wierszy pieniądze powinny zostać pobrane. PrestaShop rozdziela je proporcjonalnie: każdy wiersz otrzymuje część zniżki odpowiadającą udziałowi tego wiersza w koszyku.
Kwota 10 jest dzielona według wkładu każdej linii, a nie równo między linie.
To jest sedno obliczania rabatów PrestaShop na podstawie kuponów kwotowych. Ma to swoje konsekwencje, o których warto wiedzieć. Każdy wiersz ma swoją własną stawkę podatku, więc kwota potrąconego podatku zależy od tego, na które produkty zostanie naliczona zniżka. Przeniesienie tej samej kwoty 10 do koszyka o innej wadze spowoduje zmianę całkowitej kwoty podatku, mimo że klient zaoszczędził dokładnie taką samą kwotę.
Drugie ustawienie również ma tu znaczenie. Czy kwota vouchera jest zdefiniowana z uwzględnieniem podatku, czy bez? Ta flaga decyduje, od której wartości obliczane są udziały, więc w jednym przypadku 10 jest odejmowane od cen z uwzględnieniem podatku, a w drugim przypadku odejmowane jest przed opodatkowaniem, a oszczędność, jaką widzi klient, jest nieco inna.
5.0 W jaki sposób PrestaShop oblicza podatek podczas realizacji transakcji?
Obliczanie podatku w PrestaShop odbywa się dla każdego wiersza, a nie dla całego koszyka. Każdy produkt ma przypisaną grupę reguł podatkowych; grupa ta odpowiada stawce dla adresu dostawy, a wiersz jest opodatkowany według tej stawki.
Koszyk to zatem kilka małych kwot podatku zsumowanych razem. Nic nie oblicza „podatku od tego zamówienia” za jednym razem. Dlatego rozbicie podatku na fakturze może obejmować kilka pozycji, nawet w przypadku krótkiego zamówienia, i dlaczego te pozycje rzadko dzielą się równo.
Wysyłka jest ponownie opodatkowana osobno. Obowiązuje zasada podatku od przewoźnika, a nie od produktów, co powoduje, że klienci kupują produkty objęte stawką zerową, ale dostawa już nie.
6.0 Dlaczego PrestaShop oblicza inną wartość koszyka
Dwie sumy różnią się o centa? Zazwyczaj przyczyną jest zaokrąglenie, a PrestaShop oferuje trzy sposoby, aby to zrobić.
Te same trzy elementy uzyskują dwie różne sumy w zależności od jednego ustawienia.
Ceny są przechowywane wewnętrznie z dokładnością do sześciu miejsc po przecinku. Jedynym pytaniem jest więc, gdzie następuje zaokrąglenie. Zaokrąglając każdy element, zaokrąglasz cenę jednostkową przed przemnożeniem czegokolwiek. Zaokrąglając każdy wiersz, zachowujesz pełną precyzję aż do zsumowania wiersza. Zaokrąglając sumę, nic nie jest zaokrąglane aż do samego końca.
Żadna z tych trzech opcji nie jest błędna. Po prostu się nie zgadzają. Zaokrąglanie w linii to powszechna rada dla sklepów, które potrzebują, aby faktury dokładnie się sumowały, ponieważ zapewnia to wewnętrzną spójność każdej linii, a jednocześnie pozwala na ich czyste sumowanie. Własne notatki PrestaShop dotyczące obliczania cen szczegółowo omawiają to uzasadnienie.
Zanim zrzucisz winę na zaokrąglanie, wyklucz prostsze wyjaśnienia. Suma, która zmienia się po zmianie adresu, to podatek, a nie zaokrąglenie. Suma, która zmienia się po dodaniu kuponu, to kalkulacja zamówienia w PrestaShop, która działa prawidłowo. Różnice w zaokrąglaniu to grosze. Każda większa kwota ma inną przyczynę.
7.0 W jaki sposób PrestaShop oblicza jednocześnie rabaty i podatki
Łącząc te dwie połówki: zniżki są naliczane po obliczeniu podatku dla każdego wiersza, a zniżka zmniejsza zarówno wiersz, jak i podatek w nim zawarty proporcjonalnie.
To właśnie ta kolejność sprawia, że logika płatności w PrestaShop jest przewidywalna. Podatek nigdy nie jest przeliczany od nowa po zastosowaniu rabatu. Każdy wiersz zawiera już swoją stawkę, więc usunięcie części wiersza powoduje usunięcie odpowiadającej mu części podatku.
Odpowiada również na często zadawane pytanie: dlaczego łączna kwota podatku od zamówienia z kuponami nie jest po prostu stawką podatku zastosowaną do kwoty z rabatem? Ponieważ jest to suma wartości zawartych w wierszach, a wiersze te początkowo miały różne wartości procentowe.
8.0 Budowa modułu, który daje zniżkę
Prędzej czy później ktoś poprosi o zniżkę, której PrestaShop nie jest w stanie sam wygenerować. Wydaj określoną kwotę i otrzymaj darmowy produkt. Poziom lojalnościowy. Coś powiązanego z wartością, której sklep nie śledzi. Kuszące jest samodzielne obliczenie sumy i odjęcie jej w dogodnym dla siebie miejscu.
Sprzeciwiaj się temu. Rabat zastosowany poza systemem reguł koszyka jest niewidoczny dla wszystkich, którzy go czytają. Podsumowanie zamówienia nie będzie o tym informować, faktura go nie wyświetli, a rozbicie podatku będzie nieprawidłowe, ponieważ podatek jest naliczany dla każdego wiersza, a odejmowane kwoty nigdy nie zostały uwzględnione.
Zamiast tego stwórz prawdziwą regułę CartRule. Twój moduł decyduje, kiedy ma ona zastosowanie i ile jest warta, a następnie przekazuje zniżkę do PrestaShop jako odpowiednią regułę. Wszystko, co następuje później, działa bez dalszej pomocy: podsumowanie, faktura, podatek od wiersza, priorytetyzacja zamówień względem innych kuponów.
Moduł musi jeszcze odpowiedzieć na jedno pytanie, na które rdzeń nie potrafi odpowiedzieć: czy ta reguła nadal powinna istnieć? Reguła utworzona przez moduł powinna przestać obowiązywać w momencie jego wyłączenia. Nic w PrestaShop tego nie wie, ponieważ dla PrestaShop reguła jest po prostu kolejnym wierszem w tabeli.
9.0 Bezpieczne nadpisywanie checkValidity
Hakiem dla tego jest CartRule::checkValidity() . PrestaShop wywołuje ją po dodaniu kuponu oraz ponownie za pomocą autoRemoveFromCart() w koszykach, które już zawierają reguły. To drugie wywołanie jest przydatne: zwraca błąd, a reguła jest automatycznie usuwana z koszyka.
Zatem nadpisanie jest krótkie. Sprawdź, czy reguła należy do Twojego modułu, sprawdź, czy moduł jest włączony, a jeśli nie, poinformuj o tym. Cała reszta trafia bezpośrednio do modułu nadrzędnego.
Przy pisaniu ważne są trzy rzeczy.
W każdym innym przypadku zadzwoń do rodzica. Nadpisanie, które odpowiada we własnym imieniu, zamiast odkładać, po cichu odrzuca każdą kontrolę przeprowadzaną przez PrestaShop: daty, limity ilościowe, kwoty minimalne, ograniczenia kraju i przewoźnika. Łatwo o tym zapomnieć, a utrata jest kosztowna.
Działaj tylko zgodnie z własnymi regułami. Zidentyfikuj je za pomocą czegoś trwałego, takiego jak prefiks kodu, którego właścicielem jest Twój moduł, lub rekord we własnej tabeli. Nadpisanie, które uruchamia każdą regułę w sklepie, to ryzyko podejmowane w imieniu całego sklepu i jednego modułu.
Szanuj flagę alreadyInCart. PrestaShop celowo pomija sprawdzanie aktywności i daty dla reguł, które są już zastosowane, aby kupon, który był ważny w momencie, gdy klient z niego skorzystał, nie zniknął w trakcie finalizacji zamówienia. Twoje sprawdzenie jest inne: wyłączony moduł powinien usunąć regułę nawet z koszyka, który już ją ma, a właśnie do tego służy automatyczne usuwanie.
Dopasuj również kształt zwracany. Metoda zwraca fałsz, gdy reguła jest poprawna, i komunikat, gdy nie. Zwróć niewłaściwą wartość, a wywołujący odczytają odmowę jako akceptację.
10.0 Czyszczenie i zastrzeżenie dotyczące nadpisywania
Wyłączenie modułu powinno również zatrzymać tworzenie reguł. Funkcja nadpisywania obsługuje koszyki w trakcie pracy; sam moduł powinien przestać generować nowe reguły, gdy jest wyłączony, a po odinstalowaniu powinien dezaktywować lub usunąć te, które utworzył, zamiast pozostawiać je do ponownego rozpracowania przez kolejną osobę.
Warto wyraźnie zaznaczyć jedno zastrzeżenie. Jednocześnie może być aktywne tylko jedno nadpisanie klasy, więc dwa moduły nadpisujące CartRule będą ze sobą kolidować, a drugi, który zostanie zainstalowany, zazwyczaj przegrywa. Jeśli rabat można wyrazić za pomocą warunków, które rdzeń już obsługuje, użyj ich i całkowicie pomiń nadpisanie. Sięgaj po nie tylko wtedy, gdy reguła zależy od czegoś, czego PrestaShop naprawdę nie widzi.
11.0 Co zmieniło się między PrestaShop 1.7 a 9
Warto wiedzieć, jeśli korzystasz ze starszego poradnika lub czytasz odpowiedzi na forum sprzed lat. Część z nich nadal jest aktualna. Część nie.
Kalkulator opisany powyżej pojawił się w wersji 1.7 i kolejność trzech przebiegów nie uległa zmianie od tamtej pory. Porównując kody w wersjach 8.2 i 9, kolejność jest identyczna. Reguły nadal są stosowane w kolejności priorytetów. Rabaty kwotowe nadal są rozłożone proporcjonalnie. Trzy tryby zaokrąglania nadal działają tak jak zawsze.
To, co się zmieniło, to powierzchnia. PrestaShop 9 kontynuuje migrację stron back-office do Symfony, więc ekrany zostały przebudowane, a niektóre pola znajdują się gdzie indziej niż wcześniej. Ścieżki menu dla rabatów pozostały niezmienione. Zrzut ekranu z samouczka do wersji 1.7 nie będzie jednak odpowiadał temu, co widać na ekranie: porady dotyczące obliczeń nadal obowiązują, ale porady dotyczące tego, gdzie kliknąć, mogą już nie.
12.0 Obliczanie przyczyn, dla których suma wygląda nieprawidłowo
Oto krótka instrukcja odprawy. Każdy krok wyklucza kroki następujące po nim, co oszczędza nam szukania ustawienia zaokrąglania, gdy odpowiedzią jest automatyczny rabat, o którym nikt nie pamiętał.
Zacznijmy od reguł koszyka dotyczących zamówienia. Które z nich miały zastosowanie i w jakiej kolejności? Reguła, o której ktoś zapomniał, że jest automatyczna, to najczęstsza odpowiedź na całe pytanie.
Następnie sprawdź, czy kupon jest wyrażony procentowo, czy kwotowo. Jeśli jest kwotowy, sprawdź, czy jest oznaczony jako „z podatkiem”, czy „bez podatku”. Już sama ta flaga odpowiada za wiele zgłoszeń „rabat jest nieznacznie obniżony”.
Następnie, spójrz na stawki podatkowe dla poszczególnych produktów, a nie na cały koszyk. Mieszane stawki w jednym koszyku są całkowicie normalne. Po prostu sprawiają, że obliczenia wydają się dziwniejsze niż są w rzeczywistości.
Dopiero wtedy rozważ zaokrąglenie. I tylko wtedy, gdy różnica wynosi jeden lub dwa centy, ponieważ większa różnica oznacza, że dzieje się coś innego. Sprawdź tryb zaokrąglania w ustawieniach, aby porównać go z oczekiwaną kwotą na fakturze.
13.0 Wersja skrócona
Proces realizacji zamówienia w PrestaShop jest bardziej przewidywalny, niż się wydaje. Ceny i podatki są naliczane w pierwszej kolejności. Opłaty są na drugim miejscu, rabaty na ostatnim, a każdy rabat naliczany jest na podstawie kwoty, która pozostała po poprzednim.
Bony o stałej wartości są rozdzielane między wiersze według wagi, dzięki czemu każdy wiersz ma swoją własną stawkę podatku. Procenty są prostsze i dotyczą każdego wiersza bezpośrednio. A gdy dwie sumy różnią się o jeden grosz, zazwyczaj jest to wina ustawienia zaokrąglania, a nie błędu.
Dziękuję za przeczytanie.
Jeśli masz pytania lub potrzebujesz pomocy w zakresie wydajności lub migracji witryny, nasi eksperci są do Twojej dyspozycji. Skontaktuj się z zespołem Knowband pod adresem [email protected] już dziś, aby uzyskać niezawodne wtyczki eCommerce dopasowane do Twoich potrzeb.
