Problem Adress Änderungen

[Gregor123]

Habe ein Problem mit der Verwaltung von Adressen in einem Fakturierungsprogramm.
Finde nicht im Netz wie ich das lösen kann.
Nehmen wir an, die Hausnummer des Kunden mit der KD-Nr 1234 ändert sich. Wenn ich diese jetzt im Datensatz ändere und ich kurz darauf eine alte Rechnung für ihn neu ausdrucken muss, wird diese alte Rechnung mit der neuen Hausnummer gedruckt. Das geht nicht. Ich will aber auch keine neue Adresse eingeben. Dann wird es kompliziert mit Statistiken. (Wie viel hat der Kunde bestellt.)
Ich will aber auch nicht in alle Angebote, Rechnungen, und sonstige Formulare die Adresse „fest“ abspeichern. Das würde ziemlich viel „Datenmüll“ verursachen da ein Adress-Datensatz ca 60 Spalten hat.
Ich habe schon einmal daran gedacht in die Adresse ein von-bis Datum einzubauen.
Es gäbe dann bei Änderungen mehrere Datensätze der gleichen Adressen mit verschiedenen Gültigkeitsdaten.
1. Datensatz gültig vom 01.05.2024 - 15.09.2024
2. Datensatz gültig vom 16.09.2024 - 31.10.2025
3. Datensatz gültig vom 01.11.2025 – offen

Wenn ich jetzt eine Rechnung mit Datum 20.09.2024 nochmal drucken muss wird der 2. Datensatz benutzt. Wird aber wahrscheinlich eine sehr komplizierte Abfrage. Habe es noch nicht ausprobiert.
Gibt es keine einfacherer Möglichkeit? Wie habt ihr das gelöst.
(Das gleiche Problem gibt es ja bei Artikeln wenn sich z.B. der Preis ändert).
Viele Grüße
Gregor

 

[castorp]

Es gibt zwei Möglichkeiten so etwas zu lösen. Die eine ist wie von Dir beschrieben, die Adressen zu historisieren und die jeweils gültige zu ermitteln. So kompliziert ist das gar nicht (mit Postgres sogar extrem einfach).

Die andere Möglichkeit ist, beim Anlegen der Rechnung eine Kopie der Adresse in der Rechnung zu speichern.

 

[ukulele]

Ich finde historisierte Datensätze sehr sinnvoll, ich mache das grundsätzlich, zusätzlich zur Log, ganz unabhängig von Rechnungen. Es gibt sogar noch eine Steigerung, wenn du dir z.B. Register-Daten anschaust. Dann gibt es im Prinzip drei Ebenen: 1. Wann hat sich das Attribut in der realen Welt geändert? 2. Wann wurde es im Register bekannt gemacht? 3. Wann wurde es in der Datenbank geändert. Deine Form ist also alles andere als komplex.

Bei Rechnungslegung wird häufig mit Kopien aller rechnungsrelevanten Daten gearbeitet, vermutlich macht das am Ende jede Fakturierungslösung so um sich vor Manipulation zu schützen. Es ist viel einfacher, eine Kopie pro Rechnung zu speichern als die Stammdaten auf Manipulation zu überwachen. Die Datenmenge ist eigentlich nie das Problem.

Ich würde beide Wege gleichzeitig gehen.

 

[haldenjunge]

Ich nutze den Weg, alle für einen Auftrag relevanten Daten in der Auftragstabelle zu speichern. Die Adressen wie z.B. Lieferadresse, Rechnungsadresse, aber eben auch voreingestellte Daten wie Rabatte etc. werden aus dem Kundenstamm in den Auftrag (oder besser gesagt in die "Auftragsmappe") kopiert. So ist es möglich, Angebote, Rechnungen, Stornos etc. immer aus dem Auftrag heraus zu bedienen, ohne noch einmal neu auf die Adressdaten zurückgreifen zu müssen.
Sofern - bei mir - eine Rechnung oder eine Gutschrift erstellt wurde, damit der Gesamtauftrag faktisch "final" ist, wird auch die Möglichkeit geblockt, etwas an der Zuordnung der Kundenstammdaten zu ändern.

 

[ukulele]

So ist es möglich, Angebote, Rechnungen, Stornos etc. immer aus dem Auftrag heraus zu bedienen, ohne noch einmal neu auf die Adressdaten zurückgreifen zu müssen.

Das kann aber fatal enden. Wenn du z.B. eine Rechnung schreibst, willst du da die Adresse aus dem Auftrag oder aus den aktuellen Stammdaten ziehen? In dem Moment, wo die Rechnung fakturiert ist, darf sich die Rechnungsadresse natürlich nicht mehr ändern. Solange das nicht der Fall ist, würde ich immer auf die aktuellen Daten zurück greifen, und dann im Moment der Rechnungsschreibung die Adresse in der Rechnungstabelle hinterlegen.

 

[DBDaU]

Ich habe vor einiger Zeit eine Datenbank im Finanz- u. Rechnungenbereich gebaut. Hier ist das Problem, wenn sich der Preis eines Artikels ändert, werden alle vorher erstellten Rechnungen ungültig, da sich der Preis auch in den alten Rechnungen ändert. Ich habe für diese Datenbank mit Access gearbeitet und die Lösung, die ich gefunden und angewendet habe funktioniert, ohne dass mehrere Datensätze zu den Preisveränderungen angelegt werden müssen. Im Anhang füge ich eine Beispielprogrammierung an, dir ich im Netzt gefunden hatte.

 

[Walter]

wenn sich der Preis eines Artikels ändert, werden alle vorher erstellten Rechnungen ungültig

Da werden aber das Finanzamt und der Kunde stark etwas dagegen haben

 

[DBDaU]

Genauso ist es!! Und deswegen habe ich eine lauffähige Datenbank, mit Hilfe der in der zip-Datei vorhandenen nachzuvollziehenden Beispielprogrammierung, entworfen, die es ermöglicht nach Rechnungsdatum entsprechend, automatisch die korrekten und auch geänderten Daten zu verarbeiten und auszugeben. Also Walter (Admin) erst einmal das Konzept der vorgeschlagenen Programmierung anschauen und dann kommentieren

 

[DBDaU]

Nachtrag: Die Programmierung kann auf jedes Feld einer Datenbank bei entsprechender Bezugsänderung angewendet werden.

 

[Gregor123]

Vielen Dank für die Anregungen. Werde mir das mal über die Feiertage zu Gemüt führen.
Grüße und kommt gut ins neue Jahr