Integracja Subiekta GT z BaseLinkerem

Gdy zamówienia ze sklepu nie trafiają do Subiekta GT

Typowym objawem jest brak nowych zamówień w Subiekcie GT mimo ich widoczności w BaseLinkerze. Czasem zamówienia są pobierane, ale nie powstaje dokument sprzedaży, produkt ma niepoprawny indeks albo stan magazynowy nie zmienia się po sprzedaży. Innym problemem może być przesyłanie do sklepu ceny lub dostępności innej niż oczekiwana.

Takie sytuacje zwykle nie oznaczają uszkodzenia programu. Najczęściej przyczyną jest niezgodność kartotek, błędne mapowanie produktów, nieprawidłowe konto użytkownika albo konflikt ustawień odpowiedzialnych za tworzenie dokumentów. Integracja jest połączeniem kilku środowisk, dlatego problem trzeba sprawdzać po obu stronach.

Jakie dane może obejmować integracja

BaseLinker, czyli system pośredniczący w obsłudze zamówień z wielu kanałów sprzedaży, może wymieniać dane z Subiektem GT w kilku obszarach. Zakres zależy od przyjętej konfiguracji oraz sposobu prowadzenia sprzedaży.

• Zamówienia – dane o kupującym, pozycjach, ilościach, dostawie i płatności mogą być przekazywane do Subiekta GT.
• Stany magazynowe – liczba dostępnych sztuk w Subiekcie GT może być źródłem informacji wysyłanej do BaseLinkera, a następnie do sklepów i serwisów sprzedażowych.
• Ceny – ceny sprzedaży lub wybrane poziomy cenowe mogą być przekazywane do kanałów internetowych.
• Dokumenty – na podstawie zamówień mogą powstawać dokumenty handlowe, takie jak faktura lub paragon, zgodnie z przyjętymi regułami.
• Statusy – informacje o realizacji zamówienia, wystawieniu dokumentu lub wysyłce mogą wracać do systemu pośredniczącego.

Nie każdy zakres powinien być włączany jednocześnie. W pierwszej kolejności warto ustalić, który system jest źródłem prawdy dla kartotek, cen, stanów i dokumentów. Bez takiej decyzji oba systemy mogą nadpisywać dane w sposób trudny do przewidzenia.

Wymagania przed rozpoczęciem konfiguracji

Przed rozpoczęciem prac potrzebny jest dostęp do Subiekta GT, BaseLinkera oraz kanałów sprzedaży, które mają uczestniczyć w wymianie danych. Konieczne jest także ustalenie, gdzie znajduje się baza danych Subiekta GT i w jaki sposób program jest uruchamiany.

Ważne jest konto użytkownika z uprawnieniami wystarczającymi do odczytu kartotek, stanów i cen oraz do tworzenia zamówień lub dokumentów, jeżeli taki zakres ma zostać włączony. Uprawnienia administracyjne nie powinny być nadawane bez potrzeby. Lepiej użyć konta przeznaczonego do integracji, którego działania można później łatwo prześledzić.

Produkty muszą mieć stabilne oznaczenia. Najczęściej wykorzystuje się symbol towaru, kod SKU, czyli jednoznaczny identyfikator produktu, albo kod kreskowy. Nazwa towaru może być pomocna dla człowieka, ale nie powinna być jedynym kluczem dopasowania, ponieważ dwie kartoteki mogą mieć podobne nazwy.

Przed jakąkolwiek ingerencją w bazę Subiekta GT wykonywana jest jej kopia bezpieczeństwa. Kopia pozwala wrócić do poprzedniego stanu w razie błędnej modyfikacji, nieudanej aktualizacji albo nieoczekiwanej zmiany konfiguracji.

Najczęstsze przyczyny błędnej synchronizacji

Najczęściej problem zaczyna się od kartotek. Produkt istnieje w Subiekcie GT i BaseLinkerze, ale oba systemy rozpoznają go pod innym symbolem. Wtedy zamówienie może zostać pobrane bez prawidłowego przypisania pozycji. Czasem tworzona jest nowa, dodatkowa kartoteka zamiast użycia już istniejącej.

Drugą częstą przyczyną jest niezgodność jednostek miary. Sprzedaż prowadzona w sztukach nie powinna być automatycznie łączona z kartoteką prowadzoną w opakowaniach bez określenia przelicznika. Przelicznik, czyli reguła określająca relację między jednostkami, musi odpowiadać rzeczywistemu sposobowi sprzedaży.

Problemy powoduje także wybór niewłaściwego magazynu. Subiekt GT może zawierać więcej niż jeden magazyn, a BaseLinker może pobierać stan tylko z jednego z nich. W efekcie sklep pokazuje dostępność, której nie ma w magazynie obsługującym dane zamówienia.

Nieprawidłowości mogą wynikać również z ustawień statusów, płatności i dokumentów. Zamówienie opłacone, pobraniowe i anulowane może wymagać innej ścieżki. Jeśli reguła tworzenia dokumentu nie rozróżnia tych przypadków, dokument może powstać zbyt wcześnie, zbyt późno albo wcale.

Przygotowanie kartotek i reguł wymiany

Prace zaczynają się od przeglądu kartotek towarów. Sprawdzane są symbole, kody kreskowe, jednostki miary, stawki podatku, ceny oraz przypisanie do magazynu. Szczególnej uwagi wymagają produkty wielowariantowe, zestawy i towary sprzedawane w różnych jednostkach.

W przypadku zestawu trzeba określić, czy BaseLinker ma otrzymywać stan gotowego zestawu, czy stan ma być wyliczany na podstawie składników. Zestaw towarów, czyli pozycja składająca się z kilku innych kartotek, może być obsługiwany inaczej niż zwykły produkt. Bez jednoznacznej reguły systemy mogą prezentować różne ilości dostępne do sprzedaży.

Następnie ustalane są kierunki przepływu danych. Kierunek jednokierunkowy oznacza, że dane są wysyłane tylko z jednego systemu do drugiego. Kierunek dwukierunkowy pozwala na wymianę w obie strony, ale zwiększa ryzyko nadpisania informacji. Dla cen i stanów często warto wskazać jeden system nadrzędny.

Konfiguracja połączenia między systemami

Po przygotowaniu danych konfigurowane jest połączenie między BaseLinkerem a Subiektem GT. W zależności od zastosowanego rozwiązania może ono korzystać z modułu komunikacyjnego, połączenia z bazą albo Sfery GT. Sfera GT to interfejs programistyczny oparty na COM i OLE Automation, który pozwala zewnętrznym aplikacjom wykonywać określone operacje w programach InsERT GT.

Sfera GT działa w Subiekcie, Gestorze, Rewizorze i Gratyfikancie, jednak integracje ze sklepem internetowym w opisywanym zakresie dotyczą Subiekta GT. Rewizor GT, Rachmistrz GT, Gratyfikant GT i Gestor GT mogą być obsługiwane oraz wdrażane niezależnie, bez integracji ze sklepem internetowym. Nie dotyczy to Subiekt nexo, który należy do innej rodziny programów.

Podczas konfiguracji określa się bazę, użytkownika, magazyn, rodzaje dokumentów i sposób identyfikacji towarów. Ustawiane są także reguły obsługi statusów zamówień, płatności, dostawy i anulowania. Każda reguła powinna mieć jasny cel, ponieważ nadmiar wyjątków utrudnia późniejszą kontrolę.

Tworzenie dokumentów i obsługa statusów

Jedno zamówienie internetowe może prowadzić do utworzenia kilku różnych dokumentów zależnie od procesu sprzedaży. Dokument zamówienia, czyli zapis informujący o planowanej realizacji, nie jest tym samym co dokument sprzedaży. Trzeba ustalić, na którym etapie powstaje dokument w Subiekcie GT.

Znaczenie ma także status zamówienia. Status to oznaczenie etapu obsługi, na przykład oczekiwania na płatność, przygotowania do wysyłki albo anulowania. Samo pobranie zamówienia nie powinno automatycznie oznaczać, że sprzedaż została zakończona. Reguły muszą uwzględniać zamówienia nieopłacone, częściowo opłacone, zwrócone i anulowane.

Przy dokumentach sprawdzane są dane nabywcy, adresy, numery identyfikacyjne, stawki podatku, formy płatności oraz koszty dostawy. Warto rozdzielić koszt transportu od pozycji towarowej, jeżeli tak prowadzona jest ewidencja. Pozwala to uniknąć sytuacji, w której dostawa zmniejsza stan magazynowy albo trafia do niewłaściwej kartoteki.

Testy przed uruchomieniem sprzedaży

Przed przełączeniem integracji na pełną pracę wykonywane są testy na ograniczonym zakresie. Sprawdzane jest pobranie zamówienia z jedną pozycją, zamówienia z kilkoma produktami, sprzedaż produktu o małym stanie oraz zamówienie anulowane. Jeżeli występują różne formy dostawy i płatności, każda istotna kombinacja powinna zostać sprawdzona.

Test obejmuje cały obieg, a nie tylko pojawienie się zamówienia w Subiekcie GT. Należy sprawdzić, czy produkt został prawidłowo rozpoznany, czy ilość jest zgodna, czy dokument ma poprawne dane oraz czy zmiana stanu wraca do BaseLinkera. Następnie weryfikuje się, czy BaseLinker przekazuje poprawną dostępność do właściwego kanału sprzedaży.

Wyniki testów warto zapisać. Przydatny jest prosty opis użytego zamówienia, oczekiwanego rezultatu i faktycznego zachowania. Taki zapis ułatwia rozpoznanie regresji, czyli ponownego pojawienia się problemu po zmianie konfiguracji lub aktualizacji programu.

Kontrola działania po uruchomieniu

Po uruchomieniu integracji należy obserwować kilka niezależnych elementów. Pierwszym jest kolejka zamówień, czyli lista operacji oczekujących na przetworzenie. Drugim są komunikaty błędów, które mogą wskazywać na brak uprawnień, nieznaną kartotekę albo problem z połączeniem.

Kontrolowane są także różnice między stanem w Subiekcie GT a stanem widocznym w BaseLinkerze. Jednorazowa zgodność nie wystarcza, ponieważ problem może ujawnić się dopiero przy anulowaniu zamówienia, korekcie albo sprzedaży produktu z kilku kanałów.

Warto ustalić procedurę obsługi wyjątków. Wyjątek to przypadek, którego reguły automatyczne nie potrafią obsłużyć, na przykład brak kodu produktu lub nietypowa forma płatności. Takiego zamówienia nie powinno się bezrefleksyjnie przetwarzać ponownie, ponieważ może powstać drugi dokument albo podwójna rezerwacja stanu.

Co można sprawdzić samodzielnie

Samodzielnie można sprawdzić, czy komputer z Subiektem GT ma dostęp do sieci, czy program uruchamia się bez komunikatu o błędzie oraz czy problem dotyczy wszystkich zamówień, czy tylko wybranych produktów. Pomocne jest porównanie symbolu produktu w obu systemach i sprawdzenie, z którego magazynu pobierany jest stan.

Można również sprawdzić kolejkę operacji w BaseLinkerze, ostatni komunikat błędu oraz status konkretnego zamówienia. Warto zanotować czas wystąpienia problemu, identyfikator zamówienia i symbol produktu. Takie informacje ułatwiają analizę bez konieczności powtarzania całego procesu.

Nie należy jednak usuwać zamówień, kartotek ani dokumentów tylko po to, aby wymusić ponowne przetwarzanie. Przed zmianą konfiguracji trzeba zabezpieczyć bazę Subiekta GT i ustalić, czy dana operacja nie została już wykonana częściowo.

Błędy popełniane przy samodzielnych próbach

Częstym błędem jest wielokrotne uruchamianie synchronizacji bez sprawdzenia przyczyny. Jeśli problemem jest błędny symbol produktu, kolejne próby nie naprawią mapowania, a mogą utworzyć duplikaty dokumentów.

Ryzykowne jest także ręczne zmienianie stanów magazynowych w kilku systemach równocześnie. Jeżeli Subiekt GT jest źródłem stanów, ręczna korekta w BaseLinkerze może zostać później nadpisana. Podobne ryzyko dotyczy cen, statusów i numerów dokumentów.

Nie powinno się usuwać kartoteki, która nie pasuje do zamówienia, bez sprawdzenia jej historii. Mogła zostać użyta w starszych dokumentach albo w innym kanale sprzedaży. Bezpieczniejsza jest analiza powiązań i poprawienie reguły identyfikacji.

Nie należy też zmieniać ustawień produkcyjnych bez kopii bazy i planu wycofania zmiany. W przypadku większej liczby produktów lub dokumentów ręczne poprawki mogą być bardziej ryzykowne niż uporządkowanie konfiguracji.

Kiedy problem nie dotyczy integracji

Nie każda rozbieżność jest błędem połączenia BaseLinkera z Subiektem GT. Jeżeli stan w Subiekcie GT jest niepoprawny jeszcze przed synchronizacją, przyczyną może być błędne przyjęcie towaru, dokument magazynowy albo sprzedaż wykonana poza ustalonym obiegiem.

Jeżeli zamówienie nie pojawia się w BaseLinkerze, problem może leżeć po stronie sklepu, operatora płatności lub kanału sprzedażowego. Jeżeli zamówienie jest w BaseLinkerze, ale nie ma go w Subiekcie GT, wtedy dopiero warto sprawdzać połączenie, uprawnienia i mapowanie.

Innym przypadkiem jest niewłaściwa cena wyświetlana tylko w jednym kanale. Może to wynikać z osobnego cennika, promocji albo reguły sklepu, a nie z błędu Subiekta GT. Podobnie opóźnienie po stronie przewoźnika nie jest problemem synchronizacji dokumentów handlowych.

Pytania, które warto ustalić przed wdrożeniem

Który system ma być źródłem stanów magazynowych?

Należy wskazać jeden system nadrzędny. W typowym wariancie stany są prowadzone w Subiekcie GT, a BaseLinker przekazuje je dalej do kanałów sprzedaży. Jeżeli część operacji odbywa się poza Subiektem, trzeba uwzględnić ją w procedurze, aby nie powstawały rozbieżności.

Czy wszystkie zamówienia mają tworzyć dokumenty automatycznie?

Nie zawsze. Zamówienia nieopłacone, podejrzane lub wymagające ręcznej weryfikacji mogą być tylko pobierane do obsługi. Automatyczne tworzenie dokumentu powinno być powiązane z jasno określonym statusem i warunkiem realizacji.

Jak rozpoznawane są produkty?

Najbezpieczniej oprzeć dopasowanie na stabilnym symbolu, kodzie SKU lub kodzie kreskowym. Jeśli w kanałach sprzedaży występują różne oznaczenia, potrzebna jest jawna mapa powiązań między kartotekami.

Co ma się stać z zamówieniem anulowanym lub zwróconym?

Trzeba określić, czy anulowanie usuwa rezerwację, czy wymaga dodatkowego dokumentu. Zwrot może wymagać przyjęcia towaru na magazyn i korekty sprzedaży. Te operacje powinny być zgodne z rzeczywistym obiegiem dokumentów w Subiekcie GT.

Podsumowanie działania integracji

Integracja Subiekta GT z BaseLinkerem wymaga uporządkowanych kartotek, wskazania źródła danych i przemyślanych reguł tworzenia dokumentów. Najwięcej problemów powodują niezgodne symbole produktów, błędny magazyn, różne statusy zamówień oraz równoczesne ręczne zmiany w kilku systemach.

Bezpieczne uruchomienie obejmuje kopię bazy, konfigurację uprawnień, testy na ograniczonym zakresie i kontrolę pełnego obiegu danych. Dzięki temu można odróżnić problem integracji od błędu kartoteki, sklepu, płatności lub procesu magazynowego.