Integracja sklepu internetowego z Subiektem GT

Sklep internetowy działający bez połączenia z systemem magazynowym oznacza podwójną pracę — te same dane trzeba wprowadzać ręcznie w dwóch miejscach. Integracja z Subiektem GT eliminuje tę duplikację.

Objaw

Zgłoszenia dotyczą sklepów działających niezależnie od systemu magazynowego, w których asortyment, ceny i stany trzeba aktualizować osobno w obu miejscach, co prowadzi do rozbieżności i pomyłek.

Możliwe przyczyny

Zamiast typowej usterki, ten punkt opisuje sytuację wyjściową: sklep uruchomiony bez integracji, bo w momencie startu firma nie przewidziała skali, przy której ręczna synchronizacja przestaje się sprawdzać, albo zmiana systemu magazynowego wymagająca skonfigurowania integracji od nowa.

Co robimy

Wdrażana jest synchronizacja asortymentu, cen, opisów produktów i zdjęć między Subiektem a sklepem, wraz ze stanami magazynowymi aktualizowanymi automatycznie po każdej sprzedaży. Konfigurowane jest automatyczne fakturowanie zamówień złożonych w sklepie oraz obsługa dokumentów ZK, WZ, FS generowanych na ich podstawie bezpośrednio w Subiekcie. Integracja skonfigurowana jest jako dwukierunkowa, żeby zmiany po obu stronach — w sklepie i w systemie magazynowym — były ze sobą zawsze spójne.

Ile to trwa

Wdrożenie integracji to zwykle kilka dni pracy, zależnie od liczby produktów i złożoności cennika.

Co można zrobić samemu, zanim przyjedzie serwisant

Warto przygotować dostęp administracyjny do Subiekta GT oraz do panelu sklepu, a także określić, które dane mają być głównym źródłem prawdy — na przykład ceny ustalane zawsze w Subiekcie, a przenoszone automatycznie do sklepu.

Czego nie robić: nie warto uruchamiać integracji bez wcześniejszego testu na kilku przykładowych produktach — łatwiej poprawić błąd mapowania na małej próbce niż po synchronizacji całego asortymentu.

Warunki

Wdrożenie integracji wyceniane jest indywidualnie, zależnie od zakresu i liczby produktów.

Warianty integracji w zależności od platformy e-commerce

Rozbudowa systemu magazynowego o automatyczną wymianę danych ze sklepem wymaga dopasowania technologii do silnika, na którym oparta jest platforma sprzedażowa. Sposób komunikacji różni się w zależności od zastosowanego rozwiązania oraz architektury samego środowiska informatycznego.

Platformy typu open source (oprogramowanie o otwartym kodzie źródłowym), takie jak WooCommerce (system e-commerce oparty na popularnym systemie zarządzania treścią WordPress) oraz PrestaShop, pozwalają na pełną ingerencję w strukturę bazy danych. W ich przypadku stosuje się dedykowane moduły (wtyczki rozszerzające funkcjonalność) instalowane bezpośrednio w panelu sklepu, lub zewnętrzne aplikacje typu integrator. Tego rodzaju integrator jest najczęściej instalowany na tym samym komputerze lub lokalnym serwerze w firmie, na którym uruchomiona jest baza Microsoft SQL Server (silnik bazodanowy wykorzystywany przez oprogramowanie InsERT do przechowywania wszystkich danych o firmie). Integrator łączy się z bazą Subiekta bezpośrednio, a ze sklepem internetowym komunikuje się poprzez udostępniane przez niego środowisko API (interfejs programistyczny umożliwiający wymianę danych przez sieć internetową).

W przypadku platform typu SaaS (oprogramowanie udostępniane jako usługa abonamentowa utrzymywana w chmurze producenta), takich jak Shoper, Click Shop czy Sky-Shop, użytkownik nie ma bezpośredniego dostępu do plików źródłowych ani struktury serwera. Integracja opiera się wtedy w całości na autoryzowanym połączeniu szyfrowanym. Wymiana danych w takim modelu jest w pełni nadzorowana przez specjalny program pośredniczący na komputerze lokalnym, który wysyła gotowe pakiety informacji o zmianach cen czy stanów magazynowych w ściśle określonych interwałach czasowych (na przykład co dziesięć minut lub co godzinę).

Wybór odpowiedniego narzędzia integracyjnego jest determinowany przez elastyczność samej platformy oraz docelową wielkość asortymentu. Sklepy oferujące kilkadziesiąt tysięcy niezależnych pozycji wymagają rozwiązań zoptymalizowanych pod kątem wysokiej wydajności, aby cykliczny proces synchronizacji nie obciążał nadmiernie łącza internetowego oraz procesora głównego na komputerze pełniącym funkcję serwera bazy danych w siedzibie firmy.

Kierunki synchronizacji i prawidłowe zarządzanie przepływem informacji

Istotnym aspektem poprawnego wdrożenia wymiany danych jest ustalenie tak zwanego nadrzędnego źródła prawdy (głównego miejsca, w którym edytowane są kluczowe dane biznesowe, nadpisującego dane w innych systemach). Zasadą powszechnie przyjętą w środowiskach handlowych jest traktowanie Subiekta GT jako systemu priorytetowego dla polityki cenowej oraz całej gospodarki magazynowej. Wszelkie fizyczne przyjęcia zewnętrzne towaru (dokumenty magazynowe PZ), wydania oraz inwentaryzacje okresowe odbywają się wyłącznie w programie InsERT. Zmienione w ten sposób ilości towarów są od razu wysyłane do bazy sklepu internetowego. Dzięki takiemu podejściu stany widoczne na karcie produktu w przeglądarce internetowej klienta precyzyjnie odzwierciedlają faktyczną dostępność towaru na półce.

Kierunek odwrotny (przesyłanie informacji ze sklepu internetowego do programu Subiekt) obsługuje przede wszystkim nowe zamówienia. Gdy klient finalizuje zawartość wirtualnego koszyka, system e-commerce generuje pakiet danych zawierający szczegółowe informacje o nabywcy, wybranym sposobie dostawy, formie płatności oraz liście zakupionych produktów. Działający w tle integrator natychmiast odbiera te dane i samoczynnie tworzy w systemie magazynowym dokument ZK (Zamówienie od Klienta). W zależności od przyjętych ustawień księgowych dokument ten może od razu rezerwować stany magazynowe zdejmując je z puli dostępnej do sprzedaży, co zapobiega problematycznej sytuacji, w której inny klient kupuje ten sam, fizycznie ostatni egzemplarz produktu z magazynu.

Zautomatyzowany proces obejmuje również synchronizację statusów operacji. Kiedy pracownik biurowy realizuje dokument ZK w Subiekcie i przekształca go w odpowiedni dokument końcowy (na przykład Paragon Imienny lub Fakturę Sprzedaży), program synchronizujący odnotowuje tę zmianę w bazie i natychmiast wysyła sygnał zwrotny do systemu sklepowego. Na podstawie tego sygnału status danego zamówienia w panelu e-commerce zmienia się na „Gotowe do wysyłki” lub „Zrealizowane”, co najczęściej uruchamia w tle automatyczną wysyłkę powiadomienia e-mail do kupującego z informacją o nadaniu paczki. Tak zoptymalizowany obieg dokumentacji całkowicie eliminuje konieczność ręcznego, podwójnego ewidencjonowania tych samych transakcji.

Częste błędy przy samodzielnych próbach konfiguracji środowiska

Uruchomienie automatycznej wymiany kilkuset lub kilku tysięcy rekordów bazy danych bez odpowiedniego przygotowania informatycznego często skutkuje trwałym uszkodzeniem struktury kartotek w obu systemach naraz. Klienci podejmujący całkowicie samodzielne próby konfiguracji integratora regularnie napotykają poważne problemy, które wynikają z braku spójności identyfikatorów produktów. Podstawowym błędem wdrożeniowym jest oparcie powiązań między produktem widniejącym w Subiekcie a produktem zapisanym w sklepie na samej nazwie tekstowej. Nazwy często różnią się drobnymi szczegółami (na przykład dodatkową spacją lub wielkością liter), co sprawia, że program nie rozpoznaje istniejącego towaru jako tożsamego i generuje jego zupełnie nowy duplikat w bazie platformy sprzedażowej. Prawidłowe i bezpieczne mapowanie (trwałe wiązanie odpowiadających sobie logicznie pozycji w dwóch różnych bazach) powinno opierać się na unikalnych identyfikatorach, takich jak symbol towaru nadany w programie magazynowym lub standardowy kod kreskowy EAN (międzynarodowy numer przypisany do artykułu).

Kolejnym niezwykle powszechnym problemem jest ignorowanie kwestii zestrojenia stawek podatku VAT (podatku od towarów i usług). Sklep internetowy i program magazynowy muszą zawsze operować na dokładnie takich samych tabelach i identyfikatorach podatkowych. Przypisanie niewłaściwych klas podatkowych (na przykład zmuszenie programu do potraktowania stawki krajowej 23% jako sprzedaży zwolnionej z podatku) skutkuje seryjnym generowaniem błędnych dokumentów księgowych i fiskalnych, co wymaga później skomplikowanego, ręcznego korygowania każdej zakończonej sprzedaży za pomocą osobnych dokumentów korekty.

