Anwendungsdesign: WO Dateianhänge speichern?

[Codehunter]

Moin!

Man kennt das ja von diversen Wawi- und Fibu-Systemen: Zu einzelnen Datensätzen können eine oder mehrere Dateianhänge wie z.B. eingescannte Fremdbelege angefügt werden. Ich habe nun schon viele verschiedene Softwares gesehen. Da gab es schlechte Lösungen und noch schlechtere. Das übelste das mir jemals unter gekommen ist war ein Wawi, welches bei Dateianhängen lediglich einen Datei-Öffnen-Dialog zeigte und dann den dort gewählten Dateipfad als String in ein varchar()-Feld schrieb. Das war irre praktisch wenn man eine Mehrplatzinstallation hatte, ein Anwender mal fix ein PDF von seinem USB-Stick angehängt hat und der andere panisch den Wawi-Support anrief weil er an die Anhänge nicht ran kam ;-)

Eine Variante davon ist, wenn eine Client-Server-Installation konstruktivisch ein Netshare voraus setzt, wo solche gemeinsam genutzten Dateien abgelegt werden. Das funktioniert so lange reibungslos, wie man seine Software über Distributoren mit Wartungsverträgen vertreibt. Da kann man davon ausgehen, dass Netshares auch überall, z.B. per GPO mit dem selben Laufwerksbuchstaben laufen oder aber ein korrekter UNC verwendet wird. Bei Consumer-Software wie z.B. Vereinsverwaltungen dagegen funktioniert das wieder eher schlecht als recht, weil sich die typische Clientel selten mit Domaincontrollern, Zugriffsrechten und/oder DNS-Problemen befasst.

Die dritte Lösung die ich kenne ist, Dateien als BLOB direkt in die Datenbanken zu speichern. Damit geht man zwar was die Verfügbarkeit angeht auf Nummer sicher, bläht seine DB aber ungemein auf und ist in der Regel auch gezwungen eine Dateigrößenbeschränkung zu führen. Das gibt auch wieder Frust bei den Anwendern, wenn der Import eines 100 MB großen, mit 4096 dpi (interpoliert!) gescannten Dreiseiters mit einer Fehlermeldung abwürgt und keiner weiß, wie man ein PDF kleiner bekommt.

Wie löst ihr diese Aufgabenstellung? Gibt es noch andere Lösungswege die ich noch nicht kenne? Ich bin da neugierig :-)

Viele Grüße
Cody

[jaenicke]

Mir fällt da z.B. MongoDB GridFS ein. Das ist quasi wie ein Dateisystem auf eine NoSQL Datenbank gestülpt.

[TigerLilly]

Wen du einen performanten DB-Server im Hintergrund hast mit viel Speicher + Plattenplatz und ein DB-System, das die Verwaltung von eingebetteten Dokumenten gut unterstützt (zB FILESTREAM by MSSQL), dann ist es besser, wenn die Docs in der DB landen.

Eine Alternative ist es, in der DB nur den relativen(!) Pfad zu den Dokumenten zu speichern + je User einen Root-Pfad zum Dokumenten-Verzeichnis zu führen.

[mjustin]

In der eigenen Software ein DB-Feld mit einer GUID oder einem anderen Identifier, eventuell auch der Dateianhangname.
Die Dokumente gehören in ein System zur Dokumentenverwaltung wie Alfresco.
Das Rad muss nicht viereckig neu erfunden werden Ü

[Aviator]

Alfresco speichert die Daten allerdings auch nur in einem Verzeichnis auf einem Rechner/Server ab. Die bekommen dann eine ID, lassen sich aber mit dem, für den Dateityp, passenden Programm direkt öffnen wenn man auf das Verzeichnis Zugriff hat. Da wird also auch nichts verschlüsselt.

[mjustin]

Zitat:

Zitat von Aviator (Beitrag 1378597)

Alfresco speichert die Daten allerdings auch nur in einem Verzeichnis auf einem Rechner/Server ab. Die bekommen dann eine ID, lassen sich aber mit dem, für den Dateityp, passenden Programm direkt öffnen wenn man auf das Verzeichnis Zugriff hat. Da wird also auch nichts verschlüsselt.

Ist das Repository nicht eher eine Datenbank mit diversen Views (CIFS, SMB, FTP, WebDAV) und APIs als eine nackte Verzeichnisstruktur?

Zitat:

The actual binary streams of the content are stored in files managed in the repository, although these files are for internal use only and do not reflect what you might see through the shared drive interfaces.

http://docs.alfresco.com/4.0/concept...epo-about.html

[Aviator]

Zitat:

Zitat von mjustin (Beitrag 1378615)

Zitat:

Zitat von Aviator (Beitrag 1378597)

Alfresco speichert die Daten allerdings auch nur in einem Verzeichnis auf einem Rechner/Server ab. Die bekommen dann eine ID, lassen sich aber mit dem, für den Dateityp, passenden Programm direkt öffnen wenn man auf das Verzeichnis Zugriff hat. Da wird also auch nichts verschlüsselt.

Ist das Repository nicht eher eine Datenbank mit diversen Views (CIFS, SMB, FTP, WebDAV) und APIs als eine nackte Verzeichnisstruktur?

Zitat:

The actual binary streams of the content are stored in files managed in the repository, although these files are for internal use only and do not reflect what you might see through the shared drive interfaces.

http://docs.alfresco.com/4.0/concept...epo-about.html

Kann natürlich sein. Ich hatte mir die Software vor längerer Zeit mal angeschaut. Es wird ja eine PostgreSQL DB mitinstalliert. Ich meine mich aber auch zu erinnern, dass man ein Verzeichnis angeben konnte/musste wo die Daten abgespeichert wurden. Und da waren auch alle Daten in alle Revisionen einzusehen. Man musste nur wissen was das ursprünglich für ein Dateityp war um die Datei mit der richtigen Anwendung zu öffnen.

Aber da will ich mich jetzt mal nicht zu weit aus dem Fenster lehnen. Kann sein, dass die Original Daten in Wirklichkeit irgendwo abgespeichert sind wo man als normaler Benutzer nicht rankommt.

[p80286]

Zitat:

Zitat von Codehunter (Beitrag 1378554)

Eine Variante davon ist, wenn eine Client-Server-Installation konstruktivisch ein Netshare voraus setzt, wo solche gemeinsam genutzten Dateien abgelegt werden. Das funktioniert so lange reibungslos, wie man seine Software über Distributoren mit Wartungsverträgen vertreibt. Da kann man davon ausgehen, dass Netshares auch überall, z.B. per GPO mit dem selben Laufwerksbuchstaben laufen oder aber ein korrekter UNC verwendet wird. Bei Consumer-Software wie z.B. Vereinsverwaltungen dagegen funktioniert das wieder eher schlecht als recht, weil sich die typische Clientel selten mit Domaincontrollern, Zugriffsrechten und/oder DNS-Problemen befasst.

One fits all, kannst Du vergessen. Irgendeiner der handelden (incl. des Programmierers) bringt es fertig einen Scan eines Dokumentes als Dokument und nicht als Bild abzulegen, und dann knirscht es wieder mal im Gebälk. Und dabei ist es egal ob Du die Daten als Datei in einem FS ablegst oder als BLOB in einer/der Datenbank ablegst. Nach meiner Erfahrung hast Du bei extern abgelegten Daten wenigstens eine Chance im Falle eines Falles die Daten zu reanimieren, sofern der Dateiname einen eindeutigen Hinweis auf den Datenbankeintrag beinhaltet. Falls die DB struwellig wird ist der Aufwand um einiges höher (nach meiner Erfahrung).

Gruß
k-H

[jobo]

Ein DMS wie Alfresco scheint mir eine vernünftige Lösung, auch wenn ich es im Detail nicht kenne. Passt vielleicht nicht unbedingt ins Konzept einer jeden Software.
Wir machen es so, dass die Datenbank Dateiname, Pfad, Typ und die Datei selbst in einem BLOB schluckt.
Darüber liegt für Webclients eine Schicht, die webbasierten Upload und Download unterstützt und es per Default (ursprünglich) in die DB schiebt, analog zum FAT Client.
Da die Dokumente alle ein fachlichen Zusammenhang haben und damit einen mehr oder weniger festen Dokumenttyp, kann für den fachlichen Vorgang definiert werden, ob der Webclient das Dokument vor dem Upload komprimiert/(mehrere) gezippte Dateien erwartet und ob es in die DB oder im FS des Webserver oder doppelt abgelegt werden soll. Jede Datei die hochgeladen wird, wird umbenannt und mit der ID des Datensatzes versehen, unter dem der Vorgang und die Metadaten dazu abgelegt sind.
Damit realisieren wir hauptsächlich den Transfer von Importdaten (z.B. CSV, gezipt) oder den Export von CSV, Reports, Spreadsheet Reports.
Der Transfer zum DBServer bietet für den Import den Vorteil, dass dort lokal dann mit proprietäten Verfahren sehr schnell große Datenmengen importiert werden können. Das Verfahren bietet eine Menge Möglichkeiten für Review, Reimport usw., die Erfahrung hat leider gezeigt, dass CSV Daten beliebig schlecht sein können und maximale Flexibilität auch maximale Entspannung bei Datenproblemen bietet.
Für reine Dokumenten Verwaltung / Nachweis / OCR review ist das natürlich in der Form nicht notwendig.

[Rollo62]

Ich würde es so machen das nur der relative Pfad in der DB gespeichert wird.
So dann man von aussen entscheided wo genau das jetzt liegt, Serververzeichnis, FTP, WebDav, Cloud, etc.
Dann würde die DB auch bei grundsätzlichem Wechsel der Systeme noch stabil laufen, ohne upgedatet werden zu müssen.

Rollo

Update
Ok, TigerLilly hatte ja schon ähnliches Vorgeschlagen.

[Mikkey]

Wenn mit einer großen Zahl von Anlagen unterschiedlicher Größe umgegangen werden soll und ein BLOB-Eintrag in der Datenbank selbst nicht infrage kommt, würde ich...

• In einer Anlagen-Tabelle die Metadaten (und u.U ein Thumbnail) speichern, dazu eine Repository-Id und einen zum Repository relativen Pfad.
• Eine Repository-Tabelle identifiziert die Speicherorte (die auf diese Weise einfach umziehen können).
• Jedes Repository kann durch einen gesonderten Prozess verwaltet werden, so dass händische Eingriffe in die Repositorys unterbunden werden können. Die Datei erhält als Namen lediglich die ID des Anlagen-Eintrags.

Die Abfrage kann so auch passend darauf reagieren, wenn ein Repository gerade nicht zur Verfügung steht.

[Nersgatt]

Ich denke, dass es dabei keine allgemein gültige Lösung geben kann. Es kommt auf den Einsatzzweck an.

Wenn die Dateien nur zu Archivierungszwecken gespeichert werden, finde ich die BLOB-Lösung am schönsten. Setzt aber voraus, dass die Dateien möglichst nicht bearbeitet werden müssen.

Wenn man aber z.B. Textdokumente hat (Briefe, usw.), die von Zeit zu Zeit mit externen Programmen bearbeitet werden, müsstest Du sie aus dem Blob raus holen, bearbeiten in der Textverarbeitung wieder ins Blob einlesen. Ist fehleranfällig.

Anders herum, wenn Du z.B. bei irgendwelchen Buchungen zu Dokumentationszwecken vielleicht ein Bild einer Webcam speichern willst, würde ich das in der Datenbank speichern.
Die Größe der Datenbank dürfte bei heutigen Systemen nicht mehr der limitierende Faktor sein.

[jobo]

Zitat:

Zitat von Nersgatt (Beitrag 1378687)

Die Größe der Datenbank dürfte bei heutigen Systemen nicht mehr der limitierende Faktor sein.

so an sich nicht unbedingt, aber dann gibt es da hinten dran noch Backupsysteme und wenn es nicht filigran gemacht ist, bedeutet ein Änderung des Datensatz evtl erneutes Backup (Log).
Und je nach Eingang (freie Dokumente) kann das auch mal recht groß werden. (Der Versicherungsnehmer scannt eben ein paar Dokumente mit 1200 dpi und hängt noch ein paar Fotos vom Schaden an und dann hat man ein 100 MB Email)

[sh17]

Wenn man ein Datenbanksystem benutzt, oder auch das lokale unsichtbare Dateisystem zur Ablage der Dateien verwendet, könnten man gegen die Anwendung ein virtuelles Dateisystem integrieren, sodass sich für den Anwender alles "normal" anfühlt. Auf diese Weise können Dokumente ganz einfach bearbeitet werden. Man könnte automatisch eine Versionierung und auch ein Rechtesystem anbieten. Und die Dateien sind so auch gut gegen Verschlüsselungstrojaner geschützt. Auch ein wichtiger Punkt.

Die Firma Eldos bietet ein solches Produkt.

Ansonsten Dokany, da hab ich den Wrapper mal eine Weile aktuell gehalten. Müsste mal wieder einer ran https://github.com/dokan-dev/dokan-delphi
Oder https://github.com/billziss-gh/winfsp - eine Abspaltung/Neuentwicklung von Dokany, weil er mit der Architektur von Dokany nicht zufrieden war.

Aus Datensicherungsgründen packen wir im Moment alle Dokumente zu einem Vorgang (Das Anwendungsdesign macht es möglich) mit Versionierung in eine SQLite-DB. So sind bei einem Ausfall nicht alle Daten betroffen. Abgerufen werden die Dateien über ein REST-API

[Codehunter]

Danke euch schon mal für die vielen Meinungen!

Zitat:

Zitat von Nersgatt (Beitrag 1378687)

Wenn die Dateien nur zu Archivierungszwecken gespeichert werden, finde ich die BLOB-Lösung am schönsten. Setzt aber voraus, dass die Dateien möglichst nicht bearbeitet werden müssen.

Hier kommt noch ein Faktor hinzu, den ich im Eingangspost noch nicht erwähnt hatte, nämlich dieses wunderbar Produktivzeit vernichtende GoBD. Damit habe ich mich aber auch erst NACHDEM ich das Erstpost geschrieben hatte befasst. Insofern dürfen in manchen Fällen angehängte Dateien gar nicht mehr verändert werden können. Zumindest nicht ohne dass es dem System auffällt. GoBD schreibt außerdem ausdrücklich vor, dass simple Netshares nicht ausreichend wären. Hieße für mich, wenn man schon mit Netshare arbeitet, in welcher Form auch immer, dann müsste man mindestens noch einen Hashwert der Datei speichern. Aber da ahne ich schon dass das supportlastig wird...

[mm1256]

Google mal nach Rechnungen schreiben mir Word oder Excel. Dann dürfte schnell klar werden, was da letztendlich gemeint ist: Das Windows-Dateisystem ist vollig ungeeignet zum Archivieren, weil Änderungen nicht zuverlässig ausgeschlossen werden können, und wenn doch Änderungen erfolgen, werden sie nicht protokolliert. Die bereits angesprochene Datenbanklösung in Verbindung mit Protokollierung von Änderungen ist daher das Mittel der Wahl. Natürlich mit den entsprechenden Erweiterungen für Zugriffsrechte, Protokollierung usw.

[p80286]

Das klingt doch sehr nach einer WORM, gibt's die überhaupt noch?

Auf klassischen (Magnet-)Datenträger könnte man sich mit create/read-Rechten behelfen, aber da gibt es einige Hintertüren um die Dateien doch noch zu manipulieren.....


Gruß
K-H

[Codehunter]

Bevor wir hier ins Philosophische abdriften: Kennt sich hier jemand mit den GoBD aus? Ich würde gern wissen ob dort tatsächlich die Unveränderlichkeit von Dateien gefordert wird oder ob es reicht, stattgefundene Änderungen zu entdecken. Sprich ob die Hashwert-Lösung ausreichend ist. Eine echte Unveränderlichkeit lässt sich nur über Readonly-Datenträger erreichen und hätte natürlich ganz erhebliche Auswirkungen auf den Handlingprozess innerhalb der Unternehmen.

EDIT: Eigentlich ergibt sich aus den GoBD noch eine ganz andere Frage: Sind Open-Source-Lösungen jedweder Art nicht per GoBD-Definition ausgeschlossen? Wenn ich die Lösungen etablierter Anbieter wie Lexware, Datev, Dokumentenmanagementsysteme usw. anschaue, dann basieren die alle auf dem Prinzip der "Security by Obscurity": Eine elektronisch gespeicherte Datei in einem Fremdformat (z.B. PDF, JPEG usw.) wird durch geheime Schlüssel, Hashes o.ä. gesichert. Würden diese bekannt, ließen sich dem System auch wieder veränderte Daten unterschieben, deren Prüfwerte man nachträglich neu berechnet und mit einfügt. Klingt für mich so als könnte Open-Source-Software solche Vorgaben prinzipbedingt nicht erfüllen, da alle mathematischen Verfahren offen liegen.

[TiGü]

Zitat:

Zitat von Codehunter (Beitrag 1379416)

Bevor wir hier ins Philosophische abdriften: Kennt sich hier jemand mit den GoBD aus? Ich würde gern wissen ob dort tatsächlich die Unveränderlichkeit von Dateien gefordert wird oder ob es reicht, stattgefundene Änderungen zu entdecken. Sprich ob die Hashwert-Lösung ausreichend ist. Eine echte Unveränderlichkeit lässt sich nur über Readonly-Datenträger erreichen und hätte natürlich ganz erhebliche Auswirkungen auf den Handlingprozess innerhalb der Unternehmen.

So hart wie es klingt, aber du wirst nicht drum herumkommen die GoBD und erklärende Dokumente zu lesen.

http://www.bundesfinanzministerium.d...cationFile&v=3

Zitat:

3.2.5 Unveränderbarkeit (§ 146 Absatz 4 AO, § 239 Absatz 3 HGB)
58 Eine Buchung oder eine Aufzeichnung darf nicht in einer Weise verändert werden,
dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Auch solche Veränderungen
dürfen nicht vorgenommen werden, deren Beschaffenheit es ungewiss lässt, ob sie
ursprünglich oder erst später gemacht worden sind (§ 146 Absatz 4 AO, § 239
Absatz 3 HGB).
59 Veränderungen und Löschungen von und an elektronischen Buchungen oder Aufzeichnungen
(vgl. Rzn. 3 bis 5) müssen daher so protokolliert werden, dass die Voraussetzungen
des § 146 Absatz 4 AO bzw. § 239 Absatz 3 HGB erfüllt sind (siehe
auch unter 8). Für elektronische Dokumente und andere elektronische Unterlagen, die
gem. § 147 AO aufbewahrungspflichtig und nicht Buchungen oder Aufzeichnungen
sind, gilt dies sinngemäß.

http://www.psp.eu/media/allgemein/Go..._2_4_FINAL.pdf

Zitat:

7.2. Unveränderbarkeit48
Nach § 146 Absatz 4 AO darf eine Buchung oder Aufzeichnung nicht in einer Weise
verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist.49 Dazu
dürfen keine Veränderungen vorgenommen werden, die keinen Rückschluss darauf
zulassen, ob sie ursprünglich oder erst später initiiert wurden.50 Das zum Einsatz
kommende DV-Verfahren muss Gewähr dafür bieten, dass alle Informationen (Programme
und Datenbestände), die einmal in den Verarbeitungsprozess eingeführt
werden (Beleg, Grundaufzeichnung, Buchung), nicht mehr unterdrückt oder ohne
Kenntlichmachung überschrieben, gelöscht, geändert oder verfälscht werden können.
Bereits in den Verarbeitungsprozess eingeführte Informationen (Beleg, Grundaufzeichnung,
Buchung) dürfen nicht ohne Kenntlichmachung durch neue Daten
ersetzt werden.51

Die Unveränderbarkeit der Daten, Datensätze, elektronischer Dokumente und elektronischer
Unterlagen kann sowohl hardwaremäßig (z. B. unveränderbare und fälschungssichere
Datenträger) als auch softwaremäßig (z. B. Sicherungen, Sperren,
Festschreibungen, Löschmerker, automatische Protokollierung, Historisierungen,
Versionierungen) oder organisatorisch (z. B. mittels Zugriffsberechtigungskonzepten)
gewährleistet werden.52 Die Ablage von Daten und elektronischen Dokumenten
in einem Dateisystem erfüllt die Anforderungen der Unveränderbarkeit regelmäßig
nicht, soweit nicht zusätzliche Maßnahmen ergriffen werden, die eine Unveränderbarkeit
gewährleisten.53
Spätere Änderungen sind ausschließlich so vorzunehmen, dass sowohl der ursprüngliche
Inhalt als auch die Tatsache, dass Veränderungen vorgenommen wurden,
erkennbar bleiben. Bei programmgenerierten bzw. programmgesteuerten Aufzeichnungen
sind Änderungen an den der Aufzeichnung zugrunde liegenden
Generierungs- und Steuerungsdaten ebenfalls aufzuzeichnen. Dies betrifft insbesondere
die Protokollierung von Änderungen in Einstellungen oder die Parametrisierung
der Software. Bei der Änderung von Stammdaten (z. B. Abkürzungen oder
Schlüssel) muss die eindeutige Bedeutung in den entsprechenden Bewegungsdaten
erhalten bleiben. Gegebenenfalls müssen Stammdatenänderungen ausgeschlossen
oder Stammdaten mit Gültigkeitsangaben historisiert werden, um eindeutige und
korrekte Verknüpfungen zu gewährleisten. Auch die Änderungshistorie darf nicht
nachträglich veränderbar sein.54 Werden Systemfunktionalitäten oder Manipulationsprogramme
eingesetzt, die diesen Anforderungen entgegenwirken, führt dies
zur Ordnungswidrigkeit der elektronischen Bücher und sonst erforderlicher elektronischer
Aufzeichnungen.55

Für einen Sachkundigen Dritten muss bei einer Prüfung immer ersichtlich sein, wer (!) was (!) wann (!) geändert hat.
Das fett markierte im zweiten Zitat sagt eigentlich alles.
Wenn du einen Datensatz hast und den änderst, muss später nachträglich erkennbar bleiben was da mal stand.
Änderungsprotokoll sei hier als Stichwort genannt (was stand zum Zeitpunkt A da, was steht jetzt danach zum Zeitpunkt B).

Eine Hash-Kette wäre zum Beispiel eine Lösung, um miteinander zusammenhängende Datensätze gegen Manipulation zu schützen.
Das Verfahren muss natürlich den Stand der Technik entsprechen.

Was natürlich gar nicht geht sind so Sachen wie bspw. das du Rechnungsaufzeichnungen aus der Vergangenheit hast und nur weil du Preise oder Steuersätze jetzt aktuell im Programm änderst, diese alten Daten überschrieben/angepasst werden.

Auf Wunsch kann ich dir per PN den Namen eines guten Beratungsunternehmen für das Thema nennen.

[p80286]

Auch wenn TiGü die wesentlichen Aspekte schon genannt hat, noch ein Hinweis: Grundlage aller Überlegungen ist die Buchführung in Journalen. In diesen werden Erfassungsfehler durchgestrichen und die korrekten Daten in einem neuen Datensatz erfasst. Fehlbuchungen werden über Korrekturbuchungen berichtigt. Und solange der Prüfer die vorhandene Buchführung akzeptiert ist alles in Ordnung. Die Dokumente die der Buchung zu Grunde liegen sollten nicht editierbar sein, Bleistift wird hier nicht akzeptiert!
Für Dich heißt das, du solltest tunlichst keine Word-Dateien sondern z.B. PDF-A - Dateien verwenden.

Hier findest Du einen Einstieg:
https://de.wikipedia.org/wiki/Revisionssicherheit
https://de.wikipedia.org/wiki/Elektr...e_Archivierung

Gruß
K-H

[Codehunter]

Ich glaube ich muss meinen Gedankengang doch noch mal ein bisschen erläutern. Den Inhalt von GoBD kenne ich soweit ich ihn kennen muss (also nur den technisch relevanten Teil, nicht den buchhalterischen).

Die ursprüngliche Frage dieses Threads war: Wie soll man elektronische Dateianhänge (z.B. eingescannte Lieferscheine von Zulieferern) GoBD-konform ablegen? Wenn ich eure Ausführungen richtig verstehe ist es anwendungsseitig gar nicht vollständig zu erreichen, dass solche Dokumente 100% revisionssicher gespeichert werden. Nicht alle, wenn nicht gar nur die großen und teuren, Scansysteme unterstützen PDF-A. Wenn nun also JPEG- oder TIFF-Dateien eingeliefert werden und das originale Papierdokument dann geshreddert wird, kann die kundenseitige Implementierung des Systems die GoBD nicht erfüllen. Nur soll ich dann anwendungsseitig einen Filter einbauen der PDF-A bei den Importen erzwingt? Wäre das dann nicht schon wieder wettbewerbsrechtlich verboten? Oh man, ist man einmal in dem Paragrafenmoloch drin... :-(

Ich könnte mir vorstellen, dass es Branchen gibt bei denen die praktische Umsetzung der GoBD noch richtig Schwierigkeiten machen wird. Ich kenne schon fünf Unternehmen, die wegen GoBD von rein elektronischer Belegführung wieder zurück auf Papier umgestellt haben nachdem Steuerprüfer ihnen die rein elektronischen Systeme madig gemacht hatten.

[josef-b]

Also ich bin im Großhandel tätig, wir sind Mittelständler und über einen Einkaufsverband organisiert, der ungefähr 500 Mitglieder hat und wo
alles sehr straff organisiert ist und auch darauf geachtet wird, dass alles gesetzeskonform vonstatten geht, denn so Vorstände möchten ja
auch kein Risiko eingehen.

Wir bekommen alle Dokumente per Schnittstelle im ASCII-Format, XML etc..(die Daten) dazu jeweils Belege im PDF-Format (Rechnungen)
Lieferscheine Ein- und Ausgang scannen wir ein, auch im PDF, damit Unterschriften und händische Einträge auch vorhanden sind.

Lohnbuchhaltung machen wir per Lexware..Da ist auch alles im PDF-Format.

Das wichtigste ist eben dann die Datensicherung :)

Alle Belege vernichten wir nach dem Scanner, außer Eingangsrechnungen. Da hat uns mal ein Steuerberater geraten, die in Papierform aufzubewahren
um evtl. Diskussionen wegen dem Vorsteuer-Abzug mit dem Finanzamt aus dem Weg zu gehen.

Wir machen das seit einigen Jahren so, mittlerweile gabs auch einige Routine-Prüfungen vom Finanzamt..Es gab darüber niemals Beanstandungen.

Es wurde ja auch in den letzten Jahren gesetzlich gelockert, dass PDF-Dateien anerkannt werden, eine zeitlang war das wohl nur mit elektronischer
Signatur der Fall, das ist soweit ich weiß, entfallen..

Man sollte Bedenken, dass auch das Finanzamt grossen Wert darauf legt, dass sie alles elektronisch bekommen, also müssen sie es auch uns
ermöglichen.

Davon unberührt sind natürlich solche Sachen wie, GOB, dass z.B. Stornobuchen erkennbar sein müssen etc. Nummernkreise vollständig sein müssen etc.
das übliche halt.

[sh17]

Dem Finanzamt geht es eher weniger darum, das gar nichts geändert werden kann (WORM), sondern das alles nachvollziehbar ist. Und die Manipulation dem Anwender so schwer wie möglich gemacht wird. Mit genug Energie ist alles änderbar, das wissen wir alle. Da schießt die GoBD-Beschreibung technisch auch gern über das Ziel hinaus und relativ praxisfern.

[Codehunter]

Zitat:

Zitat von sh17 (Beitrag 1379443)

DMit genug Energie ist alles änderbar, das wissen wir alle. Da schießt die GoBD-Beschreibung technisch auch gern über das Ziel hinaus und relativ praxisfern.

Das sehe ich ganz genauso. Man kann das Logging, Hashing, Verschlüsselung etc. in der eigenen Software bis zum Exzess treiben. Doch dann wird sich kein Nutzer mehr dafür finden. Zumal Steuerprüfer aus technischer Sicht meist Laien sind. Sie wurden auf abgesteckte Szenarien geschult, haben ggf. einen Satz Validierungssoftware für Exportdateien an der Hand, aber auf gewisse kausale Zusammenhänge können die gar nicht eingehen. Also wird nach Bauchgefühl entschieden ob es eine Schätzung gibt oder nicht und den Rest überlässt man Anwälten, Gutachtern und Gerichten.

[p80286]

[OT]

Zitat:

Zitat von Codehunter (Beitrag 1379460)

Zumal Steuerprüfer aus technischer Sicht meist Laien sind. Sie wurden auf abgesteckte Szenarien geschult, haben ggf. einen Satz Validierungssoftware für Exportdateien an der Hand, aber auf gewisse kausale Zusammenhänge können die gar nicht eingehen.

Das erinnert mich ein wenig an die Meinungen, die hier manchmal über Lehrer geäußert werden.

nichts für ungut
K-H
[/OT]

[Codehunter]

Zitat:

Zitat von p80286 (Beitrag 1379505)

Das erinnert mich ein wenig an die Meinungen, die hier manchmal über Lehrer geäußert werden.

Sagen wir mal, ich gehe von den hiesigen Finanzbeamten aus. Die kommen mir in gewisser Weise wie eine Drückerkolonne vor, die es bewusst in Kauf nimmt überzogene Forderungen am oberen Ende möglicher Ermessensspielräume zu stellen. Die kleinen Unternehmen, die sich vor Gerichtsprozessen scheuen, nehmen die bittere Pille dann lieber in Kauf. Es gehen Gerüchte (!!!) um, es gäbe im Amt eine Art Erfolgsbeteiligung. Zumindest ergäbe das Sinn. Vergleiche ich die Herangehensweisen der FA bei uns hier und derer unserer Geschäftsstelle in Bayern, da liegen Welten dazwischen.

[TigerLilly]

Zitat:

Zitat von Codehunter (Beitrag 1379666)

Zitat:

Zitat von p80286 (Beitrag 1379505)

Das erinnert mich ein wenig an die Meinungen, die hier manchmal über Lehrer geäußert werden.

Sagen wir mal, ich gehe von den hiesigen Finanzbeamten aus. Die kommen mir in gewisser Weise wie eine Drückerkolonne vor, die es bewusst in Kauf nimmt überzogene Forderungen am oberen Ende möglicher Ermessensspielräume zu stellen. Die kleinen Unternehmen, die sich vor Gerichtsprozessen scheuen, nehmen die bittere Pille dann lieber in Kauf. Es gehen Gerüchte (!!!) um, es gäbe im Amt eine Art Erfolgsbeteiligung. Zumindest ergäbe das Sinn. Vergleiche ich die Herangehensweisen der FA bei uns hier und derer unserer Geschäftsstelle in Bayern, da liegen Welten dazwischen.

Genau. Gerüchte muss man möglichst schnell weiter verbreiten. :roll:

Wie so oft - wenn´s einen selber betrifft, ist jammern und klagen und sich beschweren angesagt. Aber wehe irgendwo passiert etwas, dann ist die Entrüstung groß, warum es da keine Prüfungen und Kontrollen und Richtlinien gibt.

[Codehunter]

Zitat:

Zitat von TigerLilly (Beitrag 1379673)

Wie so oft - wenn´s einen selber betrifft, ist jammern und klagen und sich beschweren angesagt. Aber wehe irgendwo passiert etwas, dann ist die Entrüstung groß, warum es da keine Prüfungen und Kontrollen und Richtlinien gibt.

Die könnens eben auch nicht jedem Recht machen. Aber letztlich ist es doch genau der Grund, weshalb man sich um GoBD Gedanken machen und seinen eigenen Laden sauber halten sollte. Oder siehst das anders?