![]() |
AW: Preisanpassung
Habt ihr seit der Anlage der Artikel nie die Preise geändert? Das Problem, das du beschreibst, muss es bereits gegeben habe. Hinzu kommt, dass Lieferanten ganz gerne unterjährig Preise anpassen.
Der Preis hat im Artikelstamm nichts verloren, der gehört im Datenmodell immer als eigene Instamz / Tabelle gepflegt. z.B. als Preisliste mit Artikelnummer, Gültig von, Gültig bis, Preis netto. Die Umsatzsteuer muss in einer eigenen Tabelle gepflegt werden (mit ähnlichem Aufbau) ggf. erweitert um Land und entsprechende Umsatzsteuer (Import). Grüße Mikhal |
AW: Preisanpassung
Sehe ich auch so, wobei ich immer nur ein Datum verwenden würde (GueltigAB oder ähnlich). Das hat zwar den Nachteil, dass die Preisabfrage eines Artikels zum Zeitpunkt X etwas umständlich wird, aber so können keine Überschneidungen oder Zeitspannen ohne Preis auftreten.
|
AW: Preisanpassung
Hallo mikhal,
nein die Preise wurden damals (Senior-Chef) als Festpreis ausgehandelt und bis heute nicht erhöht. Diese Faktura wurde damals, aufgrund von speziellen Anforderungen und Besonderheiten für einen speziellen Kunden, von mir auf Firebird-Basis geschrieben und in laufe der Zeit erweitert und angepasst. Wir haben hier noch eine andere Faktura für andere Aufträge (auch schon locker 25 Jahre alt, die ebenfalls von einem Freelancer auf Access-Basis erstellt) und die, aufgrund der weiteren User und anderen Erweiterungen, sehr langsam, nicht mehr passend und oft absturzgefährdet geworden ist. Die schreibe ich jetzt auch um auf Firebird und würde diese neuen Erkenntnisse dort ebenfalls unterbringen. Wie würde dann eine Tabelle mit Preisliste mit Artikelnummer, Gültig von, Gültig bis, Preis netto, aussehen? Gruß, Luckner |
AW: Preisanpassung
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). |
AW: Preisanpassung
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 |
AW: Preisanpassung
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. |
AW: Preisanpassung
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 |
AW: Preisanpassung
Zitat:
Zitat:
Kann es weitere Preisanpassungen geben? |
AW: Preisanpassung
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. |
AW: Preisanpassung
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:52 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz