Preisanpassung

[Luckner]

Diese spez. Faktura ist nur für diesen Kunden geschrieben. Wenn er mal kein Bock mehr auf uns hat, wird dieses Programm auch wieder eingestampft. In der neuen allgemeinen Faktura, die gerade am entstehen ist, werden natürlich diese Punkte alle berücksichtigt werden. Da ich aber nicht weiß, ob der Kunde die nächsten 20 Jahre mit uns arbeiten möchte, würde ich nicht unbedingt nur eine einfache Lösung haben wollen, sondern eine die möglicherweise auch später funktioniert. Wenn der Kunde, jedoch in 2 Jahren weg ist, dann ist diese Faktura auch weg. Rechnungen liegen als Papier und/oder als PDF-Datei im Archiv.

Luckner.

[MyRealName]

Eine Preisliste kann (und sollte IMHO) auch aus Kopf- und Detai-Tabelle bestehen.
Im Kopf kommt Gültigkeitsdauer, eventuell KundenId (oder -1 wenn für alle), Name der Liste etc rein.
Im Detail kommt Artikel-ID mit Netto-Verkaufspreis.


Nicht jeder Artikel muss in der Liste stehen, es werden einfach bei der Preisfindung alle für den Kunden gültigen Listen mit dem Artikel durchsucht und der günstigste Preis genommen.

[Luckner]

In diesem Fall Aufschlag für alle Artikel. Ist es jetzt besser (auch für die Zukunft gedacht) in einer Tabelle pro Preisanpassung, jeweils 2 Spalten einzufügen mit DatumAb und Preis? Oder besser pro Preisanpassung eine neue Tabelle mit 2 Feldern zu erzeugen?

Luckner

[MyRealName]

Eine neue Tabelle pro Preisanpassung macht garkeinen Sinn, wie willst denn da ein gültiges SQL bauen. Muss man doch ständig seinen Code anpassen.

Wenn Du es ohne Kopf machen willst (ist dann eben nicht normalisiert), dann halt so

ArtikelId
PreisNetto (der Preis ohne Mwst)
PreisBrutto (Preis mit Mwst, damit Du ihn ohne Rundungsungenauigkeiten als Festwert hast)
GültigVon
GültigBis

Mwst-Satz ist preislistenunabhängig, deswegen eher ein Attribut des Artikels.

[Jasocul]

Da das ein kundenspezifischer Preis ist, würde ich die Kunden-ID mitführen. Es ist zwar im Moment nur ein Kunde, aber sollte ein weiterer dazu kommen, ist das in der Tabelle bereits berücksichtigt.

[Luckner]

Also, soweitich verstanden habe, pro Preisanpassung jeweils die 5 Spalten zufügen?

Luckner

[mikhal]

Dann musst du wieder deinen Code bei jeder Preisänderung anpacken.
Die fügst in die Tabelle Preisliste für jeden Artikel einen neuen Datensatz ein mit dem neuen Preis und dem Datum gültig ab. Beim derzeit gültigen Preis in der Preisliste trägst du in Gültig bis das Datum des neuen Preises -1 ein, so es dieses Feld gibt. Dann hast du eine Chronologie der Preise ohne dass du dir jedesmal die Mühe machen musst, deinen Quelltext anzupassen.

Die Preisfindung realisierst du dann über eine View oder eine Function auf der DB.

Grüße
Mikhal