War klar, dass auch noch Rabatte auftauchen.
Da geht das Spielchen genau so weiter wie gehabt : ein Rabatt ist grundsätzlich vereinbart, dann braucht man dafür eine Stamm-Table. Solche Strukturen sind dabei nicht unüblich : 10 % Rabatt auf Gemüse (als Waren-Hauptgruppe) und auf Gurken gibt es 15 % (Waren-Untergruppe) und wenn einer spanische Gurken will (Artikel), dann gibt es jetzt 30 % Rabatt. Um das umzusetzen braucht man dann 3 Tabellen.
Ein Sonderfall wäre nun kein Sonderfall, wenn er nicht noch einen Sonderfall hätte : einer will für die nächste Lieferung spanischer Gurken 50 % Rabatt, sonst würde er nichts bestellen. Und nun ? Wenn es irgendwie geht, dann würde ich sagen, man macht eine kurzfristige Änderung in der Rabattverwaltung, schreibt die Bestellung und speichert den Rabatt und dann wieder zurückändern. Aber, wer sieht den Haken an der Sache ? Wird später die Rechnung neu gedruckt, dann ist ja der Rabatt wieder bei den üblichen 30 %. Ergo : die ganze Geschichte muss auch wieder irgendwo bei den Rechnungspositionen untergebracht werden. Also für die genannten 3 Rabattarten noch 3 Tabellen.
Aber das ist nocht längst nicht alles. Sagen wir mal : bestellt werden : 10 x spanische Gurken, 10 x deutsche Gurken, 10 x Tomaten, 10 x Bohnen. Das Programm muss dann folgendes errechnen : es gibt auf 20 Einheiten 10 % (Bohnen+Tomaten), 15 % auf die deutschen Gurken und 30 % bzw. 50 % auf die spanischen Gurken.
Kommen da jetzt auch noch möglicherweise beliebige Preise/Rabatte ins Spiel, dann gilt : Viel Vergnügen beim testen.
