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

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.