Dwie osobne instalacje PrestaShop, które sprzedają te same produkty z tego samego fizycznego magazynu: przypadek jest częsty. Sklep dla klientów indywidualnych i sklep dla firm, sklep francuski i sklep niemiecki na osobnych domenach albo marka główna i outlet.
Dopóki stan magazynowy nie jest współdzielony, każdy sklep myśli, że dysponuje całością. Pierwsza nadsprzedaż pojawia się w ciągu tygodnia.
Trzy możliwe architektury
Natywny multisklep. Jedna instalacja, kilka sklepów logicznych. Stan jest współdzielony natywnie, pytanie w ogóle się nie pojawia. To rozwiązanie najprostsze i często niesłusznie odrzucane: wiele projektów rusza z dwiema osobnymi instalacjami, choć multisklep by wystarczył.
Dwie zsynchronizowane instalacje. Każda ma swoją bazę, swój motyw, swoje moduły, a mechanizm utrzymuje spójność stanu. Cięższe, ale konieczne, gdy oba serwisy muszą rozwijać się niezależnie albo należeć do różnych podmiotów prawnych.
Zewnętrzny system nadrzędny. ERP lub program do zarządzania posiada stan magazynowy, a oba sklepy z niego korzystają. To architektura najzdrowsza, gdy tylko istnieje trzeci kanał, sklep stacjonarny albo marketplace.
Zanim zbudujesz synchronizację, sprawdź, czy pierwsza opcja nie wystarczy. Ona usuwa problem, zamiast nim zarządzać.
Jeden master, tylko jeden
To decyzja fundamentalna, a naiwna synchronizacja dwukierunkowa to klasyczna pułapka.
Jeśli oba sklepy mogą modyfikować stan i odsyłać go sobie nawzajem, powstają pętle: sklep A zmniejsza stan, wysyła do B, B stosuje i odsyła do A, który zmniejsza ponownie. Stany rozjeżdżają się w kilka godzin, i to w złą stronę.
Istnieją dwa poprawne modele.
Model master-slave: jeden sklep posiada prawdę, drugi ją otrzymuje. Prosty, ale sprzedaże ze sklepu podrzędnego muszą wracać do nadrzędnego, co zakłada osobny kanał dla zmniejszeń stanu.
Model ze scentralizowanym magazynem: żaden ze sklepów nie posiada stanu, robi to zewnętrzne repozytorium. Każda sprzedaż wywołuje zmniejszenie w tym repozytorium, które redystrybuuje wartości. Jest to bardziej odporne i wymaga dodatkowego elementu.
Synchronizacja Wielu Sklepów: Moduł PrestaShop 8 i 9Synchronizuj katalog, stany magazynowe i ceny między wieloma sklepami PrestaShop€99,00
Częstotliwość i okno nadsprzedaży
Każda synchronizacja okresowa zostawia okno, w którym oba sklepy widzą co innego. To okno da się obliczyć.
Jeśli synchronizujesz co piętnaście minut i sprzedajesz trzy sztuki danej referencji na godzinę, okno to średnio mniej niż jedna sztuka: ryzyko jest niskie. Przy sprzedaży błyskawicznej z pięćdziesięcioma sztukami na godzinę to samo okno przepuszcza kilkanaście zamówień za dużo.
Wynikają z tego trzy ustawienia. Wysoka częstotliwość, pięć do piętnastu minut, dla referencji o szybkiej rotacji. Synchronizacja zdarzeniowa zamiast okresowej dla produktów krytycznych: każda sprzedaż natychmiast wywołuje propagację. Oraz margines bezpieczeństwa, przez zarezerwowanie jednej lub dwóch sztuk na sklep, który absorbuje okno bez dodatkowej złożoności.
Dopasowanie referencji
Punkt techniczny, który decyduje o wykonalności. Identyfikatory produktów nigdy nie są takie same między dwiema instalacjami: produkt 421 w sklepie A to nie produkt 421 w sklepie B.
Dopasowanie musi więc opierać się na stabilnym kluczu biznesowym, obecnym po obu stronach i nigdy niezmienianym. Referencja produktu się nadaje, pod warunkiem że jest wszędzie uzupełniona i unikalna. Kod kreskowy to solidna alternatywa.
Dwie pułapki. Warianty muszą mieć własną referencję, inaczej synchronizacja odbywa się na poziomie produktu, a stan per rozmiar pozostaje błędny. A produkty obecne tylko po jednej stronie muszą być jawnie ignorowane, nie traktowane jako błędy w każdym cyklu.
Czego się nie synchronizuje
Pokusa, by wyrównać wszystko, jest silna. To błąd, który czyni system kruchym.
Nie synchronizuj cen, jeśli oba sklepy mają różne pozycjonowanie, co prawie zawsze jest powodem ich osobnego istnienia. Nie synchronizuj przetłumaczonych opisów ani metadanych SEO, bo stworzysz zduplikowaną treść między dwiema domenami. Nie synchronizuj zamówień ani klientów, chyba że jest to jawnie potrzebne: to dane o dużym ciężarze regulacyjnym.
Minimalny zakres, który działa: stan magazynowy, dostępność i ewentualnie status aktywny lub nieaktywny produktu.
Konflikty i odzyskiwanie po awarii
Dwie sytuacje do przewidzenia już na etapie projektowania.
Konflikt. Obie strony zmieniły się między dwiema synchronizacjami. Reguła musi być spisana: albo master zawsze wygrywa, albo zwycięża niższa wartość, co jest ostrożne przy stanach magazynowych. Reguła niespisana staje się regułą losową.
Awaria. Co się dzieje, gdy synchronizacja zatrzyma się na sześć godzin i nikt tego nie zauważy? Trzy zabezpieczenia: przeglądalny dziennik synchronizacji z ich wynikiem, alert przy powtarzających się błędach oraz pełna resynchronizacja uruchamiana ręcznie.
Ta ostatnia jest tą, o której się systematycznie zapomina, i tą, której potrzebuje się pilnie w sobotni poranek.
Kontrola
Rozjazdu stanów nie widać, stwierdza się go dopiero przy nadsprzedaży. Cotygodniowa kontrola porównująca ilości po obu stronach, referencja po referencji, zajmuje kilka minut i ujawnia odchylenia, zanim będą kosztować anulowane zamówienie.
Moduł Synchronizacja Multi-Sklep obsługuje ten łańcuch w PrestaShop 8 i 9: dopasowanie po referencji lub kodzie kreskowym na poziomie wariantów, synchronizacja stanu z konfigurowalnym kierunkiem i częstotliwością, dziennik operacji i pełna resynchronizacja na żądanie.