Błędy logiczne zdarzają się również często w obszarze zarządzania wariantami (produktami bazowymi posiadającymi specyficzne cechy, takie jak rozmiar koszulki czy kolor obudowy). Standardowa wersja programu Subiekt GT nie posiada wbudowanego, zaawansowanego mechanizmu drzewiastego wariantów, co w praktyce zmusza operatorów do tworzenia osobnych, płaskich kartotek dla każdego dostępnego rozmiaru z osobna. Jeśli dany silnik sklepu internetowego narzuca strukturę nadrzędną (produkt główny będący kontenerem) i podrzędną (warianty z własnym, niezależnym stanem magazynowym), brak odpowiednio zaawansowanej konfiguracji samego integratora spowoduje nieestetyczne wyświetlenie w sklepie kilkunastu osobnych, podobnych do siebie produktów, zamiast jednej przejrzystej karty towaru z listą rozwijaną dla klienta.

Krytycznym niedopatrzeniem podczas prac technicznych jest także uruchamianie pełnej, masowej synchronizacji cenników bez wcześniejszego utworzenia pełnej kopii zapasowej (tak zwanego backupu danych). Kopia taka musi obejmować zarówno relacyjną bazę SQL serwera obsługującego Subiekta, jak i komplet plików źródłowych oraz bazę danych silnika sklepu. W przypadku pomyłkowego nadpisania wypracowanych od lat opisów produktów lub zresetowania cen detalicznych do zera, brak takiego punktu przywracania uniemożliwia pracownikom serwisu szybkie odtworzenie poprawnego stanu wyjściowego systemu.

Kiedy problemem nie jest brak narzędzia, lecz jego awaria

Wielokrotnie zgłoszenia serwisowe kierowane pod nasz numer telefonu nie dotyczą pierwszej konfiguracji środowiska dla nowych sklepów, ale sytuacji awaryjnej, w której sprawnie działająca wcześniej wymiana danych pomiędzy serwerami nagle ulega całkowitemu wstrzymaniu. Prawidłowa diagnoza takiego stanu rzeczy wymaga kompleksowego sprawdzenia kilku odrębnych płaszczyzn teleinformatycznych. Pierwszym, często pomijanym elementem jest środowisko serwerowe zlokalizowane po stronie samej platformy e-commerce. Firmy hostingowe (dostawcy utrzymujący wirtualne przestrzenie na swoich serwerach w centrach danych) regularnie wprowadzają zaawansowane ograniczenia bezpieczeństwa. Zautomatyzowane uruchomienie nowej reguły dla zapory sieciowej (programu firewall filtrującego ruch) może zablokować ruch przychodzący na specyficznym porcie numerycznym używanym przez komunikację narzędzi zewnętrznych, co natychmiast odcina mechanizm Subiekta od bazy sklepu, mimo że sam interfejs sklepowy pozostaje nadal w pełni dostępny dla przeglądających go internautów.

Zupełnie inną, równie częstą przyczyną nieoczekiwanych przestojów są nieprzemyślane i nieskoordynowane aktualizacje technologiczne. Wykonanie głównej aktualizacji silnika sklepu internetowego do najnowszej wersji często pociąga za sobą modyfikację wewnętrznej struktury tabel w bazie danych, dodając nowe pola lub usuwając te uznane za przestarzałe. Jeśli oprogramowanie integrujące pracujące w biurze nie zostało w tym samym czasie zaktualizowane przez swojego producenta w celu zagwarantowania kompatybilności z nowym wydaniem platformy sprzedażowej, proces masowego zapisu nowych cen wtyczki integracyjnej kończy się nieodwracalnym błędem i zawieszeniem procedury.

W sieciowych systemach sprzedażowych zdarzają się również rozległe blokady na poziomie wydajnościowym środowiska. Bardzo duża rotacja fizycznego towaru w krótkim czasie lub też konieczność wykonania masowej aktualizacji cen cennika dostawców (wymagająca przeliczenia algorytmem nowej marży dla kilku lub kilkunastu tysięcy indeksów towarowych w jednym przebiegu) wymusza generowanie potężnej liczby zapytań do serwera docelowego w niezwykle krótkim przedziale czasowym. Zabezpieczenia chroniące przez atakami objętościowymi (typu anty-DDoS) skonfigurowane domyślnie na serwerze sklepu internetowego mogą potraktować taki nagły, masowy ruch danych jako atak hakerski, po czym trwale blokują adres IP sieci internetowej, z której fizycznie łączy się dany integrator pracujący w firmie użytkownika. W takiej sytuacji niezbędna staje się interwencja techniczna u docelowego dostawcy usług hostingowych i administracyjne wdrożenie tak zwanej białej listy adresacji (whitelist) uodparniającej wybrane pule adresów IP na agresywne filtry obronne.

