Séria · Omnibus a cenová evidencia · 4/12

Ako viesť históriu cien produktov v e-shope: od Excelu po automatickú evidenciu

Ak chcete pri zľave spoľahlivo určiť najnižšiu cenu za relevantné obdobie, musíte mať cenovú históriu. Nestačí vedieť, koľko produkt stojí dnes a akú „pôvodnú cenu“ má zadanú v administrácii.

Aktualizované: 20. 9. 2026 · Čítanie: ~10 minút

Dobrá evidencia cien má vedieť spätne odpovedať na jednoduchú otázku:

Akú cenu mal konkrétny produkt v konkrétnom čase a z akého záznamu to vieme preukázať?

To sa dá riešiť viacerými spôsobmi – od jednoduchej tabuľky až po automatický externý systém. Dôležité nie je, aby bol systém zložitý, ale aby bol pravidelný, konzistentný a spätne overiteľný.

Krátka odpoveď

Pre malý e-shop s niekoľkými produktmi môže byť dostatočná aj dobre vedená XLSX evidencia. Pri stovkách alebo tisícoch produktov je však ručné zapisovanie cien neefektívne a náchylné na chyby. Vtedy dáva väčší zmysel automatická história cien vo vlastnej databáze, cez doplnok platformy alebo v externom systéme, ktorý si ceny priebežne načítava z feedu.

Prečo nestačí pole „pôvodná cena“

Veľa e-shopových riešení pracuje s dvojicou aktuálna cena / pôvodná (stará, prečiarknutá) cena. To je vhodné na zobrazenie produktu. Nie je to však plnohodnotná história.

Ak produkt počas 30 dní prešiel napríklad takýmto vývojom:

ObdobieCena
1.–8. september79 €
9.–15. september89 €
16.–20. september84 €
od 21. septembra69 €

z polí „current price“ a „old price“ nemusíte vedieť spätne zistiť, že produkt v rozhodujúcom období stál aj 79 €. Ak sa stará hodnota prepíše novou, historický kontext zaniká.

Čo by mala cenová história minimálne obsahovať

Pri technickej evidencii cien je rozumné ukladať aspoň jednoznačný identifikátor produktu, cenu s DPH, menu, dátum a čas začiatku a konca platnosti ceny (alebo informáciu, že cena stále platí), dátum importu a zdroj údajov. Podľa typu e-shopu sa môže hodiť aj dostupnosť, sadzba DPH, URL produktu, identifikátor feedu a informácia, či išlo o automatický import alebo manuálnu zmenu.

Stabilný identifikátor je dôležitejší než názov

Produkt „Dámska bunda Alpine“ sa môže neskôr premenovať na „Dámska zimná bunda Alpine – čierna“ a stále ide o ten istý produkt. Pre históriu ceny je preto vhodnejší stabilný ITEM_ID, interné SKU, EAN alebo iný jednoznačný kľúč.

1. Evidencia cien v Exceli alebo XLSX

Najjednoduchšie riešenie je tabuľka, napríklad:

ProductIDNázovDátumCena s DPH
1001Produkt A1. 9. 202699 €
1001Produkt A8. 9. 2026109 €
1001Produkt A18. 9. 202689 €

Výhody: takmer nulové technické náklady, jednoduchá kontrola človekom, vhodné pre veľmi malý sortiment, dá sa vytvoriť okamžite.

Nevýhody: manuálna práca, riziko zabudnutých záznamov, problematické pri stovkách produktov, ľahké spätné prepísanie údajov, komplikované filtrovanie, slabšia automatizácia výpočtu.

Ak máte 10–20 produktov, meníte ceny zriedka a robíte zľavy párkrát do roka, dobre navrhnutá tabuľka môže byť praktickým riešením. Pri 5 000 produktoch a denných zmenách už nie.

2. História cien vo vlastnej databáze

Ak máte vlastný e-shop alebo vývojára, môžete si cenovú históriu ukladať priamo do databázy. Veľkou výhodou je plná kontrola nad logikou.

Odporúčaný prístup: neukladať iba snapshoty

Najjednoduchší model je každý deň uložiť cenu každého produktu. Pri 20 000 produktoch to znamená 20 000 riadkov denne, približne 600 000 mesačne a viac ako 7 miliónov ročne, aj keď sa 95 % cien vôbec nezmenilo.

Efektívnejší je delta model. Ukladá sa iba zmena:

Platí odPlatí doCena
1. 1.15. 2.100 €
15. 2.7. 4.110 €
7. 4.aktuálne95 €

Takýto model presne ukazuje, v akom období ktorá cena platila. Vlastná databáza si zároveň vyžaduje riešiť zálohy, časové zóny, migrácie, audit zásahov, oprávnenia, zabránenie duplicitným aktívnym cenám, retenciu a export pri kontrole. Pri väčšom systéme je vhodné oddeľovať cenový log od auditného logu.

3. Plugin alebo doplnok e-shopovej platformy

Ďalšou možnosťou je plugin alebo natívna funkcia platformy. Výhodou býva jednoduchá inštalácia. Nevýhodou je, že nie každý doplnok rieši to isté. Pred nasadením si overte:

  1. Ukladá doplnok skutočnú históriu cien alebo iba vypočíta údaj v momente zobrazenia stránky?
  2. Ako dlho históriu uchováva?
  3. Dá sa exportovať?
  4. Čo sa stane po odinštalovaní doplnku?
  5. Sleduje cenu s DPH?
  6. Ako identifikuje varianty?
  7. Ako rieši produkty, ktoré dočasne zmiznú z ponuky?

4. Externá evidencia cien

Pri externom systéme sa história neukladá iba v databáze samotného e-shopu. Systém si môže pravidelne čítať napríklad XML feed, produktové API alebo export z ERP. Získaná cena sa uloží do samostatného archívu.

Výhody: evidencia je oddelená od hlavnej databázy e-shopu, história môže zostať zachovaná aj po zmene platformy, menej vlastného vývoja, jednoduchšia automatizácia, vhodné pre viac e-shopov alebo feedov.

Práve tento model používa aj OmnibusPrice.eu. Systém vychádza z produktového feedu, pravidelne načítava ceny a vytvára samostatnú históriu zmien. Viac: Funkcie OmnibusPrice.eu

Snapshot verzus delta model

Oba prístupy môžu fungovať. Pri snapshote každý deň uložíte cenu každého produktu (aj keď sa nezmenila) – výhoda je jednoduchý model a ľahká rekonštrukcia konkrétneho dňa, nevýhoda veľké množstvo duplicitných dát.

Pri delte sa uloží iba zmena ceny – napríklad 1. 9. – 100 €, 12. 9. – 120 €, 25. 9. – 90 €. Výhodou je podstatne menej dát a prirodzená história platnosti ceny, nevýhodou zložitejšia implementácia. OmnibusPrice.eu je navrhnutý práve nad delta modelom – ukladá sa zmena ceny a interval jej platnosti.

Čo znamená auditovateľná evidencia

Auditovateľnosť neznamená iba „máme niekde databázu“. Dobrý systém vie spätne vysvetliť, kedy bola cena načítaná, aká hodnota bola načítaná, z akého produktu, z akého feedu alebo zdroja, kedy sa cena zmenila a či do záznamu niekto manuálne zasahoval.

Pri dôležitých logoch je vhodný append-only princíp – pôvodný záznam sa neprepisuje, prípadná oprava vytvorí nový záznam alebo auditnú udalosť. Tým zostáva viditeľné, čo sa v systéme skutočne stalo.

Ako často ceny zaznamenávať

Univerzálna odpoveď neexistuje – závisí od toho, ako často ceny meníte. Pri malom e-shope, kde sa ceny menia raz za niekoľko týždňov, môže denný import úplne postačovať. Pri bežnom e-shope synchronizovanom s ERP alebo dodávateľskými feedmi môže byť vhodných viac importov denne. Pri dynamickom preceňovaní treba frekvenciu sledovania nastaviť podľa reálneho cenového procesu.

Dôležitá otázka: ktorú cenu ukladať?

Pre B2C e-shop je rozhodujúca cena, ktorú vidí a platí spotrebiteľ. V systémoch treba jasne rozlišovať cenu bez DPH, cenu s DPH, odporúčanú cenu, nákupnú cenu, veľkoobchodnú cenu a reálnu predajnú cenu. Pre cenovú históriu používanú pri spotrebiteľských zľavách je kľúčová predajná cena s DPH.

A čo kupóny a individuálne zľavy?

Nie každá cenová výhoda funguje rovnako – verejná zľava na produkte, kupón pre konkrétneho zákazníka, vernostná zľava, individuálna ponuka alebo zľava aplikovaná až v košíku sú odlišné situácie. Cenový archív základnej produktovej ceny nemusí automaticky riešiť všetky marketingové mechanizmy. Pri kombinovaných akciách treba posúdiť konkrétny spôsob komunikácie.

Ako rieši históriu cien OmnibusPrice.eu

E-shop poskytne produktový feed, systém ho pravidelne načíta, produkty identifikuje podľa stabilného kľúča, sleduje cenu s DPH a pri zmene vytvorí nový cenový interval. História zostáva uložená mimo databázy e-shopu a z nej je možné vypočítať najnižšiu zaznamenanú cenu pre príslušné obdobie.

Ako vybrať vhodné riešenie podľa veľkosti e-shopu

10 produktov: jednoduchá XLSX evidencia môže byť zvládnuteľná.

500 produktov: ručný proces už začína byť drahší než automatizácia.

5 000 produktov: automatický import a databázová história sú prakticky nevyhnutné.

50 000 produktov: treba riešiť výkon, delta model, indexy, retenciu, importné dávky a monitoring chýb. Tu už história cien nie je „jedna tabuľka navyše“, ale samostatný technický proces.

Praktický checklist

Najčastejšie chyby

1. Ukladá sa iba aktuálna cena

Po zmene sa stará hodnota stratí.

2. História sa vytvára až pred akciou

Ak začnete ceny zaznamenávať dnes, nevytvoríte tým automaticky históriu za predchádzajúcich 30 dní.

3. Produkty sa identifikujú názvom

Po premenovaní vznikajú duplicity alebo sa história rozdelí.

4. Ukladá sa cena bez DPH

Pri B2C predaji nemusí zodpovedať spotrebiteľskej cene.

5. Import nemá audit

Pri chybnej hodnote neviete zistiť, kedy a prečo vznikla.

FAQ

Nie. Technicky ju môžete viesť aj sami, napríklad v databáze alebo tabuľke. Dôležité je, aby bol výsledok spoľahlivý a spätne overiteľný.

Pri malom sortimente a disciplinovanom procese môže byť prakticky použiteľný. Pri veľkom počte produktov však narastá riziko chýb a manuálna náročnosť.

Nie nevyhnutne. Ak systém eviduje časové intervaly, môže ukladať iba moment, keď sa cena zmenila. Dôležité je vedieť spätne určiť, aká cena platila v konkrétnom čase.

História musí stále vedieť preukázať, že daná cena počas tohto obdobia platila. Pri delta modeli sa to rieši intervalom platnosti a technickými mechanizmami na zachovanie kontinuity.

Nie automaticky. Vlastná databáza dáva plnú kontrolu, externý systém znižuje potrebu vlastného vývoja a vytvára oddelený archív. Rozhoduje veľkosť e-shopu, technické kapacity a požadovaná úroveň automatizácie.

Záver

História cien nie je primárne marketingová funkcia. Je to dátový základ, z ktorého viete spätne overiť, akú cenu mal produkt v konkrétnom čase.

Pri malom sortimente môže fungovať jednoduchá tabuľka. S rastúcim počtom produktov, frekvenciou zmien cien a počtom predajných kanálov však rastie aj význam automatizácie.

Najdôležitejšie je začať ceny evidovať priebežne. História, ktorá sa nikdy neukladala, sa totiž nedá spoľahlivo vytvoriť až vo chvíli, keď ju potrebujete.

Zdroje a právny základ

Poznámka: Tento článok má informačný a technický charakter. Nejde o individuálne právne poradenstvo. Pri neštandardnom obchodnom modeli alebo spornom spôsobe komunikácie zľavy je vhodné konkrétny prípad konzultovať s právnikom alebo príslušným orgánom dohľadu.