Preisanpassung

[Jasocul]

Zitat von Luckner:

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 von Jasocul:

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 von Maliko:

Zitat von Jasocul:

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 von Jasocul:

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 von Jasocul:

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

[mikhal]

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]

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.