Co zrobić, gdy sklep i ERP mają różne jednostki miary i opakowania?

Skąd biorą się różne jednostki miary między sklepem a ERP

ERP myśli w kartonach, paletach i kilogramach, sklep w sztukach i zestawach

System ERP jest projektowany z myślą o magazynie, logistyce i księgowości. To oznacza, że najczęściej patrzy na towar przez pryzmat opakowań logistycznych i jednostek magazynowych: kartonów, palet, kilogramów, litrów czy metrów bieżących. Powód jest prosty – tak przychodzi dostawa, tak liczy się transport, tak pracuje magazynier na wózku lub przy regale.

Silnik sklepu internetowego ma zupełnie inne priorytety. Tam dominuje perspektywa klienta: „kupuję sztukę produktu”, „chcę zestaw 3 sztuk”, „zamawiam 1,5 m materiału”. Platformy e‑commerce zakładają zazwyczaj jedną, prostą jednostkę sprzedaży i dopiero na niej budują bardziej złożone mechanizmy (pakiety, rabaty ilościowe, multipaki). Efekt jest taki, że ERP i sklep „patrzą” na ten sam produkt w zupełnie inny sposób.

Jeżeli integracja między ERP a sklepem nie uwzględni tego rozdźwięku, systemy zaczną się ze sobą kłócić: ERP będzie mówił, że są „3 opakowania”, a sklep pokaże „brak towaru” albo przeciwnie – sprzeda więcej sztuk, niż magazyn jest w stanie wydać.

Źródła rozjazdów: producent, hurtownia, logistyka i różne kanały sprzedaży

Największe zamieszanie z jednostkami miary i opakowaniami powstaje jeszcze przed wdrożeniem integracji. Każde ogniwo łańcucha dostaw dodaje swoje „trzy grosze”:

• Producent określa minimalne opakowanie (np. karton 12 sztuk, zgrzewka 6 butelek, rolka 50 m).
• Hurtownia może przepakowywać towar, sprzedając np. pół kartonu albo własne zestawy (np. 5 sztuk, bo tak „schodzi rynek”).
• Logistyka myśli w kategoriach palet, warstw, miejsc paletowych, wagi całkowitej.
• Sprzedaż B2B chętnie operuje kartonami i zgrzewkami, bo klienci „biorą na opakowania”.
• Sprzedaż B2C (sklep internetowy) chce sprzedawać pojedyncze sztuki, mniejsze pakiety lub zestawy promocyjne.

Każde z tych ogniw może mieć inne nazewnictwo jednostek („opak.”, „kart.”, „kpl”, „box”), inny współczynnik ilościowy (np. 10 vs 12 sztuk w kartonie) oraz inną politykę cenową (inna cena za sztukę w kartonie, a inna za sztukę luzem). Jeśli firma nie zdefiniuje jednego spójnego podejścia, integracja ERP–sklep zacznie dusić się w wyjątkach i ręcznych poprawkach.

Przykład: ERP w kartonach po 12 sztuk, sklep w sztukach i zestawach 6

Wyobraźmy sobie prostą sytuację. W ERP istnieje indeks XYZ zdefiniowany tak:

• jednostka magazynowa: karton,
• zawartość kartonu: 12 sztuk,
• stan magazynowy: 10 kartonów.

Sklep internetowy sprzedaje ten produkt na dwa sposoby:

• pojedyncza sztuka,
• zestaw 6 sztuk (jako osobny produkt z inną ceną).

Jeżeli integracja nie ma jasno zaprojektowanych przeliczeń, pojawi się szereg problemów:

• ERP wyśle do sklepu informację „10” (kartonów), a sklep odczyta to jako „10 sztuk”. Klient zobaczy tylko 10 sztuk, choć realnie jest 120.
• albo odwrotnie: sklep odczyta 10 kartonów jako 10 × 12 = 120 sztuk, ale magazyn zezwala wydawać towar tylko w całych kartonach, więc nie chce rozcinać opakowań.
• zestaw 6 sztuk nie ma przypisanego powiązania z indeksem ERP, więc jego sprzedaż nie zmniejszy stanów w ERP albo zmniejszy je podwójnie.

Na pozór drobna rozbieżność jednostek miary przekłada się na zwroty, reklamacje, ręczne poprawki stanów i problemy z fakturowaniem. Dlatego logika jednostek musi być tak samo stabilna, jak logika cen czy podatków.

Skutki braku wspólnej logiki jednostek

Kiedy jednostki miary i opakowania nie są spójne między ERP a sklepem, problemy zaczynają się mnożyć:

• błędne stany magazynowe – sprzedaż „na minus”, sprzedaż nieistniejących konfiguracji opakowań, brak widocznej dostępności produktu online mimo realnego stanu w magazynie,
• nieczytelne ceny – różna cena za sztukę w zależności od opakowania, brak konsekwencji cen w sklepie i w systemach B2B,
• kłopoty z dokumentami – faktury, WZ i dokumenty magazynowe z innymi jednostkami niż zamówienie z e‑sklepu,
• konflikty w procesach – magazyn nie chce rozcinać palet lub kartonów, a sklep sprzedaje sztuki; handlowcy B2B mają inne jednostki niż sklep B2C,
• nadmierna ręczna praca – korekty, przeglądanie logów integracji, ręczne przeliczanie ilości i cen przy każdej większej dostawie.

Dopóki firma sprzedaje kilka produktów, taką sytuację często „ratuje” się ręcznie. Jednak przy setkach lub tysiącach SKU i wielokanałowej sprzedaży, brak wspólnej logiki jednostek staje się realnym hamulcem skalowania biznesu.

Podstawy – jak opisać produkt i jednostki w ERP i sklepie

Minimalna „anatomia” kartoteki towarowej

Dobrze zaprojektowana kartoteka towarowa pozwala na spójne działanie ERP, sklepu i integratora. Minimalny zestaw informacji dotyczących jednostek miary i opakowań powinien obejmować:

• jednostkę bazową (referencyjną) – np. sztuka, kilogram, metr, litr,
• jednostki alternatywne – karton, paleta, zgrzewka, rolka, komplet,
• współczynniki konwersji – ile jednostek bazowych mieści się w alternatywnej (np. 1 karton = 12 szt.),
• jednostkę zakupową – w jakiej jednostce kupujesz u dostawcy (np. karton, paleta, kg),
• jednostkę sprzedażową – w jakiej jednostce najczęściej sprzedajesz (np. szt., opak., m).

Wiele systemów ERP pozwala zdefiniować kilka poziomów jednostek (bazowa, magazynowa, sprzedażowa, zakupowa). Klucz w tym, żeby nie „kombinować” z wyjątkiem przy każdym produkcie, tylko wypracować wspólne reguły: co jest bazą, jak opisujemy kartony, jak opisujemy zestawy, jak przechowujemy współczynniki. Im prościej i konsekwentniej, tym łatwiej później zintegrować ERP z e‑commerce.

Jednostka magazynowa vs. jednostka sprzedaży

W praktyce często funkcjonują dwie „warstwy” jednostek:

• jednostka magazynowa – w niej trzyma się stany w ERP (np. karton, paleta, kg),
• jednostka sprzedaży – w niej liczymy sprzedaż w sklepie, w systemie B2B czy na fakturze (np. szt., m, l).

Dla części firm jednostka magazynowa i sprzedażowa jest taka sama (np. sprzedajesz i magazynujesz w sztukach). Jednak wszędzie tam, gdzie pojawiają się kartony, palety, rolki czy „big bagi”, rozdzielenie tych dwóch pojęć pozwala na znacznie większą elastyczność. Ważne, aby system miał zawsze jasny przelicznik między nimi, a integracja wiedziała, którą jednostkę przesyłać do sklepu.

Dobrym wzorcem jest sytuacja, w której ERP trzyma stany w jednostce bazowej (np. szt.) i ma dodatkowe jednostki techniczne dla kartonów i palet. Sklep widzi wyłącznie sztuki lub inne jednostki przyjazne klientowi (np. m, kg), ale w tle integrator przelicza wszystko na jednostkę bazową ERP. To eliminuje dużą część pomyłek.

Jak sklepy obsługują jednostki: sztuki, wagowe, metry, pakiety

Popularne platformy e‑commerce mają dość uproszczony model jednostek. Zazwyczaj zakładają, że:

• podstawową jednostką jest sztuka (1 produkt w koszyku = 1 sztuka),
• jednostki wagowe (kg, g) czy metry bieżące (m, mb) są obsługiwane albo jako „sztuka z opisem”, albo jako bardziej zaawansowane typy produktów (np. sprzedaż „na odcinek”),
• pakiety, zestawy i multipaki to produkty złożone, zbudowane z kilku „zwykłych” SKU.

Sklep często nie ma wbudowanego pojęcia „karton = 12 sztuk”. Z perspektywy silnika sklepu albo sprzedajesz 1 SKU w ilości 12 szt., albo tworzysz specjalny produkt „karton 12 sztuk” i powiązujesz go z tym bazowym. To właśnie integracja musi wiedzieć, jak przełożyć logikę opakowań z ERP na strukturę produktów sklepu.

Jeżeli sklep ma sprzedawać rzeczy typu „1,3 m” tkaniny, „0,2 kg” produktu czy „5 litrów z beczki”, trzeba sprawdzić, jak platforma radzi sobie z ilościami dziesiętnymi i jak to będzie współgrało z ERP (które czasem wymaga pełnych jednostek lub ma określoną dokładność, np. 3 miejsca po przecinku).

Jednostka referencyjna – dlaczego bez niej wszystko się rozsypuje

W całej układance kluczową rolę odgrywa jednostka referencyjna (bazowa). To ta jednostka, na którą da się przeliczyć każdą inną formę występowania produktu: karton, paletę, zestaw, rolkę. Jeżeli firma nie ustali dla każdego produktu takiej „świętej” jednostki, pojawiają się typowe problemy:

• jedne procesy liczą w kartonach, inne w sztukach, nie ma jednoznacznego wzorca,
• współczynniki konwersji żyją w Excelach handlowców, a nie w systemie,
• integrator musi „zgadywać”, czy 1 karton to na pewno 12 sztuk, czy jednak 10.

Nawet jeżeli magazyn funkcjonuje w kartonach, a sprzedaż w sklepie w sztukach, dalej można przyjąć, że to sztuka jest jednostką referencyjną i wszystkie inne są do niej odwołane. W branżach surowcowych będzie to często kg lub litr, w budowlance – metr lub metr kwadratowy. Klucz w tym, aby jednostka referencyjna była najbardziej „atomową” formą występowania produktu, niepodzielną z punktu widzenia procesu sprzedaży.

Najczęstsze scenariusze rozjazdów jednostek i opakowań

Sprzedaż sztuk z kartonów i palet – jeden indeks, wiele form sprzedaży

Najbardziej klasyczny scenariusz to produkt, który w ERP ma jeden indeks, a w rzeczywistości występuje w kilku formach:

• karton 12 sztuk,
• paleta 50 kartonów (600 sztuk),
• sprzedaż pojedynczych sztuk.

W ERP często definiuje się wtedy jednostkę bazową (szt.) i jednostki alternatywne (karton, paleta) z odpowiednimi współczynnikami. Problem zaczyna się, kiedy sklep ma sprzedawać zarówno sztuki, jak i kartony, a integracja nie wie, czy przesyłać do sklepu jeden produkt z ilością (12 szt.) czy dwa osobne produkty (sztuka i karton, obie powiązane z tym samym SKU ERP).

Jeżeli zignoruje się ten problem na etapie projektu, pojawią się różnice:

• sprzedaż kartonu nie zawsze prawidłowo zdejmie ze stanu 12 sztuk bazowych,
• rabaty ilościowe i cenniki B2B będą niekonsekwentne (inna cena za sztukę w kartonie niż „luzem”),
• systemy raportujące (BI, księgowość) dostaną niespójne dane o marży.

W praktyce trzeba zdecydować: czy sklep ma sprzedawać „1 opakowanie = 12 sztuk” jako zwykłą wielokrotność, czy jako osobny produkt „karton”, który integrator przelicza na jednostkę bazową w ERP. Każde z podejść wymaga nieco innego modelu danych.

Produkty na wagę, metry, litry – „około” vs. twarda jednostka ERP

Drugi bardzo kłopotliwy scenariusz to produkty sprzedawane na wagę lub długość: mięso, sery, tkaniny, kable, farby, chemia z beczki. ERP zwykle trzyma takie towary w jednostkach typu kg, m, l i wymaga precyzyjnej ilości przy przyjęciu oraz wydaniu. Sklep internetowy często sprzedaje je jako:

• „około 1 kg” (realnie może być 0,95–1,05 kg),
• „odcinek 1 m”, ale przy docinaniu wychodzi 0,98 m,
• „porcja 0,5 l” z dużej beczki.

„Około” w sklepie a dokładność w ERP – jak to pogodzić

Sprzedaż „około” 1 kg czy „około” 1 m kłóci się z naturą systemu ERP, który wymaga twardych liczb. Da się to jednak pogodzić, jeśli rozdzieli się trzy rzeczy: to, co widzi klient, to, co jest rezerwowane w systemie, oraz to, co faktycznie wychodzi z magazynu.

Praktyczny model wygląda często tak:

• w sklepie klient zamawia „1 kg” lub „1 m”, z możliwością wprowadzenia wartości z przecinkiem (np. 1,2 kg),
• integracja rezerwuje w ERP minimalną ilość potrzebną do realizacji (np. 1,2 kg + bufor techniczny 0,05 kg),
• magazyn waży lub odmierza realną ilość, która trafia na dokument WZ i fakturę (np. 1,18 kg),
• ERP przechowuje ruchy towaru w dokładności np. do 3 miejsc po przecinku, żeby różnice były księgowo akceptowalne.

Kluczowe jest, by klient był wcześniej poinformowany, że płaci za ilość zważoną / zmierzoną, a cena w koszyku ma charakter orientacyjny. W e‑commerce z żywnością czy surowcami to standard: zamówienie jest „rezerwacją zakresu”, a końcowe kwoty docinane są na poziomie ERP i płatności.

Produkty o zmiennej zawartości – przykłady z praktyki

Niektóre branże mają jeszcze trudniej. Nawet jeśli jednostką sprzedaży jest sztuka, zawartość opakowania może się lekko różnić: bochenki chleba o różnej wadze, sery krojone „na oko”, wyroby mięsne z ubytkiem w czasie transportu. Sklep najczęściej operuje wygodnymi wartościami – „bochenek 0,5 kg” – a ERP musi poradzić sobie z tym, że realnie na magazynie jest suma kilogramów, a nie idealnych połówek.

W takim scenariuszu rozsądne bywa podejście:

• jednostką referencyjną w ERP jest kg (lub inna jednostka ciągła),
• „sztuka” w sklepie to pakietowana ilość orientacyjna (np. 0,45–0,55 kg),
• integracja przelicza „liczbę sztuk” na odpowiednią rezerwację masy (np. 1 szt. ≈ 0,5 kg + bufor),
• raporty sprzedaży i marży opierają się zawsze o jednostkę referencyjną (kg), a nie o sztuki marketingowe.

Taki model wymaga dobrej komunikacji z klientem, ale w zamian zdejmuje część napięcia z integracji i magazynu. Zamiast udawać, że każdy bochenek ma idealnie 500 g, system akceptuje naturalną zmienność i przelicza wszystko do „twardej” jednostki ERP.

Zestawy, multipaki, kompletacje – wielu SKU w jednym produkcie sklepu

Kolejna grupa problematycznych przypadków to zestawy: multipaki, komplety montażowe, pakiety promocyjne. ERP rozróżnia często komplet (kilka indeksów złożonych w jeden) i zestaw marketingowy (sprzedawany razem, ale rozliczany osobno). Sklep z perspektywy klienta widzi po prostu „zestaw w dobrej cenie”.

Jeżeli zestaw ma być sprzedawany w sklepie jako jeden produkt, integracja powinna mieć jasno zdefiniowaną strukturę:

• co jest produktem nadrzędnym (zestaw) i jakie ma składniki,
• jaką jednostkę referencyjną ma każdy składnik w ERP (szt., m, kg),
• jak liczyć dostępność zestawu: jako minimum z dostępności składników,
• jak rozliczać rabaty – czy „siedzą” na poziomie zestawu, czy poszczególnych pozycji.

Prosty przykład: sklep sprzedaje zestaw „10 rolek taśmy w kartonie”. W ERP taśma ma jednostkę bazową metr, a karton = 10 rolek po 50 m. Sprzedaż jednego zestawu oznacza zdjęcie z magazynu 500 m taśmy. Jeżeli integracja nie ma mapy: „zestaw → składniki → przelicznik na jednostkę bazową”, stany rozjadą się już po kilku zamówieniach.

Produkty konfigurowalne – różne jednostki w jednym drzewie wyboru

Konfiguratory produktów (np. okna, meble na wymiar, kable z końcówkami) dorzucają kolejny wymiar: klient wybiera cechy, a za kulisami powstaje BOM – lista materiałowa. Każda z pozycji może mieć inną jednostkę (szt., m, komplet śrub). Sklep sprzedaje „gotowy produkt”, ale ERP musi przyjąć szczegółowe rozbicie na komponenty i jednostki.

Bez przemyślanego modelu jednostek w konfiguratorze można skończyć z sytuacją, w której:

• profil aluminiowy liczony jest w metrach,
• okucia – w kompletach,
• uszczelka – w metrach bieżących, ale sprzedawana tylko w rolkach.

Dlatego na etapie projektowania konfiguratora trzeba z góry odpowiedzieć na pytanie: w jakiej jednostce zostaną zapisane zużycia materiałowe w ERP oraz jak przeliczyć wybory klienta na te jednostki. W wielu przypadkach nie obędzie się bez pośredniej jednostki technicznej, tylko na potrzeby kalkulacji – np. milimetrów, które dopiero później są zaokrąglane do pełnych metrów lub sztuk.

Strategia: jedna jednostka bazowa i przejrzyste konwersje

Jak wybrać dobrą jednostkę bazową

Jednostka bazowa powinna odpowiadać na dwa pytania: w jakiej „atomowej” postaci występuje produkt i jak jest rozliczany księgowo. Najczęściej sprowadza się to do:

• sztuk – dla gotowych produktów, elementów liczalnych,
• kg – dla surowców, produktów spożywczych, chemii, metali,
• metrów lub m² – dla materiałów budowlanych, tekstyliów, wykończeniówki,
• litrów – dla płynów technicznych, farb, paliw.

Dobór jednostki bazowej bywa strategiczną decyzją. W dużej firmie zmiana jednostki referencyjnej po kilku latach działania jest kosztowna, więc lepiej poświęcić chwilę, by zaprojektować ją sensownie. Pomaga prosta zasada: jednostka bazowa ma być tą, którą da się stosować w każdym kanale sprzedaży i logistyki, nawet jeśli nie wszędzie będzie widoczna dla użytkownika.

Definiowanie współczynników konwersji – gdzie i jak to robić

Współczynniki konwersji to serce całej układanki. Jeżeli są porozrzucane po Excelach czy w głowach magazynierów, integracja nie ma szans działać stabilnie. Najbezpieczniej jest trzymać je w jednym miejscu – w ERP – i traktować jako jedno źródło prawdy. Sklep ani integrator nie powinny „na własną rękę” zgadywać, ile sztuk ma karton.

Przy projektowaniu konwersji pomagają dwa proste kroki:

1. dla każdego produktu zidentyfikować wszystkie formy występowania (sztuka, karton, paleta, zgrzewka),
2. spisać konwersje zawsze względem jednostki bazowej, a nie względem innych jednostek alternatywnych (np. „karton = 12 szt.”, „paleta = 600 szt.”, a nie „paleta = 50 kartonów”).

Drugi punkt upraszcza życie integracji: wystarczy, że wie, jak z każdej jednostki wrócić do bazy, zamiast budować wielopoziomowe łańcuchy typu paleta → karton → sztuka. W razie zmiany „kartonów” (z 12 na 10 sztuk) nie trzeba przepisywać wszystkich formuł – modyfikuje się jeden współczynnik.

Konwersje „w jedną stronę” i „w dwie strony”

Nie każda konwersja jest symetryczna. Są przypadki, gdzie da się bez strat przejść z kartonów na sztuki (1 karton = 12 sztuk, 12 sztuk = 1 karton), ale nie da się sensownie odwrócić operacji dla stanów magazynowych. Przykładowo: magazyn raportuje stany w kartonach; jeżeli zostanie 5 sztuk luzem, to nie ma już pełnego kartonu.

Żeby uniknąć dziwnych sytuacji w integracji, można przyjąć proste reguły:

• przeliczenia między jednostką bazową a alternatywnymi są zawsze dokładne matematycznie,
• ale prezentacja stanów w jednostkach alternatywnych (np. w kartonach) może stosować zaokrąglenia jednostronne – na potrzeby informacji dla magazynu lub klienta pokazujemy tylko pełne opakowania.

W praktyce oznacza to np. że system przechowuje 234 sztuki, co odpowiada 19,5 kartonu. Sklep B2B, który sprzedaje wyłącznie całe kartony, pokaże dostępne „19 kartonów”, ale integracja i ERP dalej operują na pełnej liczbie sztuk. Dzięki temu unikamy „znikających” lub „pojawiających się” nagle produktów w raportach.

Prosta, ale twarda zasada integracji

Integrację można oprzeć o jedną prostą zasadę: wszystko, co wychodzi i wchodzi do ERP, jest finalnie w jednostce bazowej. Sklep może mówić językiem kartonów, metrów bieżących, rolek, ale do ERP zawsze trafiają sztuki bazowe lub ich ułamki. Analogicznie, przy eksporcie stanów i cen do sklepu, ERP „tłumaczy” swoje liczby na formy sprzedażowe widoczne dla klienta.

Dzięki temu integrator nie musi znać logiki każdego sklepu czy systemu B2B osobno. Wystarczy, że dla każdego kanału istnieje mapa jednostek sprzedaży ↔ jednostka bazowa ERP. W razie zmiany platformy e‑commerce lub narzędzia B2B, reguły po stronie ERP i jednostki bazowej pozostają takie same – modyfikuje się jedynie warstwę „tłumaczącą” w danym kanale.

Projektowanie mapowania jednostek między ERP a sklepem

Mapa jednostek – od czego zacząć

Zanim powstanie pierwsza linijka kodu integracji, przydaje się zwykła, ludzka mapa: jakie jednostki funkcjonują w ERP, a jakie w sklepie i innych kanałach. Prosty arkusz z kolumnami:

• SKU / indeks ERP,
• jednostka bazowa w ERP,
• jednostki alternatywne w ERP (karton, paleta itd.),
• jednostka sprzedażowa w sklepie,
• typ produktu w sklepie (zwykły, zestaw, produkt wagowy/metrażowy),
• współczynnik konwersji (ile bazowych na 1 jednostkę sprzedażową sklepu).

Już samo wypełnienie takiej tabeli dla kilkudziesięciu najważniejszych SKU ujawnia niespójności: produkty bez zdefiniowanego kartonu, różne pojemności „tego samego” opakowania, brak informacji o ilościach w materiałach od dostawców. To dobry moment, żeby wyczyścić dane, zamiast później walczyć z dziwnymi błędami integracji.

Jednostki techniczne – kiedy je wprowadzać

Czasami sklep i ERP „mówią” różnymi językami tak bardzo, że przydaje się trzeci, pośredni – jednostka techniczna. Przykłady:

• ERP liczy panele podłogowe w m², a sklep sprzedaje je w opakowaniach o różnym pokryciu (np. 1,8 m², 2,1 m²),
• ERP ma farbę w litrach, ale sklep pokazuje „pokrycie na m² przy jednej warstwie”,
• ERP przechowuje kable w metrach, a sklep przyjmuje zamówienia na „krążki” o różnych długościach.

W takich przypadkach warto wprowadzić jednostkę techniczną (np. m², metr bieżący, litr) i rozumieć opakowania jako różne multiplikatory tej jednostki. Sklep operuje wtedy opakowaniami, ale w tle każda ilość zamieniana jest na odpowiednią ilość jednostki technicznej, a dopiero potem na bazową w ERP.

To podejście jest szczególnie pomocne, gdy opakowania się zmieniają (np. nowa wersja opakowania ma inne pokrycie na m²). Zmienia się tylko współczynnik dla danego SKU, a reszta logiki integracji pozostaje nietknięta.

Mapowanie typów produktów sklepowych na jednostki ERP

Różne platformy e‑commerce oferują różne typy produktów: proste, konfigurowalne, grupowe, zestawy, produkty z wariantami. Każdy z nich może inaczej przekładać się na jednostki w ERP:

• produkt prosty – zazwyczaj 1:1 z jednostką bazową (lub prostą jednostką alternatywną),
• produkt z wariantami – kilka SKU sklepowych może mapować się na jeden indeks ERP (z różnymi jednostkami opakowań),
• zestawy – wymagają mapy komponentów i ich jednostek,
• produkt konfigurowalny – jeden „wierzchni” produkt sklepu, ale kilka lub kilkanaście pozycji ERP z różnymi jednostkami.

Na etapie projektowania integracji trzeba jasno zdefiniować, kto „zna” tę strukturę: sklep, ERP czy integrator. Jeżeli to ERP przechowuje definicję zestawów i kompletów, integracja może być prostsza – sklep służy wtedy głównie jako interfejs zamówieniowy. Jeśli natomiast złożona logika produktów siedzi w sklepie (np. w konfiguratorze), integrator musi umieć przełożyć wybory klienta na konkretne indeksy ERP i ich jednostki.

Walidacja mapy na przykładach skrajnych

Najczęściej zadawane pytania (FAQ)

Jak zsynchronizować stany magazynowe, gdy w ERP mam kartony, a w sklepie sztuki?

Najprościej przyjąć jedną jednostkę bazową – najczęściej jest to sztuka – i w ERP zdefiniować do niej wszystkie opakowania (karton, paleta, zgrzewka) jako jednostki alternatywne z konkretnym przelicznikiem, np. 1 karton = 12 sztuk. Integracja powinna zawsze przesyłać do sklepu stany w jednostce bazowej, a nie w kartonach czy paletach.

W praktyce oznacza to, że jeśli w ERP masz 10 kartonów po 12 sztuk, integrator wysyła do sklepu informację „120 sztuk”. ERP dalej „myśli” kartonami, magazyn wydaje kartony, ale sklep widzi czytelny stan w sztukach. Kluczowe jest, aby integrator znał współczynnik (12) i stosował go konsekwentnie przy każdej wymianie danych.

Co zrobić, gdy producent sprzedaje w kartonach, hurtownia w zestawach, a sklep w sztukach?

Trzeba zbudować wspólny słownik jednostek i opakowań w ERP. Każde źródło dostaw (producent, hurtownia) może mieć swoje nazwy i pojemności opakowań, ale w Twoim systemie muszą się one „zbiegać” do jednej kartoteki z jasno opisanymi przelicznikami: ile sztuk przypada na karton, zestaw, rolkę czy paletę.

Dobrym podejściem jest: jedna kartoteka produktu, jednostka bazowa (np. szt.), a do tego kilka jednostek alternatywnych z różnymi współczynnikami. Integracja ze sklepem korzysta z tej samej kartoteki, dzięki czemu niezależnie od tego, czy towar przyszedł „w kartonie 10” czy „w kartonie 12”, stan jest przeliczony do wspólnego mianownika i poprawnie widoczny online.

Jak sprzedawać zestawy (np. 6 sztuk) w sklepie, gdy w ERP mam tylko kartony?

Zestawy w sklepie najlepiej traktować jako produkty złożone powiązane z produktem bazowym z ERP. W konfiguracji integracji ustalasz, że „zestaw 6 sztuk” zużywa 6 sztuk z indeksu bazowego, niezależnie od tego, że magazyn trzyma ten towar w kartonach po 12.

Efekt jest taki, że każde zamówienie na zestaw 6 sztuk zmniejsza w ERP stan o 6 sztuk (lub odpowiedni ułamek kartonu, jeśli ERP trzyma stany w sztukach technicznych). Dzięki temu nie pojawia się „drugi magazyn” dla zestawów, a wszystkie ruchy schodzą na jedną kartotekę i łatwo kontrolować realną dostępność.

Jak uniknąć sytuacji, że sklep sprzedaje więcej sztuk niż jest w magazynie kartonów?

Najpierw trzeba uporządkować przeliczniki jednostek: magazyn musi mieć jasno zdefiniowane, czy wolno „rozcinać” kartony i w jakim zakresie. Jeśli magazyn nie rozcina opakowań, integracja powinna uwzględniać tylko pełne kartony przeliczone na sztuki, a resztę traktować jako niedostępną w e‑sklepie.

Technicznie często robi się to tak, że integrator przelicza stany z ERP (np. 10 kartonów po 12 sztuk) na sztuki, ale jednocześnie obcina wynik do pełnych wielokrotności sprzedawanej jednostki (np. dla zestawów po 6 sztuk maksymalna dostępna ilość to 120 sztuk, czyli 20 zestawów). Dzięki temu sklep nie przyjmie zamówienia na konfigurację, której magazyn nie jest w stanie fizycznie zrealizować.

