---
title: "Kdo vlastní které pole: e-shop, ERP, nebo PIM"
description: "Sklad je jednoduché pole. Ceny, parametry, média, alt texty, texty pro jednotlivé jazyky a URL klíče zapisují dva systémy zároveň a pravidlo vlastnictví je omezené tím, co dokáže vyjádřit vaše platforma."
author: "Luboš Zápotočný"
published: "2026-08-06"
language: "cs"
canonical: "https://zapolu.com/cs/blog/kdo-vlastni-ktere-pole/"
---

# Kdo vlastní které pole: e-shop, ERP, nebo PIM

Každý obchod, který se napojí na ERP, si nakonec vyřeší, kdo vlastní
skladové číslo. Odpověď zní
[téměř vždy ERP nebo skladový systém](/cs/blog/erp-eshop-stock-mismatch/),
protože právě tam se zboží rezervuje a fyzicky
pohybuje, a jakmile je to jednou zapsané, chyby synchronizace se stávají
mechanickou záležitostí.

Pak přijde stejná otázka pro každé další pole a úhledná
odpověď přestává fungovat. Sklad je jedno číslo s jedním významem. Cena je
jedno číslo na web, na trh nebo na zákaznickou firmu.
Text produktu je jedna hodnota na jazyk. Obrázek je jeden soubor, ale jeho
alt text je věta na jazyk. O tom, kdo vlastní sklad, se dlouho nikdo
nehádá. Zbytek záznamu je místo, kde otázka vlastnictví
zůstává otevřená.

Tento článek dává pravidlo vlastnictví po jednotlivých polích pro ceny,
parametry, média, texty pro jednotlivé jazyky, B2B ceny a URL klíče, a pak
každé pravidlo ověřuje proti tomu, co Magento a Shopify skutečně dokážou
vyjádřit, kde končí ERP systémy používané ve střední Evropě a kdy se
PIM vyplatí. Z platforem se text věnuje Magentu a Shopify; český nebo
slovenský obchod bude s přinejmenším stejnou pravděpodobností provozován
na Shoptetu a
otázka vlastnictví polí je tam stejná, i když mechanismy
se liší. Každý fakt o dodavateli byl 4. srpna 2026 ověřen proti jeho
vlastní dokumentaci a ty klíčové mají u sebe
odkaz; kde to nebylo možné ověřit, tak to říkáme.

## Jeden vlastník na pole, v jednom rozsahu

Princip z článku o skladu stále platí: jeden systém záznamu
na fakt. Co se mění, je to, že pole není fakt, dokud nemáte
pojmenovaný i jeho rozsah. „ERP vlastní cenu“ není pravidlo, které
integrace dokáže implementovat. „ERP vlastní katalogovou cenu za web a
cenu za zobrazení obchodu nevlastní nikdo, protože platforma ji neumí
uložit“ je.

Slovník pro tuto oblast předchází e-commerce. Pat Helland ve stati
[Data on the Outside versus Data on the Inside](https://www.cidrdb.org/cidr2005/papers/P12.pdf)
(CIDR 2005) uvádí pravidlo v jedné větě: „Referenční data jsou typ
informací, které vytváří a/nebo spravuje jedna služba a publikuje je
ostatním službám k použití... Pro každou položku existuje přesně jedna
publikující služba.“

Literatura o správě dat říká to stejné jinými
slovy a vyplatí se je přejmout, protože pojmenovávají dvě role,
které systémy obchodu hrají. DAMA-DMBOK, druhé vydání, kapitola 10
(Referenční a kmenová data), definuje systém záznamu jako „autoritativní
systém, kde jsou data vytvářena/zaznamenávána a/nebo udržována podle
definovaného souboru pravidel a očekávání,“ a referenční systém jako
„autoritativní systém, kde konzumenti dat mohou získat spolehlivá data
pro podporu transakcí a analýz, i když informace nepochází ze
samotného referenčního systému.“ Jeden ze šesti hlavních principů pro
referenční a kmenová data je Autorita: „Hodnoty kmenových dat by měly
být replikovány pouze ze systému záznamu.“ Dalším je Vlastnictví,
které tato literatura pojímá na úrovni organizace, nikoli na úrovni
pole. Váš e-shop je referenčním systémem pro většinu záznamu o
produktu, a spor, o který v tomto článku jde, je, který systém je
záznamem pro každé jednotlivé pole.

Až na úroveň granularity už ale literatura nezachází. Druhé vydání
pojmenovává označení
a mezi obchodní pravidla, která správa kmenových dat potřebuje, řadí
pravidla pro shodu, sloučení, přežití a důvěryhodnost, ale zabývá se
entitami a datovými prvky obecně, ne konkrétní otázkou, který systém
vlastní alt text e-shopu v polštině. Čtyři styly MDM, obvykle uváděné
jako registr, konsolidace, koexistence a transakční, se běžně přisuzují
Gartneru; vlastní stránky Gartneru odmítly každého klienta, kterého jsme
zkusili, a otevřeně čitelný zdroj, který jsme našli, přisuzuje tyto
styly
[konzultantům pro správu dat a dodavatelům MDM](https://www.techtarget.com/searchdatamanagement/definition/master-data-management),
nikoli Gartneru, takže je používáme jako běžný popis, a ne jako
definici.

Propagace má lépe pojmenované vzory. Push feed je konzument řízený
událostmi, zatímco noční úloha je
[polling consumer](https://www.enterpriseintegrationpatterns.com/patterns/messaging/PollingConsumer.html);
tolerování opakované zprávy je
[Idempotent Receiver](https://www.enterpriseintegrationpatterns.com/patterns/messaging/IdempotentReceiver.html),
jehož dvě zdokumentované cesty jsou explicitní deduplikace a sémantika,
díky níž je opětovné zpracování neškodné; a obnovení pořadí ve streamu,
který dorazil v jiném pořadí, je
[Resequencer](https://www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html).
Hellandova práce
[Life beyond Distributed Transactions](https://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf)
(CIDR 2007) uvádí požadavek, který tyto vzory mají plnit: „aplikace musí
tolerovat opakované pokusy o doručení zprávy a příchod některých zpráv
mimo pořadí.“

## Co dokáže vyjádřit vaše platforma

Pravidlo vlastnictví, které platforma nedokáže vyjádřit, nelze
implementovat, a proto pravidlo ověřte proti datovému modelu dříve, než
ho s kýmkoli odsouhlasíte.

**Magento rozlišuje rozsahy podle hierarchie obchodů.** Adobe
dokumentuje
[kaskádu global, website, store a store view](https://experienceleague.adobe.com/en/docs/commerce-admin/start/setup/websites-stores-views),
ale atribut produktu má rozsah jen na třech z těchto čtyř úrovní: úroveň
store nese kořenovou kategorii, nikoli hodnoty atributů, takže atribut
je buď globální, nebo na úrovni website, nebo store view. Většinu otázek
vlastnictví rozhodují dvě omezení. Cena nemá volně nastavitelný rozsah:
nastavení
[Catalog Price Scope](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/pricing/catalog-price-scope)
nabízí pouze Global nebo Website, stránka přímo uvádí, že „Commerce
neumožňuje nastavit cenu produktu pro každý store,“ a v administraci je
toto nastavení dostupné jen na úrovni Default Config, takže jde o jeden
přepínač pro celou instalaci. Některé atributy nelze přenastavit vůbec:
Magento uzamyká výběr rozsahu u `sku` a `category_ids` v
[eav_attributes.xml](https://raw.githubusercontent.com/magento/magento2/2.4-develop/app/code/Magento/Catalog/etc/eav_attributes.xml)
a vypíná ho pro `sku` a `media_gallery` v
[konfiguraci administračního formuláře](https://raw.githubusercontent.com/magento/magento2/2.4-develop/app/code/Magento/Catalog/etc/adminhtml/di.xml)
(2.4-develop, ověřeno 4. srpna 2026). Atribut použitý jako
konfigurovatelná volba
[musí být Global](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/product-attributes/product-attributes-add),
ačkoli popisky jeho hodnot zůstávají přeložitelné po jednotlivých store
view.

**Shopify odděluje tvorbu cen od překladu a jde o odlišné mechanismy.**
Varianta nese jednu základní cenu v záznamu produktu; ručně zadaná cena pro
daný trh je uložena zcela mimo produkt, v ceníku navázaném na katalog
navázaný na trh. Trh se může od základní ceny lišit i bez jakéhokoli
ceníku, prostřednictvím přepočtu měny a zaokrouhlovacích pravidel.
Magento nemá ekvivalent: ručně zadaná cena pro trh znamená website na trh,
přičemž store view pod ním tuto cenu sdílejí. Překlad je samostatná
vrstva a na samotném zdroji produktu je úzký: přeložitelné jsou pouze
title, body, handle, product type, meta title a meta description, a
[tagy zdroje přeložit vůbec nelze](https://shopify.dev/docs/apps/build/markets/manage-translated-content).
Přeložitelné jsou i názvy voleb, hodnoty voleb a veřejně přístupná
metapole, jako vlastní typy zdrojů. Překlad lze pomocí `marketId` na
vstupu překladu omezit i na jeden konkrétní trh, takže stejný jazyk se
může na dvou trzích číst jinak. Výjimkou jsou URL handly: Shopify uvádí,
že je nelze přizpůsobit podle trhu. Pro toho, kdo vlastní zápisovou
cestu, jsou důležité dva mechanismy: zápis překladu vyžaduje zdrojový
`translatableContentDigest` a
[`Translation.outdated`](https://shopify.dev/docs/api/admin-graphql/latest/objects/Translation)
hlásí, zda se původní obsah od zápisu překladu změnil. Díky tomu je
zastaralost zjistitelná, ale sama o sobě ji neřeší. A `productSet`
slaďuje seznamová pole se zaslaným payloadem: u variant, metapolí a
kolekcí vytváří a aktualizuje to, co je v payloadu, a maže to, co tam
není, takže naivní dílčí úloha „synchronizovat všechno“ je destruktivní.
Výše popsané chování odpovídá Admin API verze 2026-07, ověřeno 4. srpna
2026.

## Odpověď po jednotlivých polích

| Pole | Systém záznamu | Rozsah, který skutečně zvládne | Při konfliktu |
| ----- | ---------------- | -------------------------- | ----------- |
| Identita produktu | ERP, jako náhradní id | ID z ERP uchovávejte v atributu Magenta nebo metapoli Shopify; nespojujte podle SKU, které se přejmenovávají | Vyhrává id z ERP; změněné SKU je přejmenování, ne nový produkt |
| Katalogová cena | ERP | Magento: pouze globálně nebo na úrovni website. Shopify: jedna základní hodnota na variantu | Vyhrává ERP; úpravy v obchodě se při další synchronizaci přepíšou |
| Daňový základ a daňová třída | ERP | Magento: `tax_class_id` je atribut s rozsahem na úrovni website, zobrazení bez/s DPH je samostatné nastavení. Shopify: příznak produktu plus daňová nastavení podle trhu | Rozhodněte, která strana výpočtu DPH je autoritativní, a zapište to. Český nebo polský B2C katalog se autorsky tvoří s cenou s DPH, takže odvozování ceny s DPH z čisté ceny z ERP vkládá zaokrouhlování mezi ERP a cenu, kterou vidí zákazník |
| Cena podle trhu nebo kanálu | Obchod | Ceníky Shopify podle katalogu a trhu a k tomu přepočet měny. Magento tyto dvě věci nedokáže oddělit: cena na websitu je jediná hodnota, takže kdo vlastní katalogovou cenu, vlastní i cenu podle trhu | Pro zobrazení vyhrává obchod. ERP na objednávce přesto dostává prodejní cenu a nesmí importovanou objednávku přecenit podle vlastního ceníku |
| Akční cena | Obchod, pokud schválení marže nedrží ERP | Magento: stejný rámec jako katalogová cena, nebo cenové pravidlo katalogu podle websitu a zákaznické skupiny. Shopify: srovnávací cena (compare-at), nebo úprava katalogu | Pokud schválení marže sedí v ERP, vlastní ji ERP a obchod nesmí zároveň spouštět katalogová pravidla na stejných produktech |
| B2B nebo smluvní cena | ERP | Magento: cenové úrovně podle zákaznické skupiny na website; sdílené katalogy jen s Adobe Commerce B2B. Shopify: katalogy podle lokace firmy | Vyhrává ERP. Nad pár desítek cenových profilů ani jedna platforma nemodeluje smlouvy podle zákazníka dobře |
| Fyzický sklad | ERP, nebo WMS tam, kde existuje | Podle zdroje. Prodejné množství si platforma dopočítává ze zdrojů minus rezervace a nelze ho zapisovat | Nikdy nezapisujte prodejné množství; zapisujte množství podle zdroje a nechte platformu, ať si ho odvodí |
| Sada variant | PIM, jinak obchod | Konfigurovatelné produkty v Magentu potřebují globální atributy pro volby; většina ERP drží každou variantu jako samostatnou položku bez rodiče | Vlastní ten, kdo vlastní nadřazené seskupení; ERP to obvykle neumí vyjádřit |
| Parametry a volby | PIM, jinak obchod | Atributy konfigurovatelných voleb musí být v Magentu globální | Vyhrává PIM; obchod je jen zobrazovací kopie |
| Mediální soubory | DAM, jinak PIM | Jedna globální sada souborů; v Magentu jsou role base, small a thumbnail podle store view | Vyhrává DAM, ale jen pokud udržuje stabilní identitu každého assetu; po přejmenování při opětovné synchronizaci osiří každá role vázaná na store view |
| Alt text | PIM, jinak obchod | Podle store view v Magentu, podle jazykové verze na Shopify | Vyhrává vlastník textů |
| Text pro jednotlivé jazyky | ERP až do svého jazykového stropu, jinak PIM, jinak obchod | Store view v Magentu; na Shopify pět ze šesti přeložitelných polí produktu, a k tomu názvy voleb, hodnoty voleb a veřejně čitelná metapole (handle je řádek URL) | Vyhrává zdrojový jazyk; zastaralý překlad se označí příznakem, nenahrazuje se |
| URL klíč nebo handle | Obchod | Podle store view v Magentu; podle jazykové verze na Shopify, ale handly nelze přizpůsobit podle trhu | Vyhrává obchod; nikdy negenerujte znovu z názvu produktu |
| Publikace a stažení z nabídky | ERP pro způsobilost, obchod pro kanál | Příznak z ERP (`isInternet`, `exportNaEshop`) rozhoduje o zařazení do katalogu; obchod publikuje podle websitu nebo kanálu | Deaktivujte, nemažte: smazaný produkt ztrácí URL, recenze i historii přesměrování |
| Členství v kategorii nebo kolekci | PIM, jinak obchod | Jedno globální přiřazení v Magentu; kolekce na Shopify. Strom skupin produktů z ERP je vstup, ne záznam | Vyhrává PIM; strom z ERP se mapuje, nezrcadlí se |
| Regulační pole | Obchod, doplňováno ze záznamů dodavatele | Podle trhu, v jazyce, který daný členský stát akceptuje | Nikdo nesmí atestaci automaticky přepsat |

Dva řádky je třeba rozvést podrobněji: média a URL klíče.

**Obrázek je globální, jeho alt text nikoli.** Adobe uvádí, že „nové
obrázky produktu se **_vždy_** nahrají a jsou vidět ve **_všech_** store
view, i když se pro nahrání nepoužije rozsah `All Store Views`“
([obrázky a video u produktu](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/digital-assets/product-image),
ověřeno 4. srpna 2026), a galerie ukládá jeden soubor na obrázek bez
sloupce pro obchod. DAM proto vlastní sadu assetů pro všechny jazykové
verze najednou. Podle store view se řídí řádek vedle každého obrázku:
popisek, pozice a příznak skrytí, takže alt text, pořadí obrázků i to,
který obrázek je skrytý, jsou pole vázaná na store view. Jedna výhrada
toto úhledné rozdělení komplikuje: role obrázku (base, small, thumbnail,
swatch) jsou atributy s rozsahem podle store view a nesou cestu k
souboru, takže i to, který z globálních souborů se na daném e-shopu
vykreslí, se může lišit podle jazykové verze. Shopify vede hranici na
stejném místě, ale z opačné strany: u mediálního obrázku je jediné
přeložitelné pole `alt`. Jeho dokumentace k
[Translate & Adapt](https://help.shopify.com/en/manual/international/translate-adapt-app)
uvádí obrázky produktu mezi typy obsahu, které aplikace nedokáže
přeložit, zatímco ostatní obrázky a videa u přeloženého zdroje lze pro
daný jazyk nahradit nahráním alternativního souboru (ověřeno 4. srpna 2026).

Toto rozdělení má větší význam, než se zdá, protože alt text není
technické pole. [Evropský akt o
přístupnosti](https://eur-lex.europa.eu/eli/dir/2019/882/oj) se
vztahuje na e-commerce služby prodávané spotřebitelům a členské
státy musí jeho opatření uplatňovat od 28. června 2025. Samotná
směrnice vyžaduje, aby tyto služby byly vnímatelné, ovladatelné,
srozumitelné a odolné, aniž by přímo jmenovala alt text; konkrétní
požadavek na textovou alternativu vyjadřuje norma EN 301 549, která
odkazuje na WCAG. Platná verze, V3.2.1, byla harmonizována podle
směrnice o přístupnosti webových stránek, nikoli podle aktu o
přístupnosti, a verze V4.1.0 vztahující se k EAA v době naší
kontroly ještě nebyla citována v Úředním věstníku. Výjimka pro
mikropodniky je [užší, než vypadá](/cs/blog/accessibility-act-ecommerce/),
a samostatné posouzení nepřiměřené zátěže má k dispozici každý
poskytovatel. Alt text je obsah vázaný na jazyk, ke kterému se
pojí požadavky na soulad s předpisy, a tvoří se tam, kde vzniká
i zbytek textů. Nahrávací proces žádné z platforem k němu podle
jazykové verze nevybízí.

**URL klíč obvykle patří obchodu, ale ne proto, že by si ho nikdo jiný
nenárokoval.** Většina ERP nemá k URL adresám e-shopu žádný názor, a
láká to k závěru, že pole nemá konkurenčního uchazeče. Má. Vlastní
dokumentace e-Sklep od Comarch ERP Optima dává ERP záložku
Pozycjonowanie (pozicování) s titulkem stránky, vyhrazeným polem `Link`
pro sestavení URL, klíčovými slovy a meta popisem, a to jak pro skupiny
produktů, tak pro jednotlivé položky
([nápověda Comarch Optima, verze 2026_5](https://pomoc.comarch.pl/optima/pl/2026_5/dokumentacja/wspolpraca-z-comarch-e-sklep/),
ověřeno 4. srpna 2026). Handly zapisují i konektory a PIM, ať už jádro
ERP dokumentuje cokoli.

Provozní pravidlo je lepší než argument rozsahem, protože Comarch
ukazuje, že ERP dokáže toto pole vyjádřit. Kdo vlastní URL klíč,
vlastní i všechny důsledky jeho změny, a tyto důsledky dopadají mimo
systém, který změnu provedl. Rozhodující tedy je, co se stane při
přejmenování. Magento z toho dělá nastavení, „Create Permanent
Redirect for URLs if URL Key Changed“, a kdo vlastní klíč, zdědí
rostoucí tabulku přesměrování.

Necháte-li toto pole měnit externí systém, ponesete přímé náklady.
Heureka ve své
[specifikaci feedu](https://sluzby.heureka.cz/napoveda/xml-feed/)
označuje čtyři prvky jako bezpodmínečně povinné, název produktu, ID
položky, cenu s DPH a URL, a uvádí, že když se v XML změní URL produktů,
názvy nebo kategorie, všechny produkty se rozpojí od svých karet na
Heurece a čekají na opětovné spárování, což podle ní může trvat zhruba
čtyři pracovní dny. PIM, který regeneruje handly z názvů produktů, tak
na několik dní rozpojí celý katalog od srovnávače, aniž by v obchodě
cokoli vypadalo rozbitě.

## Kde ERP končí: texty pro jednotlivé jazyky

Pro obchod, který prodává v češtině, slovenštině, němčině a
polštině, dělicí čárou mezi „ERP může vlastnit texty produktu“ a
„musí to zvládnout něco jiného“ obvykle bývá počet jazyků, které
připouští datový model ERP, a bývá nižší než počet trhů, do kterých
obchod této velikosti prodává.

ABRA Flexi vlastní vícejazyčné texty ve své základní entitě ceníku, ale
jako pevný počet sloupců, ne jako seznam: jeden primární název a popis
plus tři další, viditelné ve
[vlastním publikovaném schématu polí entity](https://demo.flexibee.eu/c/demo/cenik/properties.json)
(ověřeno 4. srpna 2026, kde je demoverze firmy označuje jako angličtinu,
němčinu a francouzštinu). To jsou čtyři jazykové sloty v základní
entitě, a vlastní podpůrný článek ABRA potvrzuje, že další jazyky lze
přidat jen pomocí vlastních polí pro jednotlivé jazyky, což je
integrační práce, ne konfigurace. Money zpřístupňuje lokalizované názvy
a popisy přes
[PLUS view svého e-commerce konektoru](https://developer.moneyerp.com/eshop-konektor/vycitani-dat-e-shopem/),
a Comarch ERP Optima nese názvy a popisy podle jazyka na stejné záložce
e-Handel jako svá SEO pole. Business Central exportuje překlady položek
do Shopify jedním směrem a byl jediným systémem v této skupině, jehož
dokumentace popisovala most vlastních polí, mapující jeho pole na
metapole Shopify. Pro SAP Business One a InsERT jsme nenašli žádný
zdokumentovaný export textů produktu pro více jazyků, ačkoli
dokumentační portál SAP se vykresluje jen pro JavaScriptový klient a
nemohli jsme si přečíst všechno, takže to berte jako neověřené, nikoli
jako neexistující.

Další dvě omezení na straně ERP tiše komplikují integrace,
protože obě jsou pevné stropy, ne chyby. ABRA Flexi kóduje
množstevní úrovně jako pevné sloupce, ne jako řádky, a omezuje
objemové ceny na pět úrovní. Helios vyjadřuje každou cenovou úroveň
nejvýše v šesti měnách, jedné domácí a pěti zahraničních. Mřížka
úrovní nebo seznam měn, který přeroste tvar ERP, přestává být v
systému záznamu vyjádřitelný, aniž by to vyvolalo chybu.

Nejdříve se vyplatí najít příznak, který rozhoduje, jaké SKU e-shop smí
vidět. Má ho každý systém a každý ho pojmenovává jinak: `isInternet` na
[skladové kartě POHODA](https://www.stormware.cz/schema/version_2/stock.xsd),
`exportNaEshop` u položky ceníku ABRA Flexi, zdokumentováno v jejím
[publikovaném schématu polí](https://demo.flexibee.eu/c/demo/cenik/properties.json)
a použito jako filtr ve vlastním integračním návodu ABRA. Kdo vlastní
tento příznak, ovládá katalog, ať zbytek návrhu říká cokoli. Helios směr
autority řeší jinak, ve svém API: ze sedmnácti cest v jeho
[publikovaném popisu eShop API](https://public.helios.eu/inuvio/api/eshop/Inuvio_doc_api_eshopv2.json)
přijímají zápis jen objednávky a zákazníci. Produkty, kategorie, ceníky
a sklady jsou jen ke čtení, což dělá ERP autoritativním z podstaty
konstrukce.

## Pole, která přidal zákon

Některá ze sporných polí jsou nová a přišla z regulace, ne
z merchandisingu, a proto je žádný systém nenavrhoval tak, aby je
vlastnil.

[Nařízení o obecné bezpečnosti výrobků](https://eur-lex.europa.eu/eli/reg/2023/988/oj)
(nařízení (EU) 2023/988, účinné od 13. prosince 2024) vyžaduje, aby
nabídka prodeje na dálku obsahovala jméno výrobce a jeho poštovní i
elektronickou adresu, to stejné pro odpovědnou osobu výrobce mimo EU,
informace identifikující produkt včetně obrázku a jeho typu, a jakékoli
varování nebo bezpečnostní informace „v jazyce, kterému spotřebitelé
snadno rozumí, jak jej určí členský stát, ve kterém je produkt dostupný
na trhu.“ Tato poslední klauzule dělá z bezpečnostního textu obsahové
pole podle trhu, přičemž jazyk je na rozhodnutí cílového členského
státu, ne na vašem. Nařízení také vyžaduje hospodářský subjekt usazený v
EU, odpovědný za každý produkt.

Energetické štítkování přidává další požadavky.
[Nařízení (EU) 2017/1369](https://eur-lex.europa.eu/eli/reg/2017/1369/oj)
výslovně zmiňuje online prodej na dálku v povinnosti prodejce zobrazit
štítek (článek 5 odst. 1 písm. a)); informační list výrobku musí být
zákazníkům zpřístupněn podle následujícího bodu, a to bez této podmínky.
Článek 6 písm. a) samostatně vyžaduje, aby vizuální reklama na konkrétní
model uváděla jak třídu účinnosti, tak rozsah tříd dostupných na štítku.
Jeho databáze EPREL vyžaduje od dodavatelů registraci každého nového
modelu od 1. ledna 2019. Důsledek dopadá i na feed:
[Google Merchant Center](https://support.google.com/merchants/answer/7052112)
vyžaduje registrační kód EPREL v atributu certifikace u dotčených
produktů cílených na EU od dubna 2025 a nyní omezuje svůj atribut třídy
energetické účinnosti na Švýcarsko, Norsko a Spojené království.

Kanály už tato pole modelovaly.
[API Allegro](https://developer.allegro.pl/documentation) nese odpovědné
osoby a odpovědné výrobce jako vlastní zdroje, bezpečnostní informace na
úrovni nabídky a příznak pro produkty uvedené na trh před vznikem
povinnosti GPSR. Heureka dokumentuje vyhrazené tagy pro poštovní a
elektronickou adresu výrobce. Tato pole tedy potřebují systém záznamu,
který je dokáže atestovat podle trhu a jazyka, a často žádný existující
systém takový nemá: ERP zaznamenává dodavatele, ne odpovědnou osobu, a
e-shop zaznamenává texty, ne atestaci. Praktickým umístěním je metapole
nebo sada atributů podle trhu na e-shopu, vyplňovaná při onboardingu
dodavatele, ne v okamžiku zařazení do nabídky, přičemž kontrola
prázdného pole se aplikuje na nové a upravované produkty, ne zpětně.
Provozujte to jako bránu pro nové nabídky a jako report nad stávajícím
katalogem: pokud se tvrdá blokace použije na katalog čítající tisíce
SKU od desítek dodavatelů, zruší v den zapnutí publikaci celého
obchodu.

## B2B ceny fungují na každé platformě jiným mechanismem

Adobe umisťuje B2B ceny do sdílených katalogů, které jsou součástí
modulu Adobe Commerce B2B, a proto nejsou dostupné v Magento Open Source
ani v Mage-OS. Jejich zapnutí přidá volbu Shared Catalog do výběru
zákaznické skupiny na stránce produktu
[Advanced Pricing](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/pricing/pricing-advanced),
takže se stejná mřížka úrovní edituje z obou stran.

Shopify vede B2B přes stejný mechanismus katalogů a ceníků jako trhy,
přičemž katalog má rozsah podle lokace firmy. Omezením jsou limity
plánu.
[Dokumentace B2B katalogu](https://help.shopify.com/en/manual/b2b/catalogs)
od Shopify uvádí, že na plánech Basic, Grow a Advanced „lze přiřadit až 3
aktivní katalogy napříč všemi vašimi B2B trhy,“ zatímco Plus nabízí
neomezený počet a přímé přiřazení firmám i lokacím (ověřeno 4. srpna 2026).
Tam, kde na jednu lokaci firmy dopadá více katalogů, zobrazí se
nejnižší cena. Dokumentace Microsoftu ke
[konektoru Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/shopify/synchronize-items)
uvádí, že synchronizace B2B cen vyžaduje předplatné Shopify Plus a že
členství v katalogu se spravuje v administraci Shopify, ne v ERP.

Pravidlo vlastnictví, které z toho plyne, je na obou platformách
stejné: ERP vlastní to, co je s daným zákazníkem smluvně dohodnuté
platit, a platforma vlastní to, ke kterému katalogu je daný zákazník
přiřazený. Jakékoli další dělení vkládá smluvní podmínky do
merchandisingového nástroje.

## Kdy se PIM vyplatí

PIM se svou cenou vyplatí ve chvíli, kdy hodnoty podle jazyka a
kanálu přestávají zapadat do platformy. Obě přední řešení to
modelují přímo a jejich licencování se liší natolik, že rozhoduje o
volbě dříve než samotné funkce.

Mechanismus Akeneo tvoří dva nezávislé příznaky u každého atributu,
localizable a scopable. Hodnota produktu je trojice jazyka,
rozsahu a dat, a kanál sdružuje jazyky, měny, strom kategorií a
převodní jednotky pro jeden publikační cíl. Jeho Community Edition
je open source pod licencí OSL-3.0 a aktivně udržovaná, s vydáním
v2026.3 označeným 30. března 2026, přičemž Akeneo omezuje svou
tabulku konce podpory jen na placené edice, ne na Community.
Výhradou jsou upgrady: Community přešla na kalendářní verzování a
Akeneo se zříká zpětné kompatibility mezi libovolnými dvěma
verzemi. Komerčně prodává tři úrovně SaaS a jeho srovnávací stránka
vykresluje ceny pomocí skriptů na straně klienta, ne jako statický
text, takže z ní žádnou částku neuvádíme. Cenové údaje třetích stran
pro Akeneo kolují, ale žádný z nich není potvrzený na stránce
Akeneo, a proto je neopakujeme.

Pimcore, se sídlem v Salcburku, změnil licenci způsobem, který je pro
čtenáře tohoto článku přímo důležitý.
[Od verze platformy 2025.1 už není open source](https://pimcore.com/en/resources/blog/breaking-free-pimcore-says-goodbye-to-gpl-and-enters-a-new-era-with-pocl):
veřejně dostupný kód je pod licencí Pimcore Open Core, tedy licencí typu
source-available, a jeho vlastní `composer.json` na aktuální větvi
deklaruje licenci jako proprietární.
[Text licence](https://raw.githubusercontent.com/pimcore/pimcore/2026.x/LICENSE.md)
uděluje bezplatné produkční užití jen organizacím, jejichž celkový
celosvětový příjem nepřesahuje 5 milionů eur ročně, na základě vlastní
certifikace a s možností auditu se zpětnými poplatky, zakazuje nabízet
Pimcore jako hostovanou nebo spravovanou službu, zakazuje provozovat
souběžně Pimcore licencovaný pod GPLv3, a obsahuje klauzuli o
telemetrii, u níž se držitel licence zavazuje, že do ní nebude
zasahovat. Jeho
[zveřejněné ceníkové ceny](https://pimcore.com/en/pricing) jsou 9 900
dolarů ročně za Professional a 29 900 dolarů za Enterprise, obojí
on-premises, s PaaS uvedeným zvlášť. Pro obchod s příjmy nad 5 milionů
eur je Pimcore koupí komerční licence.

## Postup

Nejdříve sepište seznam polí, teprve pak vybírejte nástroj. U každého
pole pojmenujte systém, který hodnotu vytváří a udržuje, rozsah, ve
kterém ji platforma dokáže uložit, a co se stane, když se obě strany
neshodnou. Směr vyplývá z prvního bodu: systém záznamu zapisuje a
všechno ostatní čte, a proto pole, do kterého zapisují dva systémy, nemá
vlastníka. Pak zkontrolujte tři věci, na kterých ztroskotá většina
návrhů: zda předpokládaný rozsah skutečně existuje (cena podle store
view v Magentu neexistuje), zda datový model vlastníka pojme rozsah,
který potřebujete (pět měn, pět úrovní, tři navíc jazyky), a zda do
stejného pole nezapisuje za vašimi zády ještě něco jiného. Obousměrná
editace jednoho pole ve dvou systémech je návrh, kterému je třeba se
vyhnout, a obvykle k němu dojde spíše opomenutím než záměrně.

Pak rozhodněte o propagaci a pamatujte, že první načtení a ustálený
stav jsou dva různé systémy. Počáteční načtení katalogu je hromadná
úloha: hromadné operace Shopify přijímají JSONL a běží asynchronně,
Magento má asynchronní hromadné REST rozhraní a CSV importér.
Ustálený stav je delta a mechanismus určuje to, co vlastník dokáže
odeslat. ERP, který nabízí jen noční export souboru, nemůže
data aktivně odesílat, bez ohledu na to, jak je řešení navržené, takže
se z delty stává
plánovaný pull s filtrem podle data změny, a aktuálnost dat na
e-shopu je omezená intervalem exportu bez ohledu na to, co kdo
slíbil. Sesouhlasení dat je třetí úloha, ne volitelná: pravidelné
úplné porovnání, které najde to, co delta minula, protože feed, který
nikdo neaudituje, se tiše vzdaluje od reality.

Na Shopify vyplývá ještě jedno pravidlo z toho, jak
[synchronizuje `productSet`](https://shopify.dev/docs/apps/build/graphql/migrate/new-product-model/sync-data):
v rámci odesílaného seznamového pole maže položky, které vynecháte,
takže dílčí seznam variant odstraní varianty, které v něm chybí.
Používejte ho jen tam, kde odesílající systém vlastní celý každý
odesílaný seznam, a tam, kde je vlastnictví rozdělené, používejte cílené
mutace.

Namapovat tento seznam polí a postavit integrace, které ho nesou, je
to, co pokrývá naše
[služba integrací](/cs/services/integrations/), a práce na míru nad
rámec datového modelu platformy je
[vývoj na míru](/cs/services/custom-development/). Ať zvolíte jakékoli
nástroje, seznam polí je to, z čeho se integrace staví.