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, 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 (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, 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; tolerování opakované zprávy je Idempotent Receiver, 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. 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í.“

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, 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 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 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. 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 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 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á, 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, 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 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 (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, 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, 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í, 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ů (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 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 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 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, 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 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í 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: 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ý 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 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: 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í, 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, seznam polí je to, z čeho se integrace staví.