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

Každý obchod, který se napojí na ERP, si nakonec vyřeší, kdo vlastní stav skladu. Odpověď zní téměř vždy ERP nebo skladový systém, protože právě tam se zboží rezervuje a fyzicky pohybuje, a jakmile je to jednou zapsané, řešení chyb synchronizace se stává rutinou.

Pak přijde stejná otázka pro každé další pole a jednoduchá odpověď přestává platit. 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á. U zbytku záznamu otázka vlastnictví zůstává otevřená.

Tento článek stanovuje pravidla vlastnictví pro jednotlivá pole: ceny, parametry, média, texty pro jednotlivé jazyky, B2B ceny a URL klíče, a pak každé pravidlo porovnává s tím, 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 přitom stejně často, ne-li častěji, běží na Shoptetu a otázka vlastnictví polí je tam stejná, i když mechanismy se liší. Každý fakt o jednotlivých systémech byl 4. srpna 2026 ověřen v dokumentaci příslušného výrobce a u klíčových je uveden odkaz. Kde ověření nebylo možné, uvádíme to.

Jeden vlastník na pole, v jednom rozsahu

Princip z článku o skladu stále platí: jeden systém záznamu na fakt. Nové je to, že pole není faktem, dokud nemáte pojmenovaný i jeho rozsah. „ERP vlastní cenu“ není pravidlo, které integrace dokáže implementovat. „ERP vlastní katalogovou cenu na úrovni website a cenu na úrovni store view nevlastní nikdo, protože platforma ji neumí uložit“ je.

Terminologie pro tuto oblast je starší než e-commerce. Pat Helland ve stati Data on the Outside versus Data on the Inside (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 vyjadřuje stejnou myšlenku 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.“ Jedním 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 tento článek se zabývá tím, který systém je u jednotlivých polí systémem záznamu.

Až na úroveň granularity už ale literatura nezachází. Druhé vydání tento pojem uvádí a mezi obchodní pravidla, která správa kmenových dat potřebuje, řadí pravidla pro párování, slučování, výběr platné hodnoty (survivorship) 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 se nám nepodařilo načíst v žádném prohlížeči ani nástroji, který 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, nikoli Gartneru, takže je používáme jako běžný popis, a ne jako definici.

Pro šíření změn existují lépe pojmenované vzory. Push feed je konzument řízený událostmi, zatímco noční úloha je polling consumer. Tolerování opakované zprávy je Idempotent Receiver, jehož dva zdokumentované přístupy jsou explicitní deduplikace a sémantika, díky níž je opětovné zpracování neškodné. Obnovení pořadí ve streamu, který dorazil v jiném pořadí, je Resequencer. Hellandova práce Life beyond Distributed Transactions (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í.“

Vyjadřovací možnosti vaší platformy

Pravidlo vlastnictví, které platforma nedokáže vyjádřit, nelze implementovat, a proto pravidlo porovnejte s datovým modelem 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, ale atribut produktu má rozsah jen na třech z těchto čtyř úrovní: úroveň store má 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 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 a vypíná ho pro sku a media_gallery v konfiguraci administračního formuláře (2.4-develop, ověřeno 4. srpna 2026). Atribut použitý jako konfigurovatelná volba musí být Global, 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 má v záznamu produktu jednu základní cenu. 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 má jen omezený rozsah: přeložitelné jsou pouze title, body, handle, product type, meta title a meta description, a tagy zdroje přeložit vůbec nelze. 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 text ve stejném jazyce se může na dvou trzích lišit. Výjimkou jsou URL handly: Shopify uvádí, že je nelze přizpůsobit podle trhu. Pro toho, kdo do těchto dat zapisuje, jsou důležité dva mechanismy: zápis překladu vyžaduje zdrojový translatableContentDigest a Translation.outdated 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

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, 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 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 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 stabilní, 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ž se zdá, 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 se URL adresami e-shopu vůbec nezabývá, 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, ověřeno 4. srpna 2026). Handly zapisují i konektory a PIM, ať už jádro ERP dokumentuje cokoli.

Provozní pravidlo je přesvědčivější než argumentace 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 to řeší konfiguračním nastavením, „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 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 se v obchodě projevila jakákoli viditelná chyba.

Hranice ERP: texty pro jednotlivé jazyky

Pro obchod, který prodává v češtině, slovenštině, němčině a polštině, hranici mezi tím, zda texty produktu může vlastnit ERP, nebo je musí zvládnout jiný systém, obvykle určuje počet jazyků, které připouští datový model ERP, a ten bývá nižší než počet trhů, do kterých obchod této velikosti prodává.

ABRA Flexi uchovává vícejazyčné texty přímo v 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 (ověřeno 4. srpna 2026, kde je ukázková firma označuje jako angličtinu, němčinu a francouzštinu). To jsou čtyři jazykové sloty v základní entitě, a vlastní článek nápovědy 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, a Comarch ERP Optima eviduje názvy a popisy v jednotlivých jazycích 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 propojení přes vlastní pole, 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 na straně klienta pomocí JavaScriptu 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řesáhne možnosti datového modelu 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, exportNaEshop u položky ceníku ABRA Flexi, zdokumentováno v jejím publikovaném schématu polí 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 přijímají zápis jen objednávky a zákazníci. Produkty, kategorie, ceníky a sklady jsou jen ke čtení, takže je ERP rozhodujícím zdrojem dat již ze své 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ů (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, stejné údaje pro odpovědnou osobu výrobce usazeného 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 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ů zboží registraci každého nového modelu od 1. ledna 2019. Důsledek dopadá i na feed: Google Merchant Center 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 vede odpovědné osoby a odpovědné výrobce jako samostatné 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 pro každý trh a jazyk doložit, a často žádný existující systém takový nemá: ERP zaznamenává dodavatele zboží, ne odpovědnou osobu, a e-shop zaznamenává texty, nikoli doložené údaje. Praktickým umístěním je metapole nebo sada atributů podle trhu na e-shopu, vyplňovaná při onboardingu dodavatele zboží, 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ě. Uplatňujte ji jako blokující podmínku 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ů zboží, 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, 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 tarifu. Dokumentace B2B katalogu 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 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í ceny smluvně sjednané s daným zákazníkem 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.

Důvody pro PIM

PIM se svou cenou vyplatí ve chvíli, kdy hodnoty podle jazyka a kanálu už platforma nedokáže pojmout. 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: 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 uděluje bezplatné produkční užití jen organizacím, jejichž celkový celosvětový roční obrat nepřesahuje 5 milionů eur, na základě vlastního prohlášení 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 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 obratem nad 5 milionů eur znamená Pimcore nákup 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 jazyky navíc), 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 šíření změn 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: 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í každý odesílaný seznam v celém rozsahu, a tam, kde je vlastnictví rozdělené, používejte cílené mutace.

Zmapování tohoto seznamu polí a vybudování integrací, které ho přenášejí, pokrývá naše služba integrací, a práce na míru nad rámec datového modelu platformy je vývoj na míru. Ať zvolíte jakékoli nástroje, základem integrace je vždy seznam polí.