Jedna metoda dostawy to za mało – DC Ship2Pay rozpoznaje konkretne opcje wysyłki w OpenCart 3

Moduły typu Ship2Pay nie są niczym nowym. Ich zadanie jest proste: wybieramy metodę dostawy i określamy, jakie metody płatności mają być dla niej dostępne.

Jeżeli klient wybierze przesyłkę kurierską, możemy pozwolić na przelew, kartę i pobranie. Jeżeli wybierze odbiór osobisty, możemy zostawić gotówkę i płatność online. Na pierwszy rzut oka temat wydaje się właściwie rozwiązany.

Problem zaczyna się wtedy, gdy przyjrzymy się temu, jak rzeczywiście działają bardziej rozbudowane moduły wysyłkowe w OpenCart 3.

Jedno rozszerzenie wysyłki nie musi zwracać jednej metody dostawy. Może zwrócić kilka różnych usług. Ten sam moduł może obsługiwać kuriera, automat paczkowy, punkt odbioru albo kilka wariantów dostawy różniących się ceną i sposobem realizacji. Dla klienta są to osobne opcje. Dla typowego modułu Ship2Pay bardzo często nadal jest to jednak jedno rozszerzenie wysyłkowe.

I właśnie tutaj pojawił się problem, dla którego napisałem DC Ship2Pay .

Nie chciałem tylko sparować rozszerzenia wysyłki z płatnością - to już zresztą jest. Chciałem zejść poziom niżej i móc powiedzieć:  dla tej konkretnej usługi zwracanej przez moduł wysyłkowy pokaż te płatności, a dla drugiej usługi tego samego modułu pokaż zupełnie inne .

To niewielka różnica w opisie, ale bardzo duża różnica w działaniu. 

Jeśli jesteś zainteresowany wdrożeniem tego typu rozwiązania przejdź na: tworzenie sklepów internetowych Opencart.

 

Metoda wysyłki i opcja wysyłki to nie zawsze to samo

Załóżmy, że mamy rozszerzenie wysyłkowe o technicznym kodzie:

myshipping

Najprostszy moduł mógłby zwrócić jedną ofertę:

myshipping.myshipping

Ale nic nie stoi na przeszkodzie, aby ten sam model zwrócił kilka quote'ów:

myshipping.courier

myshipping.locker

myshipping.pickup

Z punktu widzenia użytkownika są to trzy różne sposoby otrzymania zamówienia. Jeden oznacza kuriera pod drzwi, drugi dostawę do automatu, a trzeci odbiór w punkcie.

I teraz załóżmy, że płatność za pobraniem ma być dostępna tylko dla kuriera .

Jeżeli system Ship2Pay patrzy wyłącznie na rozszerzenie myshipping , nie potrafi tego rozróżnić. Albo włączy pobranie dla całego rozszerzenia, albo je wyłączy.

DC Ship2Pay pracuje natomiast na pełnym kodzie wybranej oferty dostawy. Dzięki temu myshipping.courier oraz myshipping.locker mogą posiadać dwie całkowicie różne konfiguracje płatności.

To jest najważniejsza idea całego modułu.

 

Dlaczego napisałem DC Ship2Pay?

Powód był bardzo praktyczny. W coraz większej liczbie sklepów jedna integracja logistyczna obsługuje kilka usług. Sam fakt, że w panelu OpenCart widzimy jedno zainstalowane rozszerzenie wysyłki, nie oznacza jeszcze, że klient zobaczy w checkoutcie jedną opcję.

Może zobaczyć ich kilka.

Klasyczna relacja:

metoda wysyłki → płatności

przestaje wtedy wystarczać.

Potrzebna jest raczej relacja:

konkretna oferta dostawy → płatności .

Chciałem więc przygotować moduł, który najpierw spróbuje odkryć wszystkie quote'y generowane przez zainstalowane rozszerzenia wysyłkowe, pokaże je administratorowi jako osobne pozycje, a dopiero potem pozwoli stworzyć macierz płatności.

Nie chciałem przy tym wprowadzać własnego systemu checkout ani modyfikować plików Core OpenCart. DC Ship2Pay ma zrobić jedną rzecz i zrobić ją możliwie czysto: po wyborze sposobu dostawy przefiltrować standardową listę metod płatności.

Przyznaję że moduł bardzo ułatwił tworzenie sklepów internetowych w naszej firmie w przestrzeni parowania z płatnościami rozbudowanych metod wysyłki jak InPost czy DPD.

 

Czym jest DC Ship2Pay?

DC Ship2Pay 1.0.0 jest modułem dla OpenCart 3 pozwalającym określić, które metody płatności są dostępne dla poszczególnych opcji wysyłki.

Najważniejsze jest tutaj określenie poszczególnych opcji .

Moduł nie ogranicza się do kodu samego rozszerzenia wysyłkowego. Próbuje wykryć pełne kody quote w formacie:

extension.subcode

i właśnie te kody umieszcza w macierzy konfiguracyjnej.

Administrator może więc otrzymać osobne wiersze dla kilku usług pochodzących z tego samego rozszerzenia.

Każdy taki wiersz posiada własny zestaw przełączników metod płatności.

Zobacz na wideo jak działa filtrowanie metod płatności przy wybieraniu metod wysyłki:

 

Jak DC Ship2Pay wykrywa opcje wysyłki?

To jedna z ciekawszych części modułu.

Nie mogłem po prostu pobrać listy zainstalowanych rozszerzeń shipping, ponieważ wtedy wróciłbym do punktu wyjścia. Wiedziałbym, że zainstalowany jest np. moduł myshipping , ale nadal nie wiedziałbym, że zwraca on myshipping.courier , myshipping.locker i myshipping.pickup .

Dlatego Shipping Discoverer próbuje odnaleźć konkretne quote'y.

Pierwszym źródłem jest kod modelu rozszerzenia wysyłki. DC Ship2Pay analizuje zainstalowane modele znajdujące się w:

catalog/model/extension/shipping/

i szuka charakterystycznych konstrukcji wykorzystywanych w OpenCart do budowania ofert dostawy.

Potrafi wykryć między innymi zapis pełnego kodu quote:

'code' => 'extension.subcode'

oraz konstrukcje oparte na:

$quote_data['subkey']

Znaleziony podkod jest następnie łączony z nazwą rozszerzenia, dzięki czemu powstaje pełny identyfikator usługi.

 

Wykrywanie usług zapisanych w konfiguracji

Nie wszystkie moduły budują listę usług wprost w kodzie modelu.

Część moich własnych i innych bardziej rozbudowanych rozszerzeń przechowuje dostępne usługi w konfiguracji.

DC Ship2Pay próbuje więc również odczytać tablice w rodzaju:

shipping_{extension}_services

Jeżeli znajdują się tam zdefiniowane usługi, ich kody i nazwy również mogą zostać wykorzystane do zbudowania macierzy.

Dodałem także dodatkowy fallback dla rozszerzeń przechowujących konfigurację poszczególnych usług jako osobne klucze module_* , np. z własnym tytułem, statusem czy ceną.

Dzięki temu mechanizm wykrywania nie opiera się tylko na jednym konkretnym sposobie napisania rozszerzenia shipping.

 

Co jeżeli moduł wysyłki ma tylko jedną metodę?

Wtedy wszystko działa normalnie.

Jeżeli DC Ship2Pay nie znajdzie osobnych quote'ów, tworzy klasyczny kod:

extension.extension

Nie trzeba więc posiadać rozbudowanego modułu wielousługowego, żeby korzystać z rozszerzenia.

DC Ship2Pay nadal może pełnić rolę zwykłego Ship2Pay. Jego przewaga pojawia się po prostu wtedy, kiedy pojedyncze rozszerzenie dostawy zaczyna zwracać więcej niż jedną ofertę.

 

Jak wykrywane są płatności?

Po drugiej stronie macierzy znajduje się Payment Discoverer .

Moduł analizuje zainstalowane rozszerzenia płatności znajdujące się w standardowym katalogu:

admin/controller/extension/payment/

i porównuje je z listą rozszerzeń płatniczych zainstalowanych w OpenCart.

Dla każdej znalezionej metody pobierany jest jej kod, nazwa oraz aktualny status.

W efekcie panel może automatycznie zbudować relację:

każda wykryta opcja wysyłki × każda zainstalowana metoda płatności .

Nie muszę ręcznie wpisywać kodów płatności w polach tekstowych.

 

Macierz zamiast skomplikowanych reguł

Chciałem, żeby konfiguracja była możliwie prosta.

Nie ma tutaj rule buildera z warunkami „jeżeli / oraz / albo”. Nie trzeba tworzyć osobnych rekordów dla każdej relacji.

Panel przedstawia kolejne opcje wysyłki, a pod każdą z nich pokazuje dostępne metody płatności jako przełączniki.

Przykładowo konfiguracja może wyglądać logicznie tak:

Opcja dostawy	Karta	Przelew	Pobranie	PayPal
Kurier	✓	✓	✓	✓
Automat paczkowy	✓	✓	✕	✓
Punkt odbioru	✓	✓	✕	✓
Odbiór osobisty	✓	✓	✓	✕

Każdy wiersz jest niezależny, nawet jeżeli kilka pierwszych pochodzi z tego samego rozszerzenia shipping.

I właśnie na tym zależało mi najbardziej.

 

Pełny kod wysyłki widoczny w panelu

Przy każdej wykrytej opcji administrator widzi nie tylko jej nazwę, ale również techniczny kod.

Przykładowo:

myshipping.courier

Jest to przydatne z dwóch powodów. Po pierwsze od razu wiadomo, że DC Ship2Pay rzeczywiście rozpoznał kilka ofert pochodzących z jednego rozszerzenia. Po drugie przy bardziej technicznej konfiguracji można łatwo porównać kod z wartością zapisaną później w sesji checkoutu.

Nie próbowałem ukrywać całej warstwy technicznej. Nazwa jest wygodna dla administratora, ale kod często bardzo pomaga przy diagnostyce.

 

Licznik aktywnych płatności

Przy każdym sposobie dostawy panel pokazuje również licznik w rodzaju:

3/5

Oznacza on, że spośród pięciu wykrytych metod płatności trzy są aktualnie dozwolone dla tej opcji wysyłki.

Licznik aktualizuje się od razu po przełączeniu switcha w panelu.

Przy większej liczbie metod pozwala więc szybko zauważyć, że dana usługa posiada np. wszystkie płatności albo tylko jedną.

 

Bezpieczna zasada: nieznane oznacza dozwolone

To jedna z decyzji projektowych, którą uważam za szczególnie ważną.

Co powinno się stać, jeżeli administrator skonfiguruje Ship2Pay, a miesiąc później zainstaluje nową metodę płatności?

Mógłbym założyć, że skoro nowej płatności nie ma w zapisanej macierzy, należy ją zablokować.

Tylko że wtedy instalacja nowej bramki mogłaby zakończyć się sytuacją, w której w checkoutcie nagle nie jest ona dostępna dla żadnej wysyłki.

DC Ship2Pay działa odwrotnie.

Nieznana albo jeszcze nieskonfigurowana płatność pozostaje dozwolona.

Dopiero świadome wyłączenie jej w macierzy powoduje blokadę.

Ta sama zasada dotyczy opcji wysyłki, dla której nie istnieje jeszcze konfiguracja. Jeżeli macierz nie zna danego kodu, moduł nie blokuje płatności.

Wolę w tym miejscu zachowanie typu fail-open . Moduł ma ograniczać checkout zgodnie z wyraźnie zapisaną konfiguracją, a nie zgadywać, że nowa integracja powinna zostać zablokowana.

 

Co dzieje się w checkoutcie?

Panel administracyjny jest tylko połową modułu.

Właściwe filtrowanie odbywa się na frontendzie poprzez Events OpenCart .

DC Ship2Pay rejestruje dwa zdarzenia.

Pierwsze uruchamiane jest przed wyświetleniem widoku metod płatności:

catalog/view/checkout/payment_method/before

Drugie działa przed zapisaniem wybranej metody płatności:

catalog/controller/checkout/payment_method/save/before

Dzięki temu moduł nie tylko ukrywa niedozwolone płatności w interfejsie, ale ponownie filtruje ich listę przed standardową walidacją OpenCart.

 

Skąd moduł wie, jaką opcję wysyłki wybrał klient?

OpenCart przechowuje wybraną ofertę dostawy w sesji.

DC Ship2Pay odczytuje:

shipping_method['code']

I tutaj ponownie pojawia się najważniejszy element całego modułu.

Nie obcina kodu do nazwy rozszerzenia.

Jeżeli w sesji znajduje się:

myshipping.locker

to właśnie pełna wartość myshipping.locker zostaje przekazana do filtra.

Dzięki temu macierz może być znacznie dokładniejsza niż zwykłe powiązanie na poziomie myshipping .

 

Filtrowanie dostępnych płatności

Po odczytaniu kodu wysyłki moduł pobiera macierz przypisaną do aktualnego sklepu.

Następnie przechodzi przez metody płatności dostępne w checkoutcie i dla każdej sprawdza:

czy ta płatność jest dozwolona dla tego pełnego kodu wysyłki?

Jeżeli tak, zostaje na liście.

Jeżeli nie, jest usuwana.

Do standardowego widoku OpenCart trafia już przefiltrowana tablica.

Nie powstaje więc drugi formularz płatności. DC Ship2Pay wykorzystuje normalny mechanizm checkoutu i zmienia jedynie listę możliwości.

 

Co, jeśli klient wcześniej wybrał płatność, która stała się niedozwolona?

To również trzeba było obsłużyć.

Wyobraźmy sobie, że klient wybiera kuriera, dla którego dostępne jest pobranie. Zaznacza pobranie, ale następnie zmienia dostawę na automat paczkowy, przy którym pobranie zostało wyłączone.

Samo ukrycie opcji płatności nie wystarczałoby, ponieważ poprzednio wybrana metoda mogłaby nadal znajdować się w sesji.

DC Ship2Pay sprawdza więc aktualnie wybraną płatność po przefiltrowaniu listy.

Jeżeli nie znajduje jej już w dozwolonych metodach, usuwa wybór z sesji.

Klient musi wtedy wskazać jedną z metod nadal dostępnych dla nowej dostawy.

 

Druga kontrola przed zapisem płatności

Nie chciałem polegać wyłącznie na tym, co zostało pokazane klientowi.

Dlatego filtrowanie wykonywane jest ponownie przed standardową akcją:

checkout/payment_method/save

Lista metod w sesji zostaje jeszcze raz ograniczona zgodnie z aktualną metodą wysyłki.

Dopiero potem OpenCart wykonuje swoją normalną walidację.

Nie jest to osobny system bezpieczeństwa płatności, ale pozwala uniknąć sytuacji, w której stara lub niedozwolona metoda pozostałaby w sesji tylko dlatego, że checkout był wykonywany w kilku krokach.

 

Kiedy DC Ship2Pay niczego nie zmienia?

Moduł stara się działać tylko wtedy, kiedy ma ku temu powód.

Jeżeli DC Ship2Pay jest wyłączony, lista płatności wraca bez zmian.

Jeżeli koszyk nie wymaga wysyłki, również niczego nie filtruje. Ma to znaczenie np. dla produktów cyfrowych albo innych zamówień bez fizycznej dostawy.

Jeżeli w sesji nie ma jeszcze wybranej metody wysyłki, płatności także pozostają bez zmian.

I wreszcie, jeżeli dana metoda wysyłki nie posiada zapisanej konfiguracji, moduł jej nie ogranicza.

 

Instalacja DC Ship2Pay w OpenCart 3

Moduł można zdobyć na Opencart Marketplace:

Moduł jest przygotowany jako standardowa paczka:

dc-ship2pay.ocmod.zip

Instalacja nie wymaga ręcznego kopiowania plików ani edytowania Core OpenCart.

1. W panelu administracyjnym przechodzę do Extensions → Installer i przesyłam dc-ship2pay.ocmod.zip .

2. Następnie otwieram Extensions → Extensions , wybieram typ Modules i instaluję Design Cart Ship2Pay .

3. Po instalacji otwieram konfigurację modułu.

4. Włączam jego globalny status i zapisuję ustawienia.

5. Wybieram sklep z listy kafelków.

6. Sprawdzam, czy DC Ship2Pay poprawnie wykrył wszystkie opcje wysyłki i metody płatności.

7. Dla każdej opcji dostawy włączam lub wyłączam odpowiednie płatności i zapisuję macierz.

8. Na końcu wykonuję próbne zamówienie i sprawdzam kilka różnych wariantów dostawy.

Podczas instalacji moduł dodaje wymagane uprawnienia administratora oraz rejestruje eventy wykorzystywane podczas checkoutu.

Nie tworzy własnych tabel bazy danych. Konfiguracja przechowywana jest w standardowym systemie ustawień OpenCart.

 

Ekran główny – status modułu

Pierwszy ekran DC Ship2Pay jest bardzo prosty.

Znajduje się na nim przełącznik:

Opcja	Działanie
Status modułu	Globalnie włącza albo wyłącza mechanizm DC Ship2Pay.

Domyślnie moduł po instalacji jest wyłączony.

To celowe. Najpierw warto wejść do konfiguracji, sprawdzić wykryte metody i przygotować macierz, a dopiero później uruchomić ograniczenia w działającym checkoutcie.

 

Multistore – osobna macierz dla każdego sklepu

Pod statusem znajduje się lista sklepów skonfigurowanych w OpenCart.

Sklep domyślny oraz każdy dodatkowy storefront otrzymują osobny kafelek.

Po kliknięciu przechodzimy do jego macierzy Ship2Pay.

To ważne, ponieważ jeden sklep w Multistore może mieć zupełnie inne płatności i usługi logistyczne niż drugi.

Co więcej, konfiguracje nie są po cichu dziedziczone ze sklepu domyślnego .

Podczas checkoutu DC Ship2Pay odczytuje mapę przypisaną do aktualnego store_id . Jeżeli dodatkowy sklep nie posiada swojej macierzy, moduł nie zaczyna automatycznie stosować ograniczeń zapisanych dla store 0.

W przypadku reguł checkoutu wolę takie zachowanie. Administrator dokładnie wie, dla którego sklepu przygotował konfigurację.

 

Macierz „Wysyłka → Płatności”

Po wejściu do wybranego sklepu pojawia się główny ekran modułu.

Każda wykryta opcja wysyłki ma osobny blok.

W jego nagłówku znajdują się:

Element	Znaczenie
Nazwa wysyłki	Czytelna nazwa konkretnej usługi.
Kod	Pełny kod w rodzaju extension.subcode .
Licznik	Liczba włączonych płatności / liczba wszystkich wykrytych płatności.
Status rozszerzenia	Nieaktywne rozszerzenia mogą być wizualnie oznaczone jako wyłączone.

Pod nagłówkiem znajduje się lista wszystkich wykrytych metod płatności.

Przy każdej widoczna jest nazwa, techniczny kod oraz switch.

Włączony switch oznacza:

ta płatność jest dozwolona dla tej opcji wysyłki.

Wyłączony:

usuń tę płatność z checkoutu, gdy klient wybierze tę opcję dostawy.

I właściwie to cała konfiguracja.

Nie chciałem komplikować interfejsu czegoś, co można przedstawić jako prostą macierz.

 

Przykład – jeden moduł InPost, różne zasady płatności

Załóżmy przykładowy scenariusz, w którym jedno rozszerzenie logistyczne udostępnia klientowi kilka usług.

Panel DC Ship2Pay może rozpoznać je jako osobne kody, przykładowo:

shippingexample.courier

shippingexample.locker

shippingexample.point

Administrator może następnie pozwolić na pobranie dla kuriera, ale wyłączyć je dla automatu i punktu odbioru.

Dla klienta rezultat jest prosty: wybiera kuriera i widzi pobranie. Zmienia sposób dostawy na automat i pobranie znika.

Jednocześnie przelew, karta czy inna bramka online mogą nadal pozostać dostępne we wszystkich trzech wariantach.

Nie trzeba instalować trzech osobnych rozszerzeń wysyłki tylko po to, żeby Ship2Pay potrafił odróżnić trzy usługi.

 

Przykład – darmowy odbiór osobisty

Drugi klasyczny przypadek to odbiór osobisty.

Możemy skonfigurować sklep tak, aby przy kurierze były dostępne tylko płatności online oraz pobranie, natomiast przy odbiorze osobistym dodatkowo pojawiała się konkretna metoda płatności przeznaczona dla punktu stacjonarnego.

DC Ship2Pay nie interpretuje biznesowego znaczenia płatności. Po prostu realizuje zapisaną macierz.

Dzięki temu może obsłużyć wiele bardzo różnych scenariuszy bez dodawania kolejnych warunków do kodu.

 

Co się stanie po instalacji nowej płatności?

Nowa płatność jest domyślnie traktowana jako dozwolona.

To oznacza, że jeżeli skonfigurowałem DC Ship2Pay w poniedziałek, a w piątek instaluję nową bramkę płatniczą, moduł nie powinien automatycznie schować jej przed wszystkimi klientami tylko dlatego, że nie zna jej jeszcze w zapisanej mapie.

Po instalacji nowej metody wracam do konfiguracji DC Ship2Pay, sprawdzam macierz i wyłączam ją przy tych sposobach dostawy, przy których nie powinna działać.

To samo dotyczy nowej usługi wysyłkowej.

Takie zachowanie uważam za bezpieczniejsze operacyjnie.

 

Co się stanie po usunięciu lub zmianie metod?

Podczas zapisu macierzy DC Ship2Pay buduje ją na podstawie aktualnie wykrytych kodów wysyłki i płatności.

Oznacza to, że panel pracuje z rzeczywistym stanem zainstalowanych rozszerzeń.

Jeżeli metoda przestaje istnieć, nie jest potrzebna jako aktywna pozycja nowej konfiguracji.

Jeżeli pojawia się nowa, może zostać automatycznie odkryta i dołączona do panelu.

Nie trzeba prowadzić drugiej, ręcznej listy kodów rozszerzeń.

 

Nazwy usług – skąd się biorą?

DC Ship2Pay stara się pokazać administratorowi możliwie czytelne nazwy.

Dla samego rozszerzenia wykorzystuje jego plik językowy i heading_title .

Przy podmetodach próbuje odczytać odpowiednie dane z konfiguracji i plików językowych. Jeżeli rozszerzenie udostępnia nazwę konkretnej usługi, moduł może zbudować etykietę w rodzaju:

Nazwa modułu — Nazwa usługi

Jeżeli nie uda się znaleźć czytelniejszej nazwy, nadal pozostaje kod podmetody.

To kolejny powód, dla którego techniczny kod zawsze pokazuję obok nazwy.

 

A co z nietypowymi modułami wysyłkowymi?

Tutaj wolę zachować trochę pokory.

Ekosystem OpenCart jest duży i nie istnieje jeden obowiązkowy sposób napisania każdego modułu shipping. DC Ship2Pay obsługuje kilka popularnych sposobów definiowania quote'ów oraz usług zapisanych w konfiguracji, ale zawsze może powstać rozszerzenie generujące swoje opcje całkowicie dynamicznie w sposób, którego statyczny discoverer nie będzie potrafił wcześniej odczytać.

Jeżeli nie uda się rozpoznać podmetod, moduł posiada fallback do standardowego:

extension.extension

Dlatego po instalacji DC Ship2Pay zawsze zalecam otworzyć macierz i sprawdzić, czy wszystkie usługi oczekiwane w checkoutcie rzeczywiście zostały wykryte jako osobne pozycje.

Jeżeli konkretny zewnętrzny moduł buduje quote'y w bardzo nietypowy sposób, jego obsługa może wymagać dodatkowego adaptera.

Nie chcę obiecywać automatycznego rozpoznania każdego rozszerzenia OpenCart, jakie kiedykolwiek zostało napisane.

 

A co z niestandardowymi checkoutami?

DC Ship2Pay integruje się ze standardowym mechanizmem checkout OpenCart poprzez eventy widoku i kontrolera checkout/payment_method .

W klasycznym checkoutcie OpenCart jest to naturalny punkt integracji.

Jeżeli sklep korzysta jednak z całkowicie przebudowanego One Page Checkout, który omija standardowy kontroler metod płatności albo posiada własny niezależny mechanizm ładowania payment methods, współpracę warto wcześniej przetestować.

To nie jest problem specyficzny wyłącznie dla DC Ship2Pay. Każde rozszerzenie działające w checkoutcie musi mieć punkt, w którym może wpłynąć na jego dane.

 

Bez OCMOD ingerującego w checkout

Mimo że nazwa paczki kończy się na .ocmod.zip , DC Ship2Pay nie opiera filtrowania na XML-u wyszukującym i podmieniającym fragmenty standardowych plików checkoutu.

Logika runtime została podpięta przez system Events OpenCart .

Dzięki temu nie muszę wykonywać modyfikacji typu „znajdź ten fragment w payment_method.php i wstaw pod nim własny kod”.

Przy aktualizacji sklepu albo współpracy z innymi rozszerzeniami jest to dla mnie znacznie czystszy sposób integracji.

Nie oznacza oczywiście, że każdy niestandardowy checkout automatycznie będzie kompatybilny, ale przynajmniej DC Ship2Pay nie nadpisuje Core.

 

Moduł bez własnych tabel

