Kassabon adresgegevens

[ZeroXT]

Beste mensen,

Ik heb niet zozeer een programmeervraag maar wist niet waar dit ontwerp het beste in terecht kon.

Momenteel ben ik soort van online kassa aan het ontwikkelen. Er wordt automatisch een kassabon gegenereerd na een succesvolle verkoop. Echter zijn deze kassabonnen ook terug te bekijken en worden deze "on the fly" gegenereerd door PHP.

Alle gegevens worden platgeslagen en in de database gezet. Een gekoppelde klant wordt gekopieerd naar de order tabel zodat de bon ook over twee jaar er gelijk uit ziet, zelfs als de klant veranderd is.

Nu haal ik enkel de adresgegevens van het bedrijf die de producten verkoopt (niet de klant is) op uit de database, maar deze kunnen in de loop van tijd door verhuizing veranderen. Hierdoor is het mogelijk om een kassabon te genereren van twee jaar geleden met de nieuwe adresgegevens.

Is dit een goede optie? Of moet ik ook de adresgegevens van het bedrijf platslaan en in de order tabel opslaan?

[Rmg]

Lijkt me idd meer een werk en inkomen vraag idd..


Wat zegt je klant voor wie je de site bouwt? hoe doet hij dat nu? wil ie dat anders?

Bouw je het voor jezelf? Wat lijkt jouw handig?

Persoonlijk zou ik een kassabon / order zo willen hebben als hij er x jaar geleden uitzag. Waarschijnlijk zou ik er zelf voor kiezen om in mn database alleen een record te hebben en een verwijzing naar kassabon/orderbon in PDF. Dat kan je zelfs combineren met een optie dat je een oude bon met nieuwe adres gegevens genereerd

BIj een geschil lijkt het me niet handig dat een klant naar me toekomt en me met een originele bon die ik vervolgens niet op die manier terug kan vinden/krijgen.

[Gleighton]

Je kunt ook alle changes in de adresgegevens bijhouden, waarbij je de begindatum en evt. einddatum opslaat. Met behulp van de verkoopdatum heb je dan de bijbehorende adresgegevens. Dit zelfde principe zal je waarschijnlijk ook toe moeten passen bij producten (namen en prijzen veranderen) en mogelijk het btw tarief.

[Gomez12]

De oplossing die ik meestal zie is (naast een platgeslagen / vastgezette tablel) een pdf genereren en die gewoon vast opslaan.

Dat is je daadwerkelijke representatieve kassabon in de eindvorm. Qua lookups/nakijken etc kan je de database gebruiken. Maar voor de daadwerkelijke copie heb je de pdf.
Want er kan bijv ook iets wijzigen in de template qua tekstuele dingen (bijv verwijzingen naar algemene voorwaarden of gedeponeerde dingen of wetboekteksten) maar bijv ook iets heel simpels als een bank-nr wat omgegaan is naar een iban-nr en wat daardoor langer is geworden en layout-technisch van plaats is verschoven (waardoor een origineel en een kopie toch weer iets verschillen), of een overname van een bedrijf waardoor de huisstijl verandert of... of ...

Er kan van alles veranderen en dat kan allerlei oorzaken hebben, daarom zou ik gewoon de originele representatie zoals de klant die heeft gehad opslaan en niet enkel de onderliggende data waaruit je het weer kan reproduceren.

Ik zou zeggen genereer het on the fly naar een niet-veranderbaar formaat en lever het niet-veranderbare formaat aan de klant

[Megamind]

Hoe ik het zelf gedaan heb is de totale transactie vastleggen in een XML en deze opslaan in de database naast wat simpele meta data.

Over de loop der jaren worden er nogal wat tabellen aangepast, veranderen er gegevens en elke keer is het weer gedoe met de historie, aangezien het nu letterlijk een plat object is hoef je alleen maar de weergave processor backwards compatible te houden.

Daarnaast: alle gegevens ten tijde van de transactie die betrekking hebben tot de transactie (ordernr, btw, bedragen, klantadres, verzendingen etc) opslaan, telefoon nummer en adres van het bedrijf kunnen prima dynamisch blijven.

[ Voor 4% gewijzigd door Megamind op 31-10-2014 23:24 ]