Sklep spięty z ERP – na czym najczęściej się to psuje
Integracja sklepu z systemem magazynowo-księgowym brzmi jak jedna funkcja. W praktyce to kilka niezależnych przepływów danych, z których każdy ma własne pole minowe. Poniżej to, co widzimy najczęściej — bez teorii, na przykładach.
1. Kto rządzi stanem magazynowym
Najczęstsza przyczyna rozjazdów. Sklep pokazuje, że jest 12 sztuk. ERP twierdzi, że są 4. Obie liczby są aktualne — pochodzą z ostatniej synchronizacji. Problem w tym, że w międzyczasie sprzedaż poszła w obu kanałach, a synchronizacja stanów nie działa co sekundę.
Zasada jest jedna: **jeden system rządzi stanem, reszta go tylko wyświetla**. W 90% przypadków tym systemem powinien być ERP — bo to on wie, co fizycznie wjechało na magazyn i co z niego wyszło. Sklep pobiera stan i nie próbuje go „poprawiać”.
2. Ceny — źródło prawdy i wyjątki per kanał
Ceny są prostsze niż stany, dopóki nie pojawi się drugi kanał. Sprzedajesz w sklepie po X, na Allegro po X+10% (prowizja), na Amazonie po X+15%. Trzy różne ceny na ten sam produkt, ustawiane w trzech miejscach.
W praktyce: cena bazowa siedzi w ERP, integrator (BaseLinker albo dedykowane rozwiązanie) trzyma reguły „per kanał” i przelicza. Nie odwrotnie. Ustawianie cen ręcznie w każdym kanale to praca, którą i tak wcześniej czy później trzeba oddać systemowi.
3. Limity API — techniczne, ale bolesne
Każde API ma limit zapytań na minutę. Subiekt GT ma swój, BaseLinker swój, Allegro swój. Przy 100 produktach nie zobaczysz problemu. Przy 5000 SKU z częstymi zmianami cen i stanów — synchronizacja zaczyna się opóźniać dokładnie wtedy, kiedy nie może: w Black Friday, przy promocji, przy wgrywaniu nowej kolekcji.
Dobra integracja to nie ta, która „umie się połączyć”. To ta, która **umie priorytetyzować** — najpierw stany dla produktów, które się dobrze sprzedają, potem reszta. Kolejki, retry, obsługa błędów. To jest cała różnica między działającą integracją a taką, która „czasem działa”.
4. Zwroty — największe pole minowe
Sprzedaż jest łatwa do zautomatyzowania. Zwrot to trzy osobne procesy jednocześnie:
Większość „gotowych” integracji obsługuje sprzedaż. Zwroty — połowicznie albo wcale. Zapytaj wprost przed wdrożeniem.
5. Produkty, które istnieją w sklepie, ale nie w ERP (i odwrotnie)
Klasyk. W sklepie leży 300 produktów historycznych, których w ERP nie ma. W ERP siedzi 500 pozycji, których w sklepie nigdy nie było (bo hurt, bo B2B, bo przestały być sprzedawane). Integracja próbuje to zsynchronizować i dostajesz albo mnóstwo błędów, albo — gorzej — sklep wypełnia się produktami, których nie chcesz pokazywać.
Sensowne rozwiązanie: **integracja pracuje na jasno oznaczonej podzbiorze**. W ERP flaga „sprzedaje się online”, w sklepie kategoria „widoczne w kanale X”. Bez tego integracja synchronizuje wszystko z wszystkim i to nigdy nie kończy się dobrze.
Co z tego wynika przed wdrożeniem
Cztery pytania, które warto sobie zadać zanim ktokolwiek zacznie pisać kod:
Porozmawiajmy o Waszym przypadku
Spinamy sklepy z ERP (Subiekt, enova365, Navireo i inne), z BaseLinkerem i z marketplace’ami. Jeśli macie coś, co „w teorii działa, ale co miesiąc trzeba coś ręcznie poprawić” — zwykle da się to naprawić bez przebudowy całości.
