Dokumentation GOBD Konformität (Dateninterpretation GDPDU)

Sicherstellung der GOBD Konformität durch dicommerce

Fortlaufende Belegnummernvergabe

Durch den programmseitigen Ablauf ist sichergestellt, dass eine fortlaufende Belegnummernvergabe pro Belegart besteht (Angebot/Auftragsbestätigung/Lieferschein/Rechnung im Verkauf Bestellung/Wareneingang/Rechnung im Einkauf).

Wird ein erfasster Beleg wieder gelöscht (z.B. ein Angebot oder ein Lieferschein), so wird die Belegnummer wieder zur Weiterverwendung in die Datenbank zurückgeschrieben. Der nächste Beleg, der in dieser Belegart erzeugt wird, erhält dann die zuvor gelöschte Belegnummer.

Der Anwender kann nicht in diese Erzeugung und Verwendung der Belegnummern eingreifen.

Lückenanalyse

Eine Lückenanalyse muss somit über die Belegnummern durchgeführt werden. Die Belegnummer ist pro Belegart fortlaufend.

Hinweis: die fortlaufende Belegnummernvergabe findet nicht pro Jahr getrennt statt, sondern läuft über die Jahre hinweg durch.

Das bedeutet, wenn um den Zeitraum des Jahreswechsels vermeintlich Belegnummern für das ausgewertete Jahr fehlen, kann dies darauf hindeuten, dass diese nur für das andere Jahr genutzt wurden, nicht aber fehlen.

Veränderung von Belegen

Wandlung einer Belegart in den nächsten Status

Verkauf

Wird z.B. ein Angebot in eine Auftragsbestätigung gewandelt, kann der Anwender das Angebot nicht mehr verändern.

Die nächste Belegart Auftragsbestätigung ist dann der aktuelle Bearbeitungsstand und kann noch verändert werden. In der Datenbank ist das Angebot in der ursprünglichen Form gespeichert. Dies gilt ebenso für die Weiterverarbeitung zum Lieferschein und auch zur Rechnung. Ein Angebot kann über den Status Auftragsbestätigung / Lieferschein bis zur Rechnung durchgewandelt werden, muss es aber nicht.

Ein Angebot kann auch direkt zu einem Lieferschein gewandelt werden. Sobald eine Belegart einen Vorgängerbeleg hat, ist der Vorgängerbeleg nicht mehr durch den Anwender veränderbar. Es ist für den Anwender auch möglich, direkt Rechnungen zu schreiben, ohne zuvor einen Lieferschein erfasst zu haben.

Einkauf

Wird eine Bestellung in einen Wareneingang gewandelt, kann der Anwender die Bestellung nicht mehr verändern. Die nächste Belegart Wareneingang ist dann der aktuelle Bearbeitungsstand und kann noch verändert werden. In der Datenbank ist die Bestellung in der ursprünglichen Form gespeichert.

Wird ein Wareneingang zu einer Rechnung gewandelt, so ist der Wareneingang noch so lange veränderbar, bis die Rechnung den Status „geprüft“ erhält. Dieser wird vom Anwender gesetzt. Ab diesem Zeitpunkt ist weder der Wareneingang noch die Rechnung mehr zu bearbeiten.

Rechnungsverarbeitung

Ist eine Rechnung im Verkauf erstellt und gedruckt worden oder eine im Einkauf erstellte Wareneingangsrechnung geprüft worden, werden diese im Vorgang „Tagesabschluss“ für weiterverarbeitende Systeme wie Finanzbuchhaltungen aufbereitet.

Ab dem Zeitpunkt des Drucks ist keine weitere Bearbeitung durch den Anwender an dieser Rechnung mehr möglich. Eine Korrektur ist dann nur noch durch einen zusätzlichen Stornobeleg möglich. Dieser negiert den falschen Beleg und die Rechnung muss im Anschluss mit einer neuen Belegnummer neu erfasst werden.

Der Punkt „Tagesabschluss“ umfasst automatisch alle gedruckten Rechnungen im Verkauf und alle geprüften Rechnungen im Einkauf. Der Anwender hat keinen Einfluss darauf, Rechnungen von dieser Verarbeitung im Tagesabschluss auszuschließen.

Änderungshistorie

Ab dem dicommerce Release 6.0 (dicommerce 2019), gibt es in der Datenbank eine detaillierte und feldgenaue Änderungshistorie, die sowohl die Stammdaten als auch die Belegdaten umfasst.

Bis zu diesem Release gibt es bezogen auf die Stammdaten wie auf die Belegdaten immer das Datum der letzten Änderung und wer diese Änderung vorgenommen hat.

Bei den Verkaufs- wie Einkaufspreisen ist bedingt durch die Datenstruktur automatisch eine Historie vorhanden, da die Preise immer mit einem Gültigkeitsdatum bzw. Zeitraum belegt sind.

Beschreibung der GDPDU Daten

Erklärungen:

*= wenn bei einem Artikel das Kennzeichen LEIHARTIKEL auf T steht, hat der Artikel möglicherweise keine Bezeichnung, auch nicht in den Auftragspositionen und den Statistiken, da diese Artikel teilweise als Leerzeile auf Lieferscheinen / Rechnung verwendet wird.

Zuordnung NRINTERN Warenverkauf

Wird ein Beleg vom Status Angebot über eine Auftragsbestätigung und einen Lieferschein bis zu einer Rechnung gewandelt, haben alle Vorgänge die gleiche NRINTERN, aber unterschiedliche NRBELEGARTEN und unterschiedliche NRBELEGE.

Über die NRINTERN sind somit die Belege untereinander zu referenzieren. Werden mehrere Lieferscheinbelege zu einer Sammelrechnung, so greift dieser Mechanismus nicht, sondern alle Lieferscheine haben dann im Feld NRINTERNRECHNUNG die NRINTERN der zugehörigen Rechnung hinterlegt.

Beispiel

Im folgenden Beispiel liegt keine Sammelrechnung vor, sondern eine direkte Abrechnung von einem Angebot bis hin zur Rechnung.

In diesem Fall sind alle Vorgänge über die NRINTERN zueinander referenziert.

Im folgenden Beispiel hingegen liegt eine Sammelrechnung vor. Das heißt mehrere Lieferscheine sind zu einer Sammelrechnung zusammengeführt worden.

In diesem Fall sind alle Vorgänge über die NRINTERN zueinander referenziert, außer der Lieferschein zu dem Vorgang Rechnung.

Die Zuordnung mehrerer Lieferscheine zu einer Rechnung ist dann über das Feld NRINTERNRECHNUNG zu finden. Alle Lieferscheine haben somit im Feld NRINTERNRECHNUNG die Hinterlegung der NRINTERN der Rechnung.

Ob ein Anwender mit den Belegarten Angebot und Auftragsbestätigung arbeitet, bleibt ihm selbst überlassen.