- Kierowca dostępny teraz
- całą dobę, 7 dni w tygodniu
- Dojazd do 1 h w promieniu 40 km
- Diagnoza laptopa 0 zł
Nawet poprawnie skonfigurowana integracja między sklepem a magazynem czasem zaczyna „rozjeżdżać się" z czasem — stany przestają się zgadzać, mimo że synchronizacja formalnie działa.
Sklep pokazuje inny stan magazynowy niż widoczny w systemie ERP, zamówienia realizowane są mimo braku towaru na stanie, albo synchronizacja przestaje działać dla wybranych produktów bez wyraźnej przyczyny.
Diagnoza analizuje logi synchronizacji, lokalizuje moment i produkty, których dotyczy rozbieżność, oraz ustala jej przyczynę. Po naprawie mechanizmu wykonywana jest pełna, ręczna synchronizacja w celu wyrównania obecnych rozbieżności.
Diagnostyka i naprawa rozbieżności mieści się z reguły w standardowym czasie do 3 dni.
Diagnoza wstępna i wycena są bezpłatne. Dojazd na terenie Warszawy i okolic jest bezpłatny, a usługa objęta jest gwarancją do 12 miesięcy.
Spójność informacji między oprogramowaniem magazynowo-handlowym a platformą e-commerce opiera się na ciągłym przekazywaniu pakietów danych. W typowej strukturze przedsiębiorstwa system ERP (planowanie zasobów przedsiębiorstwa, czyli centralny program magazynowy) stanowi główne źródło prawdy o dostępności towarów. Platforma sklepowa lub konto w serwisie aukcyjnym odbierają te wartości za pośrednictwem modułu integracyjnego, który komunikuje się przez API (interfejs programistyczny aplikacji, pozwalający na wymianę informacji między różnymi systemami).
W zależności od wdrożonego rozwiązania przepływ ten odbywa się dwoma głównymi kanałami: poprzez cykliczne odpytywanie bazy w harmonogramie zadań lub za pomocą mechanizmu webhooków (automatycznych komunikatów sieciowych przesyłanych w czasie rzeczywistym natychmiast po zmianie rekordu). W obu modelach mogą wystąpić zakłócenia wynikające z limitów przepustowości serwera, ograniczeń nałożonych na liczbę zapytań w jednostce czasu (ang. rate limiting) lub chwilowych przerw w łączności sieciowej. Jeśli w trakcie przesyłania paczki danych zawierającej kilkaset indeksów towarowych nastąpi przekroczenie limitu czasu odpowiedzi serwera (ang. timeout), część produktów zaktualizuje się poprawnie, a pozostałe zachowają nieaktualne wartości.
Kolejnym punktem krytycznym są blokady transakcyjne na poziomie relacyjnej bazy danych SQL (mechanizm zapobiegający jednoczesnemu zapisowi do tej samej tabeli przez dwa różne procesy). Gdy w systemie ERP generowany jest w tym samym momencie duży raport finansowy lub przetwarzana jest masowa dostawa dokumentem PZ (przyjęcie zewnętrzne towaru na stan), baza danych potrafi odrzucić zapytanie integratora, aby chronić integralność transakcji. Powstały w ten sposób błąd często trafia do kolejki zdarzeń, która w przypadku braku poprawnej obsługi wyjątków zostaje pominięta bez powiadomienia administratora.
Problemy z niezgodnością danych przybierają zróżnicowane formy w zależności od konfiguracji oprogramowania, struktury asortymentu oraz dynamiki sprzedaży. Prawidłowa identyfikacja typu usterki pozwala na szybkie wdrożenie właściwych działań naprawczych.
Jednym z najczęstszych wariantów jest sytuacja, w której platforma sklepowa prezentuje stan magazynowy całkowity (fizyczną liczbę sztuk na półce), zamiast stanu dyspozycyjnego (ilości fizycznej pomniejszonej o rezerwacje pod niezrealizowane zamówienia). W systemach handlowych, takich jak Subiekt GT, Subiekt nexo, Comarch ERP Optima czy WAPRO Mag, każde nowe zamówienie tworzy rezerwację towarową (dokument ZK – zamówienie od klienta). Jeśli moduł synchronizujący został błędnie skonfigurowany i pobiera ogólną wartość z tabeli ilościowej zamiast wartości z kolumny dyspozycji, klienci w sklepie internetowym mogą kupić towar, który został już wcześniej zarezerwowany przez inny dział firmy.
Asortyment posiadający wiele cech (np. rozmiary, kolory) lub sprzedawany w pakietach (kompletach złożonych z kilku osobnych pozycji magazynowych) jest szczególnie podatny na błędy mapowania. Wystarczy, że jeden wariant produktu w sklepie internetowym posiada inny kod SKU (unikalny identyfikator asortymentowy w magazynie) niż odpowiadający mu rekord w kartotece ERP, aby aktualizacja stanów dla tego konkretnego rozmiaru przestała działać. W przypadku zestawów brak automatycznego przeliczania dostępności kompletu na podstawie najniższego stanu jego pojedynczego składnika prowadzi do oferowania produktów, których fizycznie nie da się skompletować.
Zmiany w oprogramowaniu serwerowym, wdrożenie nowej wersji wtyczki integracyjnej w sklepie lub aktualizacja samego systemu ERP potrafią zmienić strukturę zwracanych danych JSON/XML. W takich okolicznościach dochodzi do wygaśnięcia tokenów uwierzytelniających (cyfrowych kluczy dostępowych służących do bezpiecznej autoryzacji) albo błędu walidacji pól bazodanowych. Synchronizacja formalnie raportuje status działania, lecz w rzeczywistości odrzuca wszystkie wychodzące pakiety danych, co powoduje całkowite zamrożenie stanów w kanale e-commerce na poziomie z dnia aktualizacji.
Zjawisko wyścigu zapytań (ang. race condition) pojawia się podczas wzmożonego ruchu, na przykład w trakcie akcji wyprzedażowych. Jeżeli ostatnia sztuka towaru zostanie dodana do koszyka i opłacona jednocześnie przez dwóch klientów na różnych platformach (np. w sklepie internetowym i w serwisie aukcyjnym), a interwał odpytywania bazy danych wynosi kilkanaście minut, oba systemy zatwierdzą transakcję przed odebraniem informacji o wyczerpaniu zapasu. W efekcie powstaje ujemny stan magazynowy lub konieczność anulowania zamówienia.
Nieprawidłowo przeprowadzone próby przywrócenia zgodności danych mogą doprowadzić do pogłębienia problemu, a w skrajnych przypadkach do trwałego uszkodzenia relacji w bazach danych.
W procesie weryfikacji należy odróżnić awarię mechanizmów informatycznych od problemów leżących po stronie procedur magazynowych lub błędów operacyjnych personelu.
Rozbieżność nie jest usterką synchronizacji, gdy w magazynie fizycznym brakuje towaru z powodu niezaewidencjonowanych strat, pomyłek przy kompletacji zamówień (wydanie niewłaściwego towaru bez korekty w systemie) lub opóźnień we wprowadzaniu dokumentów przyjęcia dostawy. W takiej sytuacji systemy informatyczne pokazują zgodne, poprawne wartości, które rozmijają się wyłącznie ze stanem faktycznym na regałach.
Innym przypadkiem jest nieprawidłowa obsługa zwrotów konsumenckich. Jeżeli pracownik przyjmie fizycznie paczkę ze zwracanym towarem, lecz dokument korekty handlowej lub przyjęcia magazynowego zostanie zapisany w systemie ERP jako niezatwierdzony bufor, towar nie wejdzie na stan dyspozycyjny i nie pojawi się w ofercie internetowej.
Podobne zjawisko występuje w środowiskach wielomagazynowych, w których firma posiada oddzielny magazyn dla sprzedaży tradycyjnej oraz wydzielony magazyn wysyłkowy. Jeżeli integracja została ustawiona na pobieranie stanów wyłącznie z jednego z nich, a personel omyłkowo przyjmuje dostawy na konto drugiego magazynu, oferta internetowa nie wykaże nowych produktów, mimo że w całym systemie ERP widnieją one jako dostępne.
Przywrócenie stabilnej wymiany danych wymaga systematycznego podejścia eliminującego źródła błędów na każdym poziomie architektury IT.
Najczęstszą przyczyną jest zablokowanie całego dostępnego zapasu przez niezrealizowane zamówienia lub dokumenty rezerwacji w systemie ERP. Innym powodem może być odznaczenie znacznika publikacji internetowej w kartotece towarowej danego artykułu, brak przypisania towaru do grupy synchronizowanej albo błąd walidacji kodu SKU po stronie platformy e-commerce.
W prawidłowo zaprojektowanym środowisku nadrzędnym źródłem prawdy powinien być zawsze system ERP. To w nim ewidencjonowane są dokumenty księgowe, faktury zakupu, przyjęcia zewnętrzne oraz dokumenty inwentaryzacyjne. Sklep internetowy oraz kanały marketplace powinny działać wyłącznie jako odbiorcy tych informacji, przekazując do ERP jedynie dane o nowych zamówieniach.
Skutecznym rozwiązaniem jest zastosowanie bufora magazynowego (ang. safety stock), czyli programowego zmniejszenia stanu widocznego w sklepie o określoną liczbę sztuk lub wartość procentową. Wsparciem jest również przejście z cyklicznej synchronizacji harmonogramowej na mechanizm zdarzeniowy (webhooki), który aktualizuje stan natychmiast po zatwierdzeniu zakupu przez klienta.
W większości przypadków prace diagnostyczne, analiza logów oraz konfiguracja reguł synchronizacji odbywają się w tle, bez konieczności wyłączania platformy handlowej. Jedynie ostateczne, pełne wyrównanie bazy danych planowane jest w okresie najmniejszego natężenia ruchu, aby zagwarantować pełne bezpieczeństwo rejestrowanych transakcji.
Prawidłowe funkcjonowanie integracji między oprogramowaniem handlowym a platformą internetową decyduje o płynności realizacji zamówień, terminowości wysyłek i wiarygodności przedsiębiorstwa w oczach klientów. Eliminacja wąskich gardeł w komunikacji bazodanowej, poprawne skonfigurowanie logiki rezerwacji towarowych oraz regularny nadzór nad spójnością kartotek produktowych pozwalają trwale zapobiegać powstawaniu rozbieżności asortymentowych w dynamicznie działających kanałach sprzedaży.