[Gelöst] Änderungsprotokoll und Umsetzung GoBD

Liebe Forumianer,

wir fahren eine NAV 2013 R2 Anwendung mit ca. 100 concurrent Users hauptsächlich über den WebClient. Unsere NAV Installation ist recht weit vom Standard entfernt. D.h. es gibt zahlreiche eigene Anpassungen, die relevant für die Rechnungslegung sind.

Aus technischen Gründen haben wir das Änderungsprotokoll über ausgewählte Stammdaten- und Konfigurationstabellen laufen. Dabei fallen im Monat ca. 8 Mios Datensätze an. Datensätze die älter sind, werden automatisch per SqlServer Agent in einem Wartungsjob entfernt.

Jetzt gibt es die Anforderung, die Änderungsprotokollierung auch für GoBD/den Wirtschaftsprüfer zu verwenden. Bei einer Aufbewahrungsfrist von 10 Jahren explodiert unsere Datenbank somit

Gibt es bei Euren Installationen diese Anforderungen? Wie geht Ihr damit um?

Grüsse aus HH

Zuletzt geändert von Elbkind am 6. Juni 2017 11:38, insgesamt 1-mal geändert.

Müssen die Daten zwingend in der SQL-DB aufbewahrt werden?
Ansonsten wäre vielleicht die Idee, dass ihr euch ein Archiv mit einer nosql-DB aufbaut und anstatt aufzuräumen dahin auslagert.

Hallo Markus,

vielen Dank für die Antwort

Das "Änderungsprotokoll-Archiv" soll ja auch ausgewertet werden. Und zwar von NAV KeyUsern, die mit dem Filtern in NAV vertraut sind. NAV bietet ein sehr performantes Filtern und Darstellen von Listen mit sehr sehr vielen Datensätzen. Das ist nicht so einfach "nachzubauen".

Vor diesem Hintergrund fände ich eigentlich den Gedanken verlockend, eine NAV-Instanz zu installieren, in der faktisch nur das Änderungsprotokoll bewegt wird:
* Ein SQLServer Agent Job lagert regelmäßig per TSQL INSERT alle Datensätze der Tabelle Change Log Entries (595) aus der Produktions NAV-Instanz in die Archiv-Instanz (klar, könnte man auch als NAS Job machen, aber wir können keine C/Side )
* Wenn im Archiv "geforscht" werden muss, dann verbinden sich die User mit der Archiv-Instanz, öffnen dort das Änderungsprotokoll und browsen und filtern dort nach Belieben. Das Ganze dann nur mit Leseberechtigungen über die bekannte NAV Zugriffssteuerung.

Ich möchte in diesem Kontext soviel wie geht mit bekannten, vertrauten Tools arbeiten und wenig eigenes Implementierungsrisiko eingehen.

Allgemein wundert mich, dass es, wenn ich nach "NAV GoBD Änderungsprotokoll" google, so wenig Treffer gibt Das das Änderungsprotokoll für diese Zwecke verwendet werden soll, entnehme ich der "Softwarebescheinigung - Standardsoftware Microsoft Dynamics NAV 2013 Teilgebiet Finanzbuchhaltung" Abschnitt "5.2.1.4. Protokollierungsfunktion". Wenn wir die Daten aber im Änderungsprotokoll liegen ließen, dann würden wir ständig Festplatten ohne Ende nachstecken und die Performanz geht in den Keller

Wir gehen mit NAV erst jetzt richtig produktiv, deshalb fehlen uns Erfahrungen.

Hallo,

wo bitteschön steht denn, das man ein Änderungsprotokoll à la NAV führen muss?

Gruß Fiddi

Bei uns hat der Wirtschaftsprüfer gesagt wir sollen einige Stammdaten loggen.
Eine Liste was wir Loggen sollen konnten sie uns aber nicht geben ... es wurde nur gesagt "das sagt doch der normale Menschenverstand"

Das Thema mit dem Änderungsprotokoll ist ja, ob ich diese Stammdaten für die Buchhaltung überhaupt benötige. Es hängt doch sehr vom Programm ab, ob es überhaupt relevant ist, was in den Stammdaten steht.

Z.B. ein ERP-Programm speichert keine Addressdaten in gebuchten Rechnungen.
Dann ist sehr wohl relevant, wann ich die Stammdaten geändert habe, weil ein erneuter Ausdruck einer Rechnung u.U. eine andere Rechnungsanschrift erzeugt. Dann muss ich nachvollziehen können, wann ich die Daten geändert habe, um beweisen zu können, das die Rechnung ursprünglich mal an jemanden ganz anders ging.
In NAV wird die Adresse in der gebuchten Rechnung gespeichert, und eine Änderung der Debitorenadresse hätte keinen Einfluss auf den Beleg. (solange ich ihn nicht lösche, denn im Deb.- Posten steht keine Adresse).

Gruß Fiddi

Ich glaube es ging ihnen auch eher darum "das Unternehmen zu schützen"
Zum Beispiel sollen wir Änderungen an Kreditor Bankkonten loggen, damit man beweisen kann das Benutzer xy das Konto auf ein "privates" geändert hat, falls das Geld beim Kreditor nicht an kommt.

Aber wie gesagt... wir haben keine Definition erhalten was geloggt werden soll.

Zum Thema "was hat GoDB mit dem NAV Änderungsprotokoll zu tun?"

Das habe ich mich auch gefragt... und mich betriebsintern dagegen gewehrt. Meine Argumente waren, a) das ist technisch orientiert, b) es werden viel zu viele Daten produziert, c) es ist keine Archiv Lösung.

Jedoch...

Sh. "Softwarebescheinigung - Standardsoftware Microsoft Dynamics NAV 2013 Teilgebiet Finanzbuchhaltung" Abschnitt "5.2.1.4. Protokollierungsfunktion":

Anforderungen. Bei programmgenerierten bzw. programmgesteuerten Buchungen (...) sind Änderungen an den der Buchung zu Grunde liegenden Generierungs- und Steuerungsdaten aufzuzeichenen. (...) Microsoft Dynamics NAV 2013 besitzt ein umfangreiches, zu konfigurierendes Änderungsprotokoll (...)

fiddi hat oben geschrieben:

Z.B. ein ERP-Programm speichert keine Addressdaten in gebuchten Rechnungen.
Dann ist sehr wohl relevant, wann ich die Stammdaten geändert habe, weil ein erneuter Ausdruck einer Rechnung u.U. eine andere Rechnungsanschrift erzeugt. Dann muss ich nachvollziehen können, wann ich die Daten geändert habe, um beweisen zu können, das die Rechnung ursprünglich mal an jemanden ganz anders ging.
In NAV wird die Adresse in der gebuchten Rechnung gespeichert, und eine Änderung der Debitorenadresse hätte keinen Einfluss auf den Beleg. (solange ich ihn nicht lösche, denn im Deb.- Posten steht keine Adresse).

Ted antwortet:

Zum Beispiel sollen wir Änderungen an Kreditor Bankkonten loggen, damit man beweisen kann das Benutzer xy das Konto auf ein "privates" geändert hat, falls das Geld beim Kreditor nicht an kommt.

In fiddis Beispiel macht NAV das automatisch. Der WP hat genau den Fall von Ted problematisiert. Wir haben aber noch zahlreiche andere Änderungen jenseits der Adresse, die nicht in die gebuchte Rechnung oder in Posten kommen. Im oben zitierten Dokument aus der "Softwarebescheinigung" wird dafür explizit das Änderungsprotokoll genannt. Meine o.g Argumente (a) das ist technisch orientiert, b) es werden viel zu viele Daten produziert, c) es ist keine Archiv Lösung) sind damit entkräftet

Hallo,

das Änderungsprotokoll für (wichtige) Stammdaten macht ja auch Sinn. Das erzeugt aber nicht die Unmenge an Daten, die man langfristig benötigen würde.

Gruß Fiddi

Es kommt wohl darauf an, was man in den Teil "Änderungen an den der Buchung zu Grunde liegenden Generierungs- und Steuerungsdaten" hineininterpretiert.
Es dürfte jedem klar sein, dass Änderungen von Buchungsgruppen in den Stammdaten zu den sensiblen Daten gehören, dessen Änderungen protokolliert werden sollten.
Aber zählen auch der VK-Preis, Zeilenrabatt % & Co. aus den Belegzeilen dazu? Immerhin sind das ja auch Daten, welche der Buchung zugrunde liegen.
Nein, tun sie nicht, denn sie steuern nicht die Buchung.

Kommen wir zurück auf die Buchungsgruppen.
Bei der Buchung werden die Buchungsgruppen aus der Belegzeile herangezogen, nicht die in den Stammdaten.
Die Buchungsgruppen werden zum Zeitpunkt der Anlage einer Belegzeile aus den Stammdaten in die Zeile kopiert.
Jetzt könnte man theoretisch in der Verkaufszeile die Produktbuchungsgruppe manuell ändern, so dass die Werte in der Buchhaltung auf einem ganz anderen Konto gebucht würden.
Auf der Artikelkarte steht jedoch die korrekte Produktbuchungsgruppe.
Also müsste man auch die Änderung der Buchungsgruppen auf Belegkopf und -zeilenebene protokollieren.
Ändere ich aber in einer Verkaufszeile die Artikelnr. von 4711 in 0815, so ändert sich logischerweise auch die Produktbuchungsgruppe.
Dies müsste logischerweise nicht protokolliert werden.
Für das System ist dies eine Feldwertänderung innerhalb des vorhandenen Datensatzes, und protokolliert diese Änderung.
Ändert jedoch der Anwender in der Verkaufszeile die Produktbuchungsgruppe, so müsste die Änderung auf jeden Fall protokolliert werden, da es die anschließende Buchung maßgeblich steuert (Kontenfindung).

Hallo,

eine Frage, die ich mir zuallererst stellen würde, wofür gilt die Aufzeichnungspflicht eigentlich, für die gebuchten oder für die ungebuchten Daten?

Bei ersterem wäre es aus gesetzlicher Sicht auf NAV bezogen fast unnötig ein Protokoll zu schreiben, da alle Informationen (u.U. bis auf die Verkäufer- Informationen, deshalb: keine Verkäufer löschen!) in Beleg- oder Postentabellen enthalten sind.
Würde das auch bei letzterem gelten, müsste ich jedes Angebot, jede Anfrage, jeden Buchungsvorschlag archivieren, es könnte ja relevant sein. Auch ein telefonisch angefragter Preis, den man mal eben mit dem Taschenrechner kalkuliert hat, müsste protokolliert werden. Man stelle sich einen Heizölhändler vor, den am Tag mehrere hundert Anrufer anrufen, und nach dem Preis fragen, und vielleicht nur 10 % davon bei Ihm kaufen. Ich weiß nicht, was das Finanzamt daran interessant finden könnte, da hier keine für das Amt relevanten Daten enthalten sind. Auch Aufträge oder Bestellungen sind nicht wirklich relevant, da sich bis zur Rechnungsstellung noch einiges ändern kann. Das ändert sich allerdings dann, wenn man z.B.eine Auftragsbestätigung verschickt hat, weil hier für den Verkaufsvorfall relevante Daten enthalten sind, die vom Gegenüber akzeptiert werden oder auch nicht.

Mir persönlich scheint das auch nicht gewollt zu sein, und eher wieder so eine Aktion wie bei den Gutschriften zu sein, wo mal wieder was in ein BMF- Schreiben hinein interpretiert wurde, was gar nicht gemeint war.

Was man zur Eigensicherung und Fehlersuche protokollieren möchte, ist ein anderes Thema. Das muss man aber auch keine 10 Jahre aufbewahren.

Gruß Fiddi