Najczęstsze pytania klientów

Czy integracja zadziała ze starszymi wersjami programu magazynowego na starszym systemie?

Zdecydowana większość obecnie stosowanych, nowoczesnych programów pośredniczących w transferze informacji wymaga relatywnie nowych, zaktualizowanych wersji oprogramowania systemu InsERT GT. Starsze, nierozwijane wieloletnie instalacje mogą posiadać archaiczną strukturę bazy SQL lub całkowity brak wbudowanych we wczesnych wersjach funkcji dedykowanych systemu Sfera (jest to specjalny, licencjonowany dodatek programistyczny dostarczany przez firmę InsERT, bezwzględnie wymagany przez wiele integratorów do poprawnego odczytu i bezkolizyjnego zapisu dokumentów w bazie głównej z zewnątrz). Przed rozpoczęciem pierwszych prac konfiguracyjnych weryfikowana jest bieżąca wersja licencji stanowiskowych i, jeśli zachodzi taka potrzeba technologiczna, przeprowadzana jest ogólna aktualizacja całego oprogramowania bazowego firmy do bieżącej i wspieranej wersji rynkowej.

Czy można stabilnie podłączyć kilka różnych sklepów do jednego programu bazowego?

Tak, system przewiduje takie rozwiązanie. Jest to bardzo popularny scenariusz wdrożeniowy w nowoczesnych firmach handlowych prowadzących rozbudowaną sprzedaż wielokanałową (prowadząc na przykład rozbudowany sklep hurtowy pod pierwszą domeną internetową i mniejszy sklep detaliczny dla konsumentów pod drugą, niezależną marką). Odpowiednia konfiguracja w zaawansowanym widoku integratora pozwala powiązać poszczególne platformy internetowe z osobnymi magazynami wirtualnymi wydzielonymi wcześniej w ramach jednej instancji głównej Subiekta. Mechanizm ten nakłada jednak wymóg bardzo precyzyjnego i zaawansowanego zdefiniowania w programie oddzielnych cenników, które będą na stałe przypisane do odpowiednich, konkretnych kanałów dystrybucji na zewnątrz.

Czy w trakcie wdrażania połączenia i pierwszych testów cała platforma sklepowa musi zostać wyłączona?

Przez zdecydowaną większość czasu przeznaczonego na przygotowywanie wewnętrznych ustawień i konfiguracji sprzętowych zewnętrzna platforma zakupowa może działać całkowicie normalnie dla wizytujących klientów. Przejście systemu w tak zwany tryb konserwacji (czyli celowe, tymczasowe ukrycie interfejsu dla kupujących z jednoczesnym wyświetleniem im specjalnego komunikatu graficznego o planowanej przerwie technicznej) zalecane jest bezwzględnie i wyłącznie na samym etapie pierwszej, pełnej, masowej synchronizacji obejmującej przesyłanie setek lub tysięcy rekordów pełnej bazy. Zabezpieczenie to ma na celu stuprocentowe uniknięcie konfliktów bazodanowych na wypadek sytuacji, w której klient fizyczny dokonałby zatwierdzenia zakupu w koszyku w tej samej mikrosekundzie, w której pracujący w tle system integratora aktualizuje dany obiekt i modyfikuje jego dostępne ilości rynkowe.

Co z dotychczasowym asortymentem, który przez miesiące został wprowadzony ręcznie do obu systemów osobno?

Przed bezpiecznym uruchomieniem stałej, automatycznej pętli synchronizacyjnej wykonywany jest zawsze proces tak zwanego mapowania asortymentu w przygotowanym środowisku. Dedykowany mechanizm precyzyjnie analizuje wszystkie unikalne kody powiązane z towarem (takie jak główny symbol zdefiniowanego towaru, unikalny kod kreskowy zgodny z formatem EAN lub opcjonalne, specjalnie do tego celu powołane pole rozszerzone w kartotece). Po odnalezieniu pasujących par po obu stronach systemu, program nie dubluje istniejącej listy asortymentowej. Zamiast tego łączy odpowiadające sobie pozycje w jeden spójny rekord, widoczny i obsługiwany tak samo po stronie sklepu, jak i systemu magazynowego.

Podsumowanie wdrożenia

Zbudowanie zautomatyzowanego kanału komunikacji między platformą sklepową a systemem InsERT odciąża pracowników odpowiedzialnych za księgowość i wprowadzanie danych. Zmniejsza też ryzyko sprzedaży towaru, którego fizycznie nie ma już na stanie, co chroni wizerunek firmy w oczach klientów.

22 378 48 09