Tabellenaufbau Auftragsverwaltung praktischer Tipp

[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.