Podłączenie sklepu do systemu magazynowego albo ERP jest zadaniem skończonym. Ma początek, koniec i odbiór. Utrzymanie tego połączenia skończone nie jest, bo od dnia startu obie strony codziennie wymieniają dane i codziennie mogą się o nie pokłócić.
Ten tekst jest o tej drugiej części. O tym, co dokładnie płynie między sklepem a systemem firmowym, w którą stronę, jak często i kto ma rację, gdy oba systemy znają tę samą wartość. Metody połączenia, czyli wybór między gotowym modułem, wymianą plikową a integracją dedykowaną, opisaliśmy osobno w tekście o integracji PrestaShopa z systemami firmowymi.
Co da się mieć gotowe, a czego nie zestandaryzuje nikt
Część pracy integracyjnej jest powtarzalna i można ją mieć przygotowaną z góry: warstwa techniczna połączenia, harmonogram, obsługa błędów i logowanie. Dlatego w pakietowych wdrożeniach podpięcie płatności, kurierów i systemu firmowego bywa osobnym, wycenionym etapem, obok migracji danych.
Różnicę robi tu pochodzenie modułów. Jeśli są autorskie i utrzymuje je zespół wdrożeniowy, jak w naszym starterze WayBox, to przy awarii po aktualizacji nie czeka się na poprawkę od zewnętrznego dostawcy. Przy module z rynku ten czas jest poza Waszą kontrolą.
Czego natomiast nie zestandaryzuje żaden pakiet, nasz ani cudzy: tego, co w Waszej firmie jest źródłem prawdy. Ta decyzja nie jest techniczna. Wynika z tego, kto u Was wystawia dokumenty, kto prowadzi kartotekę kontrahentów i który zespół odpowiada za ceny. Dwie firmy z tym samym ERP-em i tym samym sklepem potrafią mieć zupełnie inną odpowiedź.
Macierz synchronizacji, czyli od czego zacząć rozmowę
Zamiast pytać „czy integrujecie się z naszym ERP”, warto przejść daną po danej. Dla każdej z nich potrzebne są trzy odpowiedzi: w którą stronę płynie, kto jest jej źródłem prawdy i jak często się odświeża.
Katalog produktowy
Zwykle płynie z systemu firmowego do sklepu, bo tam powstaje kartoteka towarowa. Rzadko jednak w całości. Nazwa, kod i numer EAN idą z systemu, a opisy marketingowe, zdjęcia i przypisanie do kategorii powstają po stronie sklepu i nie mogą zostać nadpisane przy kolejnym imporcie. To najczęstsza przyczyna sporu na starcie: import, który miał aktualizować stany, kasuje pracę zespołu contentowego.
Rozwiązaniem jest podział pól na te zarządzane przez system firmowy i te zarządzane w sklepie, spisany przed pierwszym uruchomieniem, a nie po pierwszej awarii.
Stany magazynowe
Jedyna dana, przy której opóźnienie kosztuje bezpośrednio, bo kończy się sprzedażą towaru, którego nie ma. Kierunek jest jednoznaczny, z magazynu do sklepu, ale częstotliwość już nie. Co godzinę wystarcza przy stabilnej rotacji i przestaje wystarczać w szczycie sprzedażowym albo przy sprzedaży wielokanałowej, gdzie ten sam towar leży równolegle na marketplace.
Drugie pytanie przy stanach dotyczy tego, co sklep robi z rezerwacją. Czy odejmuje sztukę w momencie dodania do koszyka, przy złożeniu zamówienia, czy dopiero po opłaceniu. Każda z tych odpowiedzi daje inny obraz dostępności i inną liczbę sytuacji, w których trzeba dzwonić do klienta.
Ceny i cenniki
Cena zwykle pochodzi z systemu firmowego, ale rzadko w jednej wersji. Do tego dochodzą ceny promocyjne ustawiane w sklepie, cenniki walutowe, ceny indywidualne dla kontrahentów i rabaty progowe. Trzeba rozstrzygnąć nie tylko, skąd przychodzi cena bazowa, ale też która warstwa wygrywa, gdy nakładają się dwie.
Przy sprzedaży na kilku rynkach dochodzi jeszcze kontekst sklepu, bo ten sam produkt ma inną cenę w każdej domenie. Piszemy o tym szerzej w tekście o architekturze multistore.
Kartoteka klienta
Tu kierunek bywa dwustronny i to jest najtrudniejszy przypadek w całej macierzy. Klient detaliczny zakłada konto w sklepie i trafia do systemu firmowego. Kontrahent hurtowy zwykle istnieje w systemie wcześniej i to sklep musi go odnaleźć, najczęściej po numerze NIP, zamiast zakładać duplikat.
Bez rozstrzygnięcia, kto zakłada kartotekę, po kilku miesiącach ma się dwie bazy klientów, które trzeba ręcznie scalać.
Zamówienia
Ze sklepu do systemu firmowego, natychmiast, bo od tego zależy realizacja. To jedyna dana, przy której tryb cykliczny prawie nigdy nie ma sensu.
Warto ustalić, które zamówienia w ogóle wychodzą. Przekazywanie zamówień nieopłaconych zaśmieca system firmowy i miesza w raportach sprzedaży, więc częstą granicą jest zmiana statusu na opłacone.
Dokumenty sprzedaży i statusy
Faktury, korekty i numery listów przewozowych wracają w drugą stronę, z systemu firmowego do sklepu, i prawie zawsze z opóźnieniem. To nie jest usterka, tylko właściwość tych danych. Sklep musi umieć pokazać zamówienie, które jest już wysłane, ale numeru do śledzenia jeszcze nie ma.
Wsad czy zdarzenie, czyli dwa tryby wymiany
Każda pozycja z macierzy działa w jednym z dwóch trybów i to rozstrzygnięcie ma większy wpływ na koszt niż wybór samej technologii.
Tryb zdarzeniowy uruchamia wymianę w momencie, w którym coś się dzieje. Klient składa zamówienie, sklep od razu odzywa się do systemu firmowego. Dane są aktualne, a obciążenie rozłożone równomiernie. Cena to wrażliwość na chwilową niedostępność drugiej strony: jeśli system nie odpowiada w tej sekundzie, trzeba mieć plan.
Tryb wsadowy przetwarza dane porcjami, według harmonogramu. Jest odporniejszy, bo przebieg można powtórzyć, i tańszy po stronie systemu firmowego. Płaci się opóźnieniem i tym, że przy dużym katalogu przebieg potrafi nie zdążyć przed kolejnym.
Podział, który sprawdza się w większości wdrożeń: zamówienia zdarzeniowo, wszystko pozostałe wsadowo, z częstotliwością dobraną osobno dla każdej danej. Stany co godzinę, ceny raz na dobę, kartoteka kontrahentów raz na dobę plus ręczne wywołanie na żądanie.
Kolejka, czyli co się dzieje, gdy druga strona milczy
To jest warstwa, o której nie myśli się przy wycenie, a która decyduje o tym, czy integracja przetrwa pierwszy gorszy dzień.
Wywołanie zdarzeniowe zakłada, że druga strona odpowie. Kiedy nie odpowiada, bo trwa aktualizacja, skończył się limit zapytań albo po prostu wypadło łącze, zamówienie nie może zniknąć. Musi trafić do kolejki i poczekać.
Kolejka wymaga trzech rozstrzygnięć, a odpowiedź „ponawiamy i logujemy” nie jest żadnym z nich. Ile razy ponawiać, zanim uznamy próbę za nieudaną. Co zrobić z pozycją, która po tych próbach nadal nie przechodzi, bo dane są po prostu błędne. Kto się o tym dowiaduje i gdzie to widzi.
Praktyka, która działa: osobny status wyjątku, który wyciąga takie zamówienie na wierzch listy w panelu, zamiast chować je w logu. Zamówienie, które nie dotarło do systemu firmowego i o którym nikt nie wie, jest zamówieniem niezrealizowanym.
Przy przetwarzaniu wsadowym dochodzi druga zasada: przebieg musi dać się powtórzyć bez skutków ubocznych. Jeśli ten sam plik przetworzony dwa razy tworzy dwa razy te same dokumenty, kolejka jest bombą z opóźnionym zapłonem.
Szczyt sprzedażowy jako test synchronizacji
Konfiguracja, która działa w marcu, w listopadzie zachowuje się inaczej, bo zmieniają się dwie rzeczy naraz: rośnie liczba zamówień i rośnie tempo schodzenia stanów magazynowych.
Cykl godzinny, który przez większość roku jest w zupełności wystarczający, w szczycie oznacza godzinę sprzedawania towaru, którego już nie ma. Jednocześnie przebieg wsadowy robi się dłuższy, bo pozycji do przetworzenia jest więcej, więc akurat wtedy, gdy potrzeba go częściej, zaczyna się wydłużać.
Dlatego przed sezonem warto sprawdzić dwie rzeczy: ile faktycznie trwa pełny przebieg synchronizacji przy obecnej wielkości katalogu i czy da się na czas kampanii zagęścić harmonogram bez nakładania się przebiegów. Wydajnościową stronę przygotowań opisujemy w materiale o kosztownych awariach w szczycie sprzedażowym.
Sprzedaż do firm dokłada trzy warstwy
W wariancie B2B macierz synchronizacji rozrasta się o dane, których w sklepie detalicznym nie ma wcale.
- Cenniki kontrahenckie. Nie jedna cena na produkt, tylko cena zależna od tego, kto patrzy. To zmienia nie tylko import, ale i sposób budowania cache, bo strona produktu przestaje być jedna.
- Kredyt kupiecki i rozliczenia. Przyznany limit, limit dostępny, zaległości i terminy płatności pochodzą z systemu firmowego i muszą docierać do sklepu na tyle często, żeby klient nie złożył zamówienia ponad limit, który wyczerpał wczoraj.
- Struktura kontrahenta. Oddziały, role i akceptacja zamówień po stronie kupującego, powiązane z jedną kartoteką w systemie firmowym.
Te trzy warstwy obsługuje wariant platformy B2B na PrestaShop, opisany osobno razem z przebiegiem wdrożenia.
Odbiór integracji i co sprawdzać później
Integracja ma własne kryteria odbioru, osobne od odbioru sklepu. Na środowisku przedprodukcyjnym, przed puszczeniem ruchu, przechodzi się synchronizację w obie strony, wykonanie zadań cyklicznych o zaplanowanych porach, zgodność stanów po przebiegu oraz zachowanie przy celowo wprowadzonym błędzie.
Po starcie zostają trzy rzeczy do regularnego sprawdzania: czy zadania cykliczne faktycznie się wykonują i w jakim czasie, czy w kolejce nie zalegają pozycje w statusie wyjątku i czy stany w sklepie zgadzają się z systemem firmowym po pełnym przebiegu. Pusty log jest przy tym tak samo podejrzany jak log pełen błędów.
Pełny zakres prac integracyjnych opisuje strona integracji PrestaShop, a mechanikę połączeń z przewoźnikami, porównywarkami i hurtowniami rozwijamy w tekście o integracjach zewnętrznych.
