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.