Promóciókezelő rendszer tervezése

Promóciókezelő rendszer tervezése
2019-02-07T11:17:08+01:00
2019-02-09T19:55:14+01:00
2022-10-18T11:00:34+02:00
  • Azért az nem ugyan az. Például szép is lenne, ha kiállítasz egy számlát a nevére, és fizetés helyett megy a zember panaszra, hogy de te azonnal törölj róla minden adatot 

    Egy email nem hiteles adat, és nem is te kérted, hogy rád tukmálják. Aki küldte, szabad akaratából tette az előzetes megkérdezésed nélkül, minden következményért őt terheli felelősség. Egy számlának meg rendezett szabályai vannak, azok nem jelentenek extra terhet. Extra terhet az jelent, ha neked valami szolgáltatásodról külön ÁSZF-et kell aláfirkantatnod az összes vásárlóddal. Kép a következő, áll a biztonsági őr a bejáratban, hogy addig ő be nem engedi a vásárlót, amíg alá nem írja a szerződést. Jót nevettünk? 
    Mutasd a teljes hozzászólást!
  • a gdpr-t senki nem ússza meg.
    kapnak egy emailt-t, kiállítanak egy számlát és már ott is van.
    Mutasd a teljes hozzászólást!
  • A webshop és házhozszállítás az szerintem is jó ötlet, ha van egy ország, ahol a minőségi szolgáltatás iránt társadalmi felelősséget éreznek az emberek. Magyarország szerinted az a hely?  

    "Másikat csináltatni" - ahhoz adatnyilvántartás kell. Bármi, amihez személyes adatok nyilvántartása kell, bármi, ami harmadik személy által külön beleegyezés nélkül megfigyelhető megkülönböztető jelzés, és akár csak statisztikai eséllyel ugyan ahhoz a személyhez köthető, azonnal a nyakadba hajította a gdpr marhaságait. Szerintem ők azt nem akarják   Az ő számukra a megoldás teljes költsége a kérdés, ami nem áll meg az informatikánál. Ha valami hardverről hiszed, hogy drága, próbálj meg egyszer jogi szolgáltatásokat vásárolni  

    A wizzair utalást még értettem, de így hirtelen nem esett le a tantusz, melyik akciójukra célzol. Bevallom töredelmesen, nem követtem nyomon  De egy repülőtársaságnak egyébként is adva van a teljes logisztikai környezet, és ők a gdpr-t semmi módon meg nem ússzák szárazon. Nekik mindegy, milyen eszközöket használnak fel, mert az infrastruktúrát mindenképpen fizetik. Annak nem mindegy, aki azt megúszhatja.

    ne legyen már természetkárosító plasztik kártya, meg fakivágó papír alapú kártya, meg további elektronikai hulladék halmozás

    Igen, jó lenne, ha úgy lenne, vagy legalább abba az irányba haladna a világ. De ahhoz képest pont ellenkező irányba haladunk. A csendes-óceán északi részén európányi szemét hulladék úszik (és folyamatosan növekszik), ami a nasa által megfigyelt műanyag felület a vízfelszínen. Képzelheted, mennyi van még a felszín alatt. És akkor gyárt az eu egy ilyen idiótaságot, mint a gdpr, ami még direkt rárak nem is egy lapáttal. Bár mondhatnám, hogy javulni fog a helyzet, vagy hogy mikroökonómiai szereplőként legalább statisztikai esélyed lesz nem még neked is bűnrészessé válnod, ráadásul akaratod és minden igyekezeted ellenére is, de sajnos, hazugság lenne olyat állítanom.
    Mutasd a teljes hozzászólást!
  • Kérlek titeket, ne térjünk el az eredeti kérdésektől. Valóban, nagyon érdekelne egy ilyen rendszer megtervezése, ezért is kezdtem neki én magam


    Azzal hogy elkezdtél interfészeken gondolkozni lényegében meghatároztad hogy az űrrakétád csúcsa milyen színű legyen.

    The Dictator (2012) - Nuclear Nadal - [Full Scene]

    A rendszer tervezése nem az osztály interfészeinél kezdődik hanem a rendszertervnél, ahol összerakod hogy milyen komponensek fognak dumcsizni egymással, milyen módon, és mit, majd végül ha ez megvan akkor jöhetnek a felhasználható library-k, framework-ök,  és ezután jönnek a hiányzó részeket megvalósító osztályok, algoritmusok, adattípusok.

    Lásd lentebb, mobil app QR kód, webkamera, vagy NFC, Bluetooth
    Mutasd a teljes hozzászólást!
  • kártyát elveszti, újat kell csináltatni $$$$

    Könyörgöm ott a mobiltelefon legyen már egy app ami meg tudja mutatni a QR kódot amit beolvas egy CsingCsang szuper extra USB6.2 márkájú webkamera, akár a "pénztárgép" PC-n akár RPI-n futtatva a boltba.

    REST+ valami xyz AUTH meg mondjuk valami könnyű cross platform keretrendszer

    Ha valaki nagyon eszköz fetisiszta akkor meg ott van még az NFC, meg ott van a Bluetooth.

    Hát a rózsaszín repcsitársaságnak is volt már annyi lövése, hogy ne szerencsétlenkedjünk már, papír kártyákkal.

    De tényleg 2019-ben ne legyen már természetkárosító plasztik kártya, meg fakivágó papír alapú kártya, meg további elektronikai hulladék halmozás.

    Meg amúgy is legyen már webshop a bolt helye meg egy átvevőhely ha jól tudom ilyenkor lehet is optimalizálni dolgokat.
    Mutasd a teljes hozzászólást!
  • Szerintem is úgy gondolta, és arra írtam, hogy marketing oldalon olyan pofáraesés várható (ezeregy legkülönfélébb problémák miatt), amihez képest olcsóbb lesz a smart card árát kifizetni.
    Mutasd a teljes hozzászólást!
  • Szerintem ugy gondolta hogy a qr koddal nyomtat ki kartyakat, amit a kaszas fizetesnel mindig beolvas egy mobillal es ezzel azonositja a vasarlot, ha van kedvezmenye kiirja, a kaszas pedig be a penztargepbe.

    Persze meg igy sem fog tudni a promocio rendszer arrol hogy ki, mit vett de az csak implementacios reszlet, most az interfacek a fontosak.
    Mutasd a teljes hozzászólást!
  • Szia Lilla!

    Érdemes ránézni egy kicsit az ethereumra.

    Elosztott, redundáns, nem túl drága, megbízható. 
    Az ethereum nem csak a coint jelenti, hanem egy infrastruktúrát is.

    Én ezt a tutoriált néztem.
    Mutasd a teljes hozzászólást!
  • +1 neked, de a véleményem változatlan  

    Én értem a felvetést, hogy spórolni lehetne a smart card-on, de az a része nem üzleti matek, hanem sanity check. Van egy olyan, hogy felhasználói élmény, és a megszokás nagyobb úr, mint a logika. Ami kártyára qr kódot nyomtatnak, annak másmilyen érzete van, mint a chip kártyáknak, de még a mágnes csíkosak is másmilyenek. A qr kártyának gagyi érzete van. Egyszer használatos, eldobható cucc. Azzal ugyan nem fognak vissza járni a vendégek. Qr kódot rá lehet nyomtatni mondjuk egy belépő jegyre, ahol plasztik kártyát adnak belépő jegyként, és a qr kód alapján a vendég kap mondjuk 1 ingyen sört, belépést egyéb helyekre is, vagy valami olyasmit. Olyan felhasználásra okés. A korlát, hogy amikor vége a rendezvénynek, a kártyát kukába dobják. Mert "elhasználták". Másnap az már nem kártya, hanem "elhasznált" cucc. Ha megpróbálnak valahol másmilyen viselkedésre szoktatni vásárlókat, termelnek vele olyan feszültséget, hogy vásárlókat fognak veszíteni.

    A qr kódot csak nagyon máshogyan lehetne használni, és Magyarországon lesz vele baj nem kevés. Lehet android bináris alkalmazást írni, és azt mondani a felhasználóknak, hogy azt telepítsék fel az okos telefonjukra. (Akinek az nincs, úgy járt.) Minden alkalmazás példány kap egyedi azonosítót telepítéskor, felhasználási feltételekben gdpr is játszik, el kell fogadtatni a felhasználókkal, hogy vásárlói magatartás nyomon követésére is felhasználható alkalmazást telepítenek a mobiljukra. Azért cserébe kapják a kedvezményt. A qr kódot a pénztárhoz kell kicsi táblára felpingálni, és aki éppen odaért a pénztárhoz, lefotózza. Az alkalmazásnak mobil telefonról tudnia kell hálózati csatornát elérnie, hogy jelezze a felhasználó jelenlétét a pénztárnál, ami a qr kódból azonosítható. Kínában a TenCent be tudta vezetni a leírt felhasználói szokást, része a WeChat-nek, de ott van stabil és relatíve olcsó gsm net, lóg is rajta mindenki - Magyarországon nincs. Nálunk talán egy BT routert lehetne kirakni a pénztárakhoz 1 méteres hatósugárral, amit az alkalmazás automatán megkeres, és felhasznál a qr fotó után. Ha a technika ördöge bármiben közbe szól, a vásárló nem fog kedvezményt kapni, és mérges lesz. Előre borítékolható, hogy az elgondolás ebben az országban marketing öngyilkosság.

    Én továbbra is a kontakt smart card-ot javasolnám olyan célra, vagy inkább elfelejteni az egész fejlesztést.
    Mutasd a teljes hozzászólást!
  • Guid CardId { get; } //ez a kártyán egy QR kód formájában látszik

     ...
    Mutasd a teljes hozzászólást!
  • Ha a programozás elméletbe szántad a topicot, akkor talán a gyakorlat nem sokat számít neked, de azért csak leírom 

    A smart card-okban egy mikrovezérlő van. Egyedi és nem hamisítható a kártyátok annyira lesz, amennyire saját firmware-t írtok hozzá. A kártyák üresen kb 5 rugóból lesznek meg / darab, gondoljátok át, érdemes-e olyasmiket ingyen osztogatnotok. És persze még a szoftver bele. Az olvasók nem drágák, és lévén nem kell belőle sokat venni, a programozó sem az. Nagy tételben ha ilyen ezres darabszámban adjátok, az üres kártya értéke lesz a legnagyobb tényező - még mindig pont túl sok ahhoz a gyakorlatban, hogy pici bolt azzal játszadozzon. Hipermarketek arra használják, hogy a brand-et tudatosítsák vele a felhasználókban, és nem arra, hogy azzal csalogassanak felhasználókat.

    A kártyákat egy smart reader azonosítja, a kontakt kártyákat be kell dugni az olvasóba. Az olvasó mögött ott kell lennie egy számítógépnek (elfogadható hálózaton keresztül is bárhol), aminek ráhatása lehet a pénztárgép végeredményére. A pénztárgép végeredménye az után lesz meg, hogy már minden tételt végig számolt, megvan a számla végösszeg, és utána azt az összeget keresztül kell küldenie azon az alkalmazáson, ami megkapta a kártya adatait, majd annak az alkalmazásnak a kimenetét kell végül felhasználni. Kérdéses, hogy a pénztárgép rendszereteknek van-e olyan támogatása? Ha nincs, akkor kicsit bukta a gondolat.

    Kedvezményekből annyi féle fajta lehet, mint égen a csillag. Az ötlettel annyi az "off", hogy hiába próbálsz egységes logikát kidolgozni rá, felejtős. A db-be vegyél fel egy olyan táblát, ami az érvényes kedvezmény kódokat rögzíti (darabra amilyen féle kedvezmények egyáltalán léteznek), aztán egy másik táblába a kedvezmény kód mellé egy DLL nevet is, amit a c# program betölt, és a háziszabványos interface-en keresztül küldi az összes adatot, amit egyáltalán felhasználhasson. Mint például hanyadik vásárlása volt az a kártyának, mi a végösszeg, mi az aktuális dátum, meg nem tudom még milyen feltételeket írtál vizsgálatra. Azokat mind tárolod db-ben minden kártyához. Adsz mindennek egyedi nevet, belepakolod mondjuk json-ba, beküldöd az egészet a DLL-nek, és az visszaküld majd egy kimeneti json-t, amit küldesz be a következő DLL-nek. A kedvezmények tényleges vizsgálatát és implementációját a DLL-ben írod meg. Amikor már nincs több kedvezmény-feldolgozód, ott az uccsó kimenetben a json-ban, mennyi kedvezménye legyen összesen a felhasználónak. Azt alkalmazod, küldöd vissza a pénztárgépnek.

    A kérdéseid:

    1) Az nincs rendben, hogy nem vagy letisztult információkezelési szemléletekhez hozzászokva. Talán éppen frissen szabadultál az egyetemről, ahol beletömték a fejedbe a mindenféle interface-eket, meg a szintaktikai nyalánkságokat, és arra kaptál jelest, ha azt mind visszabifláztad. A gyakorlatban az eszetlen bonyolultságot csak olyan környezetben használják, ahol nincs elásva a csatabárd, dúl az üzleti kanibálkodás, és mindenki mindenkinek farkasa. Ha most vagy fiatal, én azt mondanám, nem egészséges neked lelkileg olyan helyen időznöd. Szóval a bonyolultságot felejtsd is el. A gyakorlat egyszerű: .net c# 2.0 szintaktika. Ami abban még nem volt jelen, azt nem használhatod. Írj programot úgy. Ja igen, előtte szellőztesd ki az iskolát a fejedből. Ott nem a gyakorlatot tanultad, hanem az ellenkezőjét.

    2) Ha a felhasználóról semmi adatot nem tárolsz, csak a saját kártyáidat azonosítod - és édes mindegy neked, ki fogja azt felhasználni - a gdpr-nek nulla köze van a történethez. Eleve a smart card firmware alapján az is titkos, ahogyan a kártya működik. Mások ha akarják sem tudják azonosítani a kártya és a felhasználó összetartozását. És te különben sem kötelezel senkit arra, hogy az a kártya bárkihez tartozzon. Az nem magántulajdon, ami fixen személyhez lenne kötve. Oda adja egyik személy a másiknak, te csak vállat vonsz, hogy téged nem érdekel. Ha nem vonsz vállat, na akkor kerül a gdpr játékba - addig nem.

    3) Jogilag annyi a problémád, hogy olyan pénztárgépet használj, aminek van olyan engedett szolgáltatása, hogy vásárlói custom engedmény saját alkalmazás szerver döntése alapján. Történetesen a szoftvered kapcsolatban kell álljon a kártya olvasóval, meg a pénztárgéppel is. Nem tudod anélkül végrehajtani a folyamat egészét. Gondold csak át, hogyan csinálnád anélkül?

    Részemről egyetértek előttem felszólókkal abban, hogy egy kicsit nagyobb falat az említett rendszer részletes kidolgozása, átgondolása, bevezetése, mint amihez már kiforrott tapasztalataid lennének. Alábecsülted. Nagyon. Ha céges policy, hogy csak te barkácsolhatsz, akkor ezt a kártyás dolgot most inkább ne erőltesd. Sokkal több tapasztalatra lenne hozzá szükség. Majd pár év múlva újra előszeded. Egyébként is ráférne az üzleti matek és a sanity check az elgondolásra. Ha meg valami miatt mégis muszáj, amit itt nem részleteztél, fontold meg külső fejlesztő cég bevonását.
    Mutasd a teljes hozzászólást!
  • Ha ismersz ilyen kész szoftvert, szívesen vennék néhány javaslatot :) Amit mi keresünk:
    - egyszeri költségű licenc (tehát nem havidíj alapon számlázó szolgáltatót keresünk),
    - legyen kártyakibocsátó funkciója, amivel elkészíthetjük a saját kártyáinkat a mi látványtervünket használva,
    - képes legyen kezelni az általam felvázolt promóciókat a szoftver által kibocsátott kártyákat felhasználva.

    Kérlek titeket, ne térjünk el az eredeti kérdésektől. Valóban, nagyon érdekelne egy ilyen rendszer megtervezése, ezért is kezdtem neki én magam. Hogyha az segít a témánál maradásban, felejtsük is el, hogy élesben lesz használva :D
    Mutasd a teljes hozzászólást!
  • Ebből jött az ötlet, hogy csináljunk ilyen kártyákat, és azt vizsgáljuk, mibe kerülne egy ilyen rendszert kivitelezni.

    Akkor miert nem kerdeztetek meg egy fejleszto ceget arrol, vagy egy hivatasos fejlesztot? Szerintem ez ilyenkor kell megtanulni az oop alapjait.
    Mutasd a teljes hozzászólást!
  • Teljesen jogos, amit mondasz. Emellett felmerült még a Facebook-nyereményjáték ötlete is, amihez aztán végképp semmi sem szükséges (a felajánlott nyereményen kívül). Csak belegondoltunk abba, hogy az reklámnak nagyon jó, de nem ösztönzi a vásárlót a vásárlásra. Ebből jött az ötlet, hogy csináljunk ilyen kártyákat, és azt vizsgáljuk, mibe kerülne egy ilyen rendszert kivitelezni.
    Mutasd a teljes hozzászólást!
  • [off]
    Pár gondolat:
    Felejtsd el, egy átlag vásárlót ezt a szabályrendszert nem fogja tudni lekövetni. De valószínűleg az eladó sem fogja tudni, hogy mit üssön a pénztárgépbe (Egy rontás-> jelentős bizalomvesztés, ami induló fázisban elég fájdalmas)

    Ezzel nem fogod tudni elérni, megszólítani és becsábítani vevőket a boltodba, inkább fektesd az energiádat az online marketing megismerésébe, és alkalmazásába. Ott is lehet automatizálni, infós hajlamaidat kiélni.

    Ilyen kupon rendszer biztosan van, keresd meg és módosítsd ha szükséges.

    Értelmezésem szerint nem szoftverfejlesztő boltot akarsz létrehozni, tehát minden betű amit fejlesztéssel töltesz a boltod költsége.

    Gondolj bele ha ezt az energiát jól fizető projektekben használod fel akkor az abból származó pénzt be tudod fektetni marketingbe, tehát összességében hatékonyabb vagy.
    Mutasd a teljes hozzászólást!
  • A 2. 3. pontot konyvelovel es ugyveddel kell megbeszelni.

    - Interfacet akkor hozz letre, ha tobb fele implementacio kell. Ha csak egy fele kartya van akkor annak nem kell interface.

    Eloszor csinalj egy konkret implementaciot, szarmaztatas, interfacek es hasonlok nelkul. Nezd meg hogy mik a kozos pontok, mit kell bovithetove tenni, es ugy alakitsd at lepesenkent bovithetore.

    Az oop-nek nem az a lenyege hogy felhasznalj minden eszkozt es tervezesi mintat amit csinak lehet mert ugyan olyan rossz lesz a kod mintha nem oop lenne.

    A lenyeg az hogy ott legyen bovitheto ahol kell.
    Mutasd a teljes hozzászólást!
  • Nem beadandó :) Főleg, hogy már végeztem az egyetemen.
    Mutasd a teljes hozzászólást!
  • Ez ugye egy beadandó?
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Nem találtam a fejlesztésen belül megfelelő rovatot, ezért került a programozás-elmélet kategóriába. Illetve a kérdésemnek van társalgóba és tudástárba illő része is, de nem szerettem volna copy-paste-elni. Ha nem ide kellett volna nyitnom, bocsi :)

    Szeretnénk egy kis boltot nyitni és az első hónapban tervezünk kedvezménykártyákat kiosztani a vásárlók közt, ami tartalmaz egy egyedi azonosítót. Ezzel a kártyával kezdetben kétféle kedvezményre lenne jogosult a vásárló:
    1) A vásárló a következő 5 vásárlása során 10% kedvezményt kap a végösszegből.
    2) Ha megvolt ez az 5 vásárlása, akkor minden tizedik vásárlására kap 10% kedvezményt.
    Későbbiekben szükség lehet újfajta promóciókra is, mint például
    - bizonyos végösszeg felett jár X% kedvezmény (ez szintén érdekes, mert a pénztárgép nem áll majd kapcsolatban a szoftveremmel)
    - bizonyos időintervallumban történő vásárláshoz jár X% kedvezmény
    Van egy elképzelésem, hogy én ezt hogyan csinálnám meg, de szeretném kikérni a ti véleményeteket is, hátha vannak buktatói, amire én nem gondoltam.

    Először is felvettem a következő interfészeket:

    interface IPromotion { Guid PromotionId { get; } string Comment { get; } bool Apply(ICustomerCard customerCard); bool Applicable(ICustomerCard customerCard); } interface ICustomerCard { Guid CardId { get; } //ez a kártyán egy QR kód formájában látszik } interface IReadOnlyCustomerHistoryProvider { //ez az interfész megadja egy adott kártya history-ját IReadOnlyList<ICustomerHistoryItem> GetHistory(); } interface ICustomerHistoryItem { //ennek pedig van két implementációja - a kártya le lett olvasva és járt kedvezmény, illetve nem járt ICustomerCard Card { get; } DateTime Timestamp { get; } }
    Hogy ez könnyen bővíthető legyen új promóciókkal, felvennék egy AlwaysApplicablePromotion osztályt:

    public class AlwaysApplicablePromotion : IPromotion { public Guid PromotionId { get; } public string Comment { get; } public AlwaysApplicablePromotion(Guid promotionId, string comment) { this.PromotionId = promotionId; this.Comment = comment; } public bool Apply(ICustomerCard customerCard) { return true; } public bool Applicable(ICustomerCard customerCard) { return true; } }
    Majd ezt az osztályt a Decorator tervezési mintát használva bővíteném új funkciókkal, mint például:

    public class LimitedApplicablePromotion : HistoryBasedDecoratorBase { public int MaximumNumberOfApplies { get; } public LimitedApplicablePromotion(int maximumNumberOfApplies, IPromotion decoratedPromotion, IReadOnlyCustomerHistoryProvider historyProvider) : base(decoratedPromotion, historyProvider) { this.MaximumNumberOfApplies = maximumNumberOfApplies; } protected override bool ValidateCondition(ICustomerCard customerCard) { return this.HistoryProvider.GetHistory().OfType<PromotionAppliedHistoryItem>().Count(x => x.AppliedPromotionId == this.DecoratedPromotion.PromotionId) < this.MaximumNumberOfApplies; } }
    És itt kezdődik az a kihívás, amire még nem nagyon van ötletem. A promóciókat valahogy szerializálni kellene egy adatbázisba, de ezzel a megoldással van egy probléma: nem csak a promóció paramétereit és feltételeit kezeli egy IPromotion osztály, hanem a rendszerből is vannak függőségei, mint például az IReadOnlyCustomerHistoryProvider. Emiatt ha ki is tudom majd szerializálni, visszaolvasni adatbázisból már nem fogom tudni.

    És amiben a véleményeteket szeretném kérni az az, hogy:
    1) Érzem, hogy valami ezzel a tervvel nagyon nincs rendben. Valahogy külön kellene választani a promóció konfigurációját és feltételeit (ennek kellene a DB-be kerülnie), illetve az alkalmazhatóság vizsgálatát. De hogyan?
    2) Mennyire GDPR-kompatibilis ez így? Elvégre semmilyen customer információt nem tartok nyilván.
    3) Jogilag mivel jár egy ilyen rendszer bevezetése? Ha nem áll a szoftver kapcsolatban semmilyen más rendszerrel (pénztárgép, bankkártya-terminál), kell bármilyen jogi előkészület, hogy ilyen kártyákat adjunk a vásárlóknak? Egyáltalán önhatalmúlag lehet ilyen kártyákat osztani?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd