Endnu mere om priser, part 3

Nu hvor vi har en ide om hvordan vi kunne gøre det, så er det tide lige at vende tilbage til nogen af de krøller vi skøjtede let hen over i første omgang.

Første punkt er attributter på produkter. Ser vi på Übercart som et glimrende eksempel på hvordan brugerne ønsker det, så når vi hurtigt frem til at vi har brug for en metode til at afgøre hvordan en given attribut på et produkt påvirker produktets pris. Forskellen fra en almindelig produkt pris er at her giver en negativ pris også mening, da det reelt set er en modifikation af produkt prisen. En måde at implementere det på er ved at have en attribute_price(attribute_id, vid), hvor attribute_id er en unik ID i forhold til shop systemets attributter, i Übercart vil det sandsynligvis være oid (option id), mens i E-Commerce er det en vid da options er fulde noder. Hvad det er er sådan set ligemeget, vi skal bare bruge en unik id at hæfte priser på.

Übercart har så 'default priser' hvor der ikke er nogen node at regne ud fra, men spørgsmålet er om det er en feature der er vigtig. Men det kunne implementeres attribute_price(attribute_id, null).

Funktionen returnerer en pris meget lig product_price, dog med lidt andre keys, da det ikke vil være alle pris justerende moduler der vil være interesseret i at justere attribut priser også.

Så er det vi render ind i et problem, for hvordan får vi nu det inkluderet i produkt prisen? Den umiddelbare løsning ville være at tilføje et ekstra optional argument til product_price, hvor man kan angive de valgte attributter, og så lade et submodul (eller prismodulet selv) lægge dem til som en almindelig modifikation af prisen. Det logiske ville så også være at inkludere dem som en fast del af pris array'en, så themeren kan hive priserne på de forskellige options ud hvis han vil det. Så vi har et pris array der kunne se sådan her ud:

  1. array(
  2.   'base price' => 499,
  3.   'price' => 509,
  4.   'moms' => 101,8,
  5.   'attributes' => array(
  6.     1 => array(
  7.       'attribute name' => "Farve",
  8.       'selection name' => 'Blå',
  9.       'price' => 10,
  10.       'moms' => 2,
  11.     );
  12.   );
  13. ); 

Der er det vigtigt at de forskellige plugin moduler 'kommer til' i den rigtige rækkefølge, hvis man f.eks. har et plugin modul der automatisk lægger moms til, så bør den enten gøre det før attributterne bliver lagt til, hvis den også gør det for de enkelte attributter, ellers skal den gøre det efter. Men den vægtning bør være noget man kan styre fra administrationen.

Det andet problem vi gik lidt hurtigt over i første omgang er dependencies. Produkter der leverer priser vil for en stor dels vedkommende være afhængige af eksterne forhold. Priser på bruger grupper er et glimrende eksempel, dens pris er afhængig af den bestillende brugers tildelte roller. hvilket i bestillings fasen vil sige den aktive bruger. Men når vi når over i administrationen og den der styrer webshoppen kigger på bestillingen, så er det ikke længere den aktive bruger, men den bruger der er tilknyttet ordren.

Der er så 2 muligheder. Den første er at lade den slags dependencies følge produktet, så det i administrationen er muligt for koden der viser fakturaen at sige til pris modulet 'giv mig prisen, under de her omstændigheder'. Hvilket komplicerer tingene en kende, og ikke virker som den rigtige løsning når man overvejer mulighed 2.

Den anden mulighed hviler på en indsigt: På et eller andet tidspunkt er man nødt til at trække en linje i sandet og sige 'det her er prisen'. Om ikke andet, så når ordren afgives. Der er et punkt hvor ændringer i eksterne forhold ikke længere bør have nogen indflydelse. Når en kunde har godkendt en ordre med nogen priser, så nytter det ikke noget at de priser automatisk ændrer sig fordi webmaster i mellem det tidspunkt som kunden har afgivet ordren, og det tidspunkt han effektuerer den har ændret priserne på et produkt, eller brugeren er blevet tildelt en anden rolle.

Det understreges da også af at både Übercart og E-Commerce gemmer prisen for de enkelte produkter når de sættes ind i deres respektive ordre tabeller.

Hvilket taler for simpelthen at gemme det sidst genererede price array sammen med de enkelte produkter når bestillingen gennemføres.

Men naturligvis er der mindst en usecase der smider en svensknøgle i tandhjulene: Webmaster har lige fyldt nye tilbud i på nogen produkter, og vil gerne have at en ordre fra før får de ekstra billige priser.

Med den komplicerede løsning ville det bare være at trykke på 'genberegn priser', og ordren ville blive opdateret. Med 'trækken en linje i sandet' metoden er den eneste måde reelt set at justere prisen manuelt med en 'afslags' linje i fakturaen.

En sidste ting der også lige skal overvejes, er om line items som det hedder i Übercart, dv.s de ekstra linjer der kommer på en faktura i form af 'subtotal', 'moms', 'levering', etc, også skal køres igennem systemet på en eller anden måde. For ikke at tale om indkøbskurven som helhed, der kunne f.eks. være moduler der vil give rabat hvis der købes mere end 5 af et givent produkt. Eller om den slags stadig hører hjemme i shop løsningens regi.

Blog tags: