---
title: "Kto vlastní ktoré pole: e-shop, ERP alebo PIM"
description: "Sklad je jednoduché pole. Ceny, parametre, médiá, alt texty, texty pre jednotlivé jazyky a URL kľúče zapisujú dva systémy súčasne a pravidlo vlastníctva je obmedzené tým, čo dokáže vyjadriť vaša platforma."
author: "Luboš Zápotočný"
published: "2026-08-06"
language: "sk"
canonical: "https://zapolu.com/sk/blog/kto-vlastni-ktore-pole/"
---

# Kto vlastní ktoré pole: e-shop, ERP alebo PIM

Každý obchod, ktorý sa napojí na ERP, si nakoniec ujasní, kto vlastní
číslo skladovej zásoby. Odpoveď je
[takmer vždy ERP alebo skladový systém](/sk/blog/erp-eshop-stock-mismatch/),
pretože práve tam sa tovar rezervuje a fyzicky
presúva, a len čo je to raz zapísané, chyby synchronizácie sa stanú
mechanickou záležitosťou.

Potom sa tá istá otázka objaví pri každom ďalšom poli a úhľadná
odpoveď prestáva fungovať. Sklad je jedno číslo s jedným významom. Cena je
jedno číslo na webovú stránku, na trh alebo na zákaznícku spoločnosť.
Text produktu je jedna hodnota na jazyk. Obrázok je jeden súbor, ale jeho
alt text je veta na jazyk. O tom, kto vlastní sklad, sa nikto dlho neháda.
Pri zvyšku záznamu otázka vlastníctva
zostáva otvorená.

Tento článok uvádza pravidlo vlastníctva pre jednotlivé polia: ceny,
atribúty, médiá, texty pre jednotlivé jazyky, B2B ceny a URL kľúče, a
potom overuje každé pravidlo oproti tomu, čo Magento a Shopify skutočne
dokážu vyjadriť, kde končia ERP systémy používané v strednej Európe a
kedy si PIM zaslúži svoje miesto. Polovicu platformovej časti tvoria
Magento a Shopify; český alebo slovenský obchod je minimálne rovnako
pravdepodobne postavený na Shoptete a otázka vlastníctva polí je tam
rovnaká, aj keď mechanizmy sa líšia. Každý fakt o dodávateľovi bol
overený voči vlastnej dokumentácii daného dodávateľa 4. augusta 2026 a
tie kľúčové nesú svoj odkaz; ak sa niečo nepodarilo overiť, uvádzame to.

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

Princíp z článku o sklade stále platí: jeden systém záznamov na fakt.
Mení sa to, že pole nie je faktom, kým ste nepomenovali aj jeho rozsah.
„ERP vlastní cenu“ nie je pravidlo, ktoré vie integrácia implementovať.
„ERP vlastní katalógovú cenu na úrovni webovej stránky a nikto nevlastní
cenu na úrovni zobrazenia obchodu, pretože platforma ju nedokáže uložiť“
je.

Slovná zásoba na toto predchádza vzniku elektronického obchodu. Pat
Helland v texte
[Data on the Outside verzus Data on the Inside](https://www.cidrdb.org/cidr2005/papers/P12.pdf)
(CIDR 2005) formuluje pravidlo v jednej vete: „Referenčné údaje označujú
typ informácií, ktoré vytvára a/alebo spravuje jedna služba a publikuje
ich ostatným službám na použitie... Pre každú časť existuje presne jedna
publikujúca služba.“

Literatúra o správe dát hovorí to isté, len inými slovami, a oplatí sa
si ich požičať, pretože pomenúvajú dve úlohy, ktoré systémy obchodu
zohrávajú. DAMA-DMBOK, druhé vydanie, kapitola 10 (Referenčné a hlavné
dáta), definuje systém záznamov (System of Record) ako „autoritatívny
systém, v ktorom sa dáta vytvárajú/zachytávajú a/alebo udržiavajú
prostredníctvom definovanej sady pravidiel a očakávaní“, a referenčný
systém (System of Reference) ako „autoritatívny systém, z ktorého môžu
konzumenti dát získať spoľahlivé údaje na podporu transakcií a analýz,
aj keď informácie nemajú pôvod v tomto referenčnom systéme“. Jedným zo
šiestich hlavných princípov pre referenčné a hlavné dáta je Autorita:
„Hodnoty hlavných dát by sa mali replikovať iba zo systému záznamov.“
Ďalším je Vlastníctvo, ktoré je definované na úrovni organizácie, nie na
úrovni poľa. Vaša e-shopová vitrína je referenčným systémom pre väčšinu
záznamu o produkte a otázkou, o ktorú v tomto článku ide, je, ktorý
systém je záznamom pre jednotlivé polia.

Literatúra sa však nedostane až na úroveň granularity. Druhé vydanie
pomenúva
samotné označenie a medzi obchodné pravidlá, ktoré správa hlavných dát
potrebuje, radí aj pravidlá zhody, zlučovania, prežitia a
dôveryhodnosti, ale zaoberá sa entitami a dátovými prvkami vo
všeobecnosti, nie konkrétnou otázkou, ktorý systém vlastní alt text
e-shopu v poľštine. Štyri štýly MDM, zvyčajne uvádzané ako register,
konsolidácia, koexistencia a transakcia, sa bežne pripisujú spoločnosti
Gartner; vlastné stránky Gartnera odmietli každého klienta, ktorého sme
skúsili, a verejne dostupný zdroj, ktorý sme našli, pripisuje tieto
štýly
[konzultantom pre správu dát a dodávateľom MDM riešení](https://www.techtarget.com/searchdatamanagement/definition/master-data-management),
nie Gartneru, takže ich používame ako bežný opis, nie ako definíciu.

Pre šírenie dát existujú lepšie pomenované vzory. Push feed je udalosťami
riadený konzument (event-driven consumer) a nočná úloha je
[konzument s dopytovaním](https://www.enterpriseintegrationpatterns.com/patterns/messaging/PollingConsumer.html)
(polling consumer); tolerovanie opakovanej správy je
[Idempotentný prijímač](https://www.enterpriseintegrationpatterns.com/patterns/messaging/IdempotentReceiver.html)
(Idempotent Receiver), ktorého dva zdokumentované postupy sú explicitná
deduplikácia a sémantika, vďaka ktorej je opätovné spracovanie neškodné;
a obnovenie poradia v prúde, ktorý prišiel mimo poradia, je
[Resequencer](https://www.enterpriseintegrationpatterns.com/patterns/messaging/Resequencer.html).
Hellandov text
[Life beyond Distributed Transactions](https://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf)
(CIDR 2007) formuluje požiadavku, ktorú majú tieto vzory splniť:
„aplikácia musí tolerovať opakované pokusy o doručenie správy a príchod
niektorých správ mimo poradia.“

## Čo dokáže vyjadriť vaša platforma

Pravidlo vlastníctva, ktoré platforma nedokáže vyjadriť, sa nedá
implementovať, preto pravidlo overte oproti dátovému modelu skôr, než ho
s niekým odsúhlasíte.

**Magento definuje rozsahy podľa hierarchie obchodov.** Adobe
dokumentuje
[kaskádu global, website, store a store view](https://experienceleague.adobe.com/en/docs/commerce-admin/start/setup/websites-stores-views),
no atribút produktu je možné obmedziť len na tri z týchto štyroch
úrovní: úroveň store nesie koreňovú kategóriu, nie hodnoty atribútov,
takže atribút je buď globálny, alebo na úrovni website, alebo na úrovni
store view. O väčšine otázok vlastníctva rozhodujú dve obmedzenia. Cena
sa nedá obmedziť ľubovoľne: nastavenie
[Catalog Price Scope](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/pricing/catalog-price-scope)
ponúka len možnosti Global alebo Website, stránka priamo uvádza, že
„Commerce neumožňuje nastaviť cenu produktu pre každý obchod (store)
osobitne“, a administrácia sprístupňuje toto nastavenie iba na úrovni
Default Config, takže ide o jediný prepínač pre celú inštaláciu.
Niektoré atribúty nemožno prenastaviť vôbec: Magento uzamyká selektor
rozsahu pre `sku` a `category_ids` v súbore
[eav_attributes.xml](https://raw.githubusercontent.com/magento/magento2/2.4-develop/app/code/Magento/Catalog/etc/eav_attributes.xml)
a vypína ho pre `sku` a `media_gallery` v
[konfigurácii administračného formulára](https://raw.githubusercontent.com/magento/magento2/2.4-develop/app/code/Magento/Catalog/etc/adminhtml/di.xml)
(2.4-develop, overené 4. augusta 2026). Atribút použitý ako
konfigurovateľná možnosť
[musí byť globálny](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/product-attributes/product-attributes-add),
hoci jeho popisky možností zostávajú preložiteľné na úrovni store view.

**Shopify oddeľuje cenotvorbu od prekladu, ide o dva odlišné
mechanizmy.** Variant nesie jednu základnú cenu priamo v zázname
produktu; ručne zadaná cena pre daný trh je uložená úplne mimo produktu,
v cenníku
(price list) priradenom ku katalógu, ktorý je priradený k trhu. Trh sa
môže od základnej ceny odchýliť aj bez akéhokoľvek cenníka,
prostredníctvom prepočtu meny a zaokrúhľovacích pravidiel. Magento nemá
ekvivalent: ručne zadaná cena na trh znamená website na trh, pričom store
view pod ňou túto cenu zdieľajú. Preklad je samostatná vrstva a na
samotnom zdroji produktu je pomerne úzka: preložiteľné sú len title,
body, handle, product type, meta title a meta description a
[tagy zdroja nie je možné preložiť](https://shopify.dev/docs/apps/build/markets/manage-translated-content)
vôbec. Názvy možností, hodnoty možností a verejne dostupné metapolia sú
tiež preložiteľné, ako vlastné typy zdrojov. Preklad možno tiež obmedziť
na jeden trh prostredníctvom `marketId` vo vstupe prekladu, takže ten
istý jazyk sa môže na dvoch trhoch zobrazovať odlišne. Výnimkou sú URL
handle: Shopify uvádza, že sa nedajú prispôsobiť na úrovni trhu. Pre
toho, kto vlastní cestu zápisu, sú dôležité dve mechaniky: zápis
prekladu vyžaduje `translatableContentDigest` zdroja a
[`Translation.outdated`](https://shopify.dev/docs/api/admin-graphql/latest/objects/Translation)
hlási, či sa pôvodný obsah zmenil od zápisu prekladu. Vďaka tomu je
zastaranosť prekladu zistiteľná, no nerieši ju to. A `productSet`
zosúlaďuje polia typu zoznam s tým, čo pošlete v tele požiadavky
(payload): pri variantoch, metapoliach a kolekciách vytvorí a
aktualizuje to, čo v payloade je, a vymaže to, čo v ňom nie je, čím sa
naivná čiastočná úloha „synchronizuj všetko“ stáva deštruktívnou.
Uvedené správanie platí pre Admin API verzie 2026-07, overené 4. augusta
2026.

## Odpoveď pole po poli

| Pole | Systém záznamov | Rozsah, ktorý dokáže reálne uniesť | Pri konflikte |
| ----- | ---------------- | --------------------------- | ----------- |
| Identita produktu | ERP, ako náhradné ID | Uchovávajte ID z ERP v atribúte Magento alebo metapoli Shopify; nespájajte podľa SKU, ktoré sa dá premenovať | ID z ERP vyhráva; zmenené SKU je premenovanie, nie nový produkt |
| Katalógová cena | ERP | Magento: iba globálne alebo na úrovni website. Shopify: jedna základná hodnota na variant | ERP vyhráva; úpravy v obchode sa pri ďalšej synchronizácii prepíšu |
| Daňový základ a daňová trieda | ERP | Magento: `tax_class_id` je atribút na úrovni website, zobrazenie ceny bez/s DPH je samostatná konfigurácia. Shopify: príznak produktu plus daňové nastavenia na úrovni trhu | Rozhodnite, ktorá strana výpočtu DPH je smerodajná, a zapíšte to. Český alebo poľský B2C katalóg sa vedie s cenami vrátane DPH, takže odvodzovanie ceny s DPH z čistej ceny z ERP vloží zaokrúhľovanie medzi ERP a cenu, ktorú vidí zákazník |
| Cena pre trh alebo kanál | Obchod | Cenníky Shopify na úrovni katalógu a trhu, plus prepočet meny. Magento tieto dve veci nedokáže oddeliť: cena na úrovni website je jediná hodnota, takže kto vlastní katalógovú cenu, vlastní aj cenu pre trh | Pri zobrazovaní vyhráva obchod. ERP naďalej dostáva predajnú cenu z objednávky a nesmie preceniť importovanú objednávku podľa vlastného cenníka |
| Akciová cena | Obchod, pokiaľ schvaľovanie marže nemá ERP | Magento: rovnaký rámec ako katalógová cena, alebo cenové pravidlo katalógu na úrovni website a zákazníckej skupiny. Shopify: porovnávacia cena (compare-at price) alebo úprava katalógu | Ak je schvaľovanie marže súčasťou ERP, ERP ju vlastní a obchod nesmie na tých istých produktoch súbežne spúšťať aj pravidlá katalógu |
| B2B alebo zmluvná cena | ERP | Magento: cenové úrovne podľa zákazníckej skupiny na úrovni website; zdieľané katalógy len s Adobe Commerce B2B. Shopify: katalógy podľa lokality firmy | ERP vyhráva. Nad niekoľko desiatok cenových profilov nedokáže ani jedna z platforiem zmluvy podľa jednotlivých zákazníkov dobre modelovať |
| Fyzická skladová zásoba | ERP, alebo WMS, ak existuje | Podľa zdroja (source). Predajné množstvo počíta platforma zo zdrojov mínus rezervácie a nie je zapisovateľné | Nikdy nezapisujte predajné množstvo; zapisujte množstvo na zdroji a nechajte platformu, nech si ho odvodí |
| Sada variantov | PIM, inak obchod | Konfigurovateľné produkty v Magente potrebujú globálne atribúty možností; väčšina ERP systémov drží každý variant ako samostatnú položku bez rodiča | Vlastní ten, kto vlastní nadradené zoskupenie; ERP to zvyčajne nevie vyjadriť |
| Atribúty a možnosti | PIM, inak obchod | Atribúty konfigurovateľných možností musia byť v Magente globálne | Vyhráva PIM; obchod je zobrazovacia kópia |
| Mediálne súbory | DAM, inak PIM | Jedna globálna sada súborov; v Magente sú role base, small a thumbnail na úrovni store view | Vyhráva DAM, ale iba ak udržiava stabilnú identitu pre každý asset; premenovanie pri opätovnej synchronizácii osirotí každú rolu na úrovni store view |
| Alt text | PIM, inak obchod | Na úrovni store view v Magente, na úrovni locale v Shopify | Vyhráva vlastník textu |
| Text pre jednotlivé jazyky | ERP až po svoj jazykový strop, inak PIM, inak obchod | Store view v Magente; v Shopify päť zo šiestich preložiteľných polí produktu, plus názvy možností, hodnoty možností a verejne čitateľné metapolia (handle patrí k URL) | Vyhráva zdrojový jazyk (locale); zastaraný preklad sa označí, nenahradí sa |
| URL kľúč alebo handle | Obchod | Na úrovni store view v Magente; na úrovni locale v Shopify, ale handle sa nedá prispôsobiť podľa trhu | Vyhráva obchod; nikdy sa negeneruje z názvu produktu |
| Publikovanie a vyradenie z ponuky | ERP pre oprávnenosť, obchod pre kanál | Príznak z ERP (`isInternet`, `exportNaEshop`) rozhoduje o zaradení do katalógu; obchod publikuje na úrovni website alebo kanála | Radšej deaktivujte, než mažte: zmazaný produkt stratí svoju URL, recenzie aj históriu presmerovaní |
| Členstvo v kategórii alebo kolekcii | PIM, inak obchod | Jedno globálne priradenie v Magente; kolekcie v Shopify. Strom skupín produktov z ERP je vstup, nie záznam | Vyhráva PIM; strom z ERP sa mapuje, nie zrkadlí |
| Regulačné polia | Obchod, vyplnené z dodávateľských záznamov | Na úrovni trhu, v jazyku, ktorý daný členský štát akceptuje | Nikto nesmie atestáciu automaticky prepísať |

Dva riadky si zaslúžia bližšie vysvetlenie: médiá a URL kľúče.

**Obrázok je globálny; jeho alt text nie je.** Adobe uvádza, že „nové
obrázky produktov sa **_vždy_** nahrajú a zobrazia vo **_všetkých_**
store views, aj keď sa pri nahrávaní nepoužije rozsah `All Store Views`“
([obrázky a video produktu](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/digital-assets/product-image),
overené 4. augusta 2026), a galéria ukladá jeden súbor na obrázok bez
stĺpca pre store. DAM preto vlastní sadu assetov pre všetky jazykové
verzie naraz. Na úrovni store view je riadok vedľa každého obrázka:
popisok, poradie a príznak vypnutia, čím sa alt text, poradie obrázkov a
to, ktorý obrázok je skrytý, stávajú poliami na úrovni store view. Jedna
výhrada, ktorá túto úhľadnú deľbu komplikuje: *role* obrázka (base,
small, thumbnail, swatch) sú atribúty na úrovni store view, ktoré držia
cestu k súboru, takže ktorý z globálnych súborov e-shop v skutočnosti
zobrazí, sa môže líšiť podľa jazykovej verzie. Shopify vedie hranicu na
rovnakom mieste, len z opačnej strany: pri mediálnom obrázku je jediné
preložiteľné pole `alt`. Jeho
[dokumentácia Translate & Adapt](https://help.shopify.com/en/manual/international/translate-adapt-app)
uvádza obrázky produktu medzi typmi obsahu, ktoré aplikácia nedokáže
preložiť, zatiaľ čo ostatné obrázky a videá na preloženom zdroji možno
pre daný jazyk nahradiť nahraním alternatívneho súboru (overené 4.
augusta 2026).

Toto rozdelenie je dôležitejšie, než vyzerá, pretože alt text nie je len
technické pole.
[Európsky akt o prístupnosti](https://eur-lex.europa.eu/eli/dir/2019/882/oj)
sa vzťahuje na e-commerce služby predávané spotrebiteľom a členské štáty
musia jeho opatrenia uplatňovať od 28. júna 2025. Samotná smernica
vyžaduje, aby tieto služby boli vnímateľné, ovládateľné, zrozumiteľné a
robustné, alt text konkrétne nepomenúva; konkrétnu požiadavku na textovú
alternatívu vyjadruje norma EN 301 549, ktorá odkazuje na WCAG. Platná
verzia V3.2.1 bola harmonizovaná podľa smernice o prístupnosti webových
sídiel, nie podľa aktu o prístupnosti, a verzia V4.1.0 vzťahujúca sa na
EAA v čase overovania stále nebola citovaná v Úradnom vestníku. Výnimka
pre mikropodniky je
[užšia, než sa zdá](/sk/blog/accessibility-act-ecommerce/), a samostatné
posúdenie neprimeranej záťaže je otvorené každému poskytovateľovi. Alt
text je obsah viazaný na konkrétny jazyk, s pripojeným režimom súladu,
autorsky vytváraný tam, kde vzniká aj zvyšný text. Žiadna z platforiem
pri nahrávaní na túto potrebu podľa jazykovej verzie neupozorňuje.

**URL kľúč zvyčajne patrí obchodu, no nie preto, že by si ho nenárokoval
nik iný.** Väčšina ERP systémov nemá k URL adresám e-shopu žiadny názor,
a je lákavé usúdiť, že toto pole nemá konkurenčného uchádzača. Má.
Vlastná dokumentácia e-Sklep od Comarch ERP Optima dáva ERP záložku
Pozycjonowanie (pozicionovanie) s titulkom stránky, vyhradeným poľom
`Link` na tvorbu URL, kľúčovými slovami a meta popisom, a to rovnako pre
skupiny produktov ako aj jednotlivé položky
([Comarch Optima help, verzia 2026_5](https://pomoc.comarch.pl/optima/pl/2026_5/dokumentacja/wspolpraca-z-comarch-e-sklep/),
overené 4. augusta 2026). Handle zapisujú aj konektory a PIM systémy,
bez ohľadu na to, čo dokumentuje samotné jadro ERP.

Prevádzkové pravidlo je lepšie než argument rozsahu, pretože
Comarch ukazuje, že ERP toto pole dokáže vyjadriť. Kto vlastní URL kľúč,
vlastní aj všetky dôsledky jeho zmeny, a tieto dôsledky sa prejavia
mimo systému, ktorý zmenu vykonal. Kľúčové je preto rozhodnutie,
čo sa stane pri premenovaní. Magento to rieši nastavením
„Create Permanent Redirect for URLs if URL Key Changed“, a kto
vlastní kľúč, zdedí aj rastúcu tabuľku presmerovaní.

Ak toto pole necháte meniť externý systém, má to priame dôsledky.
[Špecifikácia feedu](https://sluzby.heureka.cz/napoveda/xml-feed/) od
Heureky označuje štyri prvky ako bezpodmienečne povinné: názov produktu,
ID položky, cenu s DPH a URL, a v češtine uvádza, že keď sa v XML zmenia
URL adresy produktov, názvy alebo kategórie, všetky produkty sa odpária
od svojich kariet na Heureke a potom čakajú na opätovné spárovanie, čo
podľa nej môže trvať približne štyri pracovné dni. PIM, ktorý regeneruje
handle z názvov produktov, tak na niekoľko dní odpáruje celý katalóg od
porovnávacieho systému, bez toho, aby čokoľvek v obchode pôsobilo
pokazene.

## Kde ERP končí: text pre jednotlivé jazyky

Pri obchode predávajúcom v češtine, slovenčine, nemčine a poľštine je
hranica medzi „ERP môže vlastniť text produktu“ a „musí ho vlastniť
niečo iné“ zvyčajne daná počtom jazykov, ktoré dátový model ERP
pripúšťa, a ten je nižší, než počet trhov, do ktorých obchod tejto
veľkosti predáva.

ABRA Flexi vlastní viacjazyčný text v hlavnej entite cenníka, ale ako
pevný počet stĺpcov, nie ako zoznam: jeden primárny názov a popis, plus
tri ďalšie, viditeľné vo
[vlastnej publikovanej schéme polí danej entity](https://demo.flexibee.eu/c/demo/cenik/properties.json)
(overené 4. augusta 2026, kde ich demo spoločnosť označuje ako
angličtinu, nemčinu a francúzštinu). To sú štyri jazykové sloty v
hlavnej entite, a vlastný podporný článok ABRA potvrdzuje, že ďalšie
jazyky sú možné len pridaním vlastných polí pre jednotlivé jazyky, čo je
skôr integračná práca než konfigurácia. Money sprístupňuje lokalizované
názvy a popisy cez
[PLUS pohľady svojho e-commerce konektora](https://developer.moneyerp.com/eshop-konektor/vycitani-dat-e-shopem/),
a Comarch ERP Optima nesie názvy a popisy pre jednotlivé jazyky na tej
istej záložke e-Handel ako svoje SEO polia. Business Central exportuje
preklady položiek do Shopify jednosmerne a bol jediným systémom v tejto
skupine, ktorého dokumentácia opisovala mostík vlastných polí, mapujúci
jeho polia na metapolia Shopify. Pre SAP Business One a InsERT sme
nenašli žiadny zdokumentovaný export textu produktu pre viac jazykových
verzií, hoci dokumentačný portál SAP sa vykresľuje len cez
JavaScriptového klienta a nepodarilo sa nám prečítať ho celý, takže to
berte ako neoverené, nie ako neexistujúce.

Ďalšie dve obmedzenia na strane ERP potichu narúšajú integrácie, pretože
obe sú pevným stropom, nie chybou. ABRA Flexi kóduje množstevné úrovne
ako pevné stĺpce, nie riadky, čím obmedzuje množstevné ceny na päť
úrovní. Helios vyjadruje každú cenovú hladinu najviac v šiestich menách,
jednej domácej a piatich zahraničných. Mriežka úrovní alebo zoznam mien,
ktorý prerastie tvar ERP, sa v systéme záznamov prestane dať vyjadriť,
bez toho, aby sa vyvolala chyba.

Zo všetkého najskôr sa oplatí nájsť príznak, ktorý rozhoduje, ktoré SKU
smie e-shop zobraziť. Má ho každý systém a každý ho pomenúva inak:
`isInternet` na
[skladovej karte POHODA](https://www.stormware.cz/schema/version_2/stock.xsd),
`exportNaEshop` na položke cenníka ABRA Flexi, zdokumentovaný v jej
[publikovanej schéme polí](https://demo.flexibee.eu/c/demo/cenik/properties.json)
a používaný ako filter vo vlastnom integračnom manuáli ABRA. Kto vlastní
tento príznak, ovláda katalóg, nech už zvyšok návrhu hovorí čokoľvek.
Helios smer autority rieši inak, priamo vo svojom API: zo sedemnástich
ciest vo svojom
[publikovanom popise eShop API](https://public.helios.eu/inuvio/api/eshop/Inuvio_doc_api_eshopv2.json)
prijímajú zápis iba objednávky a zákazníci. Produkty, kategórie, cenníky
a sklady sú len na čítanie, čím je ERP autoritatívny už svojou
konštrukciou.

## Polia, ktoré pridal zákon

Niektoré zo sporných polí sú nové a prišli z regulácie, nie
z merchandisingu, a preto žiadny systém pôvodne nebol navrhnutý tak, aby
ich vlastnil.

[Nariadenie o všeobecnej bezpečnosti výrobkov](https://eur-lex.europa.eu/eli/reg/2023/988/oj)
(nariadenie (EÚ) 2023/988, uplatniteľné od 13. decembra 2024) vyžaduje,
aby ponuka pri predaji na diaľku obsahovala meno výrobcu a jeho poštovú
aj elektronickú adresu, to isté pre zodpovednú osobu výrobcu mimo EÚ,
informácie identifikujúce výrobok vrátane obrázka a jeho typu, a
akékoľvek upozornenie alebo bezpečnostnú informáciu „v jazyku, ktorému
spotrebitelia ľahko rozumejú, ako to určí členský štát, v ktorom je
výrobok sprístupnený na trhu“. Táto posledná podmienka robí z
bezpečnostného textu obsahové pole viazané na trh, pričom voľba jazyka
patrí cieľovému členskému štátu, nie vám. Nariadenie tiež vyžaduje
hospodársky subjekt usadený v EÚ, zodpovedný za každý výrobok.

Energetické štítkovanie pridáva ďalšie požiadavky.
[Nariadenie (EÚ) 2017/1369](https://eur-lex.europa.eu/eli/reg/2017/1369/oj)
výslovne uvádza predaj na diaľku online v povinnosti predajcu zobraziť
štítok (článok 5 ods. 1 písm. a)); informačný list o výrobku sa musí
zákazníkom sprístupniť podľa nasledujúceho bodu, bez tejto podmienky.
Článok 6 písm. a) samostatne vyžaduje, aby vizuálna reklama na konkrétny
model niesla tak triedu energetickej účinnosti, ako aj rozsah tried
dostupných na štítku. Jeho databáza EPREL vyžaduje od dodávateľov
registráciu každého nového modelu od 1. januára 2019. Dôsledok sa
premieta aj do feedu:
[Google Merchant Center](https://support.google.com/merchants/answer/7052112)
vyžaduje registračný kód EPREL v atribúte certifikácie pre dotknuté
produkty cielené na EÚ od apríla 2025 a teraz obmedzuje svoj atribút
triedy energetickej účinnosti na Švajčiarsko, Nórsko a Spojené
kráľovstvo.

Tieto polia už kanály modelovali.
[API Allegro](https://developer.allegro.pl/documentation) nesie
zodpovedné osoby a zodpovedných výrobcov ako vlastné zdroje,
bezpečnostné informácie na úrovni ponuky a príznak pre produkty uvedené
na trh pred vznikom povinnosti podľa GPSR. Heureka dokumentuje vyhradené
značky pre poštovú a elektronickú adresu výrobcu. Tieto polia teda
potrebujú systém záznamov, ktorý ich dokáže potvrdiť pre daný trh a
jazyk, a často žiadny existujúci systém taký nemá: ERP eviduje
dodávateľa, nie zodpovednú osobu, a e-shop eviduje text, nie potvrdenie
(attestation). Praktickým riešením je metapole alebo sada atribútov na
úrovni trhu priamo v e-shope, vyplnená pri onboardingu dodávateľa, nie
pri zaraďovaní produktu do ponuky, pričom kontrola prázdneho poľa sa
aplikuje na nové a upravované produkty, nie spätne. Spustite ju ako
bránu pre nové položky a ako report nad existujúcim katalógom:
aplikovaná na katalóg tisícov SKU od desiatok dodávateľov by tvrdá
blokácia v deň zapnutia zrušila publikovanie celého obchodu.

## B2B ceny sú na každej platforme iný mechanizmus

Adobe umiestňuje B2B ceny do zdieľaných katalógov (shared catalogs),
ktoré sú súčasťou modulu Adobe Commerce B2B, a preto nie sú dostupné v
Magento Open Source ani v Mage-OS. Ich zapnutie pridá do selektora
Customer Group na stránke produktu
[Advanced Pricing](https://experienceleague.adobe.com/en/docs/commerce-admin/catalog/products/pricing/pricing-advanced)
možnosť Shared Catalog, takže tú istú cenovú mriežku je možné upravovať
z oboch strán.

Shopify smeruje B2B cez rovnaký mechanizmus katalógov a cenníkov ako
trhy, pričom katalóg je viazaný na lokalitu firmy (company location).
Obmedzením je rozsah plánu.
[Dokumentácia B2B katalógov](https://help.shopify.com/en/manual/b2b/catalogs)
od Shopify uvádza, že v plánoch Basic, Grow a Advanced „môžete priradiť
až 3 aktívne katalógy naprieč všetkými vašimi B2B trhmi“, zatiaľ čo Plus
ponúka neobmedzený počet a priame priradenie firmám aj lokalitám
(overené 4. augusta 2026). Ak sa na jednu lokalitu firmy vzťahuje
viacero katalógov, zobrazí sa najnižšia cena.
[Dokumentácia konektora Business Central](https://learn.microsoft.com/en-us/dynamics365/business-central/shopify/synchronize-items)
od Microsoftu uvádza, že synchronizácia B2B cien vyžaduje predplatné
Shopify Plus a že členstvo v katalógu sa spravuje v administrácii
Shopify, nie v ERP.

Z toho vyplýva rovnaké pravidlo vlastníctva na oboch platformách: ERP
vlastní to, čo sa daný zákazník zmluvne zaviazal platiť, a platforma
vlastní to, ku ktorému katalógu je daný zákazník priradený. Ďalšie
delenie by vložilo zmluvné podmienky do merchandisingového nástroja.

## Kedy sa PIM oplatí

PIM sa svojou cenou oplatí v bode, kde sa hodnoty pre jednotlivé jazyky
a kanály prestanú zmestiť do platformy. Obe popredné riešenia to
modelujú priamo, a ich licencovanie sa líši natoľko, že o výbere
rozhodne skôr ono než samotné funkcie.

Mechanizmus Akeneo spočíva v dvoch nezávislých príznakoch na každom
atribúte: localizable a scopable. Hodnota produktu je trojica
locale, scope a data, a kanál (channel) zväzuje jazykové verzie, meny,
strom kategórií a prevodné jednotky pre jeden publikačný cieľ. Jeho
Community Edition je open source pod licenciou OSL-3.0 a aktívne
udržiavaná, vydanie v2026.3 bolo označené (tagged) 30. marca 2026,
pričom Akeneo vzťahuje svoju tabuľku ukončenia podpory len na platené
edície, nie na Community. Háčikom sú aktualizácie: Community prešlo na
kalendárne verzovanie a Akeneo sa zrieka spätnej kompatibility medzi
akýmikoľvek dvoma vydaniami. Komerčne predáva tri úrovne SaaS a jeho
porovnávacia stránka vykresľuje ceny cez skriptovanie na strane
klienta, nie ako statický text, takže z nej žiadne číslo neuvádzame.
O Akeneo kolujú cenové údaje od tretích strán; žiadny z nich nie je
potvrdený na stránke Akeneo, a preto ich neopakujeme.

Pimcore, so sídlom v Salzburgu, zmenil licenciu spôsobom, ktorý sa
priamo dotýka čitateľa tohto článku.
[Od Platform Version 2025.1 už nejde o open source](https://pimcore.com/en/resources/blog/breaking-free-pimcore-says-goodbye-to-gpl-and-enters-a-new-era-with-pocl):
verejne dostupný kód je pod licenciou Pimcore Open Core Licence, teda
source-available licenciou, a vlastný súbor `composer.json` v aktuálnej
vetve deklaruje licenciu ako proprietárnu.
[Text licencie](https://raw.githubusercontent.com/pimcore/pimcore/2026.x/LICENSE.md)
udeľuje bezplatné produkčné použitie len organizáciám, ktorých celkový
celosvetový príjem neprekračuje 5 miliónov EUR ročne, na základe
vlastného vyhlásenia a podliehajúcim auditu so spätnými poplatkami,
zakazuje ponúkať Pimcore ako hostovanú alebo spravovanú službu, zakazuje
súbežnú prevádzku Pimcore pod licenciou GPLv3, a obsahuje aj
telemetrickú doložku, podľa ktorej sa nadobúdateľ licencie zaväzuje
nezasahovať do telemetrie. Jeho
[zverejnené cenníkové ceny](https://pimcore.com/en/pricing) sú 9 900 USD
ročne za Professional a 29 900 USD za Enterprise, obe on-premises, s
tým, že PaaS sa cení individuálne. Pre obchod s obratom nad 5 miliónov
EUR je Pimcore nákupom komerčnej licencie.

## Postup

Pred výberom akéhokoľvek nástroja si napíšte zoznam polí. Ku každému
poľu pomenujte systém, ktorý danú hodnotu vytvára a udržiava, rozsah,
v akom ju platforma dokáže uložiť, a čo sa stane, keď sa obe strany
nezhodnú. Smer vyplýva z prvého bodu: systém záznamov zapisuje a
všetko ostatné číta, a preto pole s dvoma zapisovateľmi nemá vlastníka.
Následne skontrolujte tri veci, ktoré odhalia väčšinu chýb v návrhu:
či rozsah, ktorý ste predpokladali, naozaj existuje (cena na úrovni
store view v Magente neexistuje), či dátový model vlastníka unesie
rozsah, ktorý potrebujete (päť mien, päť úrovní, tri ďalšie jazykové
verzie), a či ten istý údaj nezapisuje aj niečo iné za vaším chrbtom.
Obojsmerná úprava jedného poľa v dvoch systémoch je návrh, ktorému sa
treba vyhnúť, a zvyčajne sa k nemu dospeje opomenutím, nie zámerom.

Potom sa rozhodnite o spôsobe šírenia dát, pričom majte na pamäti, že
prvotné naplnenie a ustálený stav sú odlišné systémy. Počiatočné
naplnenie katalógu je hromadná úloha: bulk operácie Shopify prijímajú
JSONL a bežia asynchrónne, Magento má asynchrónne bulk REST rozhranie
a CSV importér. Ustálený stav je delta a mechanizmus určuje to, čo
vlastník dokáže vyslať. ERP, ktoré ponúka len nočný export súboru,
nedokáže dáta odosielať, nech je návrh akokoľvek postavený, takže sa
delta stáva plánovaným sťahovaním s filtrom podľa dátumu zmeny, a
aktuálnosť dát v e-shope je ohraničená intervalom exportu bez ohľadu
na to, čo bolo sľúbené. Zosúlaďovanie (reconciliation) je tretia úloha,
nie voliteľná: pravidelné úplné porovnanie, ktoré odhalí to, čo delta
vynechala, pretože feed, ktorý nikto neaudituje, sa nepozorovane
rozchádza s realitou.

Na Shopify vyplýva ešte jedno pravidlo z toho, ako
[synchronizuje `productSet`](https://shopify.dev/docs/apps/build/graphql/migrate/new-product-model/sync-data):
v rámci poľa typu zoznam, ktoré odošlete, vymaže položky, ktoré ste
vynechali, takže čiastočný zoznam variantov odstráni tie varianty, ktoré
neuvediete. Používajte ho iba tam, kde odosielajúci systém vlastní celý
daný zoznam, a tam, kde je vlastníctvo rozdelené, použite cielené
mutácie.

Mapovanie tohto zoznamu polí a vybudovanie integrácií, ktoré ho
prenášajú, je náplňou našej služby [integrácie](/sk/services/integrations/),
a vlastný vývoj nad rámec dátového modelu platformy je
[custom development](/sk/services/custom-development/). Nech si vyberiete
akékoľvek nástroje, práve zoznam polí je to, z čoho sa integrácia
buduje.