Naprawa błędów synchronizacji w BaseLinker

Więcej punktów awarii niż w pojedynczym sklepie

W systemie łączącym kilka platform, magazyn i księgowość błąd synchronizacji może pochodzić z każdego z tych połączeń. Diagnoza polega więc przede wszystkim na zawężeniu — ustaleniu, które konkretnie połączenie zawiodło.

Od czego zaczynamy

1. Ustalamy, czego dotyczy rozbieżność: stanów, cen, zamówień czy dokumentów.
2. Sprawdzamy, czy dotyczy jednej platformy, czy wszystkich.
3. Sprawdzamy dziennik zdarzeń — tam zwykle jest konkretny komunikat.
4. Ustalamy, co zmieniło się w ostatnich dniach po którejkolwiek ze stron.

Najczęstsze przyczyny

• Wygasły klucz dostępu do platformy albo do systemu firmowego.
• Zmienione hasło konta używanego przez integrację.
• Zmiana zasad po stronie platformy sprzedażowej.
• Produkt bez kodu albo z kodem różniącym się między systemami.
• Przekroczony limit zapytań przy dużej liczbie produktów.
• Aktualizacja systemu magazynowego zmieniająca sposób wymiany danych.

Produkty bez kodu

Najczęstsza przyczyna rozbieżności dotyczących pojedynczych pozycji. Cała reszta synchronizuje się poprawnie, więc problem wygląda na losowy — a wynika po prostu z produktu, którego systemy nie potrafią ze sobą powiązać.

Nadrobienie zaległości

Po naprawie sprawdzamy, co nie przeszło w czasie przerwy. Samo przywrócenie połączenia nie uzupełnia danych z okresu awarii — zamówienia i zmiany stanów trzeba wtedy przesłać ponownie.

Zapobieganie

Powiadomienie o zatrzymanej synchronizacji i zapis terminów wygasania kluczy.

Jak mogą wyglądać błędy synchronizacji

Nie każda awaria powoduje całkowite zatrzymanie wymiany danych. Czasami zamówienia są pobierane prawidłowo, ale zmiany stanów magazynowych nie docierają do jednej platformy. W innym przypadku synchronizują się stany, lecz nie aktualizują się ceny. Zdarza się także, że problem obejmuje tylko wybrane produkty, konkretny magazyn albo zamówienia o określonym statusie. Takie różnice są ważną wskazówką, ponieważ pozwalają oddzielić awarię całego połączenia od błędu dotyczącego pojedynczej reguły lub kartoteki.

Osobnym wariantem jest opóźnienie. Dane ostatecznie pojawiają się we właściwym miejscu, ale następuje to później niż zwykle. Przyczyną może być kolejka zadań, czyli lista operacji oczekujących na wykonanie, chwilowa niedostępność jednego z systemów albo ograniczenie liczby zapytań. Trzeba wtedy ustalić, czy zaległe operacje są nadal przetwarzane, czy zatrzymały się na jednym błędzie. Sam fakt, że część danych dociera z opóźnieniem, nie oznacza jeszcze zerwania całej integracji.

Rozbieżności stanów magazynowych

Błędny stan może mieć kilka źródeł. Produkt bywa przypisany do niewłaściwego magazynu, kilka ofert może korzystać z jednej kartoteki albo każda platforma może być skonfigurowana do odczytu danych z innego miejsca. Kartoteka to rekord produktu zawierający między innymi jego oznaczenie i stan. Jeżeli powiązania są niejednoznaczne, sprzedaż jednej oferty nie zawsze zmniejsza stan we wszystkich miejscach, w których powinna zostać uwzględniona.

Podczas diagnozy sprawdza się kierunek synchronizacji, źródło nadrzędne oraz historię ostatnich operacji. Źródłem nadrzędnym jest system uznany za właściwy przy ustalaniu stanu lub ceny. Ma to znaczenie, ponieważ ręczna zmiana wykonana na platformie może zostać później nadpisana wartością przesłaną z magazynu. Pozornie wygląda to wtedy jak nieskuteczny zapis, chociaż mechanizm działa zgodnie z ustawioną regułą.

Problemy z cenami i regułami aktualizacji

Rozbieżność cenowa nie zawsze wynika z braku połączenia. Cena może być modyfikowana przez regułę, zaokrąglenie, przypisanie do grupy produktów albo ustawienie właściwe dla konkretnego kanału sprzedaży. Reguła cenowa to mechanizm obliczający wartość wysyłaną do platformy na podstawie ceny źródłowej i ustalonych warunków. Jeśli zmieniono cenę w innym polu niż to używane przez regułę, synchronizacja może zakończyć się poprawnie, ale przesłać wartość inną od oczekiwanej.

Sprawdzenia wymaga również to, czy problem dotyczy ceny podstawowej, promocyjnej czy wariantu produktu. Wariant to odmiana tego samego towaru, na przykład różniąca się rozmiarem lub kolorem. Nieprawidłowe powiązanie wariantów może sprawić, że aktualizacja trafi do innej pozycji albo nie zostanie wykonana. Dlatego porównuje się nie tylko nazwy widoczne w panelach, lecz także identyfikatory używane przez połączone systemy.

Zamówienia, które nie zostały pobrane

Brak zamówienia w BaseLinkerze może wynikać z błędu autoryzacji, filtra pobierania, nieobsługiwanego statusu albo chwilowej przerwy po stronie platformy. Autoryzacja oznacza potwierdzenie, że integracja ma prawo odczytywać i zmieniać określone dane. Jeżeli uprawnienia zostały cofnięte lub wygasły, połączenie może nadal być widoczne w konfiguracji, ale kolejne operacje będą odrzucane.

Ważne jest ustalenie, czy zamówienia nie pojawiają się wcale, czy są pobierane bez części informacji. Brak danych kupującego, metody dostawy lub pozycji zamówienia wskazuje na inny rodzaj problemu niż całkowity brak rekordu. Sprawdza się również zakres czasu ustawiony dla pobierania oraz to, czy zamówienie nie zostało przypisane do innego konta lub źródła. Ponowne uruchamianie importu bez takiej kontroli może utworzyć duplikaty, czyli powtórzone rekordy tego samego zamówienia.

Błędy dokumentów i połączeń z księgowością

Gdy zamówienie jest widoczne, ale nie powstaje dokument, przyczyny szuka się w danych wymaganych przez system księgowy lub magazynowy. Może brakować oznaczenia produktu, przypisanej stawki, danych nabywcy albo zgodności między formą płatności i ustawionym schematem dokumentu. Schemat dokumentu to zestaw reguł określających, jaki dokument ma zostać utworzony i jakie dane powinien zawierać.

Komunikat zwrotny z systemu firmowego bywa bardziej przydatny niż ogólna informacja o nieudanej synchronizacji. Pozwala wskazać pole, którego nie zaakceptowano. Po poprawieniu danych trzeba ustalić, czy dokument może zostać wysłany ponownie z istniejącego zamówienia. Nie należy od razu tworzyć go ręcznie, ponieważ późniejsze ponowienie automatycznej operacji może spowodować powstanie drugiego dokumentu.

Co sprawdzić przed ponownym uruchomieniem wymiany danych

Najpierw warto zachować treść komunikatu oraz godzinę wystąpienia problemu. Przydatne są także identyfikatory kilku przykładowych produktów lub zamówień. Identyfikator to unikalne oznaczenie rekordu stosowane przez dany system. Same zrzuty ekranów z końcowym efektem nie zawsze wystarczają, ponieważ podobna rozbieżność może mieć kilka niezależnych przyczyn.

Następnie sprawdza się, czy nie trwa awaria jednego z zewnętrznych systemów oraz czy nikt równolegle nie zmienia konfiguracji. Jeżeli problem pojawił się po aktualizacji, zmianie konta, migracji magazynu lub dodaniu nowej platformy, ta informacja wyznacza właściwy kierunek diagnozy. Do samego zgłoszenia nie należy dołączać hasła. Dostęp powinien być przekazywany tylko wtedy, gdy bez niego nie można przeprowadzić dalszych czynności, wraz z wyjaśnieniem celu.

Błędy podczas samodzielnych prób naprawy

Częstą reakcją jest usunięcie i ponowne dodanie integracji. Taka operacja wykonana bez zapisania ustawień może skasować istotny kontekst: mapowanie magazynów, przypisania statusów oraz reguły aktualizacji. Mapowanie oznacza wskazanie, które pola lub rekordy w jednym systemie odpowiadają elementom w drugim. Ponowne połączenie konta nie odtwarza automatycznie wszystkich wcześniejszych zależności.

Ryzykowne jest także masowe ponawianie wszystkich operacji. Jeżeli część zamówień została już pobrana, a część zatrzymała się w kolejce, ponowienie całego zakresu może doprowadzić do duplikatów lub nadpisania nowszych danych starszymi. Bezpieczniej najpierw wybrać pojedynczy rekord testowy, sprawdzić rezultat, a dopiero później przetwarzać pozostałe zaległości.

Nie należy również ujednolicać kodów produktów bez sprawdzenia ich powiązań. Zmiana oznaczenia w jednym miejscu może zerwać istniejące przypisanie ofert albo połączyć ze sobą niewłaściwe warianty. Przed korektą trzeba ustalić, które pole służy jako podstawa identyfikacji i czy ten sam kod nie jest używany przez kilka różnych kartotek.

Kiedy problem nie wynika z synchronizacji

Nie każda różnica widoczna na platformie jest błędem integracji. Aktualizacja może zostać prawidłowo wysłana, lecz jej prezentacja może zależeć od ustawień samego kanału sprzedaży. Przykładem jest nieaktywna oferta, produkt ukryty, reguła promocji albo stan buforowy. Stan buforowy to część zapasu celowo niewystawiana do sprzedaży. W takim przypadku wartość wyświetlana klientom może być niższa od rzeczywistego stanu w magazynie.

Problem może też dotyczyć pamięci podręcznej, czyli tymczasowo zapisanej wersji danych używanej do szybszego wyświetlania strony. Panel administracyjny może już zawierać aktualną wartość, podczas gdy strona sklepu przez pewien czas pokazuje poprzednią. Jeżeli dziennik potwierdza poprawne wysłanie danych, trzeba sprawdzić etap ich prezentacji, zamiast ponownie zmieniać konfigurację integracji.

Podobnie wygląda sytuacja, gdy użytkownik sprawdza inny magazyn, konto lub wariant niż ten objęty aktualizacją. Porównanie powinno dotyczyć dokładnie tych samych rekordów po obu stronach. Nazwa produktu nie zawsze wystarcza, ponieważ może być powtarzana lub zmieniana niezależnie od jego identyfikatora.

Dodatkowe pytania dotyczące synchronizacji BaseLinker

Czy ponowne połączenie konta przywróci brakujące zamówienia?

Może przywrócić możliwość pobierania nowych danych, ale nie gwarantuje automatycznego uzupełnienia całego okresu awarii. Trzeba sprawdzić zakres importu, historię operacji i obecność zamówień już zapisanych w systemie. Dopiero potem można bezpiecznie ponowić wybrane zadania.

Dlaczego błąd dotyczy tylko jednego produktu?

Najczęściej wskazuje to na problem z kartoteką, kodem, wariantem albo powiązaniem oferty. Jeżeli inne pozycje przechodzą przez to samo połączenie poprawnie, sama autoryzacja prawdopodobnie działa. Porównanie wadliwego produktu z prawidłowo synchronizowaną pozycją pomaga znaleźć różnicę w konfiguracji.

Czy można ręcznie poprawić stan na platformie?

Można, ale trzeba wcześniej ustalić kierunek synchronizacji. Jeżeli stan nadrzędny pochodzi z magazynu, ręczna wartość może zostać nadpisana przy kolejnym cyklu wymiany danych. Taka korekta może być rozwiązaniem tymczasowym, lecz nie usuwa przyczyny rozbieżności.

Co zrobić, gdy komunikat błędu jest niezrozumiały?

Należy zachować jego pełną treść, wraz z informacją o operacji, której dotyczył. Skrócony opis może pominąć nazwę pola lub kod odpowiedzi potrzebny do ustalenia źródła problemu. Nie trzeba samodzielnie interpretować każdego terminu. Ważniejsze jest zachowanie kompletnego zapisu i przykładu rekordu, na którym wystąpił błąd.

Jak sprawdzić, czy naprawa była skuteczna?

Test powinien obejmować nie tylko brak nowego komunikatu. Sprawdza się pełny przebieg na kontrolnym produkcie lub zamówieniu: zapis w źródle, przekazanie danych, ich odbiór oraz końcową wartość w systemie docelowym. Następnie kontroluje się zaległą kolejkę i kilka wcześniejszych rekordów, aby wykluczyć częściową synchronizację.

Kontrola po usunięciu błędu

Naprawę kończy porównanie danych w każdym systemie uczestniczącym w wymianie. Sprawdza się, czy nie pozostały zaległe zadania, duplikaty dokumentów, nieprzetworzone zamówienia lub produkty z dawnymi stanami. Istotna jest kolejność nadrabiania zaległości. Starsza aktualizacja nie powinna nadpisać nowszej wartości, która powstała już po przywróceniu połączenia.

Po uporządkowaniu danych warto udokumentować przyczynę oraz wykonane zmiany. Jeżeli problem wynikał z wygasającego dostępu, można wcześniej kontrolować termin jego odnowienia. Gdy źródłem było niejednoznaczne mapowanie, pomocna jest lista zasad używanych przy dodawaniu kolejnych produktów i wariantów. Dzięki temu następna rozbieżność nie musi być diagnozowana od początku.

Synchronizacja jest naprawiona dopiero wtedy, gdy zgadzają się także zaległe dane

Brak bieżących komunikatów o błędzie to dopiero pierwszy etap. Końcowa weryfikacja powinna potwierdzić, że stany, ceny, zamówienia i dokumenty dotarły do właściwych miejsc, a operacje zatrzymane podczas awarii zostały rozliczone bez powtórzeń. Takie podejście pozwala usunąć nie tylko widoczny objaw, lecz także skutki przerwy w wymianie danych.