DC Ship2Pay nie potrzebuje własnych tabel w bazie danych.

Macierze zapisywane są w standardowych ustawieniach OpenCart dla odpowiednich sklepów.

Dzięki temu moduł nie tworzy dodatkowego systemu encji, modeli czy historii zmian.

Przy odinstalowaniu usuwa swoje eventy oraz ustawienia zapisane dla sklepu domyślnego i dodatkowych sklepów.

 

Dlaczego pełny kod quote jest tak ważny?

W praktyce jest to sedno całego rozwiązania.

Typowy moduł Ship2Pay może myśleć:

klient wybrał InPost → pokaż płatności A, B i C.

Ale rozbudowana integracja logistyczna może potrzebować:

klient wybrał kuriera → pokaż A, B, C i pobranie; klient wybrał automat → pokaż A, B i C; klient wybrał punkt → pokaż tylko A i B.

Jeżeli wszystkie trzy warianty pochodzą z jednego rozszerzenia, rozpoznanie tylko nazwy extension tego nie rozwiązuje.

Trzeba znać pełny kod konkretnego quote .

DC Ship2Pay właśnie na nim opiera swoją macierz oraz późniejsze filtrowanie checkoutu.

 

Czy DC Ship2Pay jest tylko dla rozbudowanych modułów dostawy?

Nie.

Jeżeli sklep posiada proste metody typu Flat Rate, Free Shipping czy Pickup, DC Ship2Pay nadal może działać jak klasyczny Ship2Pay.

Można ustalić, że dla jednej dostawy aktywne są wszystkie płatności, dla drugiej nie ma pobrania, a dla trzeciej dostępny jest wyłącznie przelew.

Obsługa wielu quote'ów jednego rozszerzenia jest jego najważniejszym wyróżnikiem, ale nie jest warunkiem użycia.

 

Najważniejsza różnica względem klasycznego Ship2Pay

Nie chciałem pisać modułu tylko po to, żeby powielić mechanizm istniejący od wielu lat.

Dlatego DC Ship2Pay powstał dopiero wtedy, kiedy pojawił się konkretny problem, którego prosta relacja „shipping extension → payment extension” nie potrafiła rozwiązać.

Tym problemem są wielousługowe metody wysyłkowe .

Współczesna integracja z przewoźnikiem coraz częściej nie oznacza jednej pozycji w checkoutcie. Jeden moduł może reprezentować cały zestaw usług logistycznych.

Jeżeli dla każdej z tych usług potrzebujemy innych zasad płatności, Ship2Pay musi zrozumieć nie tylko, jaki moduł wysyłkowy działa , ale również którą konkretnie ofertę tego modułu wybrał klient .

I właśnie to robi DC Ship2Pay.

 

Podsumowanie

DC Ship2Pay jest jednym z tych modułów, które powstały z dość małego, ale bardzo konkretnego problemu.

Chciałem przypisać dostępne płatności do sposobów dostawy w OpenCart 3. Gdyby każda integracja wysyłkowa zawsze zwracała dokładnie jedną metodę, prawdopodobnie wystarczyłby zwykły Ship2Pay.

Tyle że rzeczywiste moduły logistyczne potrafią działać inaczej.

Jedno rozszerzenie może zwrócić kilka ofert, a każda z nich może wymagać własnej konfiguracji płatności.

Dlatego DC Ship2Pay nie kończy pracy na kodzie rozszerzenia. Próbuje odkryć pełne kody extension.subcode , pokazuje każdą wykrytą usługę osobno w panelu i pozwala zbudować dla niej niezależną macierz płatności.

Podczas checkoutu ponownie korzysta z pełnego kodu wybranego quote, filtruje standardowe metody płatności oraz usuwa z sesji wcześniejszy wybór, jeżeli po zmianie wysyłki przestał być dozwolony.

Do tego dochodzi Multistore, automatyczne wykrywanie zainstalowanych płatności, bezpieczna obsługa nowych metod i integracja przez Events bez modyfikowania Core.

Nie próbowałem zrobić z tego rozbudowanego systemu reguł checkoutu. Chciałem rozwiązać jeden konkretny problem możliwie prosto.

Nie tylko „jaki moduł dostawy wybrał klient?”, ale „którą dokładnie usługę tego modułu wybrał?”.

I to jest właściwie całe DNA DC Ship2Pay . 🚚💳