Integracje z ERP, płatnościami i kurierami w Bydgoszczy dla firmy to najczęściej nie jeden projekt, a trzy niezależne warstwy: pieniądze, paczki i dane księgowe. Każda z nich ma inny koszt, inne ryzyko i inny moment, w którym warto ją wdrożyć. W tym artykule znajdziesz mapę priorytetów, widełki godzinowe do porównania ofert, przebieg wdrożenia krok po kroku oraz listę pułapek, które wychodzą dopiero po pierwszym tygodniu pracy na produkcji. Punkt wyjścia do dalszej lektury: Integracje API.
W ofertach „integracja” brzmi jak jedna usługa. W praktyce to trzy niezależne warstwy: każda ma inne API, inny koszt i inne ryzyko. Można je wdrażać osobno i rozliczać osobno.
Przepływ jednego zamówienia: klient klika „kupuję” → bramka płatności → webhook „opłacone” → zmiana statusu w sklepie → ERP rezerwuje towar → magazyn pakuje → moduł kuriera generuje etykietę → kurier odbiera paczkę → status „doręczona” wraca do sklepu → ERP wystawia fakturę. Najczęściej pęka w trzech miejscach: brak webhooka i oparcie się tylko na powrocie klienta na stronę „dziękujemy”, brak idempotencji (dwa webhooki = dwie faktury) oraz timeout API kuriera bez kolejki ponowień. Mechanikę żądań i odpowiedzi opisuje dokumentacja HTTP.
Gotowa wtyczka wystarcza, gdy masz jednego operatora płatności, jedną walutę i standardowy zestaw pól na fakturze. Koszt ukryty pojawia się, gdy ERP wymaga niestandardowego pola (numer projektu, centrum kosztów), a wtyczka go nie mapuje – wtedy płacisz abonament i dalej robisz coś ręcznie. Moduł na miarę ma sens dopiero wtedy.
Minimum słownictwa: API REST/SOAP (sposób komunikacji), webhook (powiadomienie z systemu zewnętrznego), kolejka komunikatów (bufor na wypadek awarii odbiorcy), idempotencja (to samo zdarzenie przetworzone raz), sandbox (środowisko testowe operatora).
| Warstwa | Co obejmuje | Typowe godziny | Gdzie najczęściej pęka |
|---|---|---|---|
| ERP / magazyn / faktury | zamówienia, stany, faktury, korekty, zwroty | 20–60 h | niestandardowe pola, brak wspólnego ID zamówienia |
| Płatności online | bramka, webhook, zwroty, dopasowanie transakcji | 4–10 h | brak idempotencji, brak webhooka |
| Kurierzy i etykiety | etykiety, tracking, statusy, zwroty | 6–14 h | timeout API, brak kolejki ponowień |
Kolejność wdrożeń: płatności → kurierzy → ERP. Nie dlatego, że ERP jest najmniej ważne, ale dlatego, że zależy od danych z dwóch pierwszych warstw. Jeśli statusy płatności są niepewne, a identyfikatory zamówień niespójne, ERP będzie łatał cudze błędy i każda poprawka będzie kosztować dwa razy.
Progi decyzyjne oparte na wolumenie:
Wymiana plikowa (CSV, FTP) jest wystarczająca, gdy faktury zbiorczo raz dziennie są akceptowalne, masz jeden kanał sprzedaży i magazyn kontrolujesz ręcznie. Integracja w czasie rzeczywistym jest konieczna, gdy sprzedajesz jednocześnie na Allegro i we własnym sklepie z tego samego stanu, sprzedajesz produkty na zamówienie albo obiecujesz klientowi konkretny dzień wysyłki.
Sygnały, że obecny stack nie wystarcza: stany w sklepie rozjeżdżają się z ERP, faktury wystawiacie po zamknięciu miesiąca, etykiety generujecie ręcznie, a klienci piszą „kiedy wyślecie”. Każdy z tych objawów oznacza inną warstwę – warto zacząć od tej, która generuje najwięcej telefonów.
| Sygnał | Co zwykle oznacza | Pierwszy krok |
|---|---|---|
| Stany magazynowe się rozjeżdżają | brak synchronizacji sklep–ERP | integracja ERP w czasie rzeczywistym |
| Faktury wystawiane po zamknięciu miesiąca | ręczne przepisywanie danych | integracja ERP lub plik CSV z harmonogramem |
| Etykiety generowane ręcznie | brak integracji z kurierem | integracja z jednym kurierem |
| Klienci pytają o status wysyłki | brak statusów trackingowych w sklepie | webhook kuriera + maile statusowe |
Nie podam jednej ceny, bo zależy ona od liczby integracji i od tego, jak nietypowy jest Twój proces. Podam widełki w roboczogodzinach – to jedyny sensowny sposób porównania dwóch ofert na to samo.
Co podnosi koszt: wiele magazynów (+30–50% do zakresu ERP), wiele walut, faktury korygujące, zamówienia zagraniczne (VAT OSS, dokumenty celne), niestandardowe pola w ERP wymagające ręcznego mapowania oraz integracja starszego ERP udostępniającego wyłącznie pliki, a nie API.
Budżet wdrożenia to jedno, utrzymanie drugie. Realistyczny miesięczny narzut to 2–6 h: monitoring webhooków i kolejek, poprawki po zmianach po stronie operatora, aktualizacje certyfikatów i bibliotek. Zmiana wersji API operatora zdarza się raz na 1–3 lata i potrafi wygenerować 8–20 h pracy. Jeśli wykonawca mówi „to będzie działać zawsze”, nie mówi całej prawdy.
Pytania, które trzeba zadać, żeby porównać ofertę: czy podane godziny obejmują testy i uruchomienie na produkcji, kto płaci za środowisko testowe i sandbox operatora, co dzieje się po zmianie API operatora – jest w cenie czy płatne osobno, kto monitoruje webhooki po wdrożeniu, czy kod trafia do Twojego repozytorium i jaki jest czas reakcji przy awarii. To samo dotyczy firm z regionu – takie same zasady wyceny stosuje się przy integracjach z ERP, płatnościami i kurierami w Bydgoszczy.
| Zakres | Widełki (roboczogodziny) | Co podnosi koszt |
|---|---|---|
| Operator płatności | 4–10 h | zwroty częściowe, wiele metod płatności, subskrypcje |
| Jeden kurier | 6–14 h | punkty odbioru, przesyłki zagraniczne, zwroty |
| Integracja z ERP | 20–60 h | wiele magazynów, faktury korygujące, niestandardowe pola |
| Moduł niestandardowy | 15–40 h | logika rabatowa, wycena B2B, wielowalutowość |
| Utrzymanie (miesięcznie) | 2–6 h | aktualizacje API operatorów, monitoring, poprawki |
Typowy projekt integracji w firmie MŚP to 4–6 tygodni pracy, jeśli dane w sklepie i ERP są uporządkowane. Poniżej realny rozkład etapów.
Etap 1 – inwentaryzacja (tydzień 1). Spisujemy wolumeny i systemy: liczba zamówień miesięcznie, średnia liczba pozycji w koszyku, metody płatności (BLIK, karta, przelew, za pobraniem), kurierzy (Paczkomat, kurier krajowy, przesyłka zagraniczna), wersja ERP. Ustalamy jedno źródło prawdy dla numeru zamówienia i stanu magazynowego — najczęściej jest to ERP, ale bywa, że numer nadaje sklep i ERP musi go przyjąć.
Etap 2 – mapowanie pól (tydzień 1–2). Powstaje tabela: pole sklepu → pole ERP → pole operatora płatności i kuriera. Sprawdzamy pola obowiązkowe: NIP do faktury, EAN, waga i wymiary paczki, kod punktu odbioru. Pominięcie wagi i wymiarów kończy się ręcznym uzupełnianiem dużej części zamówień w panelu kuriera.
Etap 3–4 – sandbox i testy (tydzień 2–4). Operatorzy płatności i kurierzy udostępniają środowiska testowe; ERP zwykle sandboxu nie ma, więc pracujemy na kopii bazy. Minimum 20 zamówień: 12 krajowych, 3 zagraniczne (inne stawki VAT, inny endpoint kuriera), 3 ze zwrotem, 2 anulowane po opłaceniu.
Etap 5–6 – produkcja i monitoring (tydzień 4–5). Wdrożenie we wtorek lub środę, poza szczytem sprzedażowym. Przez 30 dni codzienny przegląd logów, ze szczególnym uwzględnieniem poniedziałków i dni po zakończeniu promocji.
Etap 7 – dokumentacja i rollback. Punkt przywrócenia to kopia bazy, poprzednia wersja modułu oraz instrukcja wyłączenia webhooków w ciągu 2 minut. Szczegóły techniczne opisujemy w materiale o integracjach API, a różnice między wdrożeniami w poszczególnych miastach zbieramy w artykule o integracjach w Bydgoszczy.
| Tydzień | Zakres prac | Efekt |
|---|---|---|
| 1 | Inwentaryzacja systemów i wolumenów, ustalenie źródła prawdy | Lista pól i systemów do połączenia |
| 1–2 | Mapowanie pól sklep → ERP → płatności → kurier | Zatwierdzona tabela mapowania |
| 2–4 | Sandbox operatorów, testy na 20+ zamówieniach | Raport z testów, lista poprawek |
| 4–5 | Wdrożenie produkcyjne poza szczytem, monitoring 30 dni | Stabilna praca na produkcji |
| 5–6 | Dokumentacja i punkt rollbacku | Instrukcja wyłączenia w 2 minuty |
Większość awarii integracji nie wynika z błędów w kodzie, a z założeń przyjętych przed pierwszym commitem. Cztery najczęstsze pułapki:
Test przed wdrożeniem: podwójne kliknięcie „zapłać”, przerwanie połączenia w połowie transakcji oraz ponowne użycie tego samego numeru przesyłki. Trzy scenariusze, kilkanaście minut pracy, a eliminują najdroższe błędy. Kontekst całego projektu znajdziesz w opracowaniu o tym, co i jak łączymy w integracjach ERP, płatności i kurierów.
| Scenariusz testowy | Oczekiwany wynik |
|---|---|
| To samo zdarzenie webhooka wysłane 3 razy | 1 zamówienie w ERP, brak duplikatu |
| Podwójne kliknięcie „zapłać” | 1 transakcja, brak drugiego obciążenia |
| Przerwanie połączenia w połowie transakcji | Zamówienie w statusie wymagającym weryfikacji, nie „opłacone” |
| Ponowne użycie tego samego numeru przesyłki | Czytelny błąd operatora i komunikat dla obsługi |
Klucze API. Klucze i tokeny trzymamy poza repozytorium — w zmiennych środowiskowych lub menedżerze sekretów. Jeśli klucz kiedykolwiek trafił do gita, traktujemy go jako spalony i rotujemy, nawet jeśli repozytorium jest prywatne. Rotacja co 90 dni, osobne klucze dla sandboxu i produkcji. Klucz produkcyjny nie może być tym samym kluczem, na którym robiliśmy testy.
Zakres danych. Do operatora płatności trafia kwota, waluta, identyfikator zamówienia i e-mail; do kuriera — imię, nazwisko, adres, telefon i e-mail. To dane osobowe, więc potrzebna jest umowa powierzenia przetwarzania z każdym operatorem. Warto sprawdzić, czy nie wysyłamy pól zbędnych, np. NIP-u do kuriera — im mniej danych wyjdzie poza sklep, tym prostsza jest dokumentacja.
Retencja logów. Logi integracyjne trzymamy 30–90 dni, potem je usuwamy. Anonimizacja: skrót (hash) e-maila i numeru telefonu, obcięcie adresu IP, brak pełnych payloadów płatności. Numeru karty i CVV nie logujemy nigdy, niezależnie od tego, kto o to prosi.
Dostępy. Konta imienne, 2FA, konto techniczne z minimalnym zakresem uprawnień i bez dostępu do panelu administratora. W WooCommerce generuj osobne klucze API z uprawnieniami tylko do odczytu lub zapisu — zgodnie z dokumentacją WooCommerce — a nie konto głównego administratora. W PrestaShop analogicznie: osobne konto webservice, nie konto właściciela sklepu. Konto techniczne powinno mieć prawo wyłącznie do tych zasobów, których integracja naprawdę dotyka.
Podpisanie umowy na wdrożenie bez ustalenia opieki to odroczenie kosztu, nie oszczędność. Pierwszy tydzień na produkcji generuje zwykle od trzech do ośmiu zgłoszeń. Bez SLA każde z nich ląduje bezpośrednio na biurku właściciela firmy, a on nie ma jak sprawdzić, czy problem leży w sklepie, w ERP, czy u kuriera.
Czas reakcji to nie czas naprawy. Te dwa parametry muszą być zapisane osobno. Czas reakcji to potwierdzenie zgłoszenia i wstępna diagnoza — realnie 2–4 godziny w dni robocze. Czas naprawy to przywrócenie działania — dla zgłoszeń krytycznych (płatności nie księgują się, etykiety się nie generują) 8 godzin, dla pozostałych 2–3 dni robocze. Umowa z samym czasem reakcji jest nieegzekwowalna: wykonawca odpowie w 15 minut i nie zrobi nic przez tydzień. Dopiszcie też klasyfikację P1/P2/P3 i sposób jej ustalania, żeby nie było sporu, czy brak numeru listu przewozowego to P1, czy P3.
Zakres monitoringu. Cztery obszary, które trzeba objąć alertami: kolejka zamówień (alert, gdy najstarsze nieprzetworzone zamówienie ma więcej niż 15 minut), nieudane webhooki — ponowienia i kolejka wiadomości, które nie przeszły po trzech próbach, błędy generowania etykiet oraz rozjazd stanów magazynowych między sklepem a ERP. Ten ostatni wychodzi najczęściej dopiero przy inwentaryzacji, więc warto ustawić alert przy różnicy powyżej 2% lub kilku sztuk na jednym SKU. Przy webhookach warto znać podstawy kodów odpowiedzi HTTP, bo 4xx i 5xx wymagają zupełnie innej reakcji — punkt wyjścia znajdziesz w dokumentacji protokołu HTTP w MDN Web Docs.
Raport miesięczny powinien zawierać: liczbę incydentów z podziałem na P1/P2/P3, średni czas naprawy, przyczynę źródłową każdego P1 oraz plan działania na kolejny miesiąc. Bez tego nie wiesz, czy system się psuje, czy tylko hałasuje.
Bezpośredni kontakt z deweloperem skraca naprawę o godziny. Model przez pośredników (kierownik projektu, potem dział techniczny, potem podwykonawca) dodaje dwie–trzy iteracje zanim ktoś dotknie kodu. Przy zgłoszeniu płatności, które nie księgują się od 9:00, to różnica między porankiem a popołudniem.
| Parametr | Przykładowa wartość w umowie | Co się dzieje bez zapisu |
|---|---|---|
| Czas reakcji | 2–4 h w dni robocze dla P1 | Zgłoszenie leży bez potwierdzenia |
| Czas naprawy | 8 h dla P1, 2–3 dni dla P2 | Wykonawca odpowiada, ale nikt nie naprawia |
| Monitoring kolejki zamówień | Alert przy zaległości > 15 min | Zamówienia zatrzymują się na weekend |
| Kolejka nieudanych webhooków | Alert po 3 nieudanych próbach | Płatność pobrana, zamówienie nie powstało |
| Raport miesięczny | Liczba incydentów, MTTR, przyczyny | Brak wiedzy, czy system się psuje |
Nie musisz szukać wykonawcy integracji w promieniu 20 km od Bydgoszczy. Wdrożenie i tak dzieje się na serwerze, w API i w bazie danych, a nie w sali konferencyjnej. Pytanie brzmi więc nie „skąd jest wykonawca”, tylko „kto odbierze telefon w środę o 8:15, gdy padnie księgowanie płatności”.
Jak wygląda typowy model pracy. Start: warsztat online (60–90 minut), na którym ustalacie zakres — ile zamówień na dobę, jaka płatność, jaki kurier, jaki ERP. Dalej wspólny kanał komunikacji, np. Slack, Teams albo nawet zwykły wątek mailowy z tematem projektu, plus lista zadań z deadline'ami. Odbiór: testy na kopii sklepu (staging), lista scenariuszy — zamówienie opłacone, zamówienie za pobraniem, zwrot, anulowanie, zamówienie zagraniczne. Każdy scenariusz przechodzi z jedną osobą z Twojej strony, która kliknie to sama, a nie tylko obejrzy zrzut ekranu.
Przekazanie dostępów bez wysyłania haseł mailem. Praktyka, która sprawdza się najlepiej: hasła przez menedżer haseł z linkiem jednorazowym (Bitwarden, 1Password), a do integracji osobne konta techniczne z minimalnymi uprawnieniami — konto API tylko do odczytu zamówień, oddzielne klucze kurierskie w trybie testowym, konto w ERP z ograniczeniem do dokumentów sprzedaży. Po wdrożeniu rotacja kluczy i usunięcie kont tymczasowych. Jeśli wykonawca prosi o hasło do głównego administratora „na wszelki wypadek”, to sygnał ostrzegawczy.
Odległość a dostępność. Technicznie nie ma znaczenia. Ma znaczenie po starcie: czy wykonawca pracuje w tej samej strefie czasowej, czy ma jasno zapisany kanał zgłoszeń i czy jego czas naprawy nie rośnie, gdy trzeba jechać na miejsce. Większość incydentów w integracjach to i tak zmiany po stronie API kuriera albo płatności — do diagnozy wystarczy zdalny dostęp do logów.
Punkt wyjścia: integracje API oraz artykuł integracje z ERP, płatnościami i kurierami w Bydgoszczy.
Zanim wyślesz zapytanie „ile to kosztuje”, przygotuj dwie liczby: ile zamówień obsługujesz dziennie w szczycie i ile z nich wymaga ręcznego przepisania między systemami. Wykonawca, który nie zada tych pytań, wyceni projekt w ciemno.
Co przygotowuje klient przed startem:
Co leży po stronie wykonawcy: mapowanie pól, obsługa błędów i ponowień, logi z możliwością filtrowania po numerze zamówienia, dokumentacja powdrożeniowa (co robić przy konkretnym błędzie), testy na stagingu oraz szkolenie z podstaw obsługi, np. ręczne ponowienie wysyłki webhooka.
Pytania do wykonawcy:
Zamiast pytać o cenę, wyślij zakres: sklep, ERP, operator płatności, dwóch kurierów, liczba zamówień na dobę, czy potrzebne faktury automatyczne. Na tej podstawie da się podać widełki w godzinach i realny termin startu.
Brak mapowania statusów zamówień między sklepem, ERP i kurierem – każdy system mówi innym językiem.
Jak wykryć: Weź 10 ostatnich zamówień i rozpisz obok siebie status w sklepie, w ERP i u kuriera. Jeśli nie da się tego zrobić bez zgadywania, mapowanie nie istnieje.
Jak naprawić: Zrób tabelę mapowania 1:1 (np. opłacone → do realizacji → przekazane kurierowi → doręczone → zwrot) i wpisz ją do dokumentacji projektu, zanim ktokolwiek zacznie pisać kod.
Wdrożenie bezpośrednio na produkcji, bez środowiska testowego i bez zestawu zamówień testowych.
Jak wykryć: Zapytaj wykonawcę, gdzie będą robione testy. Odpowiedź „na sklepie, po godzinach” oznacza, że sandbox nie został użyty.
Jak naprawić: Ustal z góry zestaw minimum 20 zamówień testowych: krajowe, zagraniczne, zwrot, anulowanie, płatność nieudana. Bez tego zestawu wdrożenie nie jest zakończone.
Brak idempotencji – ten sam webhook płatności przychodzi dwa razy i powstają dwie faktury lub dwa stany magazynowe.
Jak wykryć: W dokumentacji operatora płatności sprawdź, czy deklaruje powtórzenia powiadomień. Jeśli tak, a w projekcie nie ma unikalnego identyfikatora transakcji – problem jest przesądzony.
Jak naprawić: Wymagaj zapisu identyfikatora transakcji i sprawdzania go przed utworzeniem dokumentu. Powtórzone żądanie ma zostać odrzucone, nie przetworzone drugi raz.
Wybór wtyczki bez sprawdzenia, czy obsługuje niestandardowe pola z ERP i faktury korygujące.
Jak wykryć: Poproś o demo na Twoich danych: zamówienie z Twoim niestandardowym polem, np. numerem zamówienia klienta lub kodem kosztu. Jeśli wtyczka go gubi, nie nadaje się.
Jak naprawić: Jeśli wtyczka nie mapuje Twoich pól, policz koszt modułu na miarę i porównaj z kosztem pracy ludzi, którzy te pola uzupełniają ręcznie co miesiąc.
Pominięcie kosztu utrzymania – budżet kończy się na wdrożeniu, a nikt nie pilnuje aktualizacji API operatorów.
Jak wykryć: Zapytaj wprost: kto i za ile zareaguje, gdy operator płatności lub kurier zmieni wersję API albo wyłączy stary endpoint?
Jak naprawić: Rozdziel w budżecie kwotę wdrożenia od miesięcznego utrzymania obejmującego monitoring, poprawki po zmianach API i aktualizacje bezpieczeństwa.
Testy tylko na jednym scenariuszu – zwykłe zamówienie krajowe, opłacone, bez zwrotu i bez anulowania.
Jak wykryć: Sprawdź, czy w protokole testów są osobne pozycje dla zwrotu, anulowania, zamówienia zagranicznego i płatności odrzuconej przez bank.
Jak naprawić: Rozszerz listę testów i powtórz je po każdej zmianie. Zwrot i anulowanie to najczęstsze miejsce, w którym integracja rozjeżdża stany magazynowe.
Integracje z ERP, płatnościami i kurierami w Bydgoszczy dla firmy rozbij na trzy warstwy i wdrażaj je w kolejności: płatności, kurierzy, ERP. Największe ryzyko nie leży w samym kodzie, a w mapowaniu statusów, obsłudze powtórzonych webhooków i braku testów na zwrotach. Budżet podziel na wdrożenie i utrzymanie, a ofertę porównuj po zakresie godzin, nie po cenie całkowitej. Jeśli choć jeden z tych elementów jest nieustalony, wdrożenie jeszcze nie jest gotowe.
Od płatności, potem kurierzy, na końcu ERP. Płatności dają najszybszy efekt: mniej ręcznego sprawdzania przelewów i mniej pomyłek przy wysyłce. Kurierzy usuwają ręczne klepanie etykiet. ERP to najdroższa i najbardziej wymagająca warstwa, więc odkłada się ją do momentu, gdy wolumen zaczyna boleć.
Nie zawsze. Przy kilkunastu zamówieniach dziennie wymiana plików CSV przez FTP lub API plikowe w cyklu godzinowym często wystarcza. W czasie rzeczywistym warto iść wtedy, gdy stany magazynowe muszą być zgodne co do sztuki, np. przy sprzedaży tego samego towaru w kilku kanałach albo przy limitowanych partiach.
Policz to na własnych danych: pomnóż liczbę zamówień w miesiącu przez liczbę minut ręcznej pracy i pomnóż przez stawkę osoby, która to robi. Trwały rozjazd stanów magazynowych, faktury wystawiane po zamknięciu miesiąca i ręczne etykiety to sygnały, że proces już się nie skaluje, niezależnie od samej liczby zamówień.
To punkt, który trzeba rozstrzygnąć w ofercie, zanim cokolwiek ruszy. Środowisko testowe (staging) plus konta w sandboxie operatora płatności i kuriera to osobna praca i osobny koszt. Jeśli wykonawca zakłada to po stronie klienta, musi być to napisane wyraźnie, razem z informacją, kto utrzymuje to środowisko po wdrożeniu.
Integracja może przestać działać z dnia na dzień – zamówienia zostaną opłacone, ale system nie odnotuje płatności albo etykiety przestaną się generować. Dlatego monitoring i osoba odpowiedzialna za reakcję są częścią projektu, a nie dodatkiem. Warto ustalić z wykonawcą kanał i czas reakcji na taką zmianę. Podstawy komunikacji po HTTP opisuje dokumentacja MDN Web Docs – HTTP.
CSV wystarcza, gdy opóźnienie kilku godzin jest akceptowalne, a dane nie wymagają natychmiastowej spójności. Kolejka komunikatów ma sens, gdy zdarzenia przychodzą seriami, nie mogą zginąć i muszą być przetworzone w kolejności. Budowa kolejki tylko dlatego, że brzmi nowocześnie, to koszt bez zwrotu.
Poproś o protokół testów z minimum 20 zamówieniami obejmującymi zwrot, anulowanie i płatność nieudaną oraz o dokumentację mapowania statusów. Sprawdź, czy webhooki są zabezpieczone przed powtórzeniami i czy istnieje punkt rollbacku. Zajrzyj też do dokumentacji platformy, na której stoi sklep – dla PrestaShop to PrestaShop Developer Documentation, dla WooCommerce WooCommerce Documentation.
Jeśli chcesz sprawdzić, która warstwa integracji w Twoim sklepie jest pilna, a którą można spokojnie odłożyć, napisz do nas – przejrzymy obecny stack i powiemy wprost, co ma sens teraz. Zajrzyj też do Integracje z ERP, płatnościami i kurierami – co i jak.