Preisanpassung

[Luckner]

Hallo,

jetzt, wo Alle die Preise anpassen, muß auch unsere Firma eine Preisanpassung anstreben. Habe in den letzten Jahren ein kleines Fakturaprogramm geschrieben und mit einem Artikelstamm. In der Artikelstamm-Tabelle steht auch der Grundpreis für den betreffenden Artikel. Jetzt kommt eine Preisanpassung in Prozent für alle Artikel. Meine Überlegungen sind folgende:
1) eine einfache Lösung wäre per SQL-Befehl den Grundpreis der Artikel der gesamten Datensätze um einen Faktor zur erhöhen. An dem betreffendem Tag wird diese Routine ausgeführt und Preise sind angepasst.
Blöd ist nur, wenn man nach diesem Datum einen alten Auftrag (Rechnung) korrigieren muß, dann rechnet das Programm mit den neuen Preisen.

2) Das ganze vom Datum abhängig zu machen. Und zwar:
a) die alten Preise behalten. eine Tabelle mit 2 Feldern erzeugen: Datum, Faktor. 1-Ter Datensatz: "01.01.2014, 1" . 2-ter Datensatz: "01.01.2023, 1.25". Je nach Auftragdatum den Grundpreis mit dem entsprechendem Faktor multiplizieren.
b)mehrere Tabellen mit 3 Feldern: "Artikelnr, Datum, Preis" und je nach Datum in die entsprechende Tabelle springen und den Preis aufrufen.
c) eine Tabelle mit "Artikelnr, Datum1, Preis1, Datum2, Preis2, Datum3, Preis3, usw." Neue Felder werden erstellt, wenn neue Preisanpassung benötigt.

Sicherlich gibt es noch andere Ideen, die mir z.zt. nicht einfallen und deshalbt brauche ich Eure Hilfe.

Gruß, Luckner

[Maliko]

Deine erste Lösung ist mit Sicherheit die schlechteste wie du bereits selbst gemerkt hast.

Also ich würde dir dazu raten die Lösung 2A zu verwenden. Jedes mal wenn die Preise erhöht werden die Tabelle zu kopieren und dann zur neuen zu springen bläst die Datenbank von den Tabellen her sehr auf, das selbe bild für die andere Lösung mit Spalte pro Preis. Dann hast du irgendwann 200 Preisspalten. Je nachdem was du für ein Datenbanksystem hast, bekommst du da irgendwann auch Probleme, je nachdem wie viele Spalten eine Tabelle im System überhaupt haben darf.

Wir nutzen auch die Lösung 2A allerdings mit 2 Datumspalten. Die erste ist das Datum ab wann der Preis gilt und die zweite Spalte ist das Datum bis wann der Preis gilt. Beim den aktuellen Preisen lassen wir Datum-bis dann immer auf null. Darüber kann man dann auch ganz bequem die aktuellen Preise abfragen, da man dann einfach nur alle Preise abfragt die kein Enddatum haben.

[Jasocul]

Zitat:

Zitat von Luckner (Beitrag 1516110)

Blöd ist nur, wenn man nach diesem Datum einen alten Auftrag (Rechnung) korrigieren muß, dann rechnet das Programm mit den neuen Preisen.

Wie oft kommt das denn vor? Wenn das sehr selten ist, kann man auch einfach mal die Menschen in die Verantwortung nehmen, die die Rechnung bearbeitet. Ich gehe davon aus, dass man dort den Preis auch manuell pflegen kann.

Ansonsten würde ich auch Lösung 2a verwenden. Aber dafür muss dann möglicherweise auch die Anwendung angepasst werden. Es sei denn, das ist so gut strukturiert, dass du eine View (oder andere Möglichkeiten der DB) genutzt hast. Das würde den Anpassungsaufwand relativ gering halten.

[Maliko]

Zitat:

Zitat von Jasocul (Beitrag 1516113)

Wie oft kommt das denn vor? Wenn das sehr selten ist, kann man auch einfach mal die Menschen in die Verantwortung nehmen, die die Rechnung bearbeitet.