Jak radzić sobie z różnymi nazwami jednostek (opak., kart., kpl) w ERP i sklepie?

Zamiast próbować odwzorować w sklepie wszystkie skróty z ERP, lepiej w ERP stworzyć uporządkowany słownik jednostek i opakowań, a integracji „nauczyć” mapowania: co w ERP oznacza karton, zgrzewkę, komplet i ilu sztukom to odpowiada. Sklep powinien widzieć już docelową, przyjazną nazwę lub po prostu sztuki/metry/kilogramy.

Przykładowo: w ERP możesz mieć jednostki „OP”, „KART”, „KPL”, ale integrator sprowadza je do opisanych form i przeliczników. Do sklepu wychodzi już czysta logika sprzedaży (np. szt. lub „zestaw 3 sztuki”), bez technicznych skrótów z magazynu. Dzięki temu klient nie widzi żargonu, a Ty nie gubisz się w wyjątkach.

Czy każda platforma sklepu internetowego obsłuży kartony, palety i sprzedaż „na metry”?

Większość silników e‑commerce jest projektowana pod sprzedaż w sztukach, a opakowania logistyczne (karton, paleta) traktuje raczej jako osobne produkty lub warianty. Sprzedaż „na metry” czy „na kilogramy” jest zwykle możliwa, ale wymaga odpowiedniego typu produktu i włączenia sprzedaży w ilościach dziesiętnych.

Dlatego pełna obsługa kartonów i palet nie dzieje się „magicznie” po stronie sklepu, tylko w logice integracji i konfiguracji ERP. Sklep widzi po prostu poprawną jednostkę sprzedaży (np. metr materiału), a integrator dba o przeliczenia do magazynowej jednostki technicznej (np. rolki 50 m) i o to, żeby stany się zgadzały.

Jak uporządkować jednostki miary przed wdrożeniem integracji ERP–sklep?

Dobrym początkiem jest audyt kartotek towarowych: sprawdzenie, jakie jednostki bazowe i alternatywne są używane, jakie są przeliczniki oraz gdzie pojawiają się „dziwne” wyjątki (inne ilości w kartonie, ręczne dopiski, różne skróty tej samej jednostki). Na tej podstawie da się ustalić prosty, spójny model: jedna jednostka bazowa + ograniczona lista standardowych opakowań z jasno opisanymi współczynnikami.

Kolejny krok to decyzja, które jednostki są magazynowe, a które sprzedażowe, oraz w jakiej formie mają trafiać do sklepu. Im mniej wyjątków i ręcznych przeliczeń w codziennej pracy, tym łatwiej później zbudować integrację, która naprawdę odciąża zespół zamiast generować kolejne korekty i spory między magazynem a e‑commerce.

Kluczowe Wnioski

• ERP i sklep patrzą na ten sam produkt z zupełnie innych perspektyw: ERP „myśli” w kartonach, paletach i kilogramach, a sklep w pojedynczych sztukach, zestawach i długościach (np. metry materiału).
• Rozjazdy jednostek miary powstają w całym łańcuchu dostaw – producent, hurtownia, logistyka, sprzedaż B2B i B2C mogą stosować inne opakowania, nazwy jednostek i przeliczniki, co bez wspólnych reguł kończy się chaosem.
• Brak jasno zdefiniowanych przeliczeń między jednostkami (np. karton = 12 sztuk) powoduje konkretne błędy: sprzedaż „na minus”, niewidoczne stany w sklepie mimo pełnego magazynu albo sprzedaż konfiguracji, których magazyn fizycznie nie wydaje.
• Problemy z jednostkami bezpośrednio uderzają w obsługę klienta i finanse: zwroty, reklamacje, korekty faktur, rozjazdy między dokumentami magazynowymi a zamówieniami ze sklepu, a także nieczytelne i niespójne ceny za sztukę.
• Przy małej skali biznesu różnice w jednostkach da się „łatać” ręcznie, ale przy setkach lub tysiącach SKU i sprzedaży wielokanałowej brak wspólnej logiki jednostek staje się realną barierą wzrostu.
• Kluczowe jest spójne zdefiniowanie w ERP minimalnej „anatomii” produktu: jednostki bazowej (sztuka, kg, m), jednostek alternatywnych (karton, paleta, zgrzewka, komplet), współczynników konwersji oraz osobno jednostki zakupowej i sprzedażowej.