Prisproblemer, part 2

Jeg er kommet til at tænke på at alt min snak om forskellige priser i sidste post, lidt giver indtrykket at jeg opfatter alle priser som lige. Men naturligvis er der det vi kan kalde prisen, nemlig den pris der i sidste ende bliver trukket på kundens dankort for den pågældende vare, og i en ideel verden burde det netop være det eneste tal som vi behøver at vise kunden. Men som vi også allerede har opdaget, så spænder moms lidt ben for den måde at anskue tingene på.

Ret beset, så kunne hele moms problematikken fikses ved at shop løsningen forstod konceptet 'display price'. Man kunne så have alle sine priser inkl. moms, og nøjes med en faktura linje der beregner 20% af varernes samlede pris, eller man kunne have dem uden moms, og lade den lægge 25% til på faktura'en. Og så kunne 'display price' blive justeret +/- moms, alt efter kunden er erhvervs kunde eller ej. Men i hvert fald Übercart har svært ved den forskel.

Men hvis vi lige glemmer moms og procentvise discounts et øjeblik, og vender tilbage til de 'alternative priser' baseret på bruger grupper, valutaer og den slags, så kan vi se at der er en 'basis pris'. Der er altid en 'grundpris', uanset om den varierer pga. brugeren, valutaen eller andet.

'Basis prisen' svarer meget godt til Übercarts sell_price og E-Commerces price, hvor den sådan set er et spørgsmål om at kunne vise prisen på forskellige måder (med og uden moms f.eks.), men prisen der i sidste ende bliver trukket er stadig den samme. Så man kunne fristes til at blive ved den måde at gøre det på og udelukkende bygge et system op til at vise alternativerne diverse steder. Men som jeg allerede har påpeget har det som minimum nogen performance-mæssige problemer, og ville i hvert fald i Übercarts tilfælde kræve hård patchning af webshop modulerne.

Ud over at det ville være rart med et dedikeret system til at give forskellige priser afhængigt af ydre omstændigheder, så er det en fordel med en metode til at få et definitiv pris, uden at skulle være omhyggelig med at noden er loaded og alle mulige hooks er blevet kaldt.

Så lad os prøve at konkretisere det lidt med version 0.001:

  1. $price = product_price($vid);

Ideen er at alle moduler der vil bruge prisen på et produkt kalder den funktion, som gør det magiske med at finde den rigtige pris alt efter omstændighederne, og kalder alle moduler der gerne vil hooke sig ind i den process (discount moduler og lignende).

I første omgang kan vi sige at den returnerer en array med forskellige priser:

  1. array(
  2.   'currency' => 'dkk',
  3.   'price' => 499,
  4.   'previous' => 599,
  5.   'eksl moms' => 399.2
  6. );

Den key der hedder 'price' er så prisen som bliver brugt til faktureringen. For at gøre livet nemmere for alle andre, kunne vi også definere en theming funktion:

  1. theme_price($price, 'location');

Hvor 'location' er en streng der definerer hvor outputtet bliver vist. Der skal laves en liste over standard steder ala 'cart', 'product', 'checkout', etc, så det er simpelt for themeren at lave det så produkt priserne vises som "499,- (399,20 eksl. moms)" på produktet og evt. som 399,20 i indkøbskurven hvis det er en erhvervskunde. Der vil naturligvis skulle være noget samspil imellem de moduler der leverer de alternative priser og ham der sidder og laver frontenden, men det betyder at resten af systemet ikke behøver at skulle bekymre sig om detaljerne.

Så er der stadig en udfordring i at udforme product_price funktionen så den kalder forskellige submoduler i den rigtige rækkefølge, men i første omgang kan man sådan set hardcode den til ens specifikke regler.

Tyg lidt på den.. Kan det gøres simplere, bedre? Er der nogen problemer i den approach?

Blog tags: