Wie archiviert man Rechnungen am besten für das Finanzamt für 10 Jahre?

Die Frage bezieht sich nicht darauf, was für ein Speichermedium man verwenden soll, sondern eher darauf, wie man die Daten strukuriert und ablegt.

Gehen wir mal von einem Online Händler aus der Rechnungen verschickt und diese wegen dem Finanzamt für 10 Jahre speichern muß.

Wie sollte der Händler dann die Daten am besten speichern?

Sollte es eine Datenbank sein, in der die Rechnungen so gespeichert werden,
daß aus z.B. einer Tabellenstruktur und ähnliches jederzeit eine Rechnung rekonsruiert werden soll (das spart nämlich Speicherplatz!), oder soll das eher eine Speicherung von kompletten Rechnungen sein, bei der der komplette Rechnungsbrief z.b. als PDF oder ODF Dokument gespeichert wird?

Letzteres verbraucht natürlich deutlich mehr Platz, denn in diesem Fall enthält ja jede Rechnung ein ganzes PDF Dokument, in dem die Adresse des Kunden wieder und wieder gespeichert ist. Je nachdem, wieviele Bestellungen der Kunde halt aufgibt.
Diese Daten sind in diesem Fall also nicht relational gespeichert wie es bei einer SQL Datenbank der Fall wäre.

Wie würdet ihr so etwas machen, bzw. wie muß man das machen, falls das vom Gesetz vorgeschrieben ist?

Soviel erstmal dazu.
Und nun nehmen wir noch an, daß jede Rechnung in Form einer PDF Datei vorliegen muß.
Wie archiviert man diese jetz am besten?
Sollte die PDF Datei in Form eines BLOB in einem DBMS gespeichert werden,
oder wäre es nicht besser, wenn man die Datei in einem hierachischen Verzeichnisbaum archivieren würde und in dem DBMS dann nur noch eine Referenz/Link auf den Ort der Datei speichert?
All das kann natürlich alles automatisiert werden.
Denn wir nehmen hier an, das die Rechnung automatisiert erstellt wird, wenn der Kunde seine Rechnung im Webinterface des Händlers in Auftrag gibt.

Ich persönlich halte eine hierarchische Datenspeicherung mit einem Link in einer Datenbank zu der Rechnungsdatei für besser,
da sie im Gegensatz zum DBMS im Worst Case mit einfachen Systentools leichter zugänglich ist, was bei einer Datenbank, die vielleicht kaputt ist, nicht mehr so einfach möglich ist.

Strukuieren würde ich die Verzeichnishierarchie nach Jahr und dann nach Monat
und Tag, in diesem Tag Ordner kommen dann die ganzen Rechnungen rein, wobei
der Dateinanme der Rechnung dann aus der Kundennummer und der Rechnungsnummer besteht. Das ganze könnte also so aussehen:

/2008/April/27/7349247_12.pdf

Wobei die 2008 das Jahr, die 27 der Tag im Monat April und 7349247 die Kundennummer und 12 die Rechnungsnummer des Kunden ist.
Die Rechnungsnummer des Kunden ist dabei nicht auf den Tag bezogen, sondern ist eine fortlaufende Nummer, so daß auch mit einfachsten Systemtools ohne Datenbank
alle Rechnungen ab der 10. Rechnung des Kunden gefunden werden können.

Also z.B.
find -name 7349247_1*.pdf (ok, die 1. Rechnung wäre hier auch noch dabei, aber das kann man auch anders lösen, ihr wißt schon wie ich das meine, nur ein schnelles Beispiel auf die schnelle)

Das Schöne an dieser hierarchischen Speicherung ist, daß man so die Daten auch sehr gut archivieren kann und mit normnalen Systemtools leicht an die Daten herankommt, falls die Datenbank mal zerschossen sein sollte.
Man könnte z.b. ein ganzes Jahr auf ein oder mehree Datenträger zusammenhängend speichern oder sehr bequem jeden Monat inkrementelle Backups machen usw..

Wie würdet ihr das machen, und wie machen das die Firmen in der Praxis?
Findet ihr die Hierarchy nach Datum z.b. gut, oder würdet ihr die Hierachy nach der Kundennummer machen und dann das Datum der Rechnungen?
Letzteres halte ich halt für schlechter, weil man die Daten nur 10 Jahre aufbewahren muß und alte Rechnungen nach 10 Jahren wegschmeißen ist halt mehr Aufwand, wenn jeder Kunde zuerst seinen eigenen Ordner hat und darin dann die Rechnungen mit den einzelnen Datumsangaben drinstehen.
Das kostet IMO einfach mehr Performance, wenn man z.b. das Jahr 1998 löschen muß.

PS: Falls es verschiedene Rechnungstypen gibt, z.b Gutschrift, könnte man das ja noch der Datei mit einer Index Nummer anhängen.
Z.B. so:

/2008/April/27/7349247_12_2.pdf

sothis_

tl;dr
ohne das gelesen zu haben, tippe zu 80% auf "datenbank" als antwort

sothis_ schrieb:

tl;dr
ohne das gelesen zu haben, tippe zu 80% auf "datenbank" als antwort

Dann lies es bitte noch einmal durch.
Ich möchte es schon genauer wissen ob man PDF Datein als BLOB in einer Datenbank speichern soll oder nur einen Link in die Datenbank und die PDF Datei im Dateisystem in einer Verzeichnisstruktur.

sothis_

meine augen, meine augen

grundsätzlich würde ich das so machen, dass rechnungen aus einer datenbank rekonstruiert werden können, denn dann kann man auch rücksicht auf eventuelle änderungen der kundendaten und internas, wie artikelnummern rücksicht nehmen.

für den fall, dass pdf langzeitgespeichert werden sollen, muss man abwägen, wie's mit dem umfang aussieht. blobs reduzieren die performance der datenbank erheblich, allerdings gestalten sich backups einfacher. das muss man einfach mal auf einem system testen ob man damit klarkommt oder nicht

Wieso so umständlich? Ausdrucken und abheften.

sothis_

Warum so kompliziert?? schrieb:

Wieso so umständlich? Ausdrucken und abheften.

papier ist out

Warum so kompliziert?? schrieb:

Wieso so umständlich? Ausdrucken und abheften.

Ich halte nichts von Zettelwirtschaft.

Zu den Backups der Datenbank.
Hier sehe ich halt das Problem, das man an die Daten ohne DBMS nicht so leicht herankommt.

SideWinder

PDF in DB + Verschlagwortung

http://en.wikipedia.org/wiki/Enterprise_Content_Management

MfG SideWinder

sothis_

Daten schrieb:

Warum so kompliziert?? schrieb:

Wieso so umständlich? Ausdrucken und abheften.

Ich halte nichts von Zettelwirtschaft.

Zu den Backups der Datenbank.
Hier sehe ich halt das Problem, das man an die Daten ohne DBMS nicht so leicht herankommt.

das ist nur teilweise richtig. da backups häufig in reinem text als sql-statments gespeichert werden ist ein eigenes parsertool schnell geschrieben. zur not kannst du zusätzlich ein backup als sqlite datenbank erstellen. dann ist es mit hilfe von sqlite sogar noch einfacher ohne großes dbms mit eigenen tools auf die daten zuzugreifen. wenn du aber wert daruf legst dateien plain im dateisystem zu haben, kannst du das tun, mir persönlich wäre es nichts, ich war noch nie ein verfechter von der simplen ordner/dateinamen hierarchie. das kann schneller unübersichtlich werden als man denkt

Scheppertreiber

Ich weiß jetzt nicht ob das Thema noch aktuell ist. Eigentlich habe ich nur
nach sachen über sqlite gesucht ...

Die Strategie, Sachen revisionssicher zu speichern, hängt von der Datenmenge ab
die zu verwalten ist. Wenn das richtig viel wird, kommt man mit den gängigen
Datenbanken nicht weiter. Auch die Belege in ein Dateisystem klemmen ist dann
keine gute Idee mehr. Das Gezicke kommt spätestens wenn man den ganzen Kram
sichern will. Bei größeren Datenmengen kommen dann Windows etc. ziemlich schnell
an heftige Grenzen.

Generell sollte man die Daten in einem Format speichern das mit Sicherheit auch
in 10 Jahren noch anzeigbar ist. Bei PDF etc würde ich mich da nicht drauf
verlassen. Riskieren kann man das, aber was das FA dann in 10 Jahren sagt weil
sie das nicht lesen können ?

Wie gesagt: wenn das Thema noch aktuell ist ...

hustbaer

Ich würde auf jeden Fall die PDFs als ganz normale Files speichern (*nicht* BLOBs). Der Dateiname sollte dabei möglichst alles wichtige enthalten, also Datum, Kundennummer und Rechnungsnummer.

Zusätzlich wird man wohl die Daten in Tabellenform in einer Datenbank aufbehalten, und dann natürlich in der "Rechnungen" Tabelle auch den Filenamen hinterlegen (evtl. plus relativem Pfad, so dass man z.B. für jedes Monat ein Verzeichnis machen kann).

Nur Datenbank oder BLOBs in der Datenbank halte ich für Murks. PDFs werden ja nicht so riesig wenn man keine sinnlosen Grafiken mit reinmacht und keine Fonts mit ins PDF reinpackt.

Ob PDFs oder lieber doch was anderes... hm. Vielleicht wäre die "sichere" Variante einfach zu jedem PDF noch ein stinknormales Textfile dazuzuspeichern.

Von der Datenmenge her sehe ich eigentlich kein Problem. Wenn man in 10 Jahren so viel verkauft dass man Probleme mit der Datenmenge bekommt kann man sich vermutlich auch einen dicken Storage-Server leisten. Natürlich spielt der Preis bzw. der Gewinn den man pro Artikel im Schnitt macht eine Rolle. Bei einzelnen Schrauben könnte man Probleme bekommen, bei Dingen wo man pro Rechnungszeile 1-2€ verdient vermutlich eher nicht.

Wenn du eine Vorstellung davon hast wieviel pro Jahr an Rechnungen zusammen kommen könnte kann man das ja auch überschlagen.

Scheppertreiber

Ich habe so ein Archiv.

Datenmenge > 125 GB pro Jahr, Textdaten, bei der Ausgabe werden die mit einem
Formular zu einem PDF zusammengehauen und im Browser angezeigt. Das System frißt
alles.

Das Dateisystem (Speichern in Einzeldateien) packt so etwas nicht ohne Zicken.
Die Texte, TIFFs oder was immer speichere ich in einem Container, die Datenbank
enthält dann die Kenndaten und die Verzeigerung.

Ich hatte das am Anfang mit Btrieve - die Verzweiflung über die Laufzeiten hat
dann zu etwas selbstgestricktem geführt (ich brauche ja weder Locking noch
irgendeine andere Synchronisation).

Damit man das noch sichern kann alles in Tagesdateien (eine pro Tag) aufgelöst
und nach Jahren abgelegt.