GoBD-konforme Rechnungsstellung

[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:

Zitat von mensch72 (Beitrag 1394924)

(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:

Zitat von Hobbycoder (Beitrag 1394929)

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 :thumb:

[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:

Zitat von bcvs (Beitrag 1394944)

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.

[Hobbycoder]

Umständlich sicherlich. Ich würd‘s Auch nicht so machen.
Aber ein Hash über Blob hat zumindest den Vorteil, dass man sich um bei Export/Import der DB entstehende abgeschrittene Leerzeichen, welche den Hash ungültig machen würden, keine Gedanken mehr machen muss.

[bcvs]

Zitat:

Zitat von Hobbycoder (Beitrag 1394968)

Umständlich sicherlich.

Mag sein, dass das etwas umständlich ist. Ich möchte allerdings nur so wenig wie möglich am bisherigen Workflow für die Anwender ändern.
Und die sind es gewohnt, mit den Word-Vorlagen volle Kontrolle über das Layout der gedruckten Rechnung zu haben. Deshalb will ich dieses Konzept beibehalten.