Tabellenaufbau Auftragsverwaltung praktischer Tipp

[mkinzler]

Statt Prefixe wären auch eine extra Feld möglich ( z.B. mit FK auf Artentabelle)

[Hansa]

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.

[angos]

JA, der Testaufwand für eine solche komplette Kalkualtion ist nicht Ohne (der ist sogar erfahrungsgemäß erschreckend hoch).

Ich verstehe noch nicht, wozu du für eine einmalige bestellung eine zusätzliche (du willst sogar drei) Tabelle brauchst. Der Rabatt wird der Position zugeordnet. Davon abgesehen muss auch in den anderen Fällen der Rabatt den Positionen zugeordnet werden, da dieser sich durchaus, auch bei ein un d dem selben Kunden/Produkt, ändert.
Man kommt nicht drumherum die Werte zu dem Dokument zu speichern, da sonst, wie du schon gesagt hast, ein erneuter Ausdruck, oder nur das Prüfen eines alten Dokuments (bezüglich zB einem neuen Angebot für den gleichen Kunden), falsche Werte liefert.

[mkinzler]

Zudem sollte man die Stammpreise "snowflaken". D.H. die Änderungen der Preise protokollieren

[Hansa]

Das mit den 3 Tabellen war ein Beispiel. Leichter zu programmieren z.B. für Listen : einer will wissen, wieviel Rabatt er auf was kriegt. Bei drei Tabellen würde ich die in absteigender Priorität durchgehen. Das hiesse dann : einfacher Join auf Artikel bzw. Warengruppe.

Ähnlich wäre eine einzelne Rabatttabelle zu behandeln. Flag für Artikel/WG-Rabatt usw.

Dann gäbe es ja noch die Möglichkeit, die Rechnungspositionen für Rabattzwecke zu missbrauchen. D.h.: der Preis wäre der Rabattwert und man hätte noch ein Bool-Feld RABATTPOS o.ä.

[jobo]

Zitat:

Dann gäbe es ja noch die Möglichkeit, die Rechnungspositionen für Rabattzwecke zu missbrauchen.

Das ist hoffentlich ein Scherz

Ich finde den Gedanken von SirRufo gut, Warengruppen zu bilden und implizit mit Merkmalen zu belegen, zumindest, als ersten, kleinen Ansatz. Dann muss man allerdings bei der Definition aufpassen, dass man nicht funktionale und logische Elemente vermischt. Warengruppe "Gas, Wasser, Schei.." ist diesbezüglich halt was anders als Warengruppe "Dienstleistung". Dann ist man auch sehr schnell bei der Frage, wie kann man sowas mischen usw usw.

Rabatte gibts in allen Varianten, vom Produktrabatt, Zahlungszielen bis zur Werbeaktion oder zeitbegrenzten Rabatten oder Volumenrabatten. Die müsste man entweder in den verschiedenen Ebenen einziehen oder alternativ könnte man- wie glaub ich schon irgendwo geschrieben- Rabatte als Produkte definieren, im funktionalen Warengruppenansatz wäre das dann Warengruppe "Rabatt". Hier ist dann noch zu berücksichtigen, dass man im Datenmodell des Produktes nur mit absoluten Preisen rechnet und Rabatte dann entsprechend pflegen. Ein Rabatt, der spezifisch ist (s.o.), technisch aber nicht spezifisch implementiert ist, kann natürlich auch wieder schnell in die Hose gehen.

@Andreas: Ich wollte Deine SQL Kenntnisse nicht in Frage stellen. Ich habe versucht, eine praktikable Vorgehensweise darzustellen, so wie Du gefragt hast. SQL hat auch eigentlich nicht viel mit Entwurf/Design eines solchen Systems zu tun.
Und Ich hoffe, Du bist Dir bewusst, dass die Anschaffung von 1 oder 2 Softwarepaketen (Connectivity/Reporting) nur einen kleinen Teil der (Personal)Kosten darstellt, die Ihr für Entwicklung und Tests ausgeben werdet.