Delphi-PRAXiS
Seite 2 von 4     12 34      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Preisanpassung (https://www.delphipraxis.net/212072-preisanpassung.html)

mikhal 13. Dez 2022 13:29

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

DeddyH 13. Dez 2022 13:33

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.

Luckner 13. Dez 2022 13:47

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

mikhal 13. Dez 2022 13:55

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

Luckner 13. Dez 2022 14:17

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

Jasocul 14. Dez 2022 05:54

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.

Luckner 14. Dez 2022 07:32

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

Jasocul 14. Dez 2022 07:59

AW: Preisanpassung
 
Zitat:

Zitat von Luckner (Beitrag 1516148)
Zur Zeit, geht es nur um einen Kunden.

Zitat:

Zitat von Luckner (Beitrag 1516129)
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 14. Dez 2022 08:01

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.

Luckner 14. Dez 2022 08:59

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 17:29 Uhr.
Seite 2 von 4     12 34      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz