Fachliche Frage bei Rechnungen

Bitte aktiviere JavaScript!
Hallo,

das hat nur bedingt mit Java zu tun, aber ist eine fachliche Frage zu Programmierung.

Mich würde interessieren, ob ich bei einer Rechnung nur die Referenz zu einem Kunden speichern kann oder ob die Tabelle "Invoice" tatsächlich Felder wie benötigt:
- Kundenvorname
- Kundennachname
- Kundennummer
- Adresse

-> Sprich wenn jemand die Daten der Referenz (Master Data) ändert, und jemand zu einem späteren Zeitpunkt die Rechnung aufruft, dann wäre die Rechnung eben auch mit den Daten des geänderten Kunden.

Speichere ich hingegen in weiteren Felder der Invoice tatsächlich die Kundeninformationen (wird bei der Rechnugserstellung natürlich dann aus den Stammdaten vorbelegt), dann habe ich immer wenn ich die Rechnung aufrufe, auch die Daten des Kunden, wie sie jemals ausgestellt wurde.

Dass ich dann redundante Daten habe, ist mir klar - hier geht es aber mehr um die fachliche Frage bzw. auch rechtliche Frage.
Was passiert, wenn das Finanzamt meine ganzen Rechnungen haben möchte, ich diese aber nicht ausgedruckt habe, sondern nur digital in meiner Software habe. Die Rechnung dann aber nicht den Kundeninfos ausgestellt wurde, wie sie einmal wurde?
 
Speicher eine Referenz auf die Adresse/den Kunde, anstatt das zu kopieren. Wenn der Kunde umzieht, bekommt dieser eine neue Adresse und die alte wird nicht geändert.
Der Zustand zu jedem Zeitpunkt ist dann noch passend vorhanden.
 
Eine Rechnung muss meines Wissens nach unveränderlich abgespeichert werden. Dazu gehört meiner Meinung auch, an wen genau die Rechnung ging! Alle Änderungen an einem Kunden darf also eine bestehende Rechnung nicht verändern!
Daher eine Referenz kommt in die Rechnung aber alle relevanten Daten für die Rechnung ebenso (Name, Adresse, ggf. USt Id, ....)

Aber ich selbst verlasse mich da auch auf keine Buchhaltungssoftware sondern ich speichere immer auch ein PDF in ein Archiv + Ausdruck in einem Ordner. (Sowohl für Ausgang als auch Eingang, d.h. was elektronisch kommt wird ausgedrückt und was in Papierform kommt, wird eingescannt.)
 
Hab da mal schnell gesucht und ein erster Link, den ich gefunden habe:

Rechnungen, Lieferscheine und Angebote müssen unveränderlich gespeichert werden, wenn diese elektronisch gespeichert werden. So Dein Programm eine solche Speicherung durchführen soll, dann musst Du das auch bedenken. Daher kann eine Referenz auf andere (veränderliche) Tabellen ok sein, aber sobald dies auf der eigentlichen Rechnung erscheint, dann muss es auch unveränderlich sein.

Hier kann man sich übrigens überlegen, ob man generell Daten versioniert speichert. Bedeutet, dass die Tabelle halt noch ein Änderungsdatum bekommt. Jeder Veränderung ist dann nur ein Insert einer neuen Version und Du hast dann in der Rechnung eine Referenz zu einer speziellen Version. Und wenn du den aktuellen Datensatz haben willst, dann wird die letzte Version genommen. Ggf. kann man noch ein Flag Festgeschrieben einführen. Dann ist ein Datensatz editierbar, bis er eben festgeschrieben wurde. Das bietet meine Buchhaltungssoftware - Fehler kann man dann bei der Eingabe direkt noch anpassen. Was weiß ich: Konten verwechselt oder so bei einer Buchung...
 
Vom Entwurf her ist es hier sinnvoll, sich den Vorgang klarzumachen. Der Auftrag X muss zuerst von der Papierform in ein System eingelesen werden. Rechnungsadresse, Lieferadresse usw. Unter dem Auftrag X würde man nun die zugehörigen Dokumente speichern, und nach dem Link von kneitzel auch die ausgedruckten Belege abheften. Dabei kann man eben den Bereich der Auftragsnummern auf den Ordner schreiben. Der Auftrag durchläuft verschiedene Stufen, deren letzte "archiviert" ist. Theoretisch würde das die Speicherung in eine extra physisch vom System getrennte Sicherung bedeuten.

Bei der Umsetzung des Workflows komme ich doc an eine Stelle: Vorhandener Kunde? Ja und dann weiter Kundendaten übernehmen? Bei "Nein" würde ich gar kein Update zulassen, sondern ein "Insert" und so für eine Kundennummer mehrere Adressen zulassen. Da könnte man dann in den Dokumenten (Angebot, Lieferschein, Rechnung usw. ) auch auf die Adressnummer und nicht auf die Kundennummer referenzieren.

Um die genannten Anforderungen zu erfüllen, könnte ich mir vorstellen, das Archiv in XML zu erstellen. Das wäre sogar menschenlesbar, und könnte dennoch bei einem Crash die Daten wiederherstellen. Es müssten natürlich mehrere XML-Dateien sein, um die Kundendaten von den Vorgangsdaten getrennt zu halten.
 
Danke schon Mal für die Antworten.
Es geht mir zunächst nicht um die Eingangsrechnungen, die werden ohnehin gescannt.

Es geht mir um die Rechnungen, die mein System erstellt (siehe als Beispiel den oben genannten Anbieter: Billomat).

Prinzipiell sehe ich erstmal kein Problem an die "Invoice" Tabelle eben noch ein paar weitere Felder dranzuhängen.
Wenn ich es aber richtig sehe, dann kann ich die Rechnung nicht mehr verändern. Wir waren nun zunächst bei Änderungen beim Kunden.

Ich treibe das Spielchen aber weiter:
Was ist wenn sich meine Unternehmensdaten ändern (angefangen vom Logo, Adresse, Telefon usw.). Bisher bilde ich auch hier eine Referenz in der Rechnung zu diesen Stammdaten.

Ich verwende derzeit ein XML - Template für das Layout der Rechnung, in welcher ich Platzhalter verwende, die dann beim Rendering in PDF gefüllt werden.
Hier sind dann insbesondere das Layout, als auch Dinge wie Logo gespeichert. Das XML Template ist in einer eigenen Entity abgespeichert, die dann bei der Rechnung ebenfalls als Referenz gespeichert wird.

Nach meinem Verständnis würde das dann bei mir so aussehen:
- Kundendaten speichere ich direkt in der Tabelle "Invoice"
- Referenz zum Template wird nach wie vor gespeichert.

Beim Template ändert sich dann das:
- Ich speichere den XML Code 2x ab:
a) Umwandlung der Platzhalter der Unternehmensdaten in die echten Daten (wird dann bei der Rechnung genutzt)
b) Speicherung des XML - Codes mit den Platzhaltern (wird verwendet, wenn das Template später weiter bearbeitet wird).

Wird das Template nun verändert, dann wird ein persist durchgeführt. Die Referenz zum damals genutzten Template bei der Rechnung bleibt aber bestehen, daher sieht die Rechnung dann auch so aus, wie sie zuvor war, ink. den damals genutzten Unternehmensdaten, Logo etc..

Ergibt das so Sinn? Oder habe ich was vergessen?
 
Wenn ich es aber richtig sehe, dann kann ich die Rechnung nicht mehr verändern.
Zur Rechnung wird es erst, wenn Du sie als solche nutzt (sprich: rausschickst bzw. Deinem Kunden zum Abruf zugänglich machst). Davor kannst Du natürlich rumändern, was Du lustig bist. Die Aufbewahrung muss bildlich mit dem Original übereinstimmen (inhaltlich reicht also nicht). Digitale Rechnungen müssen digital archiviert werden. Du kannst in ein PDF auch Daten einbetten (s. z. B. ZUGFeRD, https://www.ferd-net.de/)

Archivier halt die PDFs, dann ist Deine Software vermutlich fein raus.
 
Wenn du die Rechnung per E-Mail schickst, dann hast du diese normalerweise doch automatisch als E-Mail gespeichert. Da braucht es doch gar keine zusätzliche Sicherung.
 
Archivier halt die PDFs, dann ist Deine Software vermutlich fein raus.
Ich denke Du hast Recht, werde es so machen und dann eben in der Datenbank den Link zu der PDF Datei speichern.

Eine weitere Frage:
Ist das unklug komplett alle Rechnungen in einem Ordner zu speichern? Könnte das Performance Probleme geben?
Bei 100 Rechnungen bestimmt kein Problem, aber wenn es mal mehrere Millionen sind?
 
Ist das unklug komplett alle Rechnungen in einem Ordner zu speichern?
Das ist natürlich abhängig vom Dateisystem. Hier wurde das Thema allgemein mal näher beleuchtet: https://stackoverflow.com/questions/466521/how-many-files-can-i-put-in-a-directory

Aber: dürfte ja kein Problem sein, die Zahl der Dateien je Unterverzeichnis zu begrenzen. Mal ganz poplig: je Jahr.

aber wenn es mal mehrere Millionen sind?
Schreibst Du mehrere Millionen Rechnungen? Dann verlange ich künftig was :p
 
Schreibst Du mehrere Millionen Rechnungen? Dann verlange ich künftig was :p
Schön wäre es ;) Ich speichere es nun pro Monat....

Habe nochmal eine fachliche Frage zum Thema Buchhaltung...
Ich habe ja Rechnungen und Zahlungen (Eingangsrechnungen), Stichwort (Doppelte) Buchhaltung...
Beide speichere ich heute in zwei unterschiedlichen Tabellen...

Müsste ich das aber besser in einer Tabelle speichern, in der ich dann das speichere (also die Buchungssätze):
- Konto
- Gegenkonto
- Betrag
- Datum
- Rechnung_FK
- Payment_FK

-> Die Fremdschlüssel sind dann einfach nochmal die Referenz auf die eigentlichen Objekte...

Oder reichen beide Tabellen und ich schustere mir das dann eben adhoc bei einer Abfrage zusammen? Die Infos stehen ja ansich in beiden Tabellen drin....

Besten Dank
 
Also ich bin mir da nicht so sicher, wie Du das aufziehen willst. In meinen Augen sind das zwei paar Schuhe:
A) Aus einer Rechnung resultieren mehrere Buchungen.
B) Es gibt einen Kontostand. So kann es Zinsen, Mahngebühren, Teilzahlungen, .... geben (So gibt es nicht zwingend einen direkten Zusammenhang zwischen Rechnung und Kontostand. Wobei das komplex werden kann, denn was, wenn der Kunde mehrere Rechnungen mit unterschiedlichen USt Sätzen bekommen hat?)
C) Du hast Buchungen unabhängig von Rechnungen und Zahlungseingängen (z.B. Abschreibung von Geräten und so)

Generell musst Du am Ende klare Buchungen abfassen. Also wenn ein Betrag X eingeht, dann musst Du den irgendwie verbuchen ... Jede Forderung musst Du verbuchen. Jede Abschreibung musst du verbuchen....

Aber das genaue Datenmodel kenne ich nicht aber ich wäre auf jeden Fall vorsichtig. Etwas, das Du jetzt nicht brauchst, willst du evtl. In einer späteren Version haben ....
 
Müsste ich das aber besser in einer Tabelle speichern, in der ich dann das speichere (also die Buchungssätze):
Willst Du eine Buchhaltung programmieren oder geht es um eine Schnittstelle?

Oder reichen beide Tabellen und ich schustere mir das dann eben adhoc bei einer Abfrage zusammen?
Bei einer Schnittstelle kannst Du machen, was Du lustig bist. Die Frage ist eher, ob die paar Infos reichen, das hängt aber vom Zielprogramm ab. Für eine Datev-Schnittstelle brauchst Du ein paar Infos mehr.
 
Es gibt ja mittlerweile schon ein paar Cloudanbieter am Markt (zB SevDesk, billomat, easybill...).
Wie machen die das denn wohl?
Speichern die "nur" die Rechnungen und Belege in der Datenbank ab oder generieren die auch direkt Buchungssätze und schreiben diese in eine eigene Tabelle?

Also sprich gibt es eine weitere Tabelle "Buchungen", in der dann eben Konto und Gegenkonto + Betrag steht?

Irre ich mich, aber man könnte ja auch im Nachhinein anhand der Rechnungen und Belege die Buchungssätze adhoc erzeugen? Also sprich: eine eigene Tabelle ist hier nicht zwingend notwendig?

Klar, gebe ich dir Recht, dass Dinge wie unterschiedliche MwSt - Sätze auch betrachtet werden müssen.
 
Das kommt darauf an, was Du vorhast. Wenn Du immer die gleiche Leistung verkaufst und dafür Rechnungen generierst, kannst Du die Buchungssätze für eine FiBu-Schnittstelle ad hoc generieren. Natürlich wirst Du Dir auch dort merken müssen, was Du bereits "exportiert" hast.

In einem Buchhaltungsprogramm hast Du normalerweise Tabellen für das Buchungsjournal sowie für die Bewegungen auf den Konten. Erfasst Du beispielsweise eine Ausgangsrechnung über 119 € inkl. 19 % MwSt, dann wird der Buchungssatz erfasst (also etwas wie Journalnummer 685, 04.08.19, 23:48, Belegnr. AR14291/19, Debitor an Erlöse, brutto, 119 €, MwSt-Schlüssel A, Tarif B - Kunde X) und daraus generiert die Software dann mehrere Buchungen und ggf. offene Posten, die dann etwa so aussehen
1. Debitorenkonto: 119 € im Soll, Journalnummer 685, ...
2. MwSt-Konto: 19 € im Haben, Journalnummer 685, ....
3. Erlöse: 100 € im Haben, Journalnummer 685, ...
 
Also sprich gibt es eine weitere Tabelle "Buchungen",
Wenn du ein Buchhaltungssystem programmieren willst, wirst du eine Tabelle für die Buchungen brauchen. Ob du ein Buchhaltungssystem programmieren willst, ist mir noch nicht klar geworden.

in der dann eben Konto und Gegenkonto + Betrag steht?
Das Konzept "Konto und Gegenkonto in einem Datensatz" kann bei Splitbuchungen problematisch sein. Da muss man sich überlegen, ob das schon die Gegenbuchung sein soll oder nur eine Info und die Gegenbuchungen bekommen eigene Datensätze. Beispiel für eine Eingangsrechnung:
Code:
Konto                Betrag  S/H  Gegenkonto
--------------   ----------  ---  --------------
Wareneinkauf     100,00 EUR   S   Kreditor Meyer
Vorsteuer 19%     19,00 EUR   S   Kreditor Meyer
Kreditor Meyer   119,00 EUR   H   *** Split ***
Bei dem Ansatz könnte man noch je eine Spalte für Buchungs-ID und Beleg-ID vorsehen. Die Buchungs-ID wäre eindeutig. Buchungen, die aus demselben Belege hervor gehen, bekommen dieselbe Beleg-ID. Die Ausgleichinformationen der offenen Posten könnte man in eine zusätzlichen Tabelle in Form von Buchungs-ID-Paaren vornehmen.
 
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben