Klient opłacił zamówienie, ale w systemie ERP powstały dwa dokumenty. Sklep nadal pokazuje sztukę, którą magazyn właśnie wydał. Obsługa nie wie, czy poprawić dane w sklepie, czy w programie magazynowym.
Integracja sklepu internetowego z ERP rozwiązuje te problemy dopiero wtedy, gdy każda informacja ma wskazane źródło, kierunek przepływu i sposób obsługi błędu. Samo połączenie dwóch API nie ustala żadnej z tych reguł.
Właściciel danych
Najpierw trzeba zdecydować, gdzie powstaje i gdzie może być zmieniana każda informacja. Dla dostępności produktu może to być ERP, bo tam magazyn rejestruje przyjęcia, rezerwacje i wydania. Opis oraz zdjęcia mogą pozostać w sklepie, jeśli tam pracuje zespół e-commerce. Zamówienie zaczyna się w kanale sprzedaży, lecz po przekazaniu do realizacji jego status może wracać z ERP albo systemu magazynowego.
Dwukierunkowa synchronizacja wszystkiego brzmi wygodnie, ale tworzy konflikty. Gdy cenę można zmienić po obu stronach, integracja musi rozstrzygnąć, która wersja wygrywa. Bez tej decyzji ostatni zapis może przypadkiem nadpisać poprawną wartość.
| Dane | Typowe źródło | Kierunek |
|---|---|---|
| Zamówienie | Sklep lub marketplace | Do ERP |
| Dostępność towaru | ERP lub WMS | Do kanałów sprzedaży |
| Status realizacji | ERP lub WMS | Do sklepu |
| Opis i zdjęcia | Sklep albo PIM | Według ustalonego właściciela |
To nie jest uniwersalny schemat. Firma z osobnym PIM-em, kilkoma magazynami albo sprzedażą stacjonarną będzie potrzebowała innego podziału. Tabela ma ujawnić decyzje, a nie zastąpić analizę procesu.
Zamówienie i stan to dwa przepływy
Zamówienie powinno trafić do ERP dopiero w stanie, który pozwala rozpocząć realizację. W zależności od kanału może to oznaczać potwierdzoną płatność, pobranie albo zaakceptowane zamówienie B2B. Pobranie każdego nowego rekordu bez sprawdzenia statusu może utworzyć dokument dla zakupu, który nie jest jeszcze gotowy do wysyłki.
Oficjalna dokumentacja zamówień Allegro REST API pokazuje, że dla jednego zamówienia może pojawić się kilka zdarzeń, a ich kolejność nie zawsze jest oczekiwana. Logika integracji powinna więc opierać się na identyfikatorze i aktualnym stanie zamówienia, nie na założeniu, że każde powiadomienie oznacza nowy zakup.
Stan magazynowy wymaga osobnej definicji. Liczba fizycznie leżąca na półce nie musi być liczbą dostępną do sprzedaży. Część towaru może być zarezerwowana, uszkodzona albo przypisana do innego kanału. W modelu zapasów Shopify występują między innymi ilości dostępne, znajdujące się fizycznie na stanie, przychodzące i przypisane do zamówień. Przed wdrożeniem trzeba nazwać dokładnie, która z nich zasila sklep.
Powtórzenie bez duplikatu
Połączenie może zostać przerwane po wysłaniu danych, zanim integracja odbierze potwierdzenie. Wtedy nie wiadomo, czy ERP utworzył dokument. Bezpieczne ponowienie wymaga trwałego identyfikatora operacji oraz sprawdzenia, czy dane zamówienie już istnieje po drugiej stronie.
Ten mechanizm nazywa się idempotencją. Przewodnik Shopify po idempotencji rozróżnia nową operację od ponowienia tej samej próby i zaleca użycie tego samego klucza dla duplikatu żądania. Niezależnie od możliwości konkretnego API integrator powinien zachować powiązanie: identyfikator zamówienia w sklepie, identyfikator dokumentu w ERP i wynik ostatniej próby.
Wyjątki należą do procesu
Nie każde zamówienie przejdzie bez udziału człowieka. ERP może odrzucić nieznaną formę dostawy, brak mapowania wariantu, niepoprawną stawkę podatku albo klienta z niepełnymi danymi do faktury. Taki przypadek potrzebuje widocznego statusu, zrozumiałego komunikatu i możliwości ponowienia po poprawce.
Plik z logiem dostępny wyłącznie dla programisty nie wystarczy zespołowi obsługi. Dobrze zaprojektowana kolejka wyjątków odpowiada na cztery pytania: co nie przeszło, dlaczego, kto ma to poprawić i czy kolejna próba jest bezpieczna. Integracja może wtedy zatrzymać jedno zamówienie bez blokowania pozostałych.
Jeżeli nie wiadomo jeszcze, czy oba programy udostępniają potrzebne dane, zacznij od sprawdzenia konkretnego przepływu i dostępnych mechanizmów integracji.
Bezpieczny pierwszy zakres
Pierwsze uruchomienie warto ograniczyć do jednego kanału sprzedaży, jednego magazynu i jasno wybranych danych. Przykładowo: opłacone zamówienia płyną do ERP, a dostępność oraz status wysyłki wracają do sklepu. Ceny, opisy produktów i zwroty mogą poczekać, jeżeli nie są potrzebne do przetestowania głównego procesu.
Przed włączeniem automatycznego zapisu przygotuj zwykłe zamówienie, ponowione zdarzenie, brak mapowania produktu, anulowanie i chwilową niedostępność ERP. Sprawdź też, jak uzgodnić dane po przerwie. Dopiero taki test pokazuje, czy połączenie poradzi sobie z dniem pracy, a nie wyłącznie z idealną demonstracją.
