Import XML do PrestaShop bez duplicit: identifikátory a pravidla aktualizace

Import XML bez duplicit začíná stálým, jednoznačným identifikátorem a uloženým vztahem mezi záznamem dodavatele a produktem v PrestaShopu. Před prvním spuštěním určete, co může importér vytvářet, která pole aktualizuje a co znamená chybějící produkt v dalším souboru. Samotné správné XML na tyto otázky neodpovídá.

Návod je určen pro obchody plánující import z velkoobchodu nebo jiného systému. Dva malé demonstrační soubory ukazují, jak rozlišit nový produkt, změnu dat a chybějící záznam. Nejde o feed skutečného dodavatele ani o univerzální formát podporovaný každým importérem.

1. Vyberte systém odpovědný za každé pole

Nejprve rozhodněte, odkud pochází správná cena, stav, název a popis. Často velkoobchod odpovídá za dostupnost a nákupní cenu, zatímco obchod udržuje vlastní popis a prodejní cenu vypočtenou podle pravidla. Pokud importér při každé aktualizaci přepíše všechna pole, může odstranit redakční práci provedenou v obchodě.

V jednoduchém modelu jeden zdrojový záznam odpovídá jednomu produktu v obchodě. To však ještě neřeší varianty, sady, více skladů, pravidla nejnižší ceny ani přepínání dodavatele. Takové pravidlo je třeba navrhnout a následně potvrdit v konkrétním řešení.

2. Nezaměňujte ID dodavatele s ID produktu v obchodě

Záznam A-100 v XML může odpovídat produktu 501 v PrestaShopu. Tato čísla nemusí být totožná. Importér by měl znát jejich vazbu a využít ji při dalším načtení. Vytváření nové karty při každé změně názvu je chybou modelu identifikace.

Identifikátor musí být v čase stabilní a v zvoleném rozsahu jednoznačný. Pokud dva velkoobchody používají číslo 100, bezpečná vazba by měla zohledňovat zdroj, a ne pouze toto číslo. Nepředpokládejte také, že EAN je vždy dostupný a unikátní: v souboru mohou být chybějící hodnoty, chyby nebo duplicity vyžadující vysvětlení.

Před prvním párováním na existující katalog připravte report chybějících a opakujících se klíčů. Nevybírejte automaticky „první nalezený“ produkt, pokud existují dvě karty se stejným indexem.

3. Produkt a varianta potřebují oddělená pravidla

Jedna produktová karta může mít několik kombinací, každou s vlastním stavem, indexem, obrázkem nebo vlivem na cenu. Určete, zda záznam XML popisuje celou kartu, nebo jednotlivou variantu. Pokud dodavatel posílá samostatné velikosti jako samostatné záznamy, jejich spojení do jedné karty vyžaduje pravidlo seskupení.

Zkontrolujte také význam ceny varianty: může jít o plnou cenu nebo o rozdíl vůči základnímu produktu. Použití rozdílu jako konečné ceny dává nesprávný výsledek. Podobná opatrnost se týká sad atributů — změna názvu barvy by bez rozhodnutí neměla vytvářet další variantu.

Pokud importér synchronizuje celou sadu kombinací, určete, zda mají být varianty nepřítomné v souboru zachovány, vypnuty nebo odstraněny. To je zvlášť důležité, když část variant obchod spravuje samostatně.

4. Dvě verze XML a očekávaný výsledek

Níže uvedená struktura byla připravena výhradně pro demonstraci. Ceny jsou vstupní netto ceny v PLN. V příkladu nevytváříme varianty; každý záznam odpovídá jedné produktové kartě. Parser nebo adaptér konkrétního importéru musí být přizpůsoben skutečné struktuře zdroje.

První úplný soubor

  
    DEMO-BUTELKA
    Butelka oliwkowa
    50.00
    12
  
  
    DEMO-KUBEK
    Kubek kremowy
    20.00
    8
  

Další úplný soubor

  
    DEMO-BUTELKA
    Butelka oliwkowa
    55.00
    0
  
  
    DEMO-KOC
    Koc beżowy
    40.00
    5
  

Atribut complete="true" je součástí našeho příkladu, nikoli standardní zárukou úplnosti XML. Ve skutečné implementaci je třeba určit, jak dodavatel potvrzuje úplnost a jak ji importér rozpoznává.

To jsou očekávané výsledky scénáře, nikoli výsledek spuštěného importu. Čísla produktů v obchodě jsou pouze příkladná. Dva výše uvedené soubory mají ilustrační schéma ; nejsou vstupními soubory ukázkového adaptéru modulu.

Co ukázal lokální test mapování v SampleAdapter 2.0.5

27. září jsme v paměti ověřili metodu SampleAdapter::mapProduct() na třech malých XML souborech, na PHP 7.0 a 8.1. Tento adaptér očekává strukturu a pole nazwa, cena_netto a stan_magazynowy. To se liší od ilustračního schématu výše. Neprováděli jsme stažení URL ani import do databáze obchodu.

Test byl proveden na verzi 2.0.5 z balíčku označeného 2026-09-27, zpřístupněného 28.09.2026. Balíček neobsahuje modul ani konfiguraci pro plný import. Výsledek 19,99 → 19 dokumentuje chybu formátu ceny, nikoli správnou cenu.

Hranice testu: jde o výsledek mapování polí, nikoli o důkaz vytvoření nebo aktualizace karet, obsluhy variant či absence duplicit po opětovném importu. SampleAdapter je v panelu vyloučen z výběru a sám je označen jako příklad nevhodný pro produkci. Nespouštějte plný import krátkého vzorku na existujícím zdroji: pravidlo pro produkty nepřítomné v souboru může změnit stav katalogu. Plné převzetí vyžaduje izolovanou kopii obchodu, potvrzení úplnosti feedu a porovnání karet před a po průběhu.

5. Chybějící záznam neznamená vždy chybějící zboží

Produkt může zmizet z úplného katalogu, ale také se nemusí objevit v souboru obsahujícím pouze změny. Prázdný soubor, chyba přihlášení, částečné stažení nebo nedokončený import jsou další situace. Neměly by automaticky vést k vypnutí celého sortimentu.

Před provedením operace pro chybějící produkty potvrďte správné stažení, načtení a dokončení správného typu importu. Určete také rozsah: pouze karty navázané na tento zdroj. Zmizení záznamu velkoobchodu A by nemělo samočinně upravovat ručně přidaný produkt nebo nabídku velkoobchodu B.

V příkladu ponecháváme chybějící hrnek ke kontrole, abychom ukázali rozdíl mezi chybějící informací a výslovným stavem nula. Jde o zvolené demonstrační pravidlo, nikoli o nastavení vhodné pro každý obchod. Pro produkci je třeba rozhodnutí svázat s povahou zdroje a rizikem prodeje nedostupného zboží.

6. Plný import a rychlá aktualizace

V kódu Import velkoobchod Pro / pdxmlimport 2.0.4 mají plný import a rychlá aktualizace odlišný rozsah. Plná cesta může vytvářet produkty a aktualizovat data obsluhovaná adaptérem podle konfigurace. Rychlá aktualizace se týká cen a množství základních produktů již navázaných na zdroj; nejde o cestu pro vytváření nových karet ani aktualizaci stavů jednotlivých kombinací.

Nepředpokládejte, že přepínače přepisování názvů a popisů řídí každou operaci modulu. Před naplánováním určete přesnou akci, zdroj a rozsah. Změna cenového pravidla může také vyžadovat opětovné zpracování dat i při nezměněném XML.

Pokud potřebujete pouze aktualizaci existujících karet z CSV, podívejte se na samostatné návody o cenách a o stavech. Volba formátu by měla vycházet z dat a operací, které je skutečně třeba provádět.

7. Harmonogram až po kontrole výsledku

První pokus proveďte na malé, reprezentativní sadě zahrnující nový produkt, již navázaný produkt, chybějící identifikátor, kolizi a varianty. Porovnejte počet přidaných, změněných, přeskočených a chybných záznamů. Otevřete produktové karty a zkontrolujte prodejní cenu, stav, obrázky a mapování kategorií.

Teprve potom nastavte pořadí stahování a zpracování dávek i frekvenci CRON. Harmonogram by měl zohledňovat publikaci souboru dodavatelem a skutečný čas importu. Určete, kdo reaguje na chybu a jak rozpozná nedokončený průběh. Samotné spuštění adresy CRON není důkazem aktualizace celého katalogu.

Pošlete ukázku struktury XML bez důvěrných údajů a popište pravidla aktualizace. Po ověření polí a variant lze určit rozsah importu a exportu dat PrestaShop. Pokud existující adaptér tuto strukturu podporuje, podívejte se na Import velkoobchod Pro; jiné uspořádání dat vyžaduje přizpůsobení a test na kopii obchodu.

Import katalogu automaticky neznamená, že kód dodavatele je správným klíčem. V praxi je třeba ověřit jeho stabilitu, jednoznačnost a vztah k variantám. Teprve poté lze bezpečně posoudit, zda další import aktualizuje existující karty, nebo vytváří duplicity.

Názvy a čísla produktů jsou demonstrační; neobsahují data ani strukturu chráněného feedu velkoobchodu.