Fraza „DigiKrom sklep internetowy” prowadzi do dwóch różnych pytań: albo szukasz platformy, na której poprowadzisz sprzedaż, albo masz już sklep na PrestaShop lub WooCommerce i chcesz połączyć go z systemem zewnętrznym — ERP, magazynem, fakturowaniem czy WMS. Ten tekst dotyczy drugiej sytuacji i strony organizacyjnej: co ustalić, zanim ktokolwiek napisze linijkę kodu.
Zakres funkcji i nazewnictwo modułów po stronie dostawcy zmieniają się między wersjami, dlatego każdą obietnicę potwierdzaj w dokumentacji dostawcy i na piśmie w ofercie. Poniżej znajdziesz listę przepływów danych do odhaczenia, pytania do wykonawcy oraz sposób wyceny oparty na liczbie godzin. Jeśli równolegle łączysz sklep z CRM, zobacz też Jak skutecznie zintegrować sklep internetowy z CRM?
Pod frazą „DigiKrom sklep internetowy” kryją się dwie różne potrzeby i warto je rozdzielić, zanim wydasz pierwsze pieniądze. Pierwsza: szukasz platformy, na której poprowadzisz sprzedaż — porównujesz licencje, możliwości, limity. Druga: masz już sklep na PrestaShop albo WooCommerce i chcesz połączyć go z systemem zewnętrznym — ERP, magazynem, fakturowaniem albo WMS-em. Ten tekst dotyczy wyłącznie drugiej sytuacji.
Rozdzielenie tych intencji oszczędza tygodnie. Przy wyborze platformy pytanie brzmi „co potrafi system”. Przy integracji — „co, w którą stronę i jak często musi przepłynąć między dwoma systemami”. To dwa różne projekty: inny budżet, inne ryzyko, inna osoba odpowiedzialna.
Zastrzeżenie na start: zakres funkcji i nazewnictwo modułów po stronie dostawcy zmieniają się między wersjami. Ta sama funkcja może nazywać się inaczej w kolejnych wydaniach, a to, co pokazano na prezentacji, nie zawsze wchodzi w Twój zakres licencji. Każdą obietnicę potwierdź w dokumentacji dostawcy i na piśmie w ofercie: zakres, wersja, sposób utrzymania po starcie.
Jak wygląda uporządkowane wdrożenie sklepu WooCommerce krok po kroku — od checklisty po odbiór — opisujemy osobno. Tutaj skupiamy się na samych przepływach danych.
| Twoja sytuacja | Czego naprawdę szukasz | Gdzie iść dalej |
|---|---|---|
| Mam sklep na PrestaShop lub WooCommerce i chcę go połączyć z ERP, magazynem, fakturowaniem albo WMS | Integracji, harmonogramu przepływów i wyceny | Sekcja „Co realnie da się zsynchronizować…” oraz „Trzy metody integracji…” |
| Dopiero wybieram platformę sprzedaży | Porównania platform, kosztów licencji i limitów | To nie jest ten artykuł — zacznij od dokumentacji dostawcy i własnej listy wymagań |
Poniższa lista to zakres do wyceny. Odhacz te przepływy, które Cię dotyczą; reszta to zbędny koszt utrzymania.
Struktura produktu, zamówienia i klienta po stronie sklepu jest opisana w dokumentacji WooCommerce — sprawdź tam, czy system ma skąd wziąć dany atrybut, zanim obiecasz go klientowi. Jeśli jednym z łączonych systemów jest CRM, kolejność prac opiszemy w tekście o tym, jak zintegrować sklep internetowy z CRM.
Policz to na liczbach. 300 zamówień miesięcznie, ręczne przepisanie jednego zamówienia to 2–4 minuty. 300 × 2 min = 600 min, czyli 10 godzin; 300 × 4 min = 20 godzin. W skali roku 120–240 godzin. Przy koszcie pracy 40 zł/h daje to 4 800–9 600 zł rocznie — i to bez kosztu pomyłek: zdublowanej wysyłki, błędnej faktury, klienta, który kupił towar, którego nie masz.
| Przepływ | Kierunek | Typowa częstotliwość | Co najczęściej się psuje |
|---|---|---|---|
| Produkt | system → sklep | przy zmianie, zbiorczo raz na dobę | ceny brutto/netto, zdjęcia, przypisanie kategorii |
| Stan magazynowy | system → sklep, zwrotnie rezerwacje | co 5–15 minut | podwójna sprzedaż ostatniej sztuki |
| Zamówienie | sklep → system | na zdarzenie (nowe zamówienie) | brak adresu do faktury, duplikaty zamówień |
| Numer przesyłki i status | system lub kurier → sklep | na zdarzenie | status nie wraca do panelu klienta |
| Faktura | system → klient przez sklep | po wystawieniu dokumentu | numer faktury nie trafia do historii zamówienia |
1. API (REST/SOAP). Synchronizacja działa zdarzeniowo (webhook po nowym zamówieniu) albo w interwałach ustawionych w cronie, np. co 5 minut. Wymaga uwierzytelniania: klucza lub tokenu, najlepiej z ograniczeniem po adresie IP. Trzeba obsłużyć limity zapytań — jeśli dostaniesz odpowiedź „too many requests”, integracja musi poczekać i ponowić próbę z rosnącym odstępem, a nie wysypać się. Mechanikę i limity po stronie sklepu opisuje dokumentacja dla deweloperów PrestaShop.
2. Pliki wymiany CSV/XML na FTP/SFTP. Najtańsze wejście i często wystarczające, gdy sprzedajesz kilkanaście sztuk dziennie. Cena: opóźnienie od kilkunastu minut do kilku godzin, zależnie od harmonogramu eksportu. Główne ryzyko to błędne mapowanie kolumn — po zmianie kolejności w eksporcie cena potrafi wylądować w polu SKU i nadpisać dane w tysiącach produktów. Drugie ryzyko: nadpisanie pełnym plikiem kasuje ręczne poprawki zrobione w sklepie.
3. Middleware lub moduł pośredniczący. Tłumaczy formaty, kolejkuje zdarzenia i ponawia nieudane wysyłki, gdy dwa systemy nie mają gotowego łącznika. Kosztuje nie tylko wdrożenie — to kolejny element do hostowania, monitorowania i aktualizowania. Jeśli nikt go nie pilnuje, błędy znikają z oczu na dłużej niż przy prostym API. Przy diagnostyce pomaga wcześniej przygotowana procedura: co robić, gdy sklep przestaje zapisywać zamówienia.
Zasada: gdy sprzedajesz w więcej niż jednym kanale — sklep plus marketplace plus sprzedaż stacjonarna — wybierz kolejkę zdarzeń, a nie nadpisywanie stanów pełnym plikiem. Pełny plik nie wie, że marketplace sprzedał sztukę dwie sekundy temu.
| Kryterium | API REST/SOAP | Pliki CSV/XML na FTP/SFTP | Middleware / kolejka zdarzeń |
|---|---|---|---|
| Koszt startowy | średni — trzeba napisać i przetestować łącznik | niski — wystarczy eksport i import | wysoki — dodatkowy system do postawienia |
| Koszt utrzymania | średni — obsługa zmian w API i limitów | niski, ale rośnie przy każdym błędzie mapowania | najwyższy — hosting, aktualizacje, monitoring |
| Opóźnienie danych | sekundy do 5 minut | 15 minut do kilku godzin | sekundy, zależnie od kolejki |
| Odporność na awarie | dobra przy obsłudze ponowień | słaba — brak transakcyjności | najlepsza — zdarzenia czekają w kolejce |
| Trudność diagnozy błędu | średnia — potrzebne logi zapytań | średnia — widać zawartość pliku | wysoka — błąd może utknąć między systemami |
Jeśli ktoś podaje cenę integracji, nie pytając najpierw o liczbę magazynów i sposób fakturowania, ta cena nic nie znaczy. Pracę wycenia się w godzinach, a godziny wynikają z liczby przepływów danych, nie z „cennika na stronie”.
| Zakres | Godziny | Co obejmuje |
|---|---|---|
| Eksport/import produktów i stanów (jednokierunkowo) | 16–32 h | mapowanie kategorii i atrybutów, ceny, stany, harmonogram crona |
| Zamówienia i statusy (dwukierunkowo) | 40–80 h | tworzenie zamówienia, numer w systemie, statusy, numer przesyłki, faktura PDF lub link |
| Pełna integracja dwukierunkowa | 120–250 h | wiele magazynów, fakturowanie, rezerwacje, ceny grup B2B, kody rabatowe, zwroty |
To godziny netto na same prace. Dolicz analizę i mapowanie pól, moduł po stronie sklepu (PrestaShop lub WooCommerce), testy na kopii bazy, dokumentację i przekazanie — razem zwykle 10–20% powyższego zakresu. Osobno ustal okres gwarancyjny: 30 dni to standard, 90 dni to argument w negocjacjach.
Utrzymanie: monitoring i poprawki błędów to zwykle 2–6 h miesięcznie. Zapisz w umowie, co wchodzi w SLA (czas reakcji, przywrócenie synchronizacji, przegląd logów), a co jest płatne dodatkowo — nowe pola, zmiana po stronie ERP, nowy kanał sprzedaży. Inaczej każde „drobne” zgłoszenie kończy się fakturą.
Prace ukryte: nietypowe stany magazynowe (jedno SKU w kilku lokalizacjach, PZ/WZ), ceny dla grup klientów B2B i rabaty progowe potrafią dodać 20–40% do pierwotnego szacunku. Ten sam mechanizm psuje integrację sklepu z CRM: bez decyzji, które pole jest nadrzędne, każda zmiana jest liczona od nowa.
Wskazówka: poproś o wycenę w rozbiciu na etapy z osobnym punktem „testy i odbiór”. Wtedy nie płacisz dwa razy za poprawki, które wynikają z niejasnych założeń, a nie z Twojej zmiany zdania.
| Zakres | Godziny | Co obejmuje |
|---|---|---|
| Eksport/import produktów i stanów (jednokierunkowo) | 16–32 h | mapowanie kategorii i atrybutów, ceny, stany, harmonogram crona |
| Zamówienia i statusy (dwukierunkowo) | 40–80 h | tworzenie zamówienia, numer w systemie, statusy, numer przesyłki, faktura PDF lub link |
| Pełna integracja dwukierunkowa | 120–250 h | wiele magazynów, fakturowanie, rezerwacje, ceny grup B2B, kody rabatowe, zwroty |
Migrację planuje się razem z integracją, nie po niej. Zacznij od arkusza z dwiema kolumnami: stary URL i nowy URL. Dla każdego produktu i kategorii, które mają ruch lub backlinki, ustaw przekierowanie 301 — w PrestaShop przez reguły w .htaccess albo moduł, w WooCommerce przez wtyczkę przekierowań lub reguły na serwerze. Nie zmieniaj struktury adresów „przy okazji”, jeśli stara ma linki z zewnątrz.
Dane do przeniesienia: klienci, zamówienia z pozycjami, opinie, kody rabatowe, stan magazynowy, tłumaczenia. Zwykle da się to zrobić skryptem z bazy do bazy. Ręcznej pracy wymagają: hasła klientów (hasze nie zawsze są kompatybilne — wtedy zostaje reset hasła mailem), historia koszyków i sesji, część pól SEO zależnych od wtyczki oraz komentarze pod opiniami.
Test na kopii bazy przed przełączeniem DNS: pełny cykl zakupu — dodanie do koszyka, płatność, zamówienie w sklepie, status i faktura w systemie. Jeśli koszyk albo płatność zachowują się niestabilnie, to jest moment, żeby to złapać — opis typowych przyczyn znajdziesz w materiale o tym, dlaczego koszyk w sklepie nie działa.
Zamroź indeksowanie środowiska testowego: hasło na domenie testowej albo noindex w meta, plus wpis w robots.txt. Inaczej Google zaindeksuje duplikaty i po starcie będziesz czekać tygodniami na wyczyszczenie.
Po starcie: wygeneruj sitemap, wdróż dane strukturalne dla produktu i okruszków zgodnie z listą formatów obsługiwanych przez Google, wyślij mapę w Search Console i sprawdzaj raport błędów indeksowania przez pierwsze 30 dni.
Plan awaryjny: zostaw stary sklep w trybie tylko do odczytu na 2–4 tygodnie. Jeśli płatności albo zamówienia szwankują, klient może jeszcze zobaczyć historię, a Ty masz czas na naprawę bez utraty sprzedaży.
| Element | Czy da się przenieść skryptem | Uwagi |
|---|---|---|
| Klienci i zamówienia z pozycjami | Tak | mapowanie statusów zamówień i metod płatności |
| Hasła klientów | Nie zawsze | hasze bywają niekompatybilne — reset hasła mailem |
| Opinie i komentarze | Częściowo | komentarze zależne od wtyczki przenosi się ręcznie |
| Kody rabatowe | Tak | uważaj na daty ważności i limity użyć |
| Stan magazynowy | Tak | przenieś na koniec, po ostatniej synchronizacji z ERP |
| Koszyki i sesje | Nie | klient wraca do pustego koszyka |
Poniżej awarie, które widzimy najczęściej. Każda ma objaw widoczny dla klienta i sposób wykrycia, który nie wymaga czytania kodu.
Nadpisanie stanu zerem. Jeśli stany idą w obie strony, a ERP i sklep liczą je niezależnie, jedno puste pole w eksporcie potrafi wyzerować ofertę. Objaw: rano brak dostępności na produktach, które leżą na magazynie. Wykrycie: dzienny eksport stanów do CSV i porównanie z dniem poprzednim — różnice powyżej kilku procent to sygnał. Naprawa: jedno źródło prawdy dla magazynu i blokada zapisu stanu z drugiej strony.
Duplikaty zamówień. Gdy sklep ponowi zapytanie po timeoucie, system tworzy drugie zamówienie. Rozwiązanie: klucz idempotencji albo unikalny identyfikator zamówienia po stronie ERP — ten sam numer nie może wejść dwa razy.
VAT i brutto/netto. Objaw: faktura różni się od sklepu o kilka groszy na pozycji. Wykryjesz to tylko na zamówieniu z rabatem i wysyłką, gdzie zaokrąglenia się kumulują. Ustal na piśmie, kto liczy podatek i w jakich wartościach przekazujecie dane.
Zablokowany cron lub kolejka. W testach działa, w produkcji stoi. Sprawdzaj czas ostatniej udanej synchronizacji, nie tylko brak błędów w logu — job, który nie wystartował, nie zostawia śladu.
Ciche błędy płatności i kurierów. Brak numeru przesyłki w sklepie najczęściej wynika z integracji, nie z API przewoźnika. Kolejność diagnozy: log sklepu, log integracji, panel przewoźnika. Gdy zamówienia w ogóle nie pojawiają się w sklepie, idź tędy: sklep nie zapisuje zamówień.
| Pułapka | Objaw | Jak wykryć | Naprawa |
|---|---|---|---|
| Zerowanie stanów | Nagłe wyzerowanie oferty | Porównanie stanów dzień do dnia (eksport do CSV) | Jedno źródło prawdy + blokada zapisu z drugiej strony |
| Duplikaty zamówień | Dwa zamówienia z jednego kliknięcia | Ponowienie żądania w testach | Klucz idempotencji / unikalny identyfikator zamówienia |
| VAT i brutto/netto | Faktura różni się od sklepu o grosze na pozycji | Test na zamówieniu z rabatem i wysyłką | Ustalić, kto liczy podatek, i przekazywać wartości brutto |
| Zablokowany cron | Integracja działa w testach, w produkcji stoi | Czas ostatniej udanej synchronizacji | Monitoring kolejki i alert po przekroczeniu progu |
| Brak logowania zdarzeń | Diagnoza zajmuje godziny | Brak wpisów z ID zamówienia i kodem odpowiedzi | Log z datą, ID zamówienia i kodem odpowiedzi |
| Ciche błędy płatności i kuriera | Brak numeru przesyłki w sklepie | Log sklepu → log integracji → panel przewoźnika | Ponowienie żądania + alert do obsługi |
Zanim ktoś napisze pierwszą linijkę kodu, zamknij sześć tematów. Jeśli choć jeden zostanie otwarty, wdrożenie zatrzyma się na testach — zwykle w momencie, gdy zamówienia już wpadają, a magazyn pakuje niewłaściwy towar.
1. Jeden właściciel decyzji po każdej stronie. Po stronie sklepu — jedna osoba (właściciel, e-commerce manager). Po stronie systemu — jedna (główny księgowy, kierownik magazynu). Ta osoba akceptuje mapowanie pól, zgłasza błędy i ma prawo wstrzymać wdrożenie. Decyzje „komitetowe” to najczęstsza przyczyna przestojów w projektach integracyjnych.
2. Źródło prawdy dla czterech danych. Zapisz to w jednym dokumencie i podpisz. Stany magazynowe: ERP albo sklep — nigdy oba zapisujące. Ceny: ERP, sklep tylko prezentuje. Dane klienta: sklep zbiera, ERP jest bazą dla faktur, ale NIP i adres dostawy muszą wracać do sklepu. Numeracja dokumentów: jedna seria po jednej stronie — dwie serie przy dwóch kanałach sprzedaży rozjadą się w ciągu miesiąca.
| Dane | Źródło prawdy | Kierunek zapisu | Akceptowalne opóźnienie |
|---|---|---|---|
| Stany magazynowe | ERP | ERP → sklep | 5–15 min przy ponad 100 zamówieniach dziennie |
| Ceny i promocje | ERP | ERP → sklep | do 15 min |
| Dane klienta | sklep zbiera, ERP wystawia faktury | dwukierunkowo | do 1 h |
| Numeracja dokumentów | ERP | ERP → sklep | natychmiast, bez bufora |
3. Harmonogram i opóźnienia osobno dla każdego przepływu. Zamówienia: natychmiast (webhook lub kolejek co 1–2 min). Stany magazynowe: 5–15 min, jeśli sprzedajesz ponad 100 zamówień dziennie i masz wąskie stany. Ceny: do 15 min. Klienci: do godziny. Dla każdego przepływu zapisz, co się dzieje, gdy synchronizacja padnie na 30 minut — czy sklep sprzeda towar, którego nie ma, i kto oddzwania do klienta.
4. Środowisko testowe. Kopia bazy sklepu z anonimizowanymi danymi klientów, oddzielne klucze API do ERP, wyłączone maile i realne płatności. Scenariusze wypisz przed kodowaniem: zamówienie z 1 produktem, z 5 produktami, produkt ze stanem 0, zwrot, anulowanie, edycja zamówienia w panelu, klient bez konta, klient z NIP-em, dwie metody płatności, dwaj przewoźnicy. To realnie 10–12 przypadków, które wyłapią 80% błędów mapowania.
5. Monitoring po wdrożeniu. Ustal, co jest sprawdzane (czas ostatniej synchronizacji, liczba błędów w kolejce, logi wywołań API), jak często i kto reaguje w weekend. Zamówienie zapisane w sklepie, a niewidoczne w ERP w poniedziałek, to już strata klienta. Przyjmij okno reakcji: 2 h w dni robocze, 4 h w weekend — i wpisz je do umowy.
Jak to poukładać w praktyce, opiszemy na przykładzie integracji sklepu internetowego z CRM. Konfigurację webhooków i kolejek po stronie sklepu znajdziesz w oficjalnej dokumentacji WooCommerce.
Te pytania zadaj przed podpisaniem umowy, nie po pierwszym błędzie. Nie chodzi o to, żeby kogoś złapać — chodzi o to, żeby zobaczyć, gdzie w projekcie siedzi ryzyko i kto je ponosi.
Zamawianie integracji bez spisanej listy przepływów danych — co, w którą stronę i jak często ma się przenosić.
Jak wykryć: Wykonawca pyta tylko o dostęp do API i termin, a nie pyta o mapowanie pól, magazyny, rezerwacje ani statusy zamówień.
Jak naprawić: Zrób warsztat 60–90 minut i wypisz każdy przepływ osobno: produkt do sklepu, stan do sklepu, zamówienie do systemu, dokument do klienta. Wynik traktuj jako załącznik do umowy.
Mieszanie dwóch zakresów: zakupu platformy sklepowej i integracji z systemem, z którego firma już korzysta.
Jak wykryć: W ofercie nie ma rozdzielenia na trzy pozycje: licencja na sklep, licencja na system, integracja. Wszystko jest w jednej kwocie.
Jak naprawić: Poproś o rozbicie kosztów i zakresów odpowiedzialności. Jeśli któryś element jest niejasny, zażądaj doprecyzowania na piśmie przed podpisaniem.
Brak ustalenia, kto utrzymuje synchronizację po starcie.
Jak wykryć: W umowie nie ma kanału zgłoszeń, godzin reakcji ani wskazania, kto monitoruje nieudane synchronizacje.
Jak naprawić: Dopisz do umowy: kto monitoruje, w jakich godzinach, jaki jest czas reakcji i co dzieje się z zamówieniem, które nie przeszło do systemu.
Traktowanie importu stanów magazynowych jako jednorazowej akcji przy starcie.
Jak wykryć: Po pierwszej ręcznej korekcie, przyjęciu towaru lub zwrocie stany w sklepie i w systemie się różnią.
Jak naprawić: Ustal źródło prawdy o stanie, częstotliwość aktualizacji i kierunek przepływu. Przy wielu magazynach dołóż rezerwacje, inaczej sprzedasz towar, którego nie ma.
Testy bezpośrednio na produkcji, bez środowiska testowego i danych zastępczych.
Jak wykryć: Nie istnieje kopia sklepu, na której da się powtórzyć scenariusz zamówienia bez ryzyka dla realnych klientów.
Jak naprawić: Wymagaj stagingu, kluczy testowych i scenariusza akceptacyjnego na 10–20 zamówieniach przed uruchomieniem na produkcji.
Założenie, że nazwy pól i modułów nie zmienią się po aktualizacji sklepu lub systemu.
Jak wykryć: Nigdzie nie zapisano numerów wersji, na których integracja została przetestowana i działa.
Jak naprawić: Zapisz wersje w dokumentacji wdrożenia i ustal, kto testuje łącznik przed każdą aktualizacją. Bez tego pierwsza aktualizacja WooCommerce może cicho zatrzymać synchronizację.
Organizacyjnie integracja to nie jedna decyzja, a cztery: lista przepływów danych, wybór metody wymiany, wycena w godzinach i wskazanie osoby odpowiedzialnej po starcie. Najczęstszy błąd to zamawianie integracji bez spisanej listy pól i bez ustalenia, kto reaguje na nieudane synchronizacje. Jeśli sprzedajesz w więcej niż jednym kanale, planuj kolejkę zdarzeń, a nie nadpisywanie stanów pełnym plikiem. Każdą obietnicę po stronie dostawcy potwierdź w dokumentacji i na piśmie w ofercie.
Nie potwierdzam zakresu funkcji ani nazewnictwa modułów po stronie tego dostawcy — to zmienia się między wersjami. Z perspektywy sklepu liczy się jedno: czy istnieje udokumentowany sposób wymiany danych (API, pliki wymiany, gotowy łącznik). To pytanie zadaj dostawcy i poproś o potwierdzenie na piśmie w ofercie.
Widełki orientacyjne, które trzeba potwierdzić w konkretnej wycenie: prosty łącznik plikowy w jedną stronę to zwykle kilkanaście godzin, integracja przez API z zamówieniami i stanami to kilkadziesiąt godzin, a pełna synchronizacja dwukierunkowa z wieloma magazynami i statusami dokumentów potrafi przekroczyć sto godzin. Do tego dolicz 20–30% na testy i uruchomienie. Im więcej wyjątków (zwroty, zamówienia częściowo zrealizowane, wiele walut), tym bliżej górnej granicy.
Policz koszt pracy ręcznej. Przykład: 300 zamówień miesięcznie i 3 minuty na przepisanie jednego zamówienia to 15 godzin miesięcznie, czyli około 180 godzin rocznie. Przy stawce 60 zł za godzinę daje to około 10 800 zł rocznie — i to bez kosztu pomyłek. Porównaj tę kwotę z kosztem wdrożenia i utrzymania integracji, pamiętając, że integracja zwykle nie eliminuje pracy całkowicie, tylko skraca ją do wyjątków.
Czasem tak — przy jednym kanale sprzedaży, małym asortymencie i tolerancji na opóźnienie. Pliki wymiany mają jednak dwa ograniczenia: dane są nieaktualne od kilkunastu minut do kilku godzin, a błędne mapowanie kolumn potrafi nadpisać poprawne dane. Jeśli sprzedajesz równolegle w sklepie, na marketplace i stacjonarnie, wybierz kolejkę zdarzeń zamiast nadpisywania stanów pełnym plikiem.
To musi być zapisane w umowie, bo po starcie spory dotyczące „czyj to błąd” kosztują więcej niż samo wdrożenie. Ustal kanał zgłoszeń, godziny reakcji, osobę kontaktową po obu stronach oraz to, co dzieje się z zamówieniem, które nie przeszło do systemu. Bez tych ustaleń pierwsza awaria oznacza ręczne przepisywanie zamówień.
Oba systemy mają udokumentowane interfejsy do wymiany danych, więc integracja jest technicznie możliwa. Szczegóły znajdziesz w dokumentacji dla deweloperów PrestaShop oraz w dokumentacji WooCommerce. Nazwy modułów i zakres funkcji sprawdzaj zawsze dla swojej wersji, nie dla ogólnych opisów z sieci.
Najpierw ustal źródło prawdy o stanie i sprawdź, czy w sklepie nie ma ręcznych korekt robionych poza integracją. Potem dołóż raport rozbieżności uruchamiany raz na dobę oraz alert przy różnicy powyżej ustalonego progu. Jeśli problem wraca, przyczyną bywa brak obsługi rezerwacji albo dwóch kanałów sprzedaży nadpisujących ten sam stan.
Jeśli chcesz przejść przez te ustalenia z kimś, kto wdrożył już kilkadziesiąt sklepów na PrestaShop i WooCommerce, napisz do nas krótko, co masz teraz i z czym chcesz to połączyć. Odpowiemy, jakie pytania zadać dostawcy i ile realnie godzin zajmie wdrożenie.