Die Rechnung muss nicht zwingend als PDF gespeichert werden. Es muss lediglich sichergestellt sein, dass eine nachträgliche Veränderung durch den Benutzer ausgeschlossen ist (auch PDF's lassen sich ändern), oder eben, wenn dieser sich von "außen" an den Daten zu schaffen macht, diese Manipulation feststellbar ist. Ich löse diese mittels einer Checksumme und einem Hash über die kompletten Daten einer Rechnung.
Wichtig ist halt, dass du als Softwarehersteller über dein Programm dem Nutzer nicht die Möglichkeit der Manipulation fakturierter Rechnung in die Hand gibt's, und eben eine Manipulation ggf. feststellen kannst. Für die Sicherheit seiner Datenbank (o.ä.) ist der Nutzer selbst zuständig, in welcher Form (Zugriffsrechte etc.) er Manipulation durch Angestellte unterbindet.
Das ist ein interessanter Aspekt.
Aber was passiert, wenn deine Software eine Manipulation feststellt? Kommt dann einfach ein Warnhinweis? Kann man dann nicht trotzdem die Rechnung manipulieren und den Warnhinweis einfach ignorieren?
Bei der Bildung von Checksum und Hash geht es weniger darum, dass ich dem Nutzer zeige das Manipuliert wurde, sondern eher darum, dass ich auf Verlangen nachweisen kann, dass eine Manipulation stattgefunden hat. In welcher Form ist mir dabei eigentlich egal.
Nehmen wir mal an, ein Mitarbeiter (oder der Chef selbst) manipuliert nachträglich Rechnungsdaten direkt in der
DB. Das geht ein paar Jahre gut. Dann kommt eine Steuerprüfung und es werden Ungereimtheiten festgestellt. Dann würde der Mitarbeiter und/oder der Chef sämtliche Vorwürfe von sich weisen und es letztlich auf ein Fehler in der Software schieben, weil das so schön einfach ist, und das Gegenteil schwer zu beweisen ist. Also würde der Steuerprüfer, das FA oder ein Rechtsanwalt möglicherweise an mich herantreten. Mit den Daten und dem Sourcecode kann ich dann Beweisen, dass eine Veränderung von außen stattgefunden hat und bin aus der Sache schadensfrei raus.
Natürlich könnte man eine Manipulation auch innerhalb des Programms darstellen. Das ist dem Entwickler überlassen. Er kann es tun, muss es aber nicht.
Grundsätzlich lasse ich eine nachträgliche Manipulation von fakturierten Rechnungen über meine Software nicht zu, sondern biete lediglich den Weg über eine Storno an. Würde ein Kunde das von mir verlangen würde ich das ablehnen, denn damit allein würde ich mich schon auf dünnes Eis begeben.
Weiterhin bin ich aber der Meinung, dass eine Datenbank für den Nutzer offen sein sollte. Heißt, z.B. im Falle von
MSSQL, dass der Nutzer das sa-Kennwort selbst kennt, und auch für seine Datensicherung aber auch der Datensicherheit selbst zuständig ist. Benutzer verwalte ich immer auf Programmebene, auch wenn ich diese aus Windows übernehme. Ich arbeite also immer nur mit einem
SQL-Benutzer, der volle Rechte auf den
DB hat, und teile die Rechte ja nach Anmeldung dann im Programm zu.
Wer dann im Unternehmen das SA-Kennwort kennt ist dem Nutzer überlassen.
Somit ist die Rechtevergabe und die Datensicherung Kundensache. Ich weise meine Kunden in der Dokumentation entsprechend darauf hin.
Wie p80286 schon sagte, wie und von wem auf eine externe Manipulation reagiert wird, interessiert mich nicht. Ist immer besser, wenn man sich aus sowas heraushält.