Autor Zpráva
Petr Ká
Profil
Ahoj,

potřeboval bych prokonzultovat jak nejlépe a co nejobecněji navrhnout slevový systém a jeho správu (uložení v DB, zpracování podmínek ....).

- Podmínek pro slevu by mělo být neomezeně
- Časové upřesnění rozsahu platnosti (den, hodina, ...)
- Jaká sleva (procenta, pevná cena, pevné slevnění o X kč)
- Jestli se vztahuje na vše, kategorii, vybrané produkty, kombinace produktů
- napříkad i třeba první 3 produkty za plnou cenu, další slevněné o X (korun nebo procent)
- například první 2 produkty za cenu X a další za plnou (při nákupu 3 a více)

A tak různě... potřebuji aby to bylo co nejobecnější...

Díky moc
tiso
Profil
Začnem. Všeobecne by sa to dalo rozdeliť na:
- zľava konkrétneho produktu (%, pevná suma)
- zľava na kombináciu produktov (balíček)
- množstevná zľava
- zľava podľa celkovej sumy objednávky
- iné
Každá skupina potrebuje iné údaje na uplatnenie, komplikované sú najmä závislosti medzi týmito skupinami a následné vyhodnocovanie.
Joker
Profil
tiso:
Podle mě pokud v systému bude nějaký objekt košíku nebo objednávky, všechny druhy slev si musejí vystačit s ním.

Pak by to šlo zobecnit na nějaké rozhraní s metodou třeba zapoctiSlevu($objednavka). Různé typy výpočtu slevy se budou lišit jen implementací té metody.
Podobně by šlo udělat rozhraní pro podmínky slevy, které by umělo říct, jestli pro daný produkt na slevu je nebo není nárok.

A pak záleží na jaké úrovni abstrakce se zastavíme, kdybychom chtěli být „enterprisey“, můžeme zavést ISaleAlgorithmFactory a ISaleConditionFactory a tak dále :)
Juraj Hajdúch
Profil
Implementácia zľavového automatu je veľmi komplexná záležitosť; vy ste neuviedli, aký e-shop/RS používate, ak teda nejaký používate.

Pred rokmi som spolupracoval na jednom podobnom projekte, aj keď len ako zodpovedný za matematické výpočty (štatistika, ekonomické súvahy a pod.), ale postup bol približne takýto:

1. Do prezentačnej vrsty bola implementovaná kontrola existencie nejakej zľavovej akcie.

2. Zľavové akcie boli uložené v databáze v samostatnej tabuľke, ktorá, okrem stĺpa ID, NÁZVU, AKTÍVNOSTI a pod. obsahovala stĺpec NASTAVENIA, v ktorom boli uložené informácie spôsobom ako sme zviknutý v ini súboroch (Ak by boli tieto hodnoty dávané samostatne do stĺpcov, tak by ich musela mať tabuľka stovky).

3. V prípade, že program našiel jednu alebo viac zľavových akcií s príznakom AKTÍVNOSŤ=true, tak vybrala potrebné riadky a dovzdala ich objektu 'spracujZlavu' spolu s informáciami súvisiacimi s aktuálne spracovávanou tovarovou položkou.

4. Tento objekt analyzoval NASTAVENIA a podľa nich upravil cenu výrobku/služby.

5. Samotná analýza brala do úvahy nasledovné nastavenia: (poznámka: neuvádzam všetko, to by ma moderátor rýchlo odstavil a uvádzam to vo všeobecnosti a zjednodušene)

ČAS:
(A) časové obmedzenie 1, pozri premenné DATE_ŠTART a DATE_STOP (false = bez obmedzenia, toto platí pre všetky nasledujúce položky)
(B) časové obmedzenie 2, pozri premenné TIME_ŠTART a TIME_STOP
(C) časové obmedzenie 3, pozri premennú V_KTORE_DNI (Po - Ne)
(D až XYZ) časové obmedzenie 4, takto možno nastavovať množstvo vecí, napr. v ktoré mesiace, áno alebo nie počas sviatkov atď.

CENA:
(A) cena 1, o koľko percent znížiť cenu (false = percentá sa ignorujú)
(B) cena 2, o koľko EUR menej (false = nevyhodnocovať)
(C) cena 3, vyhodnotiť (a uplatniť či neuplatniť zľavu) ak je základná cena menšia ako 'x' alebo väčšia ako 'y'

KATEGÓRIA (DRUH):
(A) zoznam ID kategórií/výrobcov/druho/ a čo ja viam čoho ešte všetkého... (viac stĺpcov podľa projektu a informácií o danom výrobku), ktorých sa zľava týka

MNOŽSTEVNÁ ZĽAVA:
(A) minimálny počet výrobkov v košíku, aby sa zľava uplatnila (náväznosť na objekt spracovávajúci nákupný košík)
(B) pri zohľadnení podmienky 'A' vziať do úvahy či sa zľava týka všetkých produktov alebp len od určitého množstva

6. Objekt vráti upravenúc enu a poprípade aj potrebné 'stringy', ktoré sa použijú v prezentácii...

Na záver len toľko, že samotné skriptovanie nám (cca 12 ľudí) zabralo 2 mesiace a ďalší mesiac sa to len testovalo (a to je z hľadiska vývoja aplikácii veľmi rýchlo), takže, ako čítate, nie je to rozhodne jednoduchá vec.
tiso
Profil
Joker: jasné, ale okrem spracovania zliav ich musíš aj zobrazovať a uložiť. Ja som písal rozdelenie z pohľadu dát:
1. typ potrebuje uložiť pre produkt zľavu.
2. typ potrebuje uložiť balíček a k nemu zľavu.
3. typ potrebuje uložiť pre produkt množstvá a ich zľavy
4. typ potrebuje uložiť zľavu pre rozsahy súm objednávky

Do toho si môže vymyslieť rôzne pravidlá na uplatňovanie zliav, ktoré sa dajú uplatniť súbežne, alebo sa uplatní najvyššia atď. To si už ani neviem predstaviť všeobecne namodelovať v databáze.

Ešte doplním: napríklad ten balíček som v praxi riešil tak, že keď boli v košíku produkty spĺňajúce nejaký balíček, tak som ich vyhodil a miesto nich tam dal ten konkrétny balíček. Dá sa to riešiť aj tak, že produkty tam zostanú a pridá sa položka zľava za daný balíček.
Joker
Profil
tiso:
Tak šlo by uložit si jen nějakou hlavičku (id, popis, platí od, platí do apod.) a zbytek ve formátu idSlevy | parametr | hodnota.

Sice to má nevýhody jako že těžko půjdou selektovat rovnou z databáze třeba „happy hour“ slevy které jsou aktuálně platné, ale to bych stejně nedoporučil řešit v rámci aplikace.
Prostě vybrat všechny aktuální slevy a u každé zavolat metodu, jestli se vztahuje na danou objednávku.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0