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, 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 (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í, 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 (polling consumer); tolerovanie opakovanej správy je Idempotentný prijímač (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. Hellandov text Life beyond Distributed Transactions (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, 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 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 a vypína ho pre sku a media_gallery v konfigurácii administračného formulára (2.4-develop, overené 4. augusta 2026). Atribút použitý ako konfigurovateľná možnosť musí byť globálny, 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ť 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 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

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, 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 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 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á, 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, 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 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 (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, 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, exportNaEshop na položke cenníka ABRA Flexi, zdokumentovaný v jej publikovanej schéme polí 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 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 (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 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 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 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 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 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 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: 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 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 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: 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, a vlastný vývoj nad rámec dátového modelu platformy je custom development. Nech si vyberiete akékoľvek nástroje, práve zoznam polí je to, z čoho sa integrácia buduje.