Jak rozwiązać problem różnych numerów zamówień w marketplace i w ERP

Dlaczego numery zamówień z marketplace i ERP „nie chcą się zgadzać”

Sprzedawca, który wchodzi w sprzedaż na Allegro, Amazon czy innym marketplace, bardzo szybko orientuje się, że „numer zamówienia” nie jest pojęciem oczywistym. Klient podaje numer z Allegro, magazyn szuka po numerze WZ z ERP, księgowość mówi o numerze faktury, a integrator pokazuje jeszcze inne ID techniczne. Źródłem chaosu nie jest zła wola systemów, tylko zupełnie inne podejście do numeracji i momentu powstania zamówienia.

Jak działa numeracja zamówień po stronie marketplace

Marketplace (Allegro, Amazon, inne platformy) traktują zamówienie przede wszystkim jako zdarzenie na koncie kupującego. Kluczowe są dla nich identyfikatory techniczne, które mają być unikalne w skali całego serwisu i pozwalać na powiązanie wielu elementów: oferty, koszyka, płatności, dostawy.

Typowe cechy numerów zamówień na marketplace:

• Numer jest nadawany w momencie finalizacji koszyka – gdy kupujący klika „kupuję i płacę” lub odpowiednik.
• Identyfikator nie zmienia się i nie jest „ładny” – to zwykle długi ciąg znaków, czasem z myślnikami, bez nawiązań do roku, magazynu czy kanału.
• Marketplace używa wielu różnych ID – osobne ID zamówienia, ID oferty, ID płatności, czasem ID przesyłki czy pakietu wysyłkowego.
• Numer jest wspólny dla całego koszyka lub dla części koszyka – w zależności od sposobu implementacji (np. kilka sprzedających w jednym koszyku, różne dostawy).

Dla sprzedawcy ważne jest, że numer zamówienia w marketplace jest stabilnym punktem odniesienia przy obsłudze klienta, ale z punktu widzenia logistyki i księgowości jest zbyt „techniczny” i nie wspiera procesów wewnętrznych.

Jak ERP numeruje zamówienia sprzedaży

System ERP najczęściej działa według logiki księgowo-magazynowej, a nie „koszykowej”. Zamówienie sprzedaży w ERP jest dokumentem, który uruchamia cały ciąg kolejnych dokumentów: rezerwacje, WZ, PZ, faktury, korekty, dokumenty magazynowe między magazynami.

Typowe zasady numeracji zamówień w ERP:

• Sekwencje roczne lub miesięczne – np. ZAM/2024/000123, gdzie numer rośnie w ramach roku lub miesiąca.
• Serie dla oddziałów lub kanałów – np. ZAM/WWW/0001, ZAM/AL/0001, gdzie seria wskazuje źródło zamówienia.
• Powiązania z dokumentami magazynowymi i sprzedażowymi – WZ, faktura, korekta, które mogą mieć swoje własne numery i serie.
• Ograniczenia techniczne – maksymalna długość numeru, brak niektórych znaków (np. „/” lub „-”), konieczność używania wzorca.

ERP traktuje numer dokumentu jako element księgowy: musi być czytelny dla księgowości, łatwy do archiwizacji papierowej (jeśli jeszcze jest stosowana) i zgodny z przyjętą polityką numeracji w firmie. To często stoi w sprzeczności z numerami marketplace.

Różne momenty powstania zamówienia = różne numery

Rozjazdy numerów zamówień mają źródło w tym, że dla marketplace i ERP „zamówienie” powstaje w innym momencie procesu:

• Marketplace – w momencie złożenia koszyka i akceptacji płatności (lub zobowiązania do zapłaty).
• ERP – w momencie, gdy zamówienie zostaje zaimportowane lub ręcznie wprowadzone do systemu.

Między tymi dwoma momentami może minąć kilka sekund, ale też kilka godzin. W tym czasie dane mogą się zmienić (np. klient poprawi adres, anuluje zamówienie, marketplace podzieli przesyłkę). Efekt: jedno zamówienie z punktu widzenia klienta może odpowiadać kilku dokumentom w ERP, a systemy nie mają naturalnego „wspólnego numeru”, który by te światy spinał.

Kiedy różne numery zamówień zaczynają naprawdę boleć

Na początku, przy małej skali, różne numery zamówień nie wydają się dużym problemem. Ktoś z obsługi klienta ręcznie wyszukuje zamówienie po nazwisku lub mailu, magazyn sprawdza po adresie, a właściciel firmy jeszcze wszystko pamięta. Problemy rosną lawinowo, gdy:

• wchodzi drugi, trzeci marketplace, a do tego własny sklep internetowy,
• pojawiają się zwroty i reklamacje, które trzeba szybko kojarzyć z historią zamówienia,
• rosną wolumeny i kilka osób jednocześnie obsługuje ten sam kanał sprzedaży,
• wdrażane są automaty do wysyłek, paczkomatów, etykiet kurierskich.

Typowy scenariusz: klient dzwoni i podaje numer zamówienia z Allegro. Pracownik BOK nie ma prostego sposobu, by po tym numerze znaleźć zamówienie w ERP, bo numer z marketplace nie jest nigdzie wprowadzony lub jest w polu „Uwagi” mimochodem. Zaczyna się żmudne szukanie po nazwisku, mailu, kwocie. Każdy taki kontakt kosztuje czas i psuje wrażenie profesjonalizmu.

Minimalny słownik pojęć – żeby wszyscy mówili o tym samym

Bez prostego, wspólnego języka wewnątrz firmy większość rozmów o numerach zamówień zamienia się w nieporozumienia. Jedna osoba mówi o „zamówieniu z Allegro”, druga o „dokumencie sprzedaży”, trzecia o „fakturze” – i każda ma na myśli coś innego.

Zamówienie marketplace, zamówienie w ERP, dokument magazynowy, faktura

W typowej firmie funkcjonuje kilka warstw „zamówienia”:

• Zamówienie marketplace – to, co widzi klient w panelu Allegro/Amazon: lista produktów, sposób dostawy, kwota, numer nadany przez marketplace. Zwykle oznaczone jako „zamówienie”, „order”, czasem „transakcja”.
• Zamówienie sprzedaży w ERP – dokument wewnętrzny, z którego wynika rezerwacja towaru, wystawienie WZ, później faktury. Ma numer nadany przez ERP zgodnie z seriami i sekwencją.
• Dokument magazynowy – WZ, RW, MM, PZ i inne, które odzwierciedlają ruch towaru. Mogą mieć inne numery niż zamówienie sprzedaży, zwłaszcza gdy zamówienie jest dzielone na kilka dostaw.
• Faktura/paragon – dokument sprzedażowy dla klienta, zwykle ma swoją, niezależną numerację księgową. Nie należy mylić numeru faktury z numerem zamówienia.

W wielu procesach firma operuje trzema równoległymi numerami dla „tego samego” zamówienia: numer marketplace, numer zamówienia sprzedaży w ERP, numer faktury. Jeśli nie zostanie to jasno nazwane i zmapowane, pracownicy zaczynają używać ich zamiennie, co prowadzi do pomyłek.

ID techniczne, numery zewnętrzne, referencje

Dodatkową warstwę komplikacji wprowadzają ID techniczne i referencje zewnętrzne, którymi posługują się integratory i systemy pośredniczące:

• ID techniczne – wewnętrzne identyfikatory w bazie danych (np. „order_id” w tabeli integratora), często liczby całkowite, nieprzydatne dla człowieka.
• Numer zewnętrzny – numer nadany przez inny system, traktowany jako odniesienie (np. numer zamówienia Allegro zapisany jako „numer obcy” w ERP).
• Referencja – dodatkowe pole używane do powiązania kilku systemów, np. „ExternalRef”, „MarketplaceRef”. Może zawierać numer marketplace, numer integratora albo ich kombinację.

Dobra praktyka to jasne rozróżnienie w nazewnictwie i w polach w ERP/integratorze: jedno pole na ID marketplace, inne na ID płatności, jeszcze inne na numer dokumentu ERP. Mieszanie tych dwóch światów w jednym polu „Uwagi” kończy się bałaganem w momencie pierwszej większej awarii lub migracji danych.

Numer zamówienia, numer transakcji płatniczej, numer przesyłki

Klient bardzo często używa pojęcia „numer zamówienia” w odniesieniu do dowolnego numeru, który widzi w swoim panelu lub mailu. Dla systemów te numery są zupełnie inne:

• Numer zamówienia – identyfikator zdarzenia zakupowego (koszyka) na marketplace lub dokumentu sprzedaży w ERP.
• Numer transakcji płatniczej – identyfikator w systemie płatności (np. PayU, Przelewy24, Amazon Payments). Potrzebny głównie księgowości i przy wyjaśnianiu sporów płatniczych.
• Numer przesyłki – numer nadawczy kuriera, paczkomatu, Poczty Polskiej. Kluczowy dla śledzenia paczki, ale nie informuje o zawartości czy kwocie.

Bez ustalenia, który numer jest który, łatwo dojść do absurdalnych sytuacji, w których BOK szuka zamówienia po numerze przesyłki w ERP, księgowość próbuje rozliczyć fakturę na podstawie numeru paczki, a magazyn w ogóle nie wie, o jakim zamówieniu mowa.

Prosta „legenda” numerów na użytek firmy

Nawet w małej firmie opłaca się przygotować krótką, jedno- lub dwustronicową „legendę numerów” i omówić ją z zespołem. W praktyce wystarczy:

• zdefiniować 3–4 najważniejsze typy numerów (zamówienie marketplace, zamówienie ERP, faktura, przesyłka),
• pokazać na jednym ekranie lub wydruku, gdzie każdy z tych numerów znajduje się w systemach,
• uzgodnić, jakimi nazwami posługują się pracownicy w rozmowach (np. „numer Allegro”, „numer zamówienia ERP”, „numer przesyłki”).

Taki prosty dokument minimalizuje napięcia i skraca czas szkoleń nowych osób – zwłaszcza w BOK i magazynie, gdzie rotacja bywa największa.

Główne źródła problemu różnych numerów zamówień

Różne systemy oznaczają to samo zdarzenie innymi numerami – to fakt. Kluczowe pytanie brzmi: dlaczego w niektórych firmach to działa płynnie, a w innych zamienia się w chaos? Różnica zwykle wynika z architektury integracji i sposobu pracy z danymi.

Trzy poziomy numeracji: marketplace, integrator, ERP

W wielu środowiskach występują aż trzy warstwy numerów:

• Numer marketplace – ID/Order ID Allegro, Amazon itd.
• Numer integratora – numer zamówienia lub ID w systemie pośredniczącym (aplikacja SaaS, integracja plikowa, własne API).
• Numer ERP – numer zamówienia sprzedaży w systemie księgowo-magazynowym.

Jeżeli integrator nie przechowuje mapowania „marketplace → ERP” lub robi to w sposób nieprzejrzysty, bardzo łatwo traci się kontrolę. Każde ponowne pobranie zamówienia może utworzyć nowy dokument w ERP z innym numerem, mimo że to ten sam koszyk klienta. W efekcie:powstają duplikaty, błędne wysyłki, a czas poświęcony na ręczne wyjaśnienia rośnie.

Ręczne przepisywanie zamówień – najszybsza droga do chaosu

Na początku działalności częstą praktyką jest ręczne przepisywanie zamówień z panelu marketplace do ERP. Czyli: pracownik loguje się do Allegro lub Amazona, przepisuje dane kupującego, produkty, kwoty i tworzy zamówienie w ERP. Numer Allegro trafia czasem do pola „Uwagi”, czasem w ogóle nie jest zapisywany.

Konsekwencje:

• Pomyłki w danych – literówki w nazwiskach, błędne kody pocztowe, pomylone warianty produktów.
• Brak spójności numerów – dla części zamówień numer Allegro jest zapisany, dla innych nie; nie ma reguły.
• Duplikaty – przy poprawkach lub reklamacjach pracownik wprowadza zamówienie jeszcze raz, bo nie znajduje poprzedniego.
• Ogromny koszt czasu – przy kilkudziesięciu zamówieniach dziennie ręczne przepisywanie pochłania całe etaty.

Ręczne przepisywanie może mieć sens na samym starcie (kilka zamówień tygodniowo), ale przy rosnącej skali przestaje być taną metodą – łączny koszt pracy i liczby pomyłek przewyższa koszt prostego integratora.

Różne formaty numerów i ograniczenia ERP

Systemy marketplace często generują długie, alfanumeryczne identyfikatory z myślnikami, literami, czasem znakami specjalnymi. ERP bywa dużo bardziej konserwatywne: dopuszcza tylko cyfry, ew. kilka liter i separatorów. Standardowe problemy:

• ERP nie przyjmuje myślników, a numer z marketplace je zawiera.
• Długość numeru jest ograniczona do np. 20 znaków, a ID marketplace jest dłuższe.
• ERP nie pozwala na niektóre znaki, które mogą wystąpić w ID zewnętrznym.

Bez przemyślanego mapowania pojawiają się dziwne obejścia: obcinanie numeru, usuwanie znaków, zastępowanie liter. W efekcie część numerów nie zgadza się 1:1 z platformą – pracownik wpisuje numer z Allegro, ERP pokazuje nic, bo przechowuje skróconą wersję.

Jedno zamówienie marketplace, kilka dokumentów w ERP

Rozbijanie jednego koszyka na kilka dokumentów

Z punktu widzenia klienta „zamówienie” to jeden koszyk. W ERP ten sam koszyk może wygenerować kilka różnych dokumentów, każdy z własnym numerem:

• jedno zamówienie sprzedaży,
• dwie WZ-ki (bo część towaru jest na innym magazynie lub dochodzi później),
• dwie faktury (np. osobno towar i usługa montażu, albo osobno część wysłana dziś i część za tydzień).

Jeżeli systemy nie zapisują wyraźnie, że wszystkie te dokumenty dotyczą jednego numeru marketplace, po kilku miesiącach nikt już nie pamięta, skąd się wzięły „połówkowe” faktury. BOK szuka po numerze Allegro, księgowość ma tylko numery faktur, a magazyn żyje swoimi WZ-kami.

Prosty, tani sposób, żeby nad tym zapanować:

• w każdym dokumencie ERP (WZ, faktura, korekta) zapisać oryginalny numer marketplace w dedykowanym polu „Numer zewnętrzny”,
• przy rozbijaniu zamówienia dopisywać w ERP, że jest to „część 1/2”, „część 2/2” – nawet ręcznie, jeśli nie da się tego zautomatyzować.

Przy reklamacji pracownik wpisuje numer z Allegro i od razu widzi wszystkie powiązane dokumenty w ERP. Oszczędność czasu jest dużo większa niż koszt jednorazowego dopracowania szablonów dokumentów.

Korekty, zwroty, ponowne wysyłki

Drugi klasyczny generator bałaganu to zwroty i korekty. Jedno zamówienie marketplace, a w ERP:

• pierwotna faktura,
• dokument przyjęcia zwrotu (PZ, PW),
• faktura korygująca,
• kolejna WZ i faktura na ponowną wysyłkę.

Jeżeli każdy z tych dokumentów ma „swój” numer i brak wspólnej osi (marketplace ID), śledzenie historii klienta przeradza się w archeologię. Z punktu widzenia efektywności lepiej potraktować numer marketplace jako „główne drzewo”, a wszystkie korekty jako gałęzie:

• każda korekta ma obowiązkowo wypełnione pole „Numer zamówienia marketplace”,
• w opisach/komenatrzach stosuje się spójne schematy, np. „Korekta do zam. Allegro: [NUMER]”.

To niski koszt konfiguracji i krótkiego przeszkolenia, a w zamian tygodnie zaoszczędzone przy audytach i kontrolach zwrotów.

Integracje typu „półautomat” i import plików

Między ręcznym przepisywaniem a pełnym API jest spora szara strefa: importy CSV, integracje przez pliki XML, małe wtyczki. Technicznie przyspieszają pracę, ale często ignorują temat mapowania numerów.

Typowe problemy przy takich rozwiązaniach:

• import tworzy zamówienia w ERP, ale nie zapisuje numeru marketplace w żadnym stabilnym polu,
• przy ponownym imporcie (np. po błędzie) ten sam plik generuje drugi raz to samo zamówienie, bo brak unikalnego klucza,
• pliki z Allegro/Amazona mają inne nazwy kolumn po aktualizacji, a integrator „gubi” numer zamówienia.

Przy budżetowych integracjach opłaca się poświęcić parę godzin na prostą zasadę: numer marketplace = klucz unikalny. Czyli:

• zamówienie w ERP może powstać tylko raz dla danego numeru marketplace,
• przy kolejnych importach system aktualizuje istniejący dokument (np. status płatności, adres), a nie tworzy nowy.

Często wystarczy jedna prosta reguła w integratorze („przed utworzeniem zamówienia sprawdź, czy istnieje rekord z tym numerem”); koszt wdrożenia niewielki, a skala oszczędności przy kilku tysiącach zamówień rocznie ogromna.

Jak zaplanować strukturę numerów zamówień z głową (i tanio)

Większość firm nie ma wpływu na sposób nadawania numerów przez marketplace, ale ma pełną kontrolę nad tym, jak wyglądają numery dokumentów w ERP i integratorze. Zamiast przerabiać wszystko po roku działania, lepiej ułożyć kilka prostych zasad od razu.

Separacja numerów wewnętrznych i zewnętrznych

Pierwsza decyzja: które numery są „dla ludzi z zewnątrz” (klient, kurier, marketplace), a które tylko „dla nas” (ERP, magazyn). Najbardziej praktyczny schemat:

• numer zewnętrzny główny – numer zamówienia marketplace; nie zmieniamy go, zapisujemy go w ERP 1:1,
• numer wewnętrzny główny – numer zamówienia sprzedaży w ERP (serie, rok, sekwencja),
• numery dokumentów podrzędnych – WZ, faktury, korekty, powiązane zawsze z numerem wewnętrznym i zewnętrznym.

Struktura może być bardzo prosta. Nie trzeba od razu budować skomplikowanych schematów, ważne, by każdy typ numeru miał swoje „miejsce” w systemie i jasną nazwę.

Logiczne serie numeracyjne w ERP

ERP zazwyczaj umożliwia tworzenie serii numeracyjnych. Można to wykorzystać, żeby bez drogich modyfikacji odróżnić sprzedaż marketplace od innych kanałów. Przykładowo:

• ZS/A/2026/000123 – zamówienie sprzedaży z Allegro,
• ZS/S/2026/000456 – zamówienie ze sklepu internetowego (shop),
• ZS/H/2026/000789 – zamówienie hurtowe (B2B).

Taka struktura:

• nie wymaga zmian po stronie marketplace,
• ułatwia raportowanie (sprzedaż kanałami bez żadnych filtrów dodatkowych),
• ułatwia pracę BOK („jak widzisz ZS/A, to od razu wiesz, że szukasz numeru marketplace w konkretnym polu”).

Większość prostych ERP i tak obsługuje serie, więc koszt wdrożenia ogranicza się do konfiguracji i szkolenia zespołu.

Numer obcy / numer referencyjny jako „most” do marketplace

W wielu systemach istnieje pole typu „numer obcy”, „ref. zewnętrzna” albo „opis”. Bardzo często używa się go losowo: raz na NIP, raz na numer przesyłki, raz na hasło klienta. Z punktu widzenia porządku i tańszego wsparcia technicznego lepiej narzucić jedną, prostą zasadę:

• w polu „numer obcy” przy zamówieniach marketplace jest <strongzawsze numer zamówienia z Allegro/Amazon/eBay,
• wszystkie inne identyfikatory (NIP, numer przesyłki, numer płatności) mają swoje dedykowane pola albo trafiają do „Uwagi”.

To nie wymaga żadnych rozbudowanych integracji – wystarczy, aby integrator wstawiał numer marketplace właśnie w to pole (albo żeby pracownik wpisywał go w to pole ręcznie, jeśli na razie nie ma automatyzacji). Po kilku tygodniach zespół przyzwyczaja się, że „numer obcy = numer marketplace” i chaos znika.

Minimalistyczne oznaczanie dokumentów powiązanych

Pełne modelowanie relacji pomiędzy wszystkimi dokumentami (drzewka, grafy) bywa drogie. Na start wystarczą trzy proste zasady, które można ustawić w większości ERP bez programisty:

1. WZ zawsze dziedziczy numer obcy z zamówienia sprzedaży.
2. Faktura zawsze dziedziczy numer obcy z dokumentu źródłowego (zamówienia lub WZ).
3. Korekta dziedziczy numer obcy z faktury korygowanej.

Dzięki temu numer marketplace „przechodzi” przez cały łańcuch dokumentów bez dodatkowych operacji. W skali roku przy kilku tysiącach zamówień oszczędza to dziesiątki godzin na ręcznym szukaniu „po historii” w systemie.

Rezerwacja zakresów numerów – kiedy ma sens

Zaawansowane wdrożenia stosują mechanizmy rezerwacji zakresów numerów (np. integrator „rezerwuje” numery faktur przed ich utworzeniem). W małej i średniej firmie często jest to przerost formy nad treścią i niepotrzebny koszt.

Czy warto w to inwestować? Tylko w dwóch sytuacjach:

• gdy jest kilka równoległych źródeł dokumentów (np. kilka magazynów wystawia faktury w tym samym ERP i trzeba uniknąć konfliktów),
• gdy istnieją twarde, wewnętrzne wymogi ciągłości numeracji dla danego typu dokumentu (np. specyficzne branże regulowane).

W pozostałych przypadkach wystarczy, że:

• numery nadaje ERP w momencie tworzenia dokumentu,
• integrator przekazuje tylko powiązania (ID marketplace ←→ ID ERP), bez zarządzania numeracją.

To sporo tańsze, prostsze w utrzymaniu i dużo mniej wrażliwe na błędy sieci czy restarty integratora.

Mapowanie numerów zamówień: praktyczny schemat i przykłady

Nawet przy prostym przepływie danych przydaje się jasny model: skąd, dokąd i który numer idzie. Nie chodzi o skomplikowaną dokumentację, tylko o kilkanaście wierszy w tabeli, na której można oprzeć integrację i szkolenie ludzi.

Prosty model mapowania: tabela powiązań

Najbardziej praktyczne rozwiązanie to osobna tabela (w integratorze lub ERP), która przechowuje powiązania numerów. Każdy wiersz odpowiada jednemu zamówieniu marketplace i zawiera co najmniej:

• ID marketplace (np. OrderId z Allegro),
• ID zamówienia sprzedaży w ERP,
• datę utworzenia,
• aktualny status (np. „nowe”, „zrealizowane”, „anulowane w marketplace”).

Rozszerzona wersja może dodawać:

• ID płatności,
• numery WZ,
• numery faktur powiązanych,
• numery przesyłek.

Najważniejsze, żeby wszystkie systemy odnosiły się do jednego „źródła prawdy”. Gdy magazyn dzwoni do BOK i podaje numer WZ, osoba przy telefonie jednym kliknięciem przechodzi z WZ do tej tabeli mapowań i widzi numer marketplace, faktury i paczki.

Jednokierunkowy vs dwukierunkowy przepływ numerów

Podstawowy dylemat przy projektowaniu integracji: czy numery „płyną” tylko z marketplace do ERP, czy też ERP może coś „odesłać” z powrotem. Z perspektywy kosztu wdrożenia i utrzymania:

• Jednokierunkowo (taniej) – marketplace → integrator → ERP. Numery dokumentów ERP pozostają w ERP, a marketplace ich nie zna. W praktyce wystarcza większości firm, o ile BOK sprawnie korzysta z mapowania.
• Dwukierunkowo (drożej) – ERP odsyła numery faktur, WZ, a nawet statusy przesyłek do marketplace. Wymaga lepszej integracji, ale zmniejsza liczbę zapytań od klientów, bo mają więcej informacji w panelu.

Na start zwykle wystarcza wariant jednokierunkowy z dobrze opisanym mapowaniem. Dwukierunkowy przepływ można wdrażać etapami, zaczynając np. tylko od przesyłek (status i numer paczki).

Przykład: Allegro → integrator plikowy → prosty ERP

Dla małej firmy, która nie chce inwestować w rozbudowane API, daje się ułożyć tani, ale sensowny schemat:

1. Raz na X minut integrator pobiera plik CSV z Allegro z nowymi zamówieniami.
2. Dla każdego wiersza sprawdza w swojej tabeli, czy OrderId już istnieje:
   • jeśli tak – aktualizuje dane (np. status płatności),
   • jeśli nie – tworzy nowy rekord mapowania i generuje import do ERP.
3. ERP po imporcie odsyła w pliku zwrotnym numery swoich dokumentów (ID wewnętrzne).
4. Integrator dopisuje ID ERP do wiersza z danym OrderId.

W efekcie:

• nie ma duplikatów (bo numer z Allegro jest kluczem unikalnym),
• po numerze marketplace można dojść do numeru w ERP i odwrotnie,
• całość opiera się na prostych plikach i jednej tabeli w bazie – koszt realizacji niewielki, nawet u przeciętnego freelancera.

Przykład: kilka marketplace, jeden ERP

Gdy firma sprzedaje na kilku platformach, przydaje się jeden wspólny model mapowania. Można to zrobić w dość prosty sposób, dodając kolumnę „Źródło”:

• Źródło = ALLEGRO, ID_zew = numer zamówienia Allegro,
• Źródło = AMAZON, ID_zew = AmazonOrderId,
• Źródło = EMAG, ID_zew = ich ID zamówienia itd.

Dzięki temu tabela mapowania staje się centralnym rejestrem zamówień ze wszystkich marketplace, a ERP i BOK nie muszą „zgadywać”, skąd pochodzi konkretne zamówienie. Koszt dodatkowy to jedna kolumna w bazie i kilka reguł w integratorze, a korzyść – uporządkowany widok całej sprzedaży.

Strategia na zmiany formatów numerów

Marketplaces lubią zmieniać format swoich identyfikatorów (dodają prefiksy, wydłużają ciąg, zmieniają typ). Jeśli system ERP ma ścisłe ograniczenia co do długości czy znaków, wystarczy niewielka zmiana po stronie marketplace, żeby integracja zaczęła „ucinać” numery.

Najbezpieczniejsza i najtańsza strategia:

Najczęściej zadawane pytania (FAQ)

Dlaczego numer zamówienia z Allegro/Amazon nie zgadza się z numerem w ERP?

Marketplace i ERP „widzą” zamówienie w innym momencie procesu i nadają mu własne numery według różnych zasad. Allegro czy Amazon tworzą numer w chwili złożenia koszyka i płatności, natomiast ERP dopiero wtedy, gdy zamówienie zostanie do niego zaimportowane lub wprowadzone ręcznie.

Do tego marketplace używa zwykle długich, technicznych identyfikatorów, a ERP numerów księgowo‑magazynowych (serie, lata, kanały sprzedaży). Efekt jest taki, że jedno zamówienie klienta może odpowiadać kilku dokumentom w ERP, z zupełnie innymi numerami.

Jak powiązać numer zamówienia z marketplace z numerem w ERP, żeby dział obsługi nie tracił czasu?

Najprostsze i najtańsze rozwiązanie to zapisywanie numeru zamówienia marketplace w dedykowanym polu w ERP (np. „Numer obcy”, „Referencja zewnętrzna”) przy każdym imporcie. Dzięki temu BOK może wyszukiwać po numerze z Allegro/Amazon bez ręcznego przeklikiwania.

Jeśli Twój ERP nie ma takiego pola, minimalny wariant „na start” to konsekwentne używanie jednego, jasno opisanego pola tekstowego (np. „Uwagi z marketplace”), ale zawsze w tym samym formacie. Warto też ustalić z integratorem, żeby ten numer był kopiowany automatycznie, a nie dopisywany ręcznie przez pracowników.

Co wpisać w ERP jako numer zewnętrzny: numer zamówienia, płatności czy przesyłki?

Jako główną referencję zamówienia z marketplace najlepiej zapisywać numer zamówienia z Allegro/Amazon, bo to po nim najczęściej dzwoni klient. Numery płatności i przesyłek dobrze trzymać w osobnych polach, jeśli ERP na to pozwala.

Jeżeli system masz mocno ograniczony, a tylko jedno pole „na coś zewnętrznego”, priorytet wygląda zwykle tak: 1) numer zamówienia marketplace, 2) ewentualnie dopisany po separatorze numer przesyłki. Numer transakcji płatniczej jest bardziej przydatny księgowości niż obsłudze klienta, więc można go przechowywać w systemie płatności lub raporcie, a niekoniecznie w ERP.

Jak uprościć pracę z wieloma numerami: zamówienie, WZ, faktura, numer paczki?

Kluczowe jest ustalenie prostego, wewnętrznego „słownika” i trzymanie się go. Każdy dokument dostaje swoją rolę: numer marketplace służy do kontaktu z klientem, numer zamówienia w ERP do logistyki, numer WZ do magazynu, numer faktury do księgowości, numer przesyłki do śledzenia paczki.

Aby zmniejszyć chaos przy małym budżecie, wystarczy:

• spisać na jednej stronie, jakie numery istnieją i do czego służą,
• ustalić, w których polach ERP zapisuje się które numery,
• przeszkolić BOK i magazyn na krótkim, 30‑min spotkaniu z przykładami realnych zamówień.

To taniej niż poprawianie błędów przy reklamacjach i zagubionych przesyłkach.

Co zrobić, gdy klient podaje tylko numer z Allegro, a w ERP nie można po nim wyszukać?

Doraźnie zostaje szukanie po innych danych: mailu, nazwisku, kwocie zamówienia, adresie dostawy. To jednak kosztuje czas i nerwy, więc lepiej potraktować taki przypadek jako sygnał, że brakuje integracji numerów, a nie jako „normalny stan rzeczy”.

Najrozsądniejszy krok przy małym budżecie to:

• włączyć w integratorze lub ERP zapis numeru zamówienia marketplace w stałym polu,
• zrobić prostą instrukcję dla BOK: „jeśli klient podaje numer Allegro, wpisz go w filtr X”.

Po kilku dniach pracownicy sami zaczną zgłaszać, które pola i widoki w ERP warto jeszcze dostosować.

Czy trzeba zmieniać schemat numeracji w ERP pod marketplace?

Najczęściej nie ma sensu ruszać głównej numeracji ERP (serii, sekwencji rocznych) tylko po to, żeby „upodobnić” ją do marketplace. To ingerencja w obszar księgowo‑prawny, która rzadko zwraca się w postaci oszczędności czasu.

Zamiast tego taniej jest:

• dodać pola na numery zewnętrzne i referencje marketplace,
• oznaczyć w schemacie numeracji kanał (np. ZAM/AL/0001),
• zostawić pełną swobodę księgowości w numerach faktur.

Wspólny numer „łączy światy” przez pole referencji, nie przez zmianę całego systemu numeracji w ERP.

Jak nazwać pola w ERP i integratorze, żeby uniknąć bałaganu z ID i numerami?

Dobry, prosty podział to:

• Numer zamówienia ERP – oficjalny numer dokumentu sprzedaży w systemie,
• Numer zamówienia marketplace – dokładnie tak, jak nadaje go Allegro/Amazon,
• ID techniczne integratora – trzymane „pod spodem”, zwykle niewidoczne dla BOK,
• Numer przesyłki – osobne pole dla kuriera/paczkomatu,
• Numer płatności – jeśli jest potrzebny księgowości.

Im mniej „worek‑pól” typu „Uwagi”, tym lepiej. Lepsze są 2–3 krótkie, jasno opisane pola niż jedno długie, w którym każdy dopisuje, co chce – bo przy pierwszej większej skali takie notatki przestają być użyteczne.

Co warto zapamiętać

• Różne numery zamówień nie są „błędem systemu”, tylko efektem zupełnie innej logiki: marketplace działa koszykiem i identyfikatorami technicznymi, ERP – dokumentami sprzedażowo‑magazynowymi.
• Numery marketplace są stabilne i unikalne, ale mało „ludzkie” dla logistyki i księgowości; numery ERP są czytelne dla firmy (serie, lata, kanały), lecz nie mają naturalnego powiązania z numerami z Allegro czy Amazona.
• „Zamówienie” powstaje w różnych momentach procesu (koszyk vs import do ERP), dlatego jedno zamówienie widziane oczami klienta może rozpaść się na kilka dokumentów w ERP – bez wspólnego numeru wszystko trzeba łatać ręcznie.
• Przy małej skali da się jeszcze wyszukać zamówienie po nazwisku czy mailu, ale przy kilku marketplace’ach i większych wolumenach ręczne szukanie numeru staje się kosztownym pożeraczem czasu całego zespołu.
• Brak jasnych definicji („zamówienie marketplace”, „zamówienie w ERP”, „dokument magazynowy”, „faktura”) powoduje wewnętrzny chaos – każdy mówi o czymś innym, więc rośnie liczba pomyłek i niepotrzebnych telefonów.
• Najtańszy pierwszy krok to wprowadzenie prostego słownika pojęć i konsekwentne zapisywanie numeru z marketplace w dedykowanym polu w ERP (zamiast „gdziekolwiek w uwagach”), co od razu skraca obsługę kontaktów z klientem.