GoBD-konforme Rechnungsstellung

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

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

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.

[BlueStarHH]

Ich muss das wichtige Thema nochmal aufgreifen:

Ein Kunde kauft bei einem Softwareentwickler ein Rechnungs-Programm. Die GoDB fordert, dass Veränderungen an Rechnungen nicht möglich sind oder erkannt werden. Dies möchte der Kunde vom Anbieter bestätigt haben, da der Betriebsprüfer vom Finanzamt bei einer Betriebsprüfung prüfen wird, ob die Software diesen Kriterien entspricht. Sollte das nicht der Fall sein, kann die Buchhaltung verworfen werden und es drohen Steuernachzahlungen.

Hier wird nun in einigen Beiträgen behauptet, dass bei Manipulationen keine Gefahr für den Anbieter der Software drohen würden, wenn "solche Manipulationen mit krimineller Energie verbunden wären" (Beitrag #11 von mensch72). Außerdem müsse die "WaWi nur für den Normalgebrauch sicher und gegen fahrlässige Fehlnutzung durch den Softwareanbieter gesetzeskonform realisiert&geschützt sein" (Beitrag #11 von mensch72).

Ich bin hingegen der Meinung, dass die GoDB so ausgelegt werden muss, dass Manipulationen in *allen* Fällen erkannt werden oder ausgeschlossen sind. Sonst kann man als Anbieter nicht behaupten, dass die Software die GoBD einhält. Dazu habe ich ein Urteil gefunden, dass meine Meinung unterstützt. Auf der Seite eines Steuerberaters http://www.stb-panketal.de/service/3...usgabe-2017-06 gibt es unten unter dem Link Download http://www.stb-panketal.de/images/ma...nfo_201706.pdf eine PDF-Datei. Dort wird ein Fall beschrieben, wo es zu Steuernachzahlungen kam, denn:

Zitat:

Die Kassen des Klägers waren aber manipulierbar. Dies hat ein Gutachten ergeben, das vom FG eingeholt worden ist. Unbeachtlich ist dabei, ob eine Manipulation einfach ist und von einem PC-Laien durchgeführt werden kann oder ob eine Manipulation schwierig ist und nur von einem EDV-Spezialisten vorgenommen werden kann. Auf eine tatsächliche Manipulation der Kasse kommt es ebenfalls nicht an.

Zu finden in der PDF-Datei auf Seite 3 oben in der linken Spalte und dem zweiten Punkt.

Heißt also: Wenn ein "EDV-Spezialist" die Daten ändern kann, ist die Software nicht GoDB-Konform. Der Kunden könnte dann versuchen, den Anbieter in Regress zu nehmen. Oder der Anbieter kann nicht damit werben, dass die Software GoBD-konform ist. Dann kauft die aber niemand. Evtl. ist auch davon auszugehen, dass die Software GoBD-konform ist, auch wenn dies nicht explizit erwähnt ist. Und der Anbieter wäre dann trotzdem Regresspflichtig.

Lange Rede, kurzer Sinn: Wie kann eine Datenbank so vor Änderungen geschützt werden, dass diese erkennbar sind?

[mensch72]

..."Lange Rede, kurzer Sinn: Wie kann eine Datenbank so vor Änderungen geschützt werden, dass diese erkennbar sind?"...

Kurze&klare Antwort: GARNICHT, solange diese gemeinsam samt der Anwendung die dort liest&schriebt rein auf Kunden (kontrollierter) Hardware liegt

Wenn du das willst baue eine "dumme" WEB-GUI, verschlüssele&authentifiziere alles was via WEB an Anfragen an deine Server oder ein BSI zertifziertes Trustcenter geht.
Gib deiner dummen WEB-GUI nur 1:1 die Möglichkeit deine Antwortdaten zu dekodieren und "readonly" anzuzeigen.

So bist du zwar WostCase oberflächlich eventuell für dumme Leute 1% besser GoDB konform, ABER du nagelst dir damit ein eches Datenschutzproblem selbst ans Knie... sowas hat einen noch viel längeren Rattenschwanz und ist im Gegensatz zur GoBD eine echtes FassOhneBoden!!!
Daher etwas vernünfiges und gut dokumentiertes selbst machen, dann SELBST AKTIV vorab von allen möglichen Klägern (!und immer gegen Geld!) Unbedenklichkeit bestätigen lassen... bis zur nächsten Gesetzesänderung ist dann "RuheImKarton", denn wo kein Kläger, da kein Richter!

[Schokohase]

@BlueStarHH

Du musst auch den gesamten Kontext lesen und nicht nur die Stellen, die deinen Standpunkt belegen.

Zitat:

• Das Finanzamt war zu einer Hinzuschätzung berechtigt, weil die Kassenbuchführung nicht ordnungsgemäß war. So fehlten die Programmierprotokolle, aus denen sich nachträgliche Änderungen der elektronischen Kasse ergeben konnten. Ein Prüfer muss nämlich erkennen können, ob und wie die Programmierung der Kasse verändert worden ist.
• Das Fehlen von Programmierprotokollen bei einem bargeldintensiven Betrieb ist nur dann unschädlich, wenn Manipulationsmöglichkeiten ausgeschlossen sind. Die Kassen des Klägers waren aber manipulierbar. Dies hat ein Gutachten ergeben, das vom FG eingeholt worden ist. Unbeachtlich ist dabei, ob eine Manipulation einfach ist und von einem PC-Laien durchgeführt werden kann oder ob eine Manipulation schwierig ist und nur von einem EDV-Spezialisten vorgenommen werden kann. Auf eine tatsächliche Manipulation der Kasse kommt es ebenfalls nicht an.

Weil es keine Programmierprotokolle gab und die Kasse manipulierbar war, darum gab es einen auf den S*ck.

Wären die Programmierprotokolle vorhanden, dann wäre es trotz manipulierbarer Kasse korrekt gewesen.

[hanvas]

Zitat von mensch72:

..."Lange Rede, kurzer Sinn: Wie kann eine Datenbank so vor Änderungen geschützt werden, dass diese erkennbar sind?"...

Kurze&klare Antwort: GARNICHT, solange diese gemeinsam samt der Anwendung die dort liest&schriebt rein auf Kunden (kontrollierter) Hardware liegt

Man kann ein Protokoll aller Änderungen erstellen, viele DBs führen von Haus auf ein derartiges Transaktionslog. Das Log kann man in regelämäßigen Abständen exportieren, die exportierte Datei digital signieren.

Wenn man die Dateinamen so wählt das Lücken auffallen dann ist man schon ziemlich sicher. Praktisch ganz sicher ist man, wenn man Merkmale des Logs (beispielsweise Erstellungszeit, Dateiname etc.) an einen entfernten Server übermittelt, der diese Eigenschaften protokolliert.

Da nur Daten des Logs übermittelt werden, aber keine Nutzdaten hat man damit auch kein Datenschutzproblem.

cu Ha-Jö