GoBD-konforme Rechnungsstellung

[Hobbycoder]

Ich weiß nicht genau worauf du hinaus willst.
Wofür willst du Warnmeldungen anzeigen? Wenn du eine Änderung fakturierter Rechnungen aus dem Programm heraus ausschließt und auch die Rechnungsnummernvergabe immer automatisch laufen lässt, dann sollten bestimmte Fälle nie vorkommen können.
Auf eine externe Manipulation der Daten würde ich sehr eingeschränkt reagieren. Wer externe an den Daten Veränderungen vornimmt geht selbst das Risiko ein, dass er dabei möglicherweise gegen geltendes Recht verstößt. Wenn du dann eine Warnmeldung ausgibt, weiß der Angreifer, dass er weitere Manipulationen durchführen muss, um es später auf eine Fehlfunktion der Software zu schieben, und ggf. sogar, wo in der DB noch Änderungen machen muss. Damit würdest du dir evtl. die Möglichkeit nehmen später zu beweisen, dass es eben nicht an der Software gelegen hat.

Evtl. könnte man bei der Datenübergabe an Datev o. ä. allgemein auf eine Inkonsistenz hinweisen.

[Codehunter]

Von böswilliger Manipulation mal abgesehen: Ich hatte schon Fälle, wo ganz simple Fehler passiert sind. Der Anwender hatte bei einem Textfeld ein abschließendes Leerzeichen eingegeben. Es wurde auch so gespeichert in der DB. Nach GoBD würde es auch in Hashes mit einfließen. Bei einem Update des DBMS wurde das Leerzeichen weggetrimmt, weil bei der Erstellung des Updates nicht aufgepasst wurde. Der Hash wird ungültig, also erstmal verdächtig. Heißt, wir Softwareleute müssen immer an solche Möglichkeiten denken. Im konkreten Fall solche Leerzeichen schon bei der Eingabe und vor der Speicherung in der DB trimmen, nicht erst nachträglich.

[mensch72]

(Nachträgliche)Rechnungsmanipulation ist nicht das uns bekannte Hauptproblem.

Viel aufregender sind Blockbuchungen... also Rechnungen werden wie/wo auch immer gesammelt und erst später quasi alle auf einmal eingegeben und gestellt.
Das schafft sagen wir etwas Flexibilität bei Lager<->WaWi<->FiBu<->Bilanzierung nach Steuergesetz und betriebswirtschaftlicher Abrechnung nach Handelsgesetz.
Das suchen nach Blockbuchungen gehört im Saarland zum Standard bei normalen Prüfungen, weil es in Frankreich stark verbreitet ist. Unsere Software verhindert oder meldet das nicht.

Wir haben hier ein öffentliches Forum, da ist es nicht sinnvoll und möglich noch genauer auf "kreative Buchungstechniken für Lager/WaWi/FiBu&BAB" einzugehen, ganz ohne nachträgliche Manipulationen... letztendlich ist das ja auch der Grund warum es eben doch solche Software auch von Klein und/oder Nischenanbietern gibt, und sowas auch gut bezahlt wird

[sh17]

Ich finde schon, das wir das hier öffentlich diskutieren können. Wir lernen alle davon und vielleicht kann man so von Softwareseite einen praktikablen Ansatz schaffen, der allen Entwicklern hilft ohne jedes mal bei 0 anzufangen. Hier könnte man durchaus auch mal als "Konkurrent" in der Branche zusammen arbeiten. Sind wir doch mal ehrlich ... wollen wir uns mit dem "Mist" eigentlich beschäftigen? Nein. Wir wolle innovative Software für den Benutzer schaffen. Gesetzliche Auswüchse sind einfach nur nervig.

[Hobbycoder]

Zitat von mensch72:

(Nachträgliche)Rechnungsmanipulation ist nicht das uns bekannte Hauptproblem.

Aber, wenn ich mich nicht irre, der Kern der Thread-Frage.

[Hobbycoder]

