Integracja sklepów detalicznych z hurtowniami, dystrybutorami i producentami daje wymierne korzyści biznesowe. W dobie wszechobecnego Internetu jest niezbędnym instrumentem budowania przewagi rynkowej.
Ale jak to zrobić? Jak zbudować system powiązań… Sieć między oprogramowaniem ERP, sklepem i serwisami aukcyjnymi? I co zrobić jeśli ów sieć powiązań jest tak skomplikowana, że obecne w niej sklepy i serwisy aukcyjne pełnią różne, często naprzemienne role? Bo przecież może zaistnieć taki przypadek, że na jednym sklepie mamy produkty z dwóch innych sklepów należących do naszej sieci. Może też zdarzyć się, że na jednym sklepie mamy produkty z kilku hurtowni. W końcu są i tak skomplikowane sytuacje, gdzie na jednym sklepie mamy produkty, których stany magazynowe są regulowane właśnie przez ten sklep, jak i są tam produkty, których stany dyktuje zewnętrzna hurtownia.
Przypadków jest co niemiara i każdy z nich jest indywidualny. Sieć powiązań między różnymi platformami sprzedażowymi, ba! Sieć powiązań między różnymi produktami może być tak zawiła, że trudno w ogóle uzmysłowić sobie system tych powiązań, a co dopiero go zbudować. Od pewnego jednak czasu, co najmniej od kilku lat, takie sieci buduje się, jak i tworzone są oprogramowania pozwalające na wielokierunkową synchronizację przechodzących danych produktowych (stanów i cen).
Można w tym celu wykorzystać oprogramowanie typu integrator, jakim jest Baselinker (lub zbudować autorskie oprogramowanie). W niektórych, nieco bardziej skomplikowanych przypadkach należy też dodać inne programy integrujące. Dodatkowego oprogramowania wymaga zarówno integracja sklepu z ERPem. Rozszerzenie może wymagać też oprogramowanie sklepu działającego na zasadach multistore. Wiele zależy jednak od samego integratora, na którym działamy, jak i technologii, w jakiej zbudowany został nasz sklep. Dla przykładu na sklepie PrestaShop rozwiązania typu multistore są zaaplikowane już na podstawowej wersji oprogramowania i skorzystanie z nich jest stosunkowo proste. A na WooCommerce wymagają instalacji dodatkowych pluginów.
Baselinker synchronizacja produktów na sklepie
Co w takich integracjach jest trudnego? Co może się nie powieść i na jakie problemy możemy natrafić? Zacznę może od tego, że zbudowanie niektórych systemów powiązań jest trudne do wycenienia. Trudność ta wynika zarówno z wielości możliwych komplikacji i możliwych braków kompatybilności, jak i z faktu, że wbrew pozorom tego typu systemy nie są bezobsługowe i należy dość dobrze znać ich logikę, jak i umieć nie popełniać błędów i ewentualne błędy identyfikować i naprawiać.
Multistore (multishop)
W zasadzie problematyka multistore nie stanowi sedna problemu synchronizacji danych produktowych, bo bardzo rzadko zdarza się potrzeba budowania tego typu rozszerzenia, to warto na nią zwrócić uwagę, chociażby z tego względu, że jest to element niezbędny do zbudowania nieco bardziej rozbudowanej sieci powiązań. Z łatwiejszymi przypadkami radzimy sobie bez tego rozwiązania. W momencie jednak, kiedy wszystkie pomysły zawodzą i szukamy innego pomysłu dla synchronizacji stanów i cen produktowych, możemy sięgnąć właśnie po tego typu rozszerzenie.
Czym jest multistore (multishop)? To możliwość zarządzania kilkoma domenami z panelu jednego sklepu. W ramach jednego panelu administracyjnego możemy zarządzać zamówieniami, stanami i cenami z kilku sklepów postawionych na różnych domenach.
Co daje nam implementacja multishop? Jest to remedium na obsługę zamówień z wielu sklepów internetowych w jednym panelu administracyjnym. Ale nie tylko. Bo co za tym idzie, multishop może pomóc w prawidłowym przesyłaniu zamówień do integratorów, takich jak np. BaseLinker. Ktoś może zauważyć, że równie dobrze do BaseLinker można pobierać zamówienia z każdego sklepu osobno i obsługiwać po stronie BL, do tego przecież służy ten i jemu podobne integratory. Niemniej w sieci powiązań zdarzają się sytuacje, kiedy lepiej jest zaciągnąć zamówienia z jednego sklepu. Niekiedy inaczej nie będzie można zbudować dobrze reagującej na zmiany stanów i cen, zdywersyfikowanej siatki powiązań między produktami dodanymi do jednego sklepu, ale pochodzącymi z różnych sklepów (kiedy inne serwisy dyktują ich stany i ceny magazynowe). Kiedy jeden sklep wysyła dane dotyczące stanów i cen magazynowych do integratora, jak i musi też je pobierać z integratora, wtedy znaczenia zaczyna nabierać to, oprogramowanie rozumie, że niezależnie od tego, w którą stronę działa synchronizacja, w obydwu przypadkach stany magazynowe produktów w zamówieniach powinny obniżyć stany w integratorze.
“Zamówienie wpływa do BaseLinker z integracji X stan w konkretnym katalogu się zmniejsza, następnie dzięki kierunkowi “sklep podrzędny” stan wysyłany jest na pozostałe integracje, stany się zgadzają, BaseLinker = sklepy, wszystko funkcjonuje zgodnie z zasadami logiki.”
Jeśli jednak nasze powiązania między sklepami wyślizgują się tej logice, to przyczynę braku synchronizacji można (można, choć niekoniecznie tak jest) upatrywać w braku aplikacji multistore (multishop). I adekwatnie, jeśli synchronizacja zachodzi poprawnie, to możliwe, że właśnie dzięki implementacji tego typu rozszerzenia na sklepie (podstawowa wersja sklepu może posiadać takie rozwiązanie), jak i odpowiedniej konfiguracji integratora.
Jak skonfigurować Baselinker na potrzeby multistore (multishop)?
Woocommerce nigdy nie pozwalał na prowadzenie multistore w podstawowej instalacji. Na rynku dostępne są rozszerzenia dla WooCommerce pozwalające na realizację modelu multistore. PrestaShop dla przykładu pozwala na jednej bazie danych, co za tym idzie jednych ID produktów prowadzić kilka domen sklepu deklarując odpowiednie presta_shop_id w ustawieniach zaawansowanych integracji. Wtedy tworzy się X integracji na tych samych (lub innych, to nie ma większego znaczenia) domenach z zaplecza sklepu, podaje się odpowiednie ID sklepu w ustawieniach zaawansowanych… I dalej w ustawieniach zaawansowanych uruchamia się parametr og_ignore_shop_id.
Jak opracować system powiązań?
Czyli jak uzyskać dostęp do obecnego systemu informatycznego, w taki sposób aby uzyskać pożądane dane? Choć jest to dość prowokacyjne pytanie, tak chodzi w nim tylko o to, aby opracować taki system powiązań między sklepami, aby zrealizować zakładane cele. Często bowiem w naszej sieci powiązań detalicznych, hurtowych i producenckich występuje tak duża plątanina zależności magazynowo-cenowych, że nie ma dla nich gotowego rozwiązania w obrębie istniejących programów, lub też rozwiązania te są tak głęboko ukryte, że o ich wykorzystaniu nie zdawali sobie twórcy oprogramowania. Niekiedy udaje nam się, “lepiąc” różne programy i przestawiając liczne wajchy konfiguracyjne, zbudować taką chimerę, której nikt jeszcze nie wymyślił (nie przetestował) … i na dodatek rozwiązanie to działa.
W celu realizacji takiego zadania konieczne jest przygotowanie audytu. Szczegółowe rozpoznanie problemu, to pierwszy krok do sukcesu. Kolejnym krokiem na drodze rozwiązania problemu prawidłowej synchronizacji stanów i cen w skomplikowanej sieci powiązań zakupowo-sprzedażowych jest posiadanie dość dużej wiedzy na temat różnych integratorów i odpowiednia ilość czasu na ich skonfigurowanie lub odpowiednie dopracowanie.
Skomplikowana sieć powiązań
Na chwilę obecną, jeśli to ma działać oparte o platformę woocommerce flow zamówienia powinien wyglądać jak na obrazku poniżej.
Zamówienie pochodzi z 1 integracji z tą samą domeną, i powiązane jest z katalogiem y, następnie stan z tego katalogu jest wysyłane na 2 integrację z tą samą domeną, a następnie stan musi być zaczytany z 3 integracji, która powiązana jest z katalogiem 2
Innymi słowy, do obsługi jednej domeny na 2 katalogach potrzebnych będzie przynajmniej 3 integracji.
I faktycznie tak jest jeśli wziąć pod uwagę fakt, że do jednego katalogu są wysyłane stany ze sklepu, a z drugiego katalogu są przesyłane stany z Baselinker. Tylko jedna rzecz się nie trzyma kupy…, to że produkt z zamówienia jest tylko na jednym katalogu, na tym z którego stany są przesyłane na sklep. My nie mamy tych samych produktów na dwóch katalogach. U nas każdy katalog odpowiada hurtowni i ma swoje produkty. Dlatego nawet jeśli stworzę trzecią integrację i powiążę ją z drugim katalogiem, to tam nie znajdę tego samego produktu. Jego tam nie ma. Te produkt z zamówienia jest tylko w jednym katalogu.
Jeśli weźmiemy za wzór to rozwiązanie, które zostało naszkicowane, to nie ma potrzeby przesyłania stanu z Katalogu Y (Pitaya tech) na sklep X (integrację ecco smil). Bo sklep Y (Ecosmil Tech) ma synchronizację podrzędną, tzn. że powinien pobierać stany z Pitaya Tech.
Integracja Sklep X (Eco Smill) ma włączoną synchronizację nadrzędną i wysyła stany ze sklepu do katalogu Z, gdzie są zupełnie inne produkty.
Podkreślam, że w katalogach znajdują się zupełnie różne produkty. Nie duplikują się nam produkty między katalogami.
Warte podkreślenia jest to, że na tych dwóch katalogach są różne produkty, które nie powtarzają się w obrębie innych katalogów. Problemem jest tylko to, że mamy dwie integracje dla tej samej domeny, gdzie jedna integracja ma zaciągać stany z domeny, a druga integracja ma pobierać stany z Baselinker. Przy czym obydwie integracje mają włączone przekazywanie zamówień do Baselinker, więc zachodzi duplikacja zamówień.
Problem leży w tej integracji, którą zaznaczyłem na czerwono (EcoSmil Tech). Pomimo iż zamówienie spływa do Baselinker, np. zamówienie 45862272, nie obniża stanu magazynowego produktu ID 223294442, który pochodzi z katalogu Pitaya Tech. Problem polega też na tym, że integracja EcoSmil Tech jest podrzędna w stosunku do stanów magazynowych z katalogu Pitaya Tech, to nie mogę manipulować tymi stanami z poziomu Baselinker.
