---
title: "Kto jest właścicielem którego pola: sklep, ERP czy PIM"
description: "Stan magazynowy to łatwe pole. Ceny, atrybuty, media, teksty alternatywne, treści dla poszczególnych języków i klucze URL zapisują dwa systemy jednocześnie, a reguła własności jest ograniczona tym, co potrafi wyrazić twoja platforma."
author: "Luboš Zápotočný"
published: "2026-08-06"
language: "pl"
canonical: "https://zapolu.com/pl/blog/kto-jest-wlascicielem-ktorego-pola/"
---

# Kto jest właścicielem którego pola: sklep, ERP czy PIM

Każdy sklep, który łączy się z systemem ERP, ostatecznie ustala, kto
jest właścicielem numeru magazynowego. Odpowiedź brzmi
[prawie zawsze ERP lub system magazynowy](/pl/blog/erp-eshop-stock-mismatch/),
ponieważ to właśnie tam towary są rezerwowane i tam fizycznie się
przemieszczają, a gdy ta zasada jest już ustalona, błędy synchronizacji
stają się mechaniczne.

Potem to samo pytanie wraca dla każdego innego pola i ta prosta
odpowiedź przestaje działać. Stan magazynowy to jedna liczba o jednym
znaczeniu. Cena to jedna liczba na witrynę internetową, rynek lub
firmę klienta. Tekst produktu to jedna wartość na język. Obraz to
jeden plik, ale jego tekst alternatywny to zdanie na język. O to, kto
jest właścicielem stanu magazynowego, nikt długo się nie spiera. To w
pozostałej części rekordu kwestia własności pozostaje otwarta.

Ten wpis podaje regułę własności pole po polu dla cen, atrybutów,
mediów, treści dla poszczególnych języków, cen B2B i kluczy URL, a
następnie sprawdza każdą regułę pod kątem tego, co Magento i Shopify
faktycznie mogą wyrazić, gdzie zatrzymują się systemy ERP używane w
Europie Środkowej i kiedy PIM zaczyna się opłacać. Platformowa
połowa tego tekstu to Magento i Shopify; czeski lub słowacki sklep co
najmniej równie często działa na Shoptet, a kwestia własności pola
jest tam taka sama, mimo że mechanizmy są inne. Każdy fakt dotyczący
dostawcy sprawdzono względem jego własnej dokumentacji 4 sierpnia
2026 roku, a te nośne opatrzono linkiem; tam, gdzie czegoś nie udało
się zweryfikować, piszemy o tym wprost.

## Jeden właściciel na pole, w jednym zakresie

Zasada z wpisu o stanach magazynowych wciąż obowiązuje: jeden system
rekordów na fakt. Zmienia się natomiast to, że pole nie jest faktem,
dopóki nie nazwie się również jego zakresu. „ERP jest właścicielem
ceny” to nie reguła, którą można wdrożyć w integracji. „ERP jest
właścicielem ceny katalogowej na witrynę, a nikt nie jest właścicielem
ceny na widok sklepu, bo platforma nie umie jej tak przechowywać”, to
już reguła.

Słownictwo do opisu tego zjawiska jest starsze niż e-commerce. Pat
Helland w tekście
[Data on the Outside versus Data on the Inside](https://www.cidrdb.org/cidr2005/papers/P12.pdf)
(CIDR 2005) formułuje tę zasadę w jednym zdaniu: „Dane referencyjne to
rodzaj informacji tworzonych lub zarządzanych przez jedną usługę i
publikowanych dla innych usług do ich użytku (...) Dla każdego elementu
istnieje dokładnie jedna usługa publikująca”.

Literatura z zakresu zarządzania danymi mówi to samo innymi słowami i
warto je zapożyczyć, bo nazywają dwie role, jakie odgrywają systemy
sklepu. DAMA-DMBOK, drugie wydanie, rozdział 10 (Dane referencyjne i
podstawowe) definiuje System of Record jako „system autorytatywny, w
którym dane są tworzone lub przechwytywane, oraz utrzymywane zgodnie z
określonym zestawem reguł i oczekiwań”, a System of Reference jako
„system autorytatywny, w którym odbiorcy danych mogą uzyskać
wiarygodne dane do obsługi transakcji i analiz, nawet jeśli informacje
nie pochodzą z tego systemu”. Jedną z sześciu zasad przewodnich
dotyczących danych referencyjnych i podstawowych jest Autorytet:
„wartości danych podstawowych powinny być replikowane wyłącznie z
systemu rekordów”. Kolejną jest Własność, którą literatura ta
opisuje na poziomie organizacji, a nie pola. Twój storefront jest
systemem odniesienia dla większości rekordu produktowego, a tym,
czego dotyczy ten wpis, jest właśnie pytanie, który system jest
rekordem dla każdego pola.

Tym, czego literatura nie precyzuje, jest granularność. Drugie wydanie
nazywa samo oznaczenie i wymienia reguły dopasowania, scalania,
przetrwania i zaufania wśród reguł biznesowych potrzebnych do
zarządzania danymi podstawowymi, ale odnosi się do encji i elementów
danych w ogólności, a nie do konkretnego pytania, który system jest
właścicielem tekstu alternatywnego storefrontu w języku polskim. Cztery
style MDM, zwykle przywoływane jako rejestr, konsolidacja,
współistnienie i transakcja, są powszechnie przypisywane firmie Gartner;
własne strony Gartnera odrzuciły każdego klienta, z którym próbowaliśmy
się skontaktować, a otwarcie dostępne źródło, które znaleźliśmy,
przypisuje te style
[konsultantom do zarządzania danymi i dostawcom MDM](https://www.techtarget.com/searchdatamanagement/definition/master-data-management),
a nie Gartnerowi, więc traktujemy je jako wspólnie przyjęty opis, a nie
jako definicję.

Propagacja ma wzorce nazwane lepiej. Kanał push to konsument sterowany
zdarzeniami, a zadanie nocne to
[konsument odpytujący](https://www.enterpriseintegrationpatterns.com/patterns/messaging/PollingConsumer.html);
tolerowanie powtórzonej wiadomości to
[Idempotent Receiver](https://www.enterpriseintegrationpatterns.com/patterns/messaging/IdempotentReceiver.html),
którego dwie udokumentowane drogi to jawna deduplikacja i semantyka
czyniąca ponowne przetworzenie nieszkodliwym; a przywracanie porządku w
strumieniu, który dotarł w niewłaściwej kolejności, to
[Resequencer](https://www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html).
Helland w tekście
[Life beyond Distributed Transactions](https://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf)
(CIDR 2007) formułuje wymaganie, któremu te wzorce mają odpowiadać:
„aplikacja musi tolerować ponowne wysyłanie wiadomości i przychodzenie
niektórych wiadomości w nieuporządkowanej kolejności”.

## Co może wyrazić twoja platforma

Jeśli platforma nie umie wyrazić reguły własności, nie da się jej
wdrożyć, więc sprawdź regułę względem modelu danych, zanim
uzgodnisz ją z kimkolwiek.

**Magento ustala zakresy według hierarchii sklepu.** Adobe dokumentuje
[kaskadę: globalny, witryna, sklep i widok sklepu](https://experienceleague.adobe.com/en/docs/commerce-admin/start/setup/websites-stores-views),
ale atrybut produktu ma zakres tylko w trzech z tych czterech poziomów:
poziom sklepu nosi kategorię główną, a nie wartości atrybutów, więc
atrybut jest globalny, przypisany do witryny albo do widoku sklepu. O
większości pytań o własność decydują dwa ograniczenia. Cena nie ma
swobodnego zakresu: ustawienie
[Catalog Price Scope](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/pricing/catalog-price-scope)
oferuje wyłącznie poziom Global lub Website, strona wprost stwierdza, że
„Commerce nie pozwala ustawić ceny produktu dla każdego sklepu osobno”,
a panel administracyjny udostępnia to ustawienie tylko w zakresie
Default Config, czyli jest to jeden przełącznik dla całej instalacji.
Niektórych atrybutów nie da się przekonfigurować co do zakresu wcale:
Magento blokuje selektor zakresu dla `sku` i `category_ids` w
[eav_attributes.xml](https://raw.githubusercontent.com/magento/magento2/2.4-develop/app/code/Magento/Catalog/etc/eav_attributes.xml)
i wyłącza go dla `sku` oraz `media_gallery` w
[konfiguracji formularza panelu administracyjnego](https://raw.githubusercontent.com/magento/magento2/2.4-develop/app/code/Magento/Catalog/etc/adminhtml/di.xml)
(2.4-develop, sprawdzono 4 sierpnia 2026 roku). Atrybut użyty jako opcja
konfigurowalna
[musi być globalny](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/product-attributes/product-attributes-add),
choć etykiety jego opcji pozostają tłumaczalne dla każdego widoku
sklepu.

**Shopify rozdziela ceny i tłumaczenia, i są to różne mechanizmy.**
Wariant ma jedną cenę bazową w rekordzie produktu; ręcznie ustawiona
cena dla
danego rynku leży całkowicie poza produktem, w cenniku przypisanym do
katalogu przypisanego do rynku. Rynek może też różnić się od ceny
bazowej bez żadnego cennika, przez przeliczanie walut i zasady
zaokrąglania. Magento nie ma tu odpowiednika: ręcznie ustawiona cena dla
danego
rynku oznacza witrynę na rynek, przy czym widoki sklepu pod tą witryną
tę cenę dzielą. Tłumaczenie to osobna warstwa, a w samym zasobie
produktu jest ona wąska: tłumaczalne są tylko tytuł, treść, uchwyt
(handle), typ produktu, meta title i meta description, a
[tagów zasobu nie da się przetłumaczyć](https://shopify.dev/docs/apps/build/markets/manage-translated-content)
wcale. Nazwy opcji, wartości opcji i publicznie dostępne metapola też są
tłumaczalne, jako własne typy zasobów. Tłumaczenie można też ograniczyć
do jednego rynku przez `marketId` na wejściu tłumaczenia, dzięki czemu
ten sam język może być czytany różnie na dwóch rynkach. Uchwyty URL są
wyjątkiem: Shopify wprost stwierdza, że nie można ich dostosować dla
poszczególnych rynków. Dla tego, kto zarządza ścieżką zapisu, znaczenie
mają dwa mechanizmy: zapisanie tłumaczenia wymaga
`translatableContentDigest` z treści źródłowej, a
[`Translation.outdated`](https://shopify.dev/docs/api/admin-graphql/latest/objects/Translation)
raportuje, czy treść oryginalna zmieniła się od chwili zapisania
tłumaczenia. Dzięki temu nieaktualność jest wykrywalna, ale nie jest tym
samym rozwiązywana. A `productSet` uzgadnia pola listowe z przesłanym
payloadem: dla wariantów, metapól i kolekcji tworzy i aktualizuje to, co
jest w payloadzie, a usuwa to, czego w nim nie ma, co czyni naiwne,
częściowe zadanie „zsynchronizuj wszystko” destrukcyjnym. Opisane wyżej
zachowanie dotyczy Admin API w wersji 2026-07, sprawdzono 4 sierpnia 2026
roku.

## Odpowiedź pole po polu

| Pole | System rekordów | Zakres, który faktycznie może obsłużyć | W razie konfliktu |
| ----- | ---------------- | -------------------------- | ----------- |
| Tożsamość produktu | ERP, jako identyfikator zastępczy | Przechowuj identyfikator ERP w atrybucie Magento lub metapolu Shopify; nie łącz danych po SKU, które bywa zmieniane | Wygrywa identyfikator ERP; zmieniony SKU to zmiana nazwy, nie nowy produkt |
| Cena katalogowa | ERP | Magento: tylko globalnie lub na witrynę. Shopify: jedna wartość bazowa na wariant | Wygrywa ERP; edycje w sklepie są nadpisywane przy kolejnej synchronizacji |
| Podstawa opodatkowania i klasa podatkowa | ERP | Magento: `tax_class_id` to atrybut w zakresie witryny, a wyświetlanie netto lub brutto to osobna konfiguracja. Shopify: flaga produktu plus ustawienia podatkowe dla rynku | Zdecyduj, która strona przeliczenia VAT jest rozstrzygająca, i zapisz to. Katalog B2C w Czechach lub Polsce jest tworzony w cenach brutto, więc wyliczanie brutto z netto z ERP wprowadza zaokrąglenie pomiędzy ceną w ERP a ceną widzianą przez klienta |
| Cena rynkowa lub kanałowa | Sklep | Cenniki Shopify dla każdego katalogu i rynku, a do tego przeliczanie walut. Magento nie rozdziela tych dwóch: cena witryny to jedyna wartość, więc kto jest właścicielem ceny katalogowej, jest właścicielem ceny rynkowej | Sklep wygrywa przy wyświetlaniu. ERP wciąż otrzymuje cenę sprzedaży z zamówienia i nie może przeceniać zaimportowanego zamówienia według własnej listy |
| Cena promocyjna | Sklep, o ile ERP nie zatwierdza marży | Magento: ta sama koperta co cena katalogowa, albo reguła cenowa katalogu na witrynę i grupę klientów. Shopify: cena porównawcza (compare-at) albo korekta katalogu | Jeśli zatwierdzanie marży leży w ERP, ERP jest właścicielem tego pola i sklep nie może dodatkowo uruchamiać reguł katalogowych na tych samych produktach |
| Cena B2B lub kontraktowa | ERP | Magento: ceny wielopoziomowe dla grupy klientów i witryny; katalogi współdzielone tylko z Adobe Commerce B2B. Shopify: katalogi dla lokalizacji firmy | Wygrywa ERP. Powyżej kilkudziesięciu profili cenowych żadna platforma nie modeluje dobrze kontraktów indywidualnych |
| Stan fizyczny | ERP, albo WMS, jeśli istnieje | Na poziomie źródła. Ilość dostępna do sprzedaży jest wyliczana przez platformę na podstawie źródeł minus rezerwacje i nie jest zapisywalna | Nigdy nie zapisuj ilości dostępnej do sprzedaży; zapisuj ilość źródłową i pozwól platformie ją wyliczyć |
| Zestaw wariantów | PIM, w przeciwnym razie sklep | Produkty konfigurowalne w Magento wymagają globalnych atrybutów opcji; większość systemów ERP przechowuje każdy wariant jako osobny element bez nadrzędnego | Właścicielem jest ten, kto zarządza grupowaniem nadrzędnym; ERP zwykle nie umie tego wyrazić |
| Atrybuty i opcje | PIM, w przeciwnym razie sklep | Atrybuty opcji konfigurowalnych muszą być globalne w Magento | Wygrywa PIM; sklep to kopia do wyświetlenia |
| Pliki multimedialne | DAM, w przeciwnym razie PIM | Jeden globalny zestaw plików; w Magento role base, small i thumbnail są przypisane do widoku sklepu | Wygrywa DAM, ale tylko jeśli zachowuje stabilną tożsamość każdego zasobu; zmiana nazwy przy ponownej synchronizacji pozostawia bez powiązania każdą rolę przypisaną do widoku sklepu |
| Tekst alternatywny | PIM, w przeciwnym razie sklep | Na poziomie widoku sklepu w Magento, dla lokalizacji w Shopify | Wygrywa właściciel treści |
| Treść dla poszczególnych języków | ERP do granicy swoich możliwości językowych, w przeciwnym razie PIM, w przeciwnym razie sklep | Widoki sklepu w Magento; w Shopify pięć z sześciu tłumaczalnych pól produktu, plus nazwy opcji, wartości opcji i publicznie czytelne metapola (uchwyt to wiersz adresu URL) | Wygrywa lokalizacja źródłowa; nieaktualne tłumaczenie jest oznaczane, nie zastępowane |
| Klucz lub uchwyt adresu URL | Sklep | Na poziomie widoku sklepu w Magento; dla lokalizacji w Shopify, ale uchwytów nie można dostosować dla rynku | Wygrywa sklep; nigdy nie generuj go ponownie z nazwy produktu |
| Publikacja i wycofanie z listy | ERP dla kwalifikowalności, sklep dla kanału | Flaga ERP (`isInternet`, `exportNaEshop`) decyduje o wejściu do katalogu; sklep publikuje dla witryny lub kanału | Wyłączaj, nie usuwaj: usunięty produkt traci swój adres URL, opinie i historię przekierowań |
| Przynależność do kategorii lub kolekcji | PIM, w przeciwnym razie sklep | Jedno globalne przypisanie w Magento; kolekcje w Shopify. Drzewo grup produktów z ERP jest wejściem, nie rekordem | Wygrywa PIM; drzewo z ERP jest mapowane, nie kopiowane |
| Pola regulacyjne | Sklep, wypełniane na podstawie danych dostawcy | Dla każdego rynku osobno, w języku akceptowanym przez państwo członkowskie tego rynku | Nikt nie może automatycznie nadpisać atestu |

Dwa wiersze wymagają rozwinięcia: media i klucze URL.

**Obraz jest globalny, jego tekst alternatywny nie.** Adobe stwierdza,
że „nowe zdjęcia produktów są **_zawsze_** wgrywane i widoczne we
**_wszystkich_** widokach sklepu, nawet jeśli do wgrywania nie użyto
zakresu `All Store Views`”
([obrazy i wideo produktu](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/digital-assets/product-image),
sprawdzono 4 sierpnia 2026 roku), a galeria przechowuje jeden plik na
obraz, bez kolumny sklepu. DAM jest więc właścicielem zestawu zasobów
dla wszystkich lokalizacji jednocześnie. Tym, co jest przypisane do
widoku sklepu, jest wiersz przy każdym obrazie: etykieta, pozycja i
flaga
wyłączenia, co sprawia, że tekst alternatywny, kolejność obrazów i to,
który obraz jest ukryty, są polami dla widoku sklepu. Jedno zastrzeżenie
komplikuje ten uporządkowany podział: *role* obrazu (base, small,
thumbnail, swatch) to atrybuty w zakresie widoku sklepu, przechowujące
ścieżkę do pliku, więc to, który z globalnych plików wyświetla dana
witryna, może się różnić dla lokalizacji. Shopify wyznacza tę granicę w
tym samym miejscu, ale z drugiej strony: w obrazie multimedialnym
jedynym tłumaczalnym polem jest `alt`. Dokumentacja
[Translate & Adapt](https://help.shopify.com/en/manual/international/translate-adapt-app)
wymienia obrazy produktu wśród typów treści, których aplikacja nie może
przetłumaczyć, natomiast inne obrazy i filmy w przetłumaczonym zasobie
można podmienić dla języka, wgrywając plik alternatywny (sprawdzono 4
sierpnia 2026 roku).

Ten podział ma większe znaczenie, niż się wydaje, bo tekst
alternatywny nie jest polem technicznym.
[European Accessibility Act](https://eur-lex.europa.eu/eli/dir/2019/882/oj)
obejmuje usługi e-commerce sprzedawane konsumentom, a państwa
członkowskie muszą stosować jej środki od 28 czerwca 2025 roku. Sama
dyrektywa wymaga, by te usługi były postrzegalne, funkcjonalne,
zrozumiałe i solidne, nie wymienia natomiast tekstu alternatywnego z
nazwy; konkretny wymóg alternatywy tekstowej wyraża norma EN 301 549,
która wskazuje na WCAG. Warto zauważyć, że obowiązująca wersja,
V3.2.1, została zharmonizowana na podstawie dyrektywy o dostępności
stron internetowych, a nie na podstawie Accessibility Act, a wersja
V4.1.0, odnosząca się do EAA, w chwili sprawdzania wciąż nie była
przywołana w Dzienniku Urzędowym. Wyłączenie dla mikroprzedsiębiorstw
jest [węższe, niż się wydaje](/pl/blog/accessibility-act-ecommerce/), a
osobna ocena nieproporcjonalnego obciążenia jest otwarta dla każdego
dostawcy. Tekst alternatywny to treść dla języka, z przypisanym do
niej reżimem zgodności, tworzona wszędzie tam, gdzie tworzona jest
reszta tekstów. Żadna z platform nie pyta o niego dla lokalizacji w
swojej ścieżce wgrywania.

**Klucz URL zwykle należy do sklepu, ale nie dlatego, że nikt inny nie
rości sobie do niego prawa.** Większość systemów ERP nie ingeruje w
adresy URL witryny, co skłania do wniosku, że pole to nie ma
konkurującego kandydata. Taki kandydat jednak istnieje. Własna
dokumentacja e-Sklepu Comarch ERP Optima daje
systemowi ERP zakładkę Pozycjonowanie, zawierającą tytuł strony,
dedykowane pole `Link` do budowania adresów URL, słowa kluczowe i meta
description, i to zarówno dla grup produktów, jak i pojedynczych pozycji
([Pomoc Comarch Optima, wersja 2026_5](https://pomoc.comarch.pl/optima/pl/2026_5/dokumentacja/wspolpraca-z-comarch-e-sklep/),
sprawdzono 4 sierpnia 2026 roku). Konektory i systemy PIM też zapisują
uchwyty, niezależnie od tego, co dokumentuje jądro ERP.

Reguła operacyjna jest lepsza niż argument o zakresie, bo Comarch
pokazuje, że ERP potrafi wyrazić to pole. Kto jest właścicielem
klucza URL, przejmuje wszystkie konsekwencje jego zmiany, a te
konsekwencje pojawiają się poza systemem, który tę zmianę wprowadził.
Decyzją, która się liczy, jest więc to, co ma się stać przy zmianie
nazwy. Magento ma na to ustawienie, „Create Permanent Redirect for
URLs if URL Key Changed”, a kto jest właścicielem klucza, dziedziczy
rosnącą tabelę przekierowań.

Pozwolenie zewnętrznemu systemowi na dowolne zmienianie tego pola ma
bezpośredni koszt. Specyfikacja pliku
[Heureka](https://sluzby.heureka.cz/napoveda/xml-feed/)
oznacza cztery elementy jako bezwarunkowo obowiązkowe: nazwę
produktu, identyfikator pozycji, cenę z VAT i adres URL, i stwierdza,
w języku czeskim, że gdy w XML zmienią się adresy URL, nazwy lub
kategorie produktów, wszystkie produkty zostają odłączone od swoich kart
produktowych Heureka i czekają na ponowne sparowanie, co według tej
specyfikacji może zająć około czterech dni roboczych. PIM, który
regeneruje uchwyty z nazw produktów, na kilka dni odłącza więc
cały katalog od porównywarki, choć w samym sklepie nic nie wygląda na
zepsute.

## Gdzie kończy się ERP: treść dla poszczególnych języków

W sklepie sprzedającym po czesku, słowacku, niemiecku i polsku granicę
między „ERP może być właścicielem tekstów produktowych” a „musi
zająć się tym coś innego” zwykle wyznacza liczba języków, które
przewiduje model danych ERP, a liczba ta jest niższa niż liczba
rynków, na które sprzedaje sklep tej wielkości.

ABRA Flexi jest właścicielem treści wielojęzycznych w swoim głównym
obiekcie cennikowym, ale jako stała liczba kolumn, a nie lista: jedna
podstawowa nazwa i opis plus trzy dodatkowe, widoczne w
[opublikowanym schemacie pól tego obiektu](https://demo.flexibee.eu/c/demo/cenik/properties.json)
(sprawdzono 4 sierpnia 2026 roku, gdzie firma demonstracyjna oznacza je
jako angielski, niemiecki i francuski). To cztery sloty językowe w
obiekcie głównym, a własny artykuł pomocy ABRA potwierdza, że więcej
języków jest możliwych tylko przez dodanie niestandardowych pól dla
każdego języka, co jest pracą integracyjną, nie konfiguracyjną. Money
udostępnia
zlokalizowane nazwy i opisy przez
[widoki PLUS swojego konektora e-commerce](https://developer.moneyerp.com/eshop-konektor/vycitani-dat-e-shopem/),
a Comarch ERP Optima przechowuje nazwy i opisy dla języka na tej samej
zakładce e-Handel, na której znajdują się pola SEO. Business Central
eksportuje tłumaczenia pozycji do Shopify w jedną stronę i był jedynym
systemem w tej grupie, którego dokumentacja opisywała mostek
niestandardowych pól, mapujący jego pola na metapola Shopify. Dla SAP
Business One i InsERT nie znaleźliśmy udokumentowanego eksportu tekstów
produktowych w wielu językach, choć portal dokumentacji SAP renderuje
treści tylko dla klienta JavaScript i nie mogliśmy odczytać całości,
więc traktujemy to jako niepotwierdzone, a nie jako nieistniejące.

Dwa kolejne ograniczenia po stronie ERP po cichu psują integracje, bo
oba są sztywnymi pułapami, a nie błędami. ABRA Flexi koduje poziomy
ilościowe jako stałe kolumny, a nie wiersze, co ogranicza ceny
wolumenowe do pięciu poziomów. Helios wyraża każdy poziom cenowy w
maksymalnie sześciu walutach, jednej krajowej i pięciu zagranicznych.
Siatka poziomów lub lista walut, która przerasta możliwości ERP,
przestaje być wyrażalna w systemie rekordów, bez zgłoszenia błędu.

Warto znaleźć w pierwszej kolejności: flagę, która decyduje, jakie SKU
może zobaczyć storefront. Każdy system ma taką flagę i każdy nazywa ją
inaczej: `isInternet` na
[karcie towarowej POHODA](https://www.stormware.cz/schema/version_2/stock.xsd),
`exportNaEshop` na pozycji cennikowej ABRA Flexi, opisane w
[opublikowanym schemacie pól](https://demo.flexibee.eu/c/demo/cenik/properties.json)
i używane jako filtr we własnym przewodniku integracyjnym ABRA. Kto jest
właścicielem tej flagi, kontroluje katalog, niezależnie od tego, co mówi
na ten temat reszta projektu. Helios ustala kierunek autorytatywności
inaczej, poprzez zakres swojego API: z siedemnastu ścieżek w
[opublikowanym opisie API eShop](https://public.helios.eu/inuvio/api/eshop/Inuvio_doc_api_eshopv2.json)
zapis przyjmują tylko zamówienia i klienci. Produkty, kategorie, cenniki
i stany magazynowe są tylko do odczytu, co z definicji czyni ERP
systemem autorytatywnym.

## Pola dodane przez prawo

Niektóre z kwestionowanych pól są nowe i pojawiły się z regulacji, a
nie z merchandisingu, więc żaden system nie był zaprojektowany, by
je posiadać.

[General Product Safety Regulation](https://eur-lex.europa.eu/eli/reg/2023/988/oj)
(rozporządzenie (UE) 2023/988, obowiązujące od 13 grudnia 2024 roku)
wymaga, by oferta sprzedaży na odległość zawierała nazwę producenta oraz
jego adres pocztowy i elektroniczny, to samo dla osoby odpowiedzialnej
producenta spoza UE, informacje identyfikujące produkt, w tym zdjęcie i
jego rodzaj, a także wszelkie ostrzeżenia lub informacje dotyczące
bezpieczeństwa „w języku łatwo zrozumiałym dla konsumentów, określonym
przez państwo członkowskie, w którym produkt jest udostępniany na
rynku”. Ten ostatni zapis czyni tekst o bezpieczeństwie polem treści
właściwym dla każdego rynku, a wybór języka należy do docelowego państwa
członkowskiego, nie
do ciebie. Rozporządzenie wymaga też, by za każdy produkt odpowiadał
podmiot gospodarczy ustanowiony w UE.

Etykietowanie energetyczne dodaje kolejne wymagania.
[Rozporządzenie (UE) 2017/1369](https://eur-lex.europa.eu/eli/reg/2017/1369/oj)
wprost wymienia sprzedaż internetową na odległość w obowiązku sprzedawcy
dotyczącym wyświetlania etykiety (art. 5 ust. 1 lit. a); karta
informacyjna produktu musi być udostępniona klientom na podstawie
kolejnego punktu, już bez tego zastrzeżenia. Artykuł 6 lit. a) odrębnie
wymaga, by wizualna reklama konkretnego modelu zawierała zarówno klasę
efektywności, jak i zakres klas dostępnych na etykiecie. Baza EPREL
wymaga od dostawców rejestracji każdego nowego modelu od 1 stycznia 2019
roku. Konsekwencje sięgają pliku produktowego:
[Google Merchant Center](https://support.google.com/merchants/answer/7052112)
od kwietnia 2025 roku wymaga kodu rejestracyjnego EPREL w atrybucie
certyfikacji dla produktów objętych tym obowiązkiem, kierowanych na
rynek UE, i obecnie ogranicza swój atrybut klasy efektywności
energetycznej do Szwajcarii, Norwegii i Wielkiej Brytanii.

Kanały już zamodelowały te pola.
[API Allegro](https://developer.allegro.pl/documentation) prowadzi
osoby odpowiedzialne i odpowiedzialnych producentów jako osobne
zasoby, informacje o bezpieczeństwie dla oferty oraz flagę dla
produktów wprowadzonych na rynek przed obowiązkiem GPSR. Heureka
dokumentuje dedykowane pola na adres pocztowy i elektroniczny
producenta. Te pola potrzebują więc systemu rekordów, który może je
poświadczyć dla rynku i dla języka, a często żaden istniejący system
go nie ma: ERP rejestruje dostawcę, nie osobę odpowiedzialną, a
storefront rejestruje treść, nie atest. Praktycznym miejscem
na to jest metapole albo zestaw atrybutów dla rynku w witrynie
sklepowej, wypełniany przy wdrażaniu dostawcy, nie przy wystawianiu
oferty, z kontrolą pustego pola stosowaną do produktów nowych i
edytowanych, nie retroaktywnie. Uruchamiaj to jako bramkę dla nowych
ofert i jako raport dla istniejącego katalogu: zastosowana do
katalogu liczącego tysiące SKU od dziesiątek dostawców, twarda
blokada wycofuje sklep z publikacji tego samego dnia, kiedy ją
włączysz.

## Ceny B2B to inny mechanizm na każdej platformie

Adobe umieszcza ceny B2B w katalogach współdzielonych, które są częścią
modułu Adobe Commerce B2B, a więc niedostępne w Magento Open Source czy
Mage-OS. Ich włączenie dodaje opcję Shared Catalog do selektora grup
klientów na stronie
[Advanced Pricing](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/pricing/pricing-advanced)
produktu, dzięki czemu ta sama siatka poziomów jest edytowana z jednego
miejsca dla obu stron.

Shopify prowadzi B2B przez tę samą maszynerię katalogów i cenników co
rynki, przy czym katalog jest przypisany do lokalizacji firmy.
Ograniczeniem są limity planu. Dokumentacja
[katalogów B2B](https://help.shopify.com/en/manual/b2b/catalogs) Shopify
podaje, że w planach Basic, Grow i Advanced „można przypisać do 3
aktywnych katalogów łącznie na wszystkich rynkach B2B”, podczas gdy plan
Plus daje ich nieograniczoną liczbę i przypisanie bezpośrednio do firm i
lokalizacji (sprawdzono 4 sierpnia 2026 roku). Gdy do jednej lokalizacji
firmy odnosi się kilka katalogów, wyświetlana jest najniższa cena.
Dokumentacja konektora
[Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/shopify/synchronize-items)
Microsoftu podaje, że synchronizacja cen B2B wymaga subskrypcji Shopify
Plus, a przynależność do katalogu jest zarządzana w panelu
administracyjnym Shopify, nie w ERP.

Wynikająca z tego reguła własności jest taka sama w obu przypadkach:
ERP jest właścicielem tego, na co dany klient uzgodnił cenę w
kontrakcie, a platforma jest właścicielem tego, do jakiego katalogu
ten klient jest przypisany. Dalszy podział oznacza wpisanie warunków
kontraktu do narzędzia merchandisingowego.

## Kiedy PIM się opłaca

PIM jest wart swojej ceny w punkcie, w którym wartości dla lokalizacji
i dla kanału przestają mieścić się w platformie. Obie wiodące opcje
modelują to bezpośrednio, a ich licencjonowanie różni się na tyle, że
decyduje o wyborze wcześniej niż same funkcje.

Mechanizm Akeneo to dwie niezależne flagi na każdym atrybucie:
localizable i scopable. Wartość produktu to trójka: lokalizacja,
zakres i dane, a kanał grupuje lokalizacje, waluty, drzewo kategorii
i jednostki przeliczeniowe dla jednego miejsca publikacji. Community
Edition jest open source na licencji OSL-3.0 i jest aktywnie
rozwijane, z wydaniem v2026.3 oznaczonym datą 30 marca 2026 roku, a
Akeneo ogranicza swoją tabelę końca wsparcia do wersji płatnych, nie
do Community. Zastrzeżenie dotyczy aktualizacji: Community przeszło
na wersjonowanie kalendarzowe, a Akeneo nie gwarantuje zgodności
wstecznej między żadnymi dwiema wersjami. Komercyjnie sprzedaje trzy
poziomy SaaS, a jego strona porównawcza renderuje ceny za pomocą
skryptów po stronie klienta, a nie jako statyczny tekst, więc nie
podajemy stąd żadnej liczby. W obiegu są zewnętrzne szacunki cen
Akeneo; żadne nie jest potwierdzone na stronie Akeneo, więc ich nie
powtarzamy.

Pimcore, z siedzibą w Salzburgu, zmieniło licencję w sposób, który ma
bezpośrednie znaczenie dla czytelnika tego artykułu.
[Od wersji platformy 2025.1 nie jest już open source](https://pimcore.com/en/resources/blog/breaking-free-pimcore-says-goodbye-to-gpl-and-enters-a-new-era-with-pocl):
publicznie dostępny kod jest objęty Pimcore Open Core Licence, licencją
typu source-available, a jego własny plik `composer.json` w aktualnej
gałęzi deklaruje licencję jako proprietary.
[Tekst licencji](https://raw.githubusercontent.com/pimcore/pimcore/2026.x/LICENSE.md)
udziela bezpłatnego użycia produkcyjnego wyłącznie organizacjom, których
łączny globalny przychód nie przekracza 5 milionów euro rocznie, na
zasadzie samocertyfikacji podlegającej audytowi z opłatami
retroaktywnymi, zakazuje oferowania Pimcore jako usługi hostowanej lub
zarządzanej, zakazuje uruchamiania równolegle Pimcore na licencji GPLv3
i zawiera klauzulę dotyczącą telemetrii, w którą licencjobiorca
zobowiązuje się nie ingerować. Jego
[opublikowane ceny katalogowe](https://pimcore.com/en/pricing) to 9900
dolarów rocznie za wersję Professional i 29 900 dolarów za wersję
Enterprise, obie w modelu on-premises, z ceną PaaS podawaną na
zapytanie. Dla sklepu o przychodach powyżej 5 milionów euro Pimcore
oznacza zakup licencji komercyjnej.

## Procedura

Zanim wybierzesz jakiekolwiek narzędzie, spisz listę pól. Dla
każdego pola nazwij system, który tworzy i utrzymuje wartość, zakres,
w jakim platforma może ją przechowywać, oraz co się dzieje, gdy obie
strony się nie zgadzają. Kierunek wynika z tego pierwszego: system
rekordów zapisuje, a wszystko inne odczytuje, więc pole z dwoma
autorami zapisu nie ma właściciela. Sprawdź następnie trzy rzeczy,
które wychwytują większość błędnych projektów: czy zakładany zakres w
ogóle istnieje (cena dla widoku sklepu nie istnieje w Magento), czy
model danych właściciela pomieści potrzebny zasięg (pięć walut, pięć
poziomów, trzy dodatkowe lokalizacje), oraz czy nic innego nie
zapisuje tego samego pola bez twojej wiedzy. Dwustronna edycja
jednego pola w dwóch systemach to projekt, którego należy unikać, a
zwykle powstaje on przez zaniedbanie, nie z wyboru.

Następnie zdecyduj o propagacji, pamiętając, że pierwsze
wczytanie danych i stan ustabilizowany to dwa różne systemy.
Początkowe wczytanie katalogu to zadanie zbiorcze: operacje zbiorcze
Shopify przyjmują JSONL i działają asynchronicznie, a Magento ma
asynchroniczny bulk REST i importer CSV. Stan ustabilizowany to
delta, a mechanizm dyktuje to, co jest w stanie wysłać właściciel
danych. ERP, który udostępnia jedynie nocny eksport plikowy, nie
może przesyłać danych push, niezależnie od tego, jak zaprojektowano
integrację, więc delta staje się zaplanowanym odpytywaniem z filtrem
„zmienione od”, a świeżość danych w storefroncie jest ograniczona
interwałem eksportu, niezależnie od tego, co komukolwiek obiecano.
Uzgadnianie (reconciliation) to trzecie zadanie, nieopcjonalne:
okresowe pełne porównanie, które wychwytuje to, czego nie wychwyciła
delta, bo plik, którego nikt nie audytuje, dryfuje bezgłośnie.

W Shopify z tego, jak
[synchronizuje się `productSet`](https://shopify.dev/docs/apps/build/graphql/migrate/new-product-model/sync-data),
wynika jeszcze jedna reguła: w polu listowym, które wysyłasz, usuwa on
wpisy, które pominiesz, więc częściowa lista wariantów usuwa warianty,
których w niej nie umieszczono. Używaj go tylko tam, gdzie system
wysyłający jest właścicielem całej listy, którą wysyła, a tam, gdzie
własność jest podzielona, używaj mutacji celowanych.

Mapowanie tej listy pól i budowanie integracji, które ją obsługują,
to zakres naszej
[usługi integracji](/pl/services/integrations/), a prace
niestandardowe wykraczające poza model danych platformy to
[custom development](/pl/services/custom-development/). Niezależnie od
wybranych narzędzi, to lista pól jest podstawą, na której budowana
jest integracja.