Preisanpassung

[mikhal]

Dann erweitere deine Erkenntnisse um weitere Überlegungen:
+ Trennung von Verkaufs- und Einkaufspreisen
+ Verkaufspreise mit Staffeln
+ Einkaufspreise mit Staffeln und verschiedenen Lieferanten

Wie werden Rabatte verarbeitet? Auch hier kann/sollte man nach Verkauf und Einkauf unterscheiden. Das Ganze ist ein weites Feld mit vielen Tretminen. Spreche mal mit den Einkauf und dem Verkauf, finde heraus, wie dort die Preise und damit die Rechnungen/Bestellungen behandelt werden. Letztlich muss anschließend ein eindeutiger Einkaufspreis für einen Artikel bei einer gegebenen Menge bei einem bestimmten Lieferanten mit einem möglichen Rabatt herauskommen und zwar bei den gleichen Parametern immer der gleiche. Das gilt auch beim Verkaufspreis...

Grüße
Mikhal

PS: Lieferzeiten sind auch nicht schlecht in der Betrachtung (für den Einkauf und für den Verkauf).

[Luckner]

Hi mikhal,

EK-Preise, VK-Preise und auch andere Sachen werden in der neuen Software sicherlich eine Rolle spielen. Ich brauche speziell für diese eine Faktura nur eine Lösung zur einer vernüftigen Preisanpassung. Auch für die Zukunft (solange es diesen, guten Kunden gibt) brauche ich diese Ideen. Hier spielen EK-Preise usw. keine Rolle.

Luckner

[Jasocul]

Du brauchst eine Tabelle mit der Kunden-ID, der Artikel-ID, dem VK-Preis und dem Zeitraum der Gültigkeit.
Beim Zeitraum gibt es verschiedene Möglichkeiten. Entweder hast ein Ab-Datum, ein Bis-Datum oder beides.
Ich bevorzuge die Variante, bei der beides vorhanden ist. Dann kann man z.B. einen kundengebunden Artikelpreis nicht nutzbar machen, ohne ihn zu löschen und hat trotzdem die Info, von wann bis wann er genutzt wurde.
Man könnte auch ein Feld einführen, das kennzeichnet, welcher Datensatz aktiv ist. Aber das wäre im Grunde redundant, da die Info sich aus dem Zeitraum ergibt.

[Luckner]

Zur Zeit, geht es nur um einen Kunden. Also, es spricht doch alles dafür, wie ich es unter Punkt 2) a oder b geschrieben habe?

Luckner

[Jasocul]

Zitat von Luckner:

Zur Zeit, geht es nur um einen Kunden.

Zitat von Luckner:

Auch für die Zukunft (solange es diesen, guten Kunden gibt) brauche ich diese Ideen

Kommt vielleicht mal ein weiterer guter Kunde?
Kann es weitere Preisanpassungen geben?

[QuickAndDirty]

Eine richtige Faktura sollte unterschiedliche Preise je Kunde können und natürlich müssen alle Preise historisierbar sein! Wie man das unter der Haube macht ist eigentlich egal.
Du hast im Moment ein Problem, weil du die Preise nicht historisierbar gehalten hast. Das Selbe muss auch auf der Lieferantenseite geschehen. Sprich historisierbare EK-Preise und differenziert nach Lieferant.

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