Najwięcej pieniędzy traci się nie na kodzie integracji, a na kolejności prac. Sklep, który zaczyna od podpięcia kuriera, zanim uporządkował stany magazynowe, płaci dwa razy: raz za moduł, drugi raz za sprzątanie rozjechanych danych. W Biłgoraju i okolicy najczęściej pracujemy na Subiekcie, Optywie, WAPRO i Fakturowni, więc problemy są powtarzalne. Ten tekst to część organizacyjna: pokazuje kolejność, testy gotowości i listę rzeczy do sprawdzenia przed podpisaniem umów.
Kolejność prac jest krótka, a jej odwrócenie kosztuje najwięcej: 1) porządek w danych produktowych, 2) ERP jako źródło prawdy, 3) płatności, 4) kurierzy na końcu. Sklep, który zaczyna od etykiet kurierskich, generuje przesyłki na podstawie wagi wpisanej „na oko” kilka lat temu — efektem są dopłaty za niedowagę i reklamacje u przewoźnika.
Źródło prawdy (master danych) to jeden system, który ma ostatnie słowo w trzech sprawach. Kto ustala stan magazynowy: ERP, i tylko ERP — sklep nie może „poprawiać” stanu ręcznie w panelu, bo przy najbliższej synchronizacji nadpisze to, co wpisał magazynier. Kto ustala cenę: ERP, chyba że świadomie dopuszczasz promocje w sklepie — wtedy zapisz regułę, np. cena sklepowa nie może spaść poniżej progu z cennika hurtowego. Kto ustala status zamówienia: sklep tworzy zamówienie, ERP wystawia dokument, a mapowanie statusów musi być zamknięte (5 statusów sklepu ↔ 3 statusy ERP). Bez tego dwie zmiany statusu w jednej minucie potrafią wprowadzić dokument w pętlę.
Test gotowości: 50 zamówień przepisanych ręcznie do ERP bez jednego rozjazdu. Wystawiamy 50 zamówień w sklepie, ręcznie przenosimy do systemu i po każdej operacji sprawdzamy stan. W próbce muszą być: zamówienie z rabatem, produkt sprzedawany w dwóch jednostkach (sztuka i opakowanie), pozycja częściowo niedostępna i jedno anulowanie. Jeśli w 50 próbach cokolwiek się rozjedzie — nie automatyzujemy, tylko wracamy do danych. Ta sama próbka pokazuje, ile realnie trwa ręczna obsługa.
Kiedy nie integrować: przy ok. 30 zamówieniach miesięcznie ręczne przepisanie to około 2 godzin pracy (4 minuty na zamówienie). Utrzymanie integracji — aktualizacje po zmianach API, monitoring, korekty stanów — to zwykle kilkaset złotych miesięcznie. Przy niskim wolumenie dopłacasz do wygody. Sąsiednie gminy opisujemy osobno, np. integracje z ERP, płatnościami i kurierami w Frampolu.
Zanim podpiszesz umowę na moduł, ustal z wykonawcą jedną rzecz: co w danym systemie jest dostępne z pudełka, a co trzeba dopisać i utrzymywać.
| System | Zwykle w standardzie | Wymaga modułu własnego |
|---|---|---|
| Subiekt GT | Kartoteki, stany, ceny, wystawianie dokumentu przez Sferę (COM); wtyczki komercyjne | Kolejkowanie, zamówienia wysyłkowe, wiele magazynów |
| Subiekt nexo | Kartoteki, stany, dokumenty; rozszerzenia i narzędzia firm trzecich | Wydajność przy dużym katalogu, cechy i jednostki |
| Comarch Optima | Dostęp przez API lub bazę MS SQL, kartoteki, dokumenty | Mapowanie kontrahentów, cenniki i rabaty, wielofirmowość |
| WAPRO | Kartoteki, dokumenty magazynowe, dostęp przez bazę/API | Warstwa pośrednia, jednostki, historia cen |
| Fakturownia | API REST: faktury, produkty, kontrahenci | Stany magazynowe (to nie WMS), zamówienia wysyłkowe |
| Enova | API, magazyn i zamówienia w chmurze | Mapowanie statusów, nietypowe jednostki |
Subiekt: Sfera to osobne uprawnienie w licencji i dodatkowy koszt — sprawdź to przed projektem. Działa lokalnie na Windows, więc moduł musi gadać z maszyną w firmie przez serwer pośredniczący, a nie bezpośrednio z hostingu sklepu. Sfera jest jednowątkowa: przy katalogu 5 000 pozycji pełny zrzut co godzinę dławi pracę biura. Synchronizuj przyrostowo, po dacie modyfikacji.
Optima i WAPRO: jeśli łączysz się z bazą, to wyłącznie na koncie read-only i na widoku, nigdy zapisem do tabel produkcyjnych. Kontrahenta mapuj po NIP, a dla osób fizycznych po identyfikatorze złożonym (e-mail + znormalizowane nazwisko).
Chmura (Fakturownia, iFirma, Enova): szybciej na start, ale policz limit zapytań. 3 000 produktów po jednym zapytaniu to 3 000 wywołań — jeśli limit to kilkaset na godzinę, pełna synchronizacja zajmie całą noc. Dlatego delta plus cache.
Pułapka indeksów: ten sam produkt ma inne SKU w sklepie i inne w ERP. Zbuduj tabelę mapowania (erp_id, erp_sku, shop_id, ean, kod_dostawcy, nazwa_znormalizowana, źródło_mapowania) i ustal kolejność: ERP ID, potem EAN, potem kod dostawcy, a nazwa tylko z ręcznym zatwierdzeniem. Zmiana „Kubek 350 ml” na „Kubek 0,35 l” potrafi rozjechać cały magazyn. Dokumentację techniczną PrestaShop znajdziesz w PrestaShop Developer Documentation.
Porównuj operatorów dopiero wtedy, gdy wpiszesz do arkusza cztery pozycje: prowizję od transakcji, opłatę za BLIK, opłatę za zwrot środków i koszt wypłaty na konto. Stawki są negocjowane indywidualnie i zmieniają się w czasie, więc nie podaję tu konkretnych procentów — bierz własną ofertę. Przykład różnicy: jeśli dwie oferty dzieli 0,4 pkt proc., przy 200 transakcjach i średnim koszyku 150 zł (30 000 zł obrotu) to 120 zł miesięcznie, czyli 1 440 zł rocznie.
| Operator | Kiedy ma sens |
|---|---|
| Przelewy24 | Sklep B2C, w którym klient płaci głównie BLIK-iem i zwykłym przelewem |
| PayU | Większy wolumen B2C, szeroka lista metod płatności |
| Tpay | Mniejsza firma, prosty cennik, szybkie wdrożenie |
| Autopay | Raty i płatności odroczone, większe koszyki |
| Stripe | Subskrypcje, klienci zagraniczni, karty; mniej sensu, gdy cały ruch to BLIK |
Webhooki i idempotencja. Endpoint przyjmujący powiadomienie powinien natychmiast zapisać surowy payload i odpowiedzieć 200 OK, a właściwe przetwarzanie zrobić asynchronicznie (kolejka, cron). Operatory ponawiają powiadomienie, gdy nie dostaną odpowiedzi — typowo kilka razy. Bez klucza idempotencji, np. unikalnego indeksu na parze transaction_id i event_type, jedna płatność „wpada dwa razy”: dwa zamówienia albo dwa potwierdzenia.
Zwroty i reklamacje. Sprawdź w API metodę zwrotu i czy uruchomisz ją z panelu sklepu. Jeśli zwrot jest możliwy tylko z panelu operatora, każda reklamacja to dwa kliknięcia w dwóch systemach i ryzyko podwójnego zwrotu środków. Ustal też, czy prowizja wraca przy zwrocie.
3DS i fraud. Dla kart wymuszaj uwierzytelnianie — daje przeniesienie odpowiedzialności za chargeback. W B2B karty korporacyjne często nie przechodzą 3DS, ale zamiast wyłączać zabezpieczenie, lepiej zaproponować przelew z odroczonym terminem. Wyłączenie 3DS przenosi ryzyko na sklep. Podobne ustalenia dla firm z okolic opisujemy przy okazji integracji z ERP, płatnościami i kurierami w Zamościu.
Podpięcie API kuriera to najczęściej 2–4 godziny pracy. Reszta wdrożenia to mapowanie statusów, punktów odbioru i pobrań. Jeśli ktoś wycenia „integrację z InPost” jako całość bez pytania o ERP, warto dopytać, co dokładnie wchodzi w zakres.
Statusy. Kluczowe jest ustalenie trzech warstw: status u kuriera → status zamówienia w PrestaShop → status dokumentu w ERP. Bez tego pracownik magazynu wystawia WZ dwa razy, a biuro fakturę po fakcie, gdy paczka już wróciła. Mapowanie trzeba zapisać w tabeli i dać do akceptacji osobie, która wystawia dokumenty — nie tylko programiście.
Punkty odbioru. InPost (ShipX, endpoint z listą punktów), DPD Pickup i DHL POP udostępniają listy punktów w API. Praktyka: synchronizacja raz na dobę w cronie do własnej tabeli w bazie sklepu, wyszukiwarka po kodzie pocztowym i mieście, walidacja wybranego kodu przy składaniu zamówienia. Pobieranie listy „na żywo” przy każdym wejściu na checkout to najczęstsza przyczyna wolnego koszyka.
Etykiety. Przez API kuriera generujemy, gdy mamy 1–2 kurierów i jeden kanał sprzedaży — taniej i prościej. Gdy dochodzi trzeci kurier, marketplace albo wysyłka z kilku magazynów, realnie opłaca się BaseLinker albo podobny system: jedno miejsce na etykiety, ale dochodzi abonament i druga warstwa błędów do obsłużenia. Numer przesyłki musi wracać do sklepu i do ERP — inaczej przy reklamacji szuka się go w trzech miejscach.
Pobranie. Opłata za pobranie to koszt, nie przychód. W Subiekcie najczęściej ląduje jako faktura zakupu lub nota od kuriera, a kwota pobrania jako wpływ na konto. Ustal z księgowością, czy prowizja idzie w koszty wysyłki, czy w pozostałe koszty operacyjne — przy 300 paczkach pobraniowych miesięcznie to różnica w raportach.
| Status u kuriera | Status w sklepie | Status w ERP | Co dzieje się w systemie |
|---|---|---|---|
| Etykieta utworzona / nadana | Przygotowanie do wysyłki | Rezerwacja (bez WZ) | Zapis numeru przesyłki, brak zdjęcia ze stanu |
| Przesyłka odebrana od nadawcy | Wysłane | WZ wystawione | Towar schodzi ze stanu magazynowego |
| W drodze / w transporcie | Wysłane (bez zmiany) | Bez zmian | Brak akcji, tylko log |
| W dostawie u kuriera | Wysłane (bez zmiany) | Bez zmian | Opcjonalny e-mail do klienta |
| Gotowa do odbioru w punkcie | Gotowe do odbioru | Bez zmian | Powiadomienie z kodem odbioru i terminem |
| Doręczona / odebrana | Zrealizowane | Faktura sprzedaży | Wystawienie FS, jeśli nie wystawiono wcześniej |
| Nieudana próba doręczenia | Wysłane + flaga problem | Status dostawy | Zadanie dla obsługi klienta |
| Awizo / oczekuje w punkcie | Gotowe do odbioru | Bez zmian | Przypomnienie po 3 dniach |
| Zwrot do nadawcy (RTS) | Zwrócone / anulowane | Korekta lub PW | Przywrócenie stanu i korekta faktury |
| Zwrot odebrany na magazynie | Zwrot przyjęty | Dokument przyjęcia | Rozliczenie kosztów zwrotu |
Poniższa procedura działa niezależnie od tego, czy robisz to sam, czy zamawiasz u wykonawcy. Warto o nią zapytać w ofercie — brak punktów 4–6 oznacza, że testy będą robione na produkcji.
Gotowe do produkcji to brak wiszących zamówień, brak zdublowanych faktur po dwóch dniach pracy i zgodny stan magazynowy sprawdzony po 48 godzinach od startu. Dobrze jest też ustalić jedną osobę po stronie klienta, która ma prawo zatwierdzać mapowanie i odbierać testy — inaczej projekt stoi tygodniami na akceptacji.
Łatwiej porównać oferty, gdy rozbijesz je na części. Poniżej realne widełki z projektów e-commerce, nie stawki z cennika.
Powód, dla którego jedna wycena ma 20 h, a inna 120 h, prawie nigdy nie leży w stawce. Najczęstsze czynniki: brak API po stronie ERP (zostaje eksport/import plików i ręczne czynności), stara wersja PrestaShop bez wsparcia dla nowszych PHP, brak środowiska testowego, brak osoby decyzyjnej po stronie klienta, dane do posprzątania (duplikaty produktów, SKU bez EAN, stany ujemne). Do wyceny warto dopisać, ile godzin rezerwy zakładasz na sprzątanie.
Model rozliczenia. Ryczałt opłaca się klientowi wtedy, gdy zakres jest zamknięty i opisany punktowo — np. „płatność Przelewy24, etykiety InPost, eksport zamówień do Subiekta”. Stawka godzinowa jest uczciwsza, gdy ERP jest nietypowy lub nie ma dokumentacji API — wtedy ryczałt zawsze zawiera ukrytą marżę na ryzyko wykonawcy. Jeśli oferta ryczałtowa nie ma listy wyłączeń, dopytaj, co się dzieje, gdy okaże się, że ERP nie ma API.
Utrzymanie. Kurierzy zmieniają API bez pytania o zdanie — InPost, DPD i DHL robią to kilka razy w roku. Realny koszt to 2–6 h miesięcznie na monitoring i poprawki przy kilku integracjach, plus opieka z SLA (reakcja 4 h w dni robocze to inna cena niż 24 h). Warto wpisać w umowę czas reakcji i zakres: czy obejmuje przywrócenie integracji po awarii, czy tylko diagnozę.
Jak czytać ofertę. Powinny być cztery elementy: zakres (co dokładnie wchodzi), wyłączenia (czego nie ma), warunki odbioru (kto i na jakiej podstawie akceptuje testy), czas reakcji po wdrożeniu. Brak chociaż jednego z nich to zaproszenie do sporu na etapie poprawek.
| Zakres | Godziny | Typowy czas |
|---|---|---|
| Prosta integracja płatności (jeden operator) | 4–10 h | 2–4 dni |
| Kurier z etykietami i statusami | 8–20 h | 3–7 dni |
| ERP standardowe (np. Subiekt z API) | 20–60 h | 1–3 tygodnie |
| ERP nietypowe (brak API, pliki, własny system) | 60–150 h | 3–8 tygodni |
Zanim zapłacisz za poprawki, sprawdź te siedem rzeczy sam. Każda ma objaw widoczny w panelu sklepu albo w ERP, więc nie musisz pytać wykonawcy. Potrzebujesz tylko dostępu do logów modułu integracyjnego i do kartoteki w systemie księgowym. Całość zajmuje około pięciu minut.
Objawy, przyczyny i sposób sprawdzenia znajdziesz w tabeli poniżej. Po niej trzy rzeczy, które warto ustawić raz na zawsze.
Jeżeli sam piszesz albo zlecałeś moduł do PrestaShopa, punktem wyjścia jest dokumentacja dla deweloperów opisująca webhooks i webservice: PrestaShop Developer Documentation — tam sprawdzisz, czy dane zdarzenie w ogóle da się odebrać w sposób idempotentny.
| Objaw w panelu | Najczęstsza przyczyna | Weryfikacja w 5 minut |
|---|---|---|
| Dwie faktury do jednego zamówienia w Subiekcie lub Optywie | Brak idempotencji, podwójny webhook po timeoucie | W logach modułu szukaj dwóch wpisów z tym samym order_id w odstępie kilku sekund; w ERP sprawdź pole „nr obcy” |
| Stany w sklepie i w ERP różnią się o kilka sztuk po 2 dniach | Brak zapisu zwrotnego po anulowaniu lub edycji zamówienia | Anuluj testowe zamówienie na produkt ze stanem 10 szt. i po 15 minutach porównaj stan w obu systemach |
| Zamówienie „w realizacji”, a paczka jest już u klienta | Brak mapowania statusu dostarczenia z API kuriera na statusy sklepu | Weź numer listu przewozowego z ostatniej wysyłki i porównaj status u kuriera ze statusem w sklepie |
| Cena po promocji w sklepie nie zgadza się z kwotą na dokumencie w ERP | Brak reguły nadrzędności ceny przy rabatach i promocjach | Ustaw rabat 10% na jeden produkt, złóż zamówienie testowe i sprawdź kwotę na dokumencie w ERP |
| Zamówienie opłacone, a w sklepie nie ma numeru faktury | Brak zapisu zwrotnego ID dokumentu z ERP | Otwórz zamówienie sprzed 24 godzin i sprawdź, czy pole z numerem faktury jest wypełnione |
| Klient B2B nie widzi limitu kredytowego ani przeterminowań | Brak synchronizacji kartoteki kontrahenta i salda | Zaloguj się na konto testowego klienta B2B i sprawdź, czy widzi limit oraz saldo |
| Timeouty co kilka dni, zwykle między 10:00 a 14:00 | Brak kolejek i mechanizmu retry po stronie sklepu | W logach serwera szukaj „cURL error 28” i „Operation timed out”; sprawdź, czy zadania idą przez kolejkę, czy synchronicznie |
Ten fragment nadaje się do wydrukowania i odhaczania w trakcie wdrożenia. Te same pytania sprawdzają się niezależnie od tego, czy sklep działa w Biłgoraju, czy w Zamościu albo w Frampolu; klienci z Józefowa, Krasnobrodu, Zwierzyńca i Szczebrzeszyna mają zwykle ten sam zestaw systemów, różni ich jedynie sezonowość sprzedaży.
Co przygotować przed pierwszym spotkaniem:
| Pytanie do wykonawcy | Dobra odpowiedź | Czerwona flaga |
|---|---|---|
| Ile wdrożeń zrobiłeś na Subiekcie, Optywie, WAPRO lub Fakturowni? | Podaje konkretne systemy i typy dokumentów, które synchronizował | „Robimy integracje ze wszystkim” |
| Na czym będziemy testować? | Na kopii bazy ERP lub środowisku testowym dostawcy | „Przetestujemy na produkcji po godzinach” |
| Jak przekazujesz logi i raportujesz błędy? | Daje dostęp do logów z identyfikatorem requestu | „Zadzwonimy, jak coś się wysypie” |
| Co się dzieje, gdy API kuriera nie odpowiada? | Zadanie trafia do kolejki i jest ponawiane | „Zamówienie się wtedy nie zapisze” |
| Kto utrzymuje integrację po odbiorze? | Konkretna osoba, z jasno ustalonym czasem reakcji | „Zgłoszenia trafiają do naszego działu wsparcia” |
| Czy rozmawiam bezpośrednio z deweloperem? | Tak, pytania techniczne idą prosto do osoby piszącej kod | „Przekażę to zespołowi i wrócę z odpowiedzią” |
Start od integracji kuriera, gdy stany magazynowe i ceny wciąż żyją w dwóch miejscach.
Jak wykryć: Ten sam produkt ma inny stan w sklepie i w ERP, a klient złożył zamówienie na towar, którego fizycznie nie ma na półce.
Jak naprawić: Zamroź prace nad kurierem, wróć do uporządkowania danych produktowych i wskaż ERP jako źródło prawdy o stanie. Kurier podłączasz na samym końcu.
Brak ustalonego źródła prawdy (master danych) dla ceny, stanu i statusu zamówienia.
Jak wykryć: Na pytanie „kto zmienił cenę tego produktu?” nikt nie potrafi wskazać osoby ani systemu. W logach widać zapisy z dwóch stron jednocześnie.
Jak naprawić: Zapisz na piśmie trzy reguły: stan zapisuje ERP, cenę sprzedaży zapisuje sklep, status zamówienia zapisuje sklep i tylko on nadaje statusy zewnętrzne. Każdy inny system tylko czyta.
Automatyzacja uruchomiona, zanim proces został sprawdzony ręcznie.
Jak wykryć: Nie masz policzonych błędów z ręcznego przepisywania zamówień. Nikt nie wie, ile pomyłek zdarzało się przy 50 ostatnich zamówieniach.
Jak naprawić: Przepisz ręcznie 50 kolejnych zamówień do ERP i policz błędy. Zero błędów to próg gotowości. Automatyzacja powiela błąd w skali, nie naprawia go.
Brak mapowania indeksów między sklepem a ERP przed pierwszym importem.
Jak wykryć: Produkty bez SKU, duplikaty SKU, indeksy ze spacjami, polskimi znakami albo wiodącymi zerami. Ten sam towar ma inny numer po każdej stronie.
Jak naprawić: Zbuduj jedną tabelę mapowania SKU sklepu ↔ indeks ERP i wiąż rekordy po identyfikatorze, nie po nazwie. Nazwa produktu to etykieta, nie klucz.
Umowa z operatorem płatności podpisana bez kalkulacji kosztu zwrotu i wypłaty środków.
Jak wykryć: Kalkulacja obejmuje tylko prowizję od transakcji. Nikt nie sprawdził opłaty za BLIK, za zwrot, za wypłatę i okresu wypowiedzenia.
Jak naprawić: Policz koszt dla realnego koszyka: 100 zamówień, z czego kilkanaście to zwroty i zwroty częściowe. Dopiero ta kwota jest porównywalna między operatorami.
Integracja potraktowana jak projekt jednorazowy — brak monitoringu kolejek i logów.
Jak wykryć: Zadanie synchronizacji, które nie przeszło trzy razy z rzędu, nie generuje żadnego alertu. Dowiadujesz się o awarii od klienta.
Jak naprawić: Ustal, gdzie trafiają błędy synchronizacji, kto je przegląda i z jaką częstotliwością. Przez pierwszy miesiąc po wdrożeniu sprawdzasz log codziennie.
Kolejność prac ma większe znaczenie niż wybór konkretnego dostawcy ERP czy bramki płatności. Najpierw porządek w danych produktowych, potem ERP jako źródło prawdy, następnie płatności, a kurierzy na końcu — dopiero wtedy integracja oszczędza czas, a nie go zabiera. Próg gotowości jest prosty: 50 zamówień przepisanych ręcznie bez błędu. Jeśli to się nie udaje, automatyzacja tylko przyspieszy bałagan. Podobne wdrożenia prowadziliśmy w firmach z Biłgoraja i okolic — zobacz, jak wygląda to w Zamościu, a także w Zwierzyńcu.
Od uporządkowania danych produktowych i wskazania ERP jako źródła prawdy o stanie magazynowym oraz cenie zakupu. Potem podłączasz płatności, a kurierów zostawiasz na koniec. Ta kolejność wynika z prostej zależności: kurier potrzebuje poprawnego statusu zamówienia, a status zamówienia potrzebuje poprawnego stanu towaru.
Nie zawsze. Jeśli miesięcznie obsługujesz kilkadziesiąt zamówień, ręczne przepisywanie do ERP bywa tańsze niż utrzymanie i pilnowanie API. Integracja zaczyna się opłacać, gdy rosną koszty pomyłek: zamówienia na towar, którego nie ma, albo faktury wystawiane po kilku dniach. Przed decyzją policz roboczogodziny, nie tylko licencję.
To zależy od trzech rzeczy: jakości danych produktowych, liczby systemów do połączenia i tego, czy wybrany ERP ma gotowe API. Samo podłączenie płatności jest zwykle najkrótszym etapem. Najdłużej trwa etap mapowania indeksów i uzgadniania stanów, bo wymaga pracy po stronie księgowości, a nie programisty.
Technicznie tak, organizacyjnie to ryzykowne. Płatności generują statusy i zwroty, które potem trzeba dopasować do statusów w ERP. Jeśli ERP nie jest jeszcze źródłem prawdy, po każdej płatności rośnie bałagan w stanach i fakturach. Zacznij od danych i ERP, płatności podłączaj na uporządkowanym gruncie.
Zestaw listę 20–30 produktów o największym obrocie i porównaj stan w sklepie, w ERP i na półce. Różnice powinny wynikać wyłącznie z zamówień, które nie zostały jeszcze przepisane. Jeśli nie potrafisz wyjaśnić rozjazdu, nie jesteś gotowy na automatyczne odejmowanie stanów.
Zbuduj jedną tabelę mapowania i wiąż rekordy po identyfikatorze, nigdy po nazwie. Nazwa produktu zmienia się przy każdej akcji marketingowej, więc jako klucz jest bezużyteczna. Przy systemach typu Subiekt synchronizacja często idzie przez Sferę lub Wsady, a przy Optymie i WAPRO dochodzi jeszcze mapowanie kontrahentów — to trzeba zaplanować przed startem, nie w trakcie.
Gdy wolumen zamówień jest niski, a koszt utrzymania API, aktualizacji modułu i obsługi błędów przewyższa oszczędność czasu. Ręczny proces ma też jedną zaletę: błędy widzisz od razu i wiesz, kto je popełnił. Przed wdrożeniem policz oba warianty na tych samych dwunastu miesiącach.
Jeśli nie wiesz, od którego etapu zacząć u siebie, prześlij nam listę systemów i liczbę zamówień miesięcznie — powiemy, co ma sens teraz, a co można odłożyć. Zajmujemy się PrestaShopem, WordPressem, integracjami i serwerami na co dzień.