Zamówienia ze sklepu trafiają do ERP jako dokumenty
Zero przepisywania: opłacone zamówienie ze sklepu jest w ERP jako dokument w minutę od zakupu, z kontrahentem i pozycjami dopasowanymi do kartotek.
- Oszczędność
- 10–20 h/tydz.
- Podstawa: sklep z 40–80 zamówieniami dziennie w dni robocze i ok. 3 minutami na ręczne przepisanie jednego zamówienia do ERP
- Czas wdrożenia
- 2–4 tygodnie
- Pierwszy etap, do uruchomienia u Was
- Złożoność
- 3/5 średnia
- Dowód
- Wdrożenie u klienta
- Działa w sklepie Acana Polska (PrestaShop), zsynchronizowanym z systemem Comarch ERP: zamówienia obsługuje się w ERP bez przepisywania ze sklepu. Oszczędność to szacunek z podaną podstawą, nie pomiar u klienta.
Kroki automatu
Co dzieje się po kolei i gdzie decyduje człowiek.
Wyzwalacz
Nowe opłacone zamówienie w sklepie (albo zmiana statusu na „do realizacji”)
- 1
Sklep wysyła powiadomienie o opłaconym zamówieniu: dane klienta, pozycje, płatność, sposób dostawy
- 2
Integracja dopasowuje kontrahenta po NIP albo adresie e-mail, a gdy go nie ma, zakłada nowego
- 3
Pozycje zamówienia są dopasowywane do kartotek ERP po kodzie SKU lub EAN
- 4
W ERP powstaje dokument zamówienia od klienta; jego numer i status wracają do sklepu
- 5
Zamówienia, których nie da się dopasować w całości, trafiają do kolejki wyjątków
Punkt kontroli człowieka
Zamówienia bez dopasowanego kontrahenta lub pozycji, z ręczną korektą ceny albo z nietypową dostawą czekają na akceptację osoby z obsługi, zamiast trafić do ERP z błędem.
W tym wpisie
W sklepie, który obsługuje kilkadziesiąt zamówień dziennie, ktoś codziennie otwiera panel sklepu i przepisuje je do programu magazynowego: klient, adres, pozycje, forma płatności. Trzy minuty na zamówienie to przy 60 zamówieniach trzy godziny dziennie, a każda literówka w kodzie produktu oznacza wysyłkę nie tego, co zamówiono. Ta automatyzacja zamienia przepisywanie na dopasowanie: zamówienie pojawia się w ERP samo, a człowiek zajmuje się tylko tym, czego automat nie rozpoznał.
Jak to działa krok po kroku
Sklep (PrestaShop albo WooCommerce) wysyła powiadomienie, gdy zamówienie zostanie opłacone albo zmieni status na „do realizacji”. W PrestaShop korzystamy z wbudowanego Webservice API i zdarzeń modułu, w WooCommerce z REST API i webhooków. Integracja odbiera komplet danych: klienta, adresy, pozycje, kwoty, rabaty, formę płatności i dostawy.
Potem dopasowuje kontrahenta. Firmy rozpoznaje po NIP, osoby prywatne po adresie e-mail. Jeśli kontrahenta nie ma w ERP, zakłada go z danymi z zamówienia. Pozycje łączy z kartotekami po kodzie SKU albo EAN, dlatego ten sam kod musi być w sklepie i w ERP; to najczęstszy porządek do zrobienia przed startem.
Na końcu w ERP powstaje dokument zamówienia od klienta (w Subiekcie ZK, w Comarch ERP Optima rezerwacja odbiorcy). Jego numer wraca do sklepu i jest widoczny przy zamówieniu, więc obsługa nie szuka, czy „to już jest w systemie”. Zmiana statusu w ERP, na przykład po skompletowaniu, może z powrotem zmieniać status w sklepie.
Zamówienie, którego nie da się dopasować w całości (nieznany kod produktu, brak NIP przy zamówieniu na firmę, ręczny rabat, dostawa za granicę), nie trafia do ERP z lukami. Ląduje w kolejce wyjątków z opisem, co się nie zgadza, i czeka na decyzję osoby z obsługi. To jest punkt kontroli człowieka: automat robi rutynę, człowiek rozstrzyga wyjątki.
Co jest potrzebne
- Dostęp do API sklepu: klucz Webservice w PrestaShop albo klucze REST API w WooCommerce. Oba są wbudowane, bez dodatkowych licencji.
- Interfejs programistyczny ERP: Subiekt GT i Subiekt nexo udostępniają go przez dodatkowo płatny dodatek Sfera; Comarch ERP Optima przez osobno licencjonowany moduł API. Bez nich zostaje wymiana plików, która działa, ale nie w czasie rzeczywistym.
- Wspólne kody produktów (SKU lub EAN) w sklepie i w ERP oraz ustalone, który system jest źródłem prawdy dla kartotek.
- Reguły wyjątków spisane z obsługą: co ma się dziać z zamówieniem bez NIP, z rabatem ręcznym, z pozycją spoza katalogu.
Kiedy się nie opłaca
Przy kilku zamówieniach dziennie ręczne przepisywanie zajmuje kwadrans i integracja zwróci się bardzo powoli; wystarczy eksport CSV ze sklepu i import do ERP raz dziennie. Nie ma też sensu budować jej tuż przed migracją sklepu na inną platformę albo zmianą ERP, bo trzeba by ją pisać dwa razy. Jeśli zamówienia idą już przez BaseLinker i to narzędzie pokrywa Wasz proces, dokładanie własnej integracji rzadko coś zmienia.
Warianty
- Allegro i inne marketplace’y: zamówienia z Allegro trafiają do ERP tą samą drogą, bezpośrednio przez API Allegro albo przez BaseLinker, jeśli już go używacie.
- Kilka magazynów: dokument w ERP powstaje na magazynie wybranym według sposobu dostawy albo lokalizacji klienta.
- B2B z cenami indywidualnymi: ceny z cennika kontrahenta w ERP nadpisują ceny sklepowe, a zamówienie z limitem kupieckim czeka na akceptację handlowca.
- Faktura w ERP, nie w sklepie: gdy faktury powstają w ERP, integracja przenosi numer faktury i numer KSeF z powrotem do sklepu (opisujemy to w osobnym wpisie o fakturach sprzedaży do KSeF).
Ile to kosztuje
Wycenę podajemy po analizie przepływów: liczy się liczba systemów, to, czy ERP ma interfejs programistyczny, oraz ile reguł wyjątków trzeba obsłużyć. Pierwszy etap, czyli zamówienia w jedną stronę z kolejką wyjątków, zamyka się zwykle w 2–4 tygodniach i ma stałą cenę ustaloną przed startem. Koszty bieżące to licencja dodatku API po stronie ERP (Sfera, moduł API Optimy), hosting integracji i opcjonalnie opieka SLA z monitoringiem kolejki wyjątków.
Najczęstsze pytania
Czy to zadziała z moim programem magazynowym?
Najczęściej tak. Pracujemy z Comarch ERP Optima i XL, Subiektem GT i nexo, Symfonią, enova365, wFirmą i Fakturownią. Jeśli program ma API, bazę danych albo wymianę plików, da się go podłączyć; różni się tylko to, czy synchronizacja idzie w czasie rzeczywistym, czy co kilka minut.
Co z zamówieniami, które już są w sklepie?
Integracja zaczyna od ustalonej daty albo numeru zamówienia, więc nie tworzy duplikatów historycznych dokumentów. Starsze zamówienia można doładować jednorazowo, jeśli są potrzebne w ERP.
Co się dzieje, gdy ERP jest wyłączony, na przykład w nocy?
Zamówienia czekają w kolejce integracji i trafiają do ERP, gdy ten znów jest dostępny. Nic nie ginie, a w dzienniku widać, które zamówienia czekają i dlaczego.
Czy sklep musi wiedzieć o stanach magazynowych z ERP?
Nie musi, ale zwykle to drugi krok: po zamówieniach w jedną stronę dokładamy stany i ceny z ERP do sklepu, żeby sklep nie sprzedawał tego, czego nie ma na magazynie.
