Rechnungen in der Datenbank speichern

[chrootdev]

Hi @ all,

ich habe diese Frage schon im QTForum (http://www.qtforum.de) gestellt, und auch einige brauchbare Antworten erhalten, aber ich hole mir lieber noch ein paar Meinungen ein.

Problem ist folgendes:

Ich erstelle eine Fakturierungssoftware, es werden Kunden und Artikel angelegt.

Speichere ich jetzt alle Artikeldaten in die Rechnungstabelle? Oder erstelle ich nur die Rechnungskopfdaten (Rechnungsnummer, Datum, usw.) und speichere die Artikelnummer aus der Artikeltabelle als Referenz?

Erstere Möglichkeit würde eine Menge and redundanten Daten bedeuten, jedoch würden alle Rechnung theoretisch nachgedruckt werden können, auch wenn der Artikel gelöscht wird, der Verkauft worden ist.

Zweitere Möglichkeit würde alles schön übersichtlich halten und auch keine redundanten Daten beinhalten, jedoch würde der Rechnungsnachdruck nicht mehr funktionieren, sollte ein Artikel der auf der Rechnung steht gelöscht werden.

Oder sollte ich einfach den Artikel als gelöscht markieren, jedoch nicht wirklich löschen, um dadurch noch auf die Daten zugreifen zu können? Das würde jedoch eine Menge Daten produzieren, wenn nie etwas gelöscht wird.

Gleiches gilt für Sachbearbeiter, welche die Rechnung erstellt haben und mit ihren Daten darauf verewigt wurden, jedoch aus dem Unternehmen ausgeschieden sind.

Kann mir mit diese Problematik jemand helfen, und event. Erfahrungen beschreiben die er/sie bereits mit solchen Problemen gemacht haben?

Danke!

Mfg

 

[Leroux]

Ich hab mal ein Webshopp geschrieben da hab ich die erste Möglichkeit benutzt d.h die eindeutige ArtikelNr sowie Preis nochmal in die Rechnungstabelle mit eingebunden.
Außerdem eine Log-Datei erstellt in die der gelöschte Artikel eingetragen wurden*.

Wenn man dann unbedingt nochmal wissen will was es für ein Artikel es war musste man mit hilfe der ArtikelNr im Logfile nachschauen.Als alternative zum Lockfile mach ein AltArtikel Tabelle dort trägst du die gelöschten ein läst aber dein Verwaltungsdienst nur dann darauf zugreifen wenn es wirklich nötig ist.

 

[Zvoni]

Jupp, würde auch für erste Methode stimmen. In der Firma, wo ich arbeite, wird so verfahren.

BTW: Ich glaube du bist rechtlich sogar dazu verpflichtet, Rechnungen für XY Jahre aufzuheben bzw. im Original nachdrucken zu können

 

[chrootdev]

Danke für eure antworten. Jedoch kann das doch nicht sein das ich solche Redundanzen erzeuge muss.

BTW: Ich glaube du bist rechtlich sogar dazu verpflichtet, Rechnungen für XY Jahre aufzuheben bzw. im Original nachdrucken zu können

Darüber hab ich mich schon informiert, in Österreich sind es 7 Jahre, in Deutschland 10 Jahre.

 

[Zvoni]

Danke für eure antworten. Jedoch kann das doch nicht sein das ich solche Redundanzen erzeuge muss.



Darüber hab ich mich schon informiert, in Österreich sind es 7 Jahre, in Deutschland 10 Jahre.

Hmmm, um Redundanzen zu vermeiden, aber dennoch im rechtlichen Rahmen zu bleiben, könntest du ja folgendes noch machen (ist bei mir in der Firma so): Du verwendest deine erwähnte Variante 2 (Also ohne Redundanzen), erzeugst aber automatisch ein PDF der Rechnung, sobald diese gedruckt wird, und schiebst diese in ein Archiv. Somit hättest du Best of both Worlds.

Was letztendlich mehr Speicherplatz kostet würde die Erfahrung/Zeit zeigen.

 

[chrootdev]

Danke für eure Antworten.

Jetzt bin ich aber auf eine andere Idee gekommen, und zwar erstelle ich die Rechnungen als XML und transformiere sie dann mittels XSLT in HTML und drucke dies dann als PDF. Dieses transformierte HTML Dokument speichere ich in die Datenbank als TEXT oder BLOB.

Wäre das sinnvoll?

Danke!

 

[Oliver Gierke]

Damit hast du die "Daten" nur in einem recht untechnischen Format. Warum nicht die Rechnungen inklusive Rechnungspositionen in der DB halten?

Oft ist es ja auch so, dass es für bestimmte Produkte / Kunden Sonderkonditionen gibt. Ich halte es daher für essentiell, den Zustand, wie ein Produkt in einer Bestellung ausgeliefert wird unabhängig von dem Produkt selbst abzulegen. Sonst änderst du z.B. den Preis eines Produktes und alle Rechnungen werden "falsch". Sowas geistert meist als (Order)LineItem durch die Gegend, vielleicht mal danach googlen. Redundanz ist das IMHO nicht, da es konzeptionell völlig andere Daten sind. Das Produkt ist inhalt eines logischen Katalogs, die Bestellposition eben eine Bestellposition die unmittelbar mit einem Kunden, einem Zeitpunkt usw. verbunden sind.

Es spricht ja nichts dagegen im OrderLineItem eine Referenz auf das Produkt (aus dem Katalog) zu halten.

Gruß
Ollie