Das hängt davon ab wie die Rechnungen gesichert werden. Wenn die Originalrechnungen gesichert werden, so dass man diese jederzeit wieder ausdrucken kann, dann ist alles in Ordnung. Wenn die Rechnungen aber wie bei uns jedes mal neu Generiert werden, bekommst du spätenstens dann Probleme wenn das Finanzamt oder die Polizei eine ältere Rechnung anfragt. Und glaub mir dass passiert häufiger als du glaubst.

[himitsu]

Alle Artikel kopieren und in der Kopie den Preis anpassen?

Einfacher wäre es, wenn man die Artikel usw. revisionieren könnte (alle Artikel haben den selben Namen/Bezeichner aber sind mit einer internen Nummer/Serial mit den anderen Datensätzen verknubbelt),


also alle alten Rechnungen laufen gegen die alte Revision/kopie und es somit passt es immer.

[juergen]

Ich möchte zu 2A noch anmerken, wenn sowieso eine Erweiterung ansteht, dann direkt noch zwei Spalten für MwSt-Änderung (mit Datumsbezug )mit aufnehmen, falls die sich auch mal ändert.

[Jasocul]

Zitat:

Zitat von Maliko (Beitrag 1516114)

Zitat:

Zitat von Jasocul (Beitrag 1516113)

Wie oft kommt das denn vor? Wenn das sehr selten ist, kann man auch einfach mal die Menschen in die Verantwortung nehmen, die die Rechnung bearbeitet.

Das hängt davon ab wie die Rechnungen gesichert werden. Wenn die Originalrechnungen gesichert werden, so dass man diese jederzeit wieder ausdrucken kann, dann ist alles in Ordnung. Wenn die Rechnungen aber wie bei uns jedes mal neu Generiert werden, bekommst du spätenstens dann Probleme wenn das Finanzamt oder die Polizei eine ältere Rechnung anfragt. Und glaub mir dass passiert häufiger als du glaubst.

Müssen Rechnungen nicht revisionssicher abgelegt werden? Ich kenne nur sehr wenige Fakturierungssysteme, aber diese haben Rechnungen mit ihren Daten entweder redundant in der DB abgelegt oder DMS genutzt.

[Maliko]

Zitat:

Zitat von Jasocul (Beitrag 1516120)

Müssen Rechnungen nicht revisionssicher abgelegt werden?

Das ist korrekt. Darum haben wir uns halt auch für die Variante 2A entschlossen, weil wir so die jeweils gültigen Daten speichern können und wenn eine Rechnung neu gedruckt werden muss, diese einfach neu mit den Originaldaten generieren können. Zusätzlich speichern wir die Originalrechnungen aber auch noch einmal als PDF (allerdings hauptsächtlich für das Kundenportal, damit die Kunden sich ihre Rechnungen noch einmal runterladen können).

[Luckner]

Jetzt fällt mir noch auf, dass wenn nach der Preisktualisierung ein neuer Artikel angelegt wir, und dann ein aktl. Grundpreis festgelegt wird, dann wird er auch mit dem neuen Faktor berechnet und dann explodieren die Preise. Wer weiß dann schon, dass da noch ein Faktor dahinter liegt. In meinen Augen nicht so ideal.

Luckner

[Luckner]

Zitat:

Zitat von Jasocul (Beitrag 1516120)

Müssen Rechnungen nicht revisionssicher abgelegt werden?

Ich hatte das so gelöst, dass entsprechende Artikel, die in dem betrefendem Auftrag aufgeführt werden, in einer AuftragArtikel-Tabelle abgelegt werden. Das heißt, dass die Auftragsartikel nicht mehr identisch sein müssen mit dem Stamm, ausser man ruft den betreffenden Artikel in diesem Auftrag nocheinmal auf und aktualisiert ihn. Beim speichern des Auftrages, werden diese Artikel dann wieder in dieser AuftragArtikel-Tabelle aktualisiert. Also kein direkter Bezug auf die Stammartikel. Wenn sich jetzt die Preise im Stamm ändern, passiert mit den alten Aufträgen erstmal nicht viel.

Luckner