Er prisen rigtig?

Jeg er involveret i nogen webshop projekter for tiden, hvilket har fået mig til at tænke lidt over konceptet 'pris' i samme... Den her post er en slags brain dump i forsøget på at finde ud af hvordan det bedst håndteres.

Det er jo rimeligt simpelt når man står ovre i Føtex, prisen er det tal der står på skiltet, og det er det. Men som sædvanlig bliver det noget mere kompliceret når ens kunde ikke hedder Bilka (som sikkert har sit helt eget helvede, men dem om det).

Problem nummer et:
Medmindre man udelukkende sælger smykker til private, så har vi allerede fra udgangspunktet 2 priser: private og erhvervsdrivende, med og uden moms. Umiddelbart er det meget simpelt, erhvervskunder skal have kostprisen, mens prisen for private er kostprisen * 1.25. Eller privat kunderne får prisen i databasen, mens erhvervskunderne er interesseret i prisen * 0.8, hvis man foretrækker det på den måde.

Problem nummer to:
Kunden (dvs. dem der køber shoppen) vil have at de kan give en speciel kundegruppe helt specielle priser. Selve grupperingen kan vi klare i Drupal med bruger roller, men kunden vil kunne sætte priserne for hvert produkt individuelt. Hvordan de kommer frem til prisen, melder historien ikke lige noget om, men det er i hvertfald ikke nok med en generel "10% på udvalgte varer" ordning. Så det er mindst 2 priser, en til almindelige kunder og så en til "guld kunder".

Kombineret med problem et, har vi pludselig 4 priser, almindelige privat kunders pris, almindelige erhvers kunders pris, privat guld pris, og erhvervs guld pris. I virkelighedens verden vil man oftest være uinteresseret i en af kombinations mulighederne (måske det kun er erhvervskunder der kan være guld kunder), til gengæld kan der være flere grupper (guld, sølv og bronze, f.eks.).

Problem nummer tre:
Resten af verdenen. Det lader til at enhver lille biks der beslutter sig for at smække en webshop op, tilsyneladende er under den opfattelse at det pludselig vil strømme ind med kunder fra hele verdenen. Det kan man så overveje om det er virkeligheden, men under alle omstændigheder giver det helt nye variationer, i hvert fald i nogen kombinationer af lande og erhvervs kunder. For hvor danske erhvervs og privat kunder i bund og grund skal af med lige mange kroner, men hvor erhvervs kunder gerne vil have prisen uden moms, så skal nogen udenlandske erhvervs kunder ikke betale moms. Og igen, så vil kunden måske kunne sætte separate priser for udenlandske kunder.

Problem nummer fire:
"Før 599,-, nu kun 499,-!". Igen, 2 forskellige priser, og nørden der sidder og laver frontenden vil sikkert gerne have begge 2.

Problem nummer fem:
Forskellige valutaer. Når prisen i kroner er 99,95, så vil 'man' måske ikke nøjes med en automatisk konvertering til $21.37. Hvis avancen er høj nok vil man måske have $19, eller også syntes man bare at de skal betale kassen, og skal betale $25 for at man har fornøjelsen af at skulle rode med toldvæsenet. Eller også bruger man Adobe metoden og $25 = €25.

Og man kan sikkert komme på flere speciel priser, og vi er slet ikke nået til procentvise discount tilbud eller andet der istedet for en ny pris, nøjes med at modificere en eksisterende.

Men lad os kigge på det praktiske:
De fleste webshop løsninger er bygget op omkring konceptet med 'en vare, en pris'. Nogen bevæger sig hen imod fler-pris-ideen ved at have lidt mere end en, men det begrænser sig for det meste til pris, før-pris, kost-pris, og måske nogen andre der primært har intern interesse. Übercart har 'list', 'cost' og 'sell' price, mens E-Commerce simpelthen har 'Price'.

Nu har jeg rodet nok med Übercart til at kunne sige at lave et modul der simpelthen justerer $node->sell_price er en skidt løsning. Primært fordi alle moduler antager at sell_price er prisen. Så hvis man f.eks. tror at man skal være smart og bruge uc_taxes til at lægge moms på, så bevæger man sig lynhurtigt ind i helvede..

Første hurdle er at uc_taxes er amerikansk skrevet, hvilket betyder at skatter er noget man lægger til til sidst på fakturaen. Sådan gør vi jo ikke, vi har pænt priser inkl. moms for privat kunder, og for erhvervskunder har vi som regel begge priser. Så man forsøger sig med uc_taxes_prices og så er vi allerede 10 skridt indenfor porten hvor der står 'Hades' ovenover.

For uc_taxes_prices fungerer ved simpelthen at justere sell_price for alle produkt noder når de bliver loaded, hvilket umiddelbart ser fjong ud. Indtil man når til checkout og den skal til at lave linjen hvor der står moms på, for så tager den gladeligt og lægger 25% oveni igen. Koderen har så forsøgt at fikse problemet ved ikke at lægge skatterne til når siden er cart/checkout, hvilket gør at alle priserne i ens indkøbskurv pludselig er uden moms.. Forvirrende og totalt uacceptabelt. Og det er ikke til at fikse da koden der henter indholdet af indkøbskurven til visning og den der gør det samme for at lægge totalen sammen, er den samme og ikke kan skelne imellem dem.

Nå, det var lidt en sidegade, men det demonstrerer at det er noget af en padoras æske at fedte med sell_price. Ikke desto mindre er det nøjagtig det moduler som uc_discount gør.

E-Commerce 4 ser umiddelbart ud somom den er mere på vej i den rigtige retning da den har et hook der hedder adjust_price, som tilsyneladende bliver kaldt de fleste steder. Men jeg venter med at komme med en dom over den indtil jeg har forsøgt at implementere nogen løsninger til de overnævnte problemer i den. Jeg har i hvert fald spottet at dens token support glemmer at kalde den,og hvis der er lignende oversights andre steder kunne det godt blive lige så bitter en fornøjelse som Übercart...

Hvilket alt sammen uværgeligt får mig til at overveje hvordan det burde gøres. Og her er det at det bliver meget teoretisk og 'man burde'-agtigt, men hvis man kunne komme op med en ordentlig plan, så er der måske en chance for at få det implementeret i Übercart eller E-Commerce. Og der er jo sådan set ikke noget til hinder for at man kunne lave et system som begge kunne benytte sig af, så frem med milimeterblokkene!

Et par ting jeg ihvertfald er nået frem til:

Punkt 1:
Det bør være muligt at forespørge en pris udelukkende på en vid (vi vil naturligvis gerne understøtte revisioner, så vid istedet for nid). Übercarts nodeapi metode og E-Commerce 4's adjust_price metode kræver begge at der bliver lavet en node_load på produktet, og det er ikke særlig holdbart for views og andre moduler der vil lave lister af noder med priser. Hvis et plugin modul død og pine skal have noden for at kunne komme med en pris, så må den selv lave en node_load og håbe på at cachen tager det værste af straffen.

Punkt 2:
Konceptet af flere sideløbende priser skal understøttes. Kun en vil i sidste ende være den der bliver brugt, men alt efter hvor i forløbet man er kan der være 'alternative priser' som bliver præsenteret for brugeren på forskellig vis. Systemet skal for det meste lade det være op til frontend folkene at beslutte hvilke der skal vises hvor, men det skal understøtte dem. Et 'før/nu' pris plugin modul kunne evt. tage prisen for den forrige revision af en produkt node og lade den være 'prev' pris.

Punkt 3:
Dependencies. Moduler der implementerer regler for alternative priser vil ofte afhænge af variabler udenfor produktet. Rolle priser afhænger af rollen, hvilket vil sige den bruger der bestiller, valuta priser afhænger af den valuta der betales i, andre kunne afhænge af leverings land eller antallet af stjerner på brugeren.. Disse afhængigheder skal modulet kunne fortælle systemet om, evt. gemme med 'produktet i indkøbskurven' eller 'produktet på ordren', så den har en jordisk chance for at kunne finde det igen når f.eks. admin kigger på ordren, og $user pludselig er en anden.

Og så er det der skal tænkes grundigt, for det er ikke noget problem at lave et meget avanceret system der giver de muligheder, men er et helvede at implementere og bruge. Når ideerne til hvordan det implementeres dukker op, skal man også overveje nogen helt nye problemer. F.eks.:

Vi forestiller os et sub modul der tilføjer en 'før pris'. Bagefter kommer der et bruger rolle baseret modul og sætter en anden pris. Hvordan skal de 2 arbejde sammen?

Jeg vil gå i tænkebox og få noget mad.

Blog tags: 

Comments

For at lige give den et nøk

For at lige give den et nøk mere på stuff der skal med
Hva "vi" (læs kunden bedre om - og frontend duden skal implementere) har behov for er også at kunne lave en pris der ligner det her:

Liste pris: 300 (standard prisen)
Din Pris: 250 (role price)
NU kun 200 ! (role price alt)

og selvfølgeligt med og ude skatter -så kan vi nemmerlige lave alle de fantastiske nu nedsat med 15% for almindelige mennesker men dig vores Guld kunde du får 33% (og pumpe lorte ud i flash filer og hva faen ved jeg )

men ellers så tror jeg vist du har det hele med...