Wir sprechen hier ja über die Rechnungserstellung und weniger über das Buchen in der Finanzbuchhaltung.
Was aber nun wirklich immer mal wieder vorkommt ist folgender Ablauf:
Lieferant A erstellt eine Rechnung für Kunde B.
Kunde B. wartet mit der Bezahlung bis zum maximalen Zahlungsziel und ggf. etwas darüber hinaus bis zu ersten Mahnung.
Dann ruf Kunde B. bei Lieferant A. an und moniert die Rechnung, es wären z.B. Fehler im Adressfeld Rechnungsempfänger oder eine Rechnungsposition wäre nicht ganz korrekt und er könnte die Rechnung so nicht bezahlen.
Lieferant A will Kunde B behalten und nimmt den Mängel auf und möchte die Rechnung der Richtigkeit halber korrigieren.
Nun hätten wir ein Fall, wo der Rechnungsersteller gerne seine Rechnung nachträglich bearbeiten möchte. Im günstigsten Fall betrifft es "nur" die Rechnungsanschrift, aber im schlechten Fall eben auch Rechnungspositionen und damit Summen und MwSt.
Nun könnte der Softwareanbieter natürlich dem Programmnutzer erlauben diese Änderungen zu tätigen, denn die Rechnung ist noch nicht bezahlt und möglicherweise auch noch nicht in der Buchhaltung. Der Rechnungsempfänger könnte die fehlerhafte Rechnung einfach vernichten, bekommt eine neue und alles ist gut.
Nun könnte aber die Eingangsrechnung bei Kunde B. bereit in der Buchhaltung angekommen sein, und die Ausgaben, Vorsteuer, etc. bereits gebucht sein. Und was weiß ich, was noch alles für Möglichkeiten existieren, damit jetzt gezielt Abgaben am Fiskus vorbei zu schleusen.

Richtig wäre, die originale, fehlerhafte Rechnung, so wie sie ist, als Stornorechnung zu schreiben, und ggf. automatisch eine neue Rechnung "mit neuer Rechnungsnummer" zu erzeugen. Nur so ist meiner Meinung nach der ganze Vorgang lückenlos dokumentiert und kann auf beiden Seite entsprechend verbucht werden, und ist somit auch für eine Prüfung nachvollziehbar.

[sh17]

richtig, so muss es laufen. Ich sag immer, man kann sich an den Ablauf der Rechnungserstellung vor 100 Jahren orientieren, wo wirklich alles per Papier und Brief ging. Da gab es Rechnungsbücher usw wo man sich die Rechnungsnummer "abholen" musste und so weiter. Wenn man das so abbildet ist man auf der nachvollziehbaren Seite. Und wenn die Rechnung falsch war, dann muss man sie eben kommentiert im Original zurück schicken und sie wird storniert und es gibt einen neuen Zettel mit neuer Nummer

[bernau]

Zitat von Hobbycoder:

Richtig wäre, die originale, fehlerhafte Rechnung, so wie sie ist, als Stornorechnung zu schreiben, und ggf. automatisch eine neue Rechnung "mit neuer Rechnungsnummer" zu erzeugen. Nur so ist meiner Meinung nach der ganze Vorgang lückenlos dokumentiert und kann auf beiden Seite entsprechend verbucht werden, und ist somit auch für eine Prüfung nachvollziehbar.

Genau so ist es

[bcvs]

Danke für die lebhafte Diskussion. Hat mir einige interessante Aspekte aufgezeigt.

Ich werde es jetzt voraussichtlich so lösen:

Die Rechnung wird wie bisher als .Docx erstellt aus den in der DB gespeicherten Daten auf der Basis einer vom Benutzer definierten Vorlage. Das Ergebnis wird allerdings nicht im Dateisystem gespeichert, sondern als Blob-Feld in der DB.

Die Rechnungsnummer wird zunächst nicht vergeben. Solange das noch nicht geschehen ist, kann die Rechnung noch geändert werden um z.B. Schreibfehler in Zusatztexten auszubessern. Abschicken kann der User die Rg in diesem Zustand nicht, da sie noch keine Rechnungsnummer hat. Erst wenn man auf "Fertig" klickt, oder "Fakturieren" oder wie auch immer man das nennt, wird die Rechnungsnummer vergeben, ins Dokument eingesetzt und die Rechnung zum Ändern gesperrt.

Ab jetzt kann die Rechnung nur noch ausgedruckt werden. Bei Änderugnen muss storniert und neu geschrieben werden (mit neuer Rg-Nummer)

Spricht da aus eurer Erfahrung etwas dagegen?

[Codehunter]

Zitat von bcvs:

Spricht da aus eurer Erfahrung etwas dagegen?

Wenn du über das BLOB-Feld noch nen Hash legst bei der Fakturierung, könnte das so gehen. Wenngleich ich es auch ein wenig umständlich finde.