Integracja sklepu z systemem ERP – od czego zacząć

Integracja sklepu z systemem ERP oszczędza godziny ręcznego przepisywania zamówień, aktualizowania stanów i wystawiania dokumentów. Jednocześnie to projekt, w którym najwięcej problemów wynika nie z techniki, tylko z niedokładnie opisanego procesu. Zanim ktokolwiek napisze linijkę kodu, warto odpowiedzieć na kilka pytań.

W tym poradniku przechodzimy przez przygotowanie integracji krok po kroku: od ustalenia, który system jest źródłem prawdy dla poszczególnych danych, przez sprawdzenie, jak ERP udostępnia informacje, opis procesu, częstotliwość synchronizacji i obsługę błędów, aż po testy, monitoring i utrzymanie. Opisujemy też szczególne sytuacje – ERP zainstalowany na komputerze w biurze, sprzedaż w wielu kanałach, ceny indywidualne dla klientów hurtowych – oraz to, kiedy wystarczy gotowy konektor, a kiedy potrzebna jest integracja na zamówienie.

W skrócie:

• dla każdego rodzaju danych trzeba ustalić jedno źródło prawdy – inaczej systemy będą się wzajemnie nadpisywać,
• możliwości integracji zależą od tego, jak ERP udostępnia dane: przez API, pliki, bazę danych czy program pośredniczący,
• opis procesu – co dzieje się z zamówieniem krok po kroku – jest ważniejszy niż lista pól,
• częstotliwość synchronizacji dobiera się do rodzaju danych: stany często, opisy produktów rzadziej,
• integracja potrzebuje kolejki, ponawiania, dziennika zdarzeń i powiadomień o błędach.

Po co integrować sklep z ERP

W sklepie bez integracji te same informacje istnieją w dwóch miejscach i ktoś musi je ręcznie uzgadniać. Zamówienia przepisuje się do programu, stany magazynowe poprawia w sklepie, ceny zmienia w dwóch systemach, a numery przesyłek kopiuje do maili. Przy kilku zamówieniach dziennie to uciążliwe, przy kilkudziesięciu – źródło błędów i opóźnień.

Integracja przenosi tę pracę na automat. Zamówienie ze sklepu trafia do ERP, gdzie powstaje dokument sprzedaży, stany magazynowe aktualizują się w sklepie po każdej zmianie, a status realizacji i numer przesyłki wracają do klienta. Zespół zajmuje się obsługą wyjątków, a nie przepisywaniem danych.

Korzyści nie kończą się na oszczędności czasu. Aktualne stany zmniejszają ryzyko sprzedaży towaru, którego nie ma. Jedno źródło cen eliminuje rozbieżności między sklepem a fakturą. Spójne dane o klientach i zamówieniach ułatwiają raportowanie i planowanie zakupów. Zakres możliwych połączeń dla popularnych systemów pokazujemy w sekcji integracje z systemami ERP.

Ustal źródło prawdy dla każdego typu danych

Dla produktów, cen, stanów, klientów i zamówień musi być jasne, który system jest nadrzędny. Najczęściej produkty, ceny i stany pochodzą z ERP, a zamówienia – ze sklepu. Problem zaczyna się, gdy oba systemy mogą zmieniać te same dane: wtedy integracja nadpisuje zmiany, a zespół traci zaufanie do danych.

Dane	Typowe źródło prawdy	Kierunek synchronizacji
Kartoteka produktów i kody	ERP	ERP → sklep
Opisy marketingowe i zdjęcia	sklep lub system PIM	zwykle bez synchronizacji do ERP
Ceny i promocje	ERP	ERP → sklep
Stany magazynowe	ERP lub system magazynowy	ERP → sklep
Zamówienia	sklep	sklep → ERP
Statusy i numery przesyłek	ERP lub system wysyłek	ERP → sklep
Klienci	zależnie od procesu	najczęściej sklep → ERP

Szczególnej uwagi wymagają opisy produktów. ERP zwykle przechowuje krótkie nazwy i dane handlowe, a sklep potrzebuje rozbudowanych opisów, zdjęć i atrybutów do filtrów. Często najlepszym rozwiązaniem jest podział: dane handlowe z ERP, treści marketingowe w sklepie. Wtedy integracja nie nadpisuje opisów przygotowanych z myślą o klientach i wyszukiwarce.

Ustalenia warto zapisać w jednym dokumencie i pokazać wszystkim osobom, które pracują na danych. Jeśli dział handlowy zmienia ceny w sklepie, a integracja co godzinę przywraca ceny z ERP, problem nie leży w technice, tylko w braku wspólnej zasady.

Sprawdź, jak ERP udostępnia dane

Część systemów ma nowoczesne API dostępne przez internet, inne udostępniają dane przez wymianę plików, bezpośredni dostęp do bazy albo program pośredniczący instalowany na komputerze w biurze. Zapytaj dostawcę ERP o dostępne interfejsy i licencje – czasem moduł integracyjny jest płatnym dodatkiem.

Interfejs API

Najwygodniejsza sytuacja: ERP udostępnia interfejs, przez który integracja pobiera i zapisuje dane w ustalonym formacie. Zapewnia to kontrolę uprawnień, walidację danych i stabilność przy aktualizacjach systemu. Po stronie sklepu podobnie – WooCommerce udostępnia REST API, a Shopify Admin API.

Wymiana plików

Część systemów eksportuje i importuje dane w plikach, na przykład CSV lub XML. To rozwiązanie prostsze, ale wolniejsze i bardziej podatne na błędy formatów. Sprawdza się przy danych zmieniających się rzadko, na przykład przy kartotece produktów aktualizowanej raz dziennie.

Bezpośredni dostęp do bazy

Czasem jedyną drogą jest odczyt danych bezpośrednio z bazy ERP. To rozwiązanie wymaga ostrożności: struktura bazy może zmienić się przy aktualizacji systemu, a zapis bezpośrednio do bazy omija reguły, które pilnuje sam program. Dlatego zapis najlepiej realizować przez oficjalne mechanizmy importu lub interfejsy dostawcy.

Program pośredniczący

Przy systemach instalowanych lokalnie integracja często działa przez program pośredniczący na komputerze lub serwerze w firmie. Program komunikuje się z ERP na miejscu i wymienia dane ze sklepem przez internet. O tym, jak zadbać o jego niezawodność, piszemy dalej.

Dokumentację i możliwości integracji opisują producenci poszczególnych systemów – na przykład Comarch ERP Optima czy InsERT Subiekt GT. Przy tych i innych systemach pomagamy dobrać sposób połączenia w ramach usług integracja z Comarch ERP Optima i integracja z Subiektem GT.

Opisz proces, nie tylko pola

Lista pól do synchronizacji to za mało. Opisz, co dzieje się z zamówieniem krok po kroku: kiedy trafia do ERP, kto je zatwierdza, kiedy powstaje dokument sprzedaży, jak wraca status i numer przesyłki. Uwzględnij wyjątki: płatność nieudana, zamówienie anulowane, zwrot częściowy, produkt bez stanu. To właśnie wyjątki generują najwięcej pracy.

Przykładowy przebieg zamówienia

1. Klient składa zamówienie i płaci online.
2. Po potwierdzeniu płatności zamówienie trafia do ERP jako dokument zamówienia.
3. Dział magazynu kompletuje towar, a ERP rezerwuje lub zdejmuje stan.
4. Powstaje dokument sprzedaży, a zamówienie zmienia status w sklepie.
5. Po nadaniu paczki numer przesyłki wraca do sklepu i trafia do klienta w wiadomości.

Wyjątki, które trzeba opisać

• płatność nieudana lub przerwana – czy zamówienie trafia do ERP, czy czeka,
• zamówienie anulowane przed i po wysłaniu do ERP,
• zwrot całości lub części zamówienia i korekta dokumentu,
• produkt, którego stan okazał się niezgodny z rzeczywistością,
• zmiana adresu dostawy lub danych do faktury po złożeniu zamówienia,
• zamówienia z rabatem, kodem promocyjnym lub darmową dostawą.

Opis procesu przygotowany przez osoby, które na co dzień obsługują zamówienia, to najcenniejszy dokument projektu. Programista może zbudować dokładnie to, co jest opisane – nie zgadnie, jak firma obsługuje zwroty częściowe.

Dopasowanie danych: kody, jednostki, podatki

Nawet przy dobrym API dane w obu systemach rzadko pasują do siebie wprost. Sklep może mieć warianty produktu – rozmiar, kolor – a ERP osobne kartoteki dla każdego wariantu. Ceny w sklepie są zwykle brutto, w ERP często netto. Jednostki, stawki podatku, metody płatności i dostawy mają w obu systemach inne nazwy i identyfikatory.

Dlatego częścią każdej integracji jest mapowanie: tabela, która mówi, jak dane z jednego systemu odpowiadają danym w drugim. Dotyczy to produktów i wariantów, stawek podatku, metod płatności, sposobów dostawy, statusów zamówień i grup klientów. Brak jednego mapowania potrafi zatrzymać synchronizację całego zamówienia.

Warto też uporządkować dane przed integracją. Duplikaty kartotek, produkty bez kodów, różne nazwy tego samego towaru – to wszystko trzeba wyjaśnić na początku, bo integracja nie naprawi bałaganu, tylko go powieli w drugim systemie.

Częstotliwość synchronizacji

Stany magazynowe w sklepie z dużą rotacją powinny aktualizować się często, a opisy produktów – raz dziennie lub na żądanie. Zbyt częsta synchronizacja wszystkiego obciąża oba systemy, zbyt rzadka – prowadzi do sprzedaży towaru, którego nie ma.

Dane	Typowa częstotliwość	Uwagi
Stany magazynowe	często, najlepiej po każdej zmianie	kluczowe przy małych stanach i sprzedaży wielokanałowej
Ceny	po zmianie lub kilka razy dziennie	uwaga na promocje i ceny dla grup klientów
Zamówienia	niezwłocznie po złożeniu lub opłaceniu	z kolejką i ponawianiem
Statusy i przesyłki	po zmianie w ERP	klient powinien dostać informację szybko
Kartoteka produktów	raz dziennie lub na żądanie	pełna synchronizacja poza godzinami szczytu

Najlepiej sprawdza się synchronizacja zdarzeniowa: zmiana w jednym systemie wywołuje aktualizację w drugim tylko dla zmienionych danych. Pełna synchronizacja wszystkich produktów raz dziennie jest dobrym uzupełnieniem – wyłapuje rozbieżności, które mogły powstać przy błędach.

Gdy ERP stoi w biurze

Jeśli ERP działa na komputerze lub serwerze w firmie, integracja zależy od tego, czy ten komputer jest włączony i ma internet. Warto przewidzieć kolejkę zamówień, która poczeka na połączenie, oraz powiadomienia, gdy synchronizacja przestanie działać.

• komputer z programem pośredniczącym powinien działać stale, z zasilaniem awaryjnym i automatycznym startem programu,
• zamówienia ze sklepu czekają w kolejce, gdy połączenie jest przerwane, i trafiają do ERP po jego przywróceniu,
• stany w sklepie są chronione przed sprzedażą „na zapas”, gdy synchronizacja nie działa dłużej,
• osoba odpowiedzialna dostaje powiadomienie, gdy program przestanie się komunikować.

Przy lokalnych systemach ważne jest też bezpieczeństwo. Połączenie ze sklepem powinno być szyfrowane, a program pośredniczący nie może otwierać firmowej sieci na świat. Dobre praktyki zabezpieczania interfejsów zbiera projekt OWASP API Security.

Testy, logi i monitoring

Przed startem przetestuj typowe i nietypowe scenariusze na kopii sklepu i testowej bazie ERP. Integracja powinna zapisywać dziennik operacji i informować o błędach – inaczej problem wychodzi na jaw dopiero, gdy klient pyta o zamówienie, które nigdy nie trafiło do magazynu.

Scenariusze testowe

1. zamówienie z jednym produktem i płatnością online,
2. zamówienie z wieloma produktami, wariantami i rabatem,
3. zamówienie za pobraniem lub z płatnością odroczoną,
4. anulowanie zamówienia przed i po przesłaniu do ERP,
5. zwrot częściowy i korekta,
6. zmiana stanu i ceny w ERP oraz jej odzwierciedlenie w sklepie,
7. przerwa w połączeniu i ponowienie synchronizacji.

Dziennik i powiadomienia

Każda operacja integracji powinna zostawiać ślad: co, kiedy, z jakim wynikiem. Przy błędzie dziennik pokazuje, które zamówienie nie przeszło i dlaczego. Powiadomienia trafiają do osoby, która może zareagować – mailem lub w komunikatorze. Integracja, która „cicho” przestaje działać, jest groźniejsza niż jej brak.

Bezpieczeństwo i dostępy

Integracja ma dostęp do danych klientów, zamówień i często cen zakupu. Dlatego klucze dostępu powinny mieć minimalne potrzebne uprawnienia, być przechowywane bezpiecznie i regularnie zmieniane. Nie wysyła się ich mailem ani nie zapisuje w ogólnodostępnych dokumentach.

Warto też ustalić, kto ma dostęp do panelu integracji i dziennika operacji, oraz jak długo przechowywane są logi z danymi osobowymi. Dziennik jest potrzebny do diagnozy problemów, ale nie powinien przechowywać danych klientów dłużej, niż to konieczne.

Gotowy konektor a integracja na zamówienie

Dla popularnych systemów istnieją gotowe konektory, które pokrywają typowe scenariusze. Sprawdzają się, gdy proces jest standardowy. Gdy pojawiają się nietypowe zasady – ceny indywidualne, wiele magazynów, zestawy produktów, sprzedaż w kilku kanałach – lepiej sprawdza się integracja przez API zaprojektowana pod Twój proces.

Kryterium	Gotowy konektor	Integracja na zamówienie
Czas uruchomienia	krótki	dłuższy, zależny od zakresu
Koszt startowy	niższy, często abonament	wyższy, jednorazowy projekt
Nietypowe procesy	ograniczone możliwości	dopasowanie do procesu
Rozwój	zależny od dostawcy konektora	w Twoich rękach
Obsługa błędów	taka, jaką przewidział dostawca	projektowana pod firmę

Często rozsądne jest podejście mieszane: gotowy konektor dla standardowych danych i niewielkie rozszerzenia dla wyjątków. Przy prostszych przepływach, na przykład przekazaniu zamówienia do arkusza lub powiadomienia do zespołu, wystarczą automatyzacje Make i Zapier.

Sprzedaż w wielu kanałach

Sklep internetowy rzadko jest jedynym miejscem sprzedaży. Ten sam towar trafia na platformy sprzedażowe, do sklepu stacjonarnego i do klientów hurtowych zamawiających telefonicznie. Każdy z tych kanałów zdejmuje stan z tego samego magazynu, więc integracja musi patrzeć na całość, a nie tylko na sklep.

Najczęściej sprawdza się układ, w którym ERP jest centralnym miejscem stanów i zamówień, a kanały sprzedaży są do niego podłączone. Zamówienie z każdego kanału trafia do ERP, a zmieniony stan rozchodzi się do wszystkich pozostałych. Gdy kanały wymieniają dane między sobą z pominięciem ERP, bardzo łatwo o sytuację, w której ostatnia sztuka zostaje sprzedana dwa razy.

• ustal, który kanał ma pierwszeństwo przy małych stanach – czasem warto zostawić bufor bezpieczeństwa i pokazywać w sklepie mniej sztuk, niż jest na półce,
• oznaczaj w ERP, z jakiego kanału przyszło zamówienie – ułatwia to raportowanie i obsługę zwrotów,
• sprawdź, czy ceny mogą się różnić między kanałami i gdzie te różnice są przechowywane,
• zaplanuj kolejność: najpierw sklep i ERP, potem kolejne kanały – każdy nowy kanał to nowe mapowania i nowe wyjątki.

Klienci hurtowi i ceny indywidualne

W sprzedaży do firm ceny rzadko są jednakowe dla wszystkich. Klient hurtowy ma swój cennik, rabat procentowy na grupę towarów, odroczony termin płatności i limit kupiecki. Te informacje żyją w ERP i to stamtąd sklep powinien je brać – ręczne przepisywanie cenników do sklepu kończy się rozbieżnościami przy pierwszej zmianie.

Integracja dla sprzedaży hurtowej zwykle obejmuje konta klientów powiązane z kontrahentami w ERP, ceny liczone według grupy cenowej lub indywidualnego cennika, dostępne formy płatności zależne od klienta oraz historię dokumentów, którą klient może przejrzeć po zalogowaniu. Warto z góry ustalić, czy sklep ma tylko wyświetlać ceny obliczone przez ERP, czy liczyć je sam na podstawie przesłanych reguł. Pierwsze podejście jest prostsze w utrzymaniu, drugie szybsze przy dużej liczbie produktów.

Osobną kwestią jest limit kupiecki i należności. Jeśli klient przekroczył limit albo ma zaległe faktury, zamówienie może trafić do ERP z oznaczeniem do akceptacji przez handlowca, zamiast od razu do realizacji. To przykład zasady, której nie ma w żadnym gotowym konektorze, a która dla firmy jest ważniejsza niż wygląd koszyka.

Wiele magazynów i dostawy częściowe

Gdy towar leży w kilku magazynach albo część asortymentu wysyła dostawca, stan w sklepie przestaje być jedną liczbą. Trzeba zdecydować, czy klient widzi sumę stanów, stan z magazynu, z którego wysyłasz najszybciej, czy informację o czasie dostawy zależnym od miejsca, w którym leży towar.

• Suma stanów – najprostsza dla klienta, ale wymaga, żeby zamówienie dało się zrealizować z kilku miejsc.
• Stan głównego magazynu – bezpieczna, gdy pozostałe magazyny służą do uzupełnień, a nie do wysyłki.
• Stan z czasem dostawy – produkt dostępny od ręki albo na zamówienie, z różnym terminem wysyłki.

Przy dostawach częściowych zamówienie w ERP może zostać podzielone na kilka wysyłek. Klient powinien wtedy dostać informację o każdej paczce osobno, a sklep – poprawnie pokazać status całego zamówienia. To jeden z tych przypadków, które warto przetestować na prawdziwych przykładach, zanim pojawi się pierwsza reklamacja.

Dokumenty sprzedaży i e-faktury

Integracja przenosi zamówienie do ERP, ale dokument sprzedaży – paragon lub faktura – powstaje już po stronie systemu księgowo-magazynowego. Trzeba ustalić, kiedy dokładnie: od razu po opłaceniu, po skompletowaniu towaru czy po wysyłce. Od tej decyzji zależy, jak obsługuje się anulowania i zwroty.

Coraz większe znaczenie ma obieg faktur elektronicznych. W Polsce działa Krajowy System e-Faktur, z którym współpracują systemy ERP. Dla sklepu oznacza to przede wszystkim konieczność przekazania do ERP kompletnych i poprawnych danych nabywcy – nazwy firmy, numeru NIP i adresu – bo to na ich podstawie powstaje faktura. Formularz zamówienia powinien więc rozróżniać zakup prywatny i firmowy, a integracja przenosić te dane bez skracania i zmian.

Klient chce też mieć dostęp do dokumentów. Najwygodniej, gdy faktura wygenerowana w ERP wraca do sklepu i jest dostępna na koncie klienta albo dołączona do wiadomości. Wymaga to kolejnego kierunku synchronizacji, który dobrze zaplanować od początku, a nie dobudowywać po starcie.

Plan wdrożenia krok po kroku

Integracja to projekt z kilkoma wyraźnymi etapami. Ich kolejność ma znaczenie – pomijanie analizy na rzecz szybkiego programowania zwykle wydłuża całość, bo błędy wychodzą dopiero na produkcji.

1. Analiza – spis systemów, danych i sposobów ich udostępniania, rozmowa z osobami obsługującymi zamówienia.
2. Opis procesu – przebieg zamówienia, wyjątki, źródło prawdy dla każdego rodzaju danych.
3. Porządki w danych – kody produktów, duplikaty, warianty, stawki podatku, metody płatności i dostawy.
4. Mapowanie – tabela odpowiedników między systemami, zatwierdzona przez osoby z firmy.
5. Środowisko testowe – kopia sklepu i testowa baza ERP, na których nic nie trafia do prawdziwych klientów.
6. Budowa i testy – najpierw jeden kierunek, na przykład stany do sklepu, potem kolejne.
7. Uruchomienie – w spokojnym okresie, z planem powrotu do ręcznej obsługi, gdyby coś poszło nie tak.
8. Obserwacja – pierwsze tygodnie z codziennym przeglądem dziennika i szybką reakcją na wyjątki.

Warto uruchamiać integrację etapami. Synchronizacja stanów i cen do sklepu jest stosunkowo bezpieczna i od razu daje korzyści. Przesyłanie zamówień do ERP i dokumentów z powrotem można włączyć, gdy pierwszy etap działa stabilnie.

Na każdym etapie przydaje się jedna osoba po stronie firmy, która zna proces i może szybko odpowiadać na pytania: jak traktować zamówienie z odbiorem osobistym, co zrobić z produktem wycofanym ze sprzedaży, kto zatwierdza zmiany w mapowaniu. Bez takiej osoby projekt zwalnia, bo każda decyzja czeka na zebranie, a programista zaczyna zgadywać. Dobrze sprawdza się też krótkie, regularne podsumowanie postępów – co już działa, co jest w testach i jakie decyzje są potrzebne w najbliższym czasie.

Najczęstsze błędy przy integracjach

Większość problemów z integracjami powtarza się niezależnie od branży i systemu. Znając je, łatwiej ich uniknąć już na etapie planowania.

• Brak jednego źródła prawdy – ceny lub opisy zmieniane w obu systemach, które się wzajemnie nadpisują.
• Pominięte wyjątki – integracja działa dla typowego zamówienia, ale zatrzymuje się na zwrocie częściowym albo zmianie adresu.
• Synchronizacja bez kolejki – chwilowa przerwa w połączeniu oznacza utracone zamówienie, a nie opóźnione.
• Ciche błędy – nikt nie dostaje powiadomień, a problem wychodzi na jaw po skardze klienta.
• Brak środowiska testowego – testy na prawdziwym sklepie i prawdziwej bazie, z dokumentami wystawionymi przez pomyłkę.
• Nieuporządkowane dane – duplikaty i brakujące kody, które integracja powiela w drugim systemie.
• Brak właściciela – nikt w firmie nie odpowiada za integrację, więc nikt nie reaguje, gdy coś się zmieni.

Od czego zależy koszt integracji

Koszt integracji wynika z kilku czynników, które da się ocenić już na etapie analizy. Najważniejszy jest sposób, w jaki ERP udostępnia dane: dobrze udokumentowane API skraca pracę, a wymiana plików czy program pośredniczący na komputerze w biurze ją wydłużają. Drugi czynnik to liczba kierunków synchronizacji – same stany i ceny to inny projekt niż pełny obieg zamówień, dokumentów i statusów.

Duże znaczenie mają też wyjątki i reguły biznesowe: ceny indywidualne, wiele magazynów, zestawy produktów, sprzedaż w kilku kanałach. Każda taka reguła to dodatkowa logika, testy i miejsce na błąd. Do tego dochodzą porządki w danych, licencje na moduły integracyjne po stronie ERP oraz późniejsze utrzymanie. Rzetelna wycena powinna rozpisywać te elementy osobno, żeby było widać, za co płacisz i z czego ewentualnie można zrezygnować na pierwszym etapie.

Integracja a wydajność sklepu

Źle zaprojektowana synchronizacja potrafi spowolnić sklep. Pełny import tysięcy produktów w godzinach największego ruchu, aktualizacja każdego produktu osobnym zapytaniem albo przebudowa pamięci podręcznej po każdej zmianie stanu – to typowe przyczyny wolniejszego działania sklepu po uruchomieniu integracji.

Dlatego ciężkie operacje warto planować poza godzinami szczytu, aktualizować tylko zmienione dane i przetwarzać je partiami w tle, a nie w trakcie wizyty klienta. Dziennik integracji z danymi zamówień trzeba też co jakiś czas porządkować – zarówno ze względu na wydajność bazy, jak i zasadę minimalizacji danych osobowych opisaną w RODO.

Utrzymanie po uruchomieniu

Integracja nie jest projektem, który kończy się w dniu startu. Aktualizacje sklepu, nowa wersja ERP, zmiana metod płatności czy nowy przewoźnik – każda z tych zmian może wymagać dostosowania połączenia. Dlatego warto ustalić, kto i w jakim czasie reaguje na problemy oraz jak testuje się zmiany przed wprowadzeniem ich na produkcję.

Dobrą praktyką jest regularny przegląd dziennika integracji, nawet gdy nie ma alarmów. Powtarzające się drobne błędy, na przykład produkty bez mapowania albo zamówienia odrzucane z powodu niepełnych danych, pokazują, gdzie proces wymaga poprawy. Przy większych zmianach w sklepie lub ERP integrację warto przetestować ponownie według tych samych scenariuszy, które sprawdzały ją przed startem.

Utrzymanie integracji łączymy zwykle z obsługą techniczną sklepu, dzięki czemu aktualizacje sklepu i zmiany w połączeniu z ERP planuje ta sama osoba.

Najczęstsze pytania

Ile trwa wdrożenie integracji sklepu z ERP?

To zależy od sposobu udostępniania danych przez ERP i złożoności procesu. Gotowy konektor przy standardowym procesie można uruchomić stosunkowo szybko. Integracja na zamówienie z wieloma wyjątkami wymaga analizy, programowania i testów, więc trwa dłużej.

Czy integracja zadziała, gdy komputer z ERP jest wyłączony?

Zamówienia mogą czekać w kolejce i trafić do ERP po włączeniu komputera, ale stany i ceny w sklepie nie będą się wtedy aktualizować. Dlatego przy lokalnych systemach warto zapewnić stałą pracę komputera z ERP albo rozważyć wersję systemu działającą w chmurze.

Co jest lepsze: synchronizacja w czasie rzeczywistym czy co kilka minut?

To zależy od rodzaju danych i rotacji towaru. Zamówienia i stany przy małych ilościach warto przesyłać niezwłocznie, a dane zmieniające się rzadko – okresowo. Synchronizacja oparta na zdarzeniach jest zwykle najwydajniejsza i najmniej obciąża oba systemy.

Czy integracja przeniesie także opisy i zdjęcia produktów?

Może, ale nie zawsze warto. ERP zwykle przechowuje dane handlowe, a sklep potrzebuje rozbudowanych opisów i zdjęć. Często lepiej, gdy treści marketingowe powstają w sklepie, a z ERP płyną kody, ceny i stany.

Co się dzieje, gdy integracja napotka błąd?

Dobrze zaprojektowana integracja zapisuje błąd w dzienniku, ponawia operację i powiadamia osobę odpowiedzialną, jeśli problem się powtarza. Dzięki temu żadne zamówienie nie ginie bez śladu, a zespół wie, co wymaga ręcznej interwencji.

Czy integracja obsłuży ceny indywidualne dla klientów hurtowych?

Tak, jeśli ERP przechowuje cenniki i grupy cenowe, a sklep ma konta klientów powiązane z kontrahentami. Trzeba wtedy ustalić, czy sklep wyświetla ceny obliczone przez ERP, czy liczy je sam na podstawie przesłanych reguł, oraz co dzieje się z zamówieniami klientów, którzy przekroczyli limit kupiecki.

Czy mogę zintegrować sklep z kilkoma systemami naraz?

Tak, na przykład z ERP, systemem wysyłek i platformą sprzedażową. Kluczowe jest wtedy jasne źródło prawdy dla każdego rodzaju danych, żeby systemy nie nadpisywały się wzajemnie. Taki układ warto zaplanować całościowo, a nie dodawać kolejne połączenia bez wspólnych zasad.

Źródła i dalsza lektura

• WooCommerce REST API – dokumentacja interfejsu sklepu.
• Shopify Admin API – dokumentacja interfejsu Shopify.
• OWASP API Security – najczęstsze zagrożenia interfejsów API.
• Comarch ERP Optima – informacje producenta o systemie.
• InsERT Subiekt GT – opis programu u producenta.
• Krajowy System e-Faktur – informacje o e-fakturach w Polsce.
• RODO – zasady przetwarzania danych osobowych, także w dziennikach integracji.

Integracja z nami

Zaczynamy od krótkiej analizy: sprawdzamy, jak ERP udostępnia dane, opisujemy proces z osobami, które obsługują zamówienia, i proponujemy rozwiązanie – gotowy konektor, integrację na zamówienie albo połączenie obu podejść. Wdrażamy połączenia z popularnymi systemami, w tym Subiektem, Optimą, enova365 i Symfonią, przy tworzeniu sklepów internetowych i w już działających sklepach.

Po uruchomieniu integracja wymaga opieki: aktualizacji, monitoringu i reakcji na zmiany w obu systemach. Łączymy to z opieką nad sklepem, a gdy dane płyną już bez przeszkód, możemy pomóc w rozwoju sprzedaży – o tym piszemy na stronie możliwości po starcie strony.