Artikel Rename verhindern, wenn Artikel in Geb. VK-Rechnung

Hallo allerseits,

zunächst bitte ich um ein wenig Nachsicht, ich bin neu im Thema NAV.
Wir führen gerade als Pilot bei uns selbst NAV 2016 neu ein.

Mir ist aufgefallen, dass ich eine Artikelnummer nachträglich ändern kann, was an sich ja durchaus eine praktische Sache ist. (Wenn auch nicht wirklich performant )
Aber sagt unser Gesetzgeber in D nicht, dass Rechnungen nicht mehr verändert werden dürfen? Beim Rename der Artikelnummer wird aber auch die geb. VK_Rechnung geändert, was dem wiedersprechen würde.
Wie reagiert darauf denn der Wirtschafts- bzw. Steuerprüfer?

GIbt es eigentlich für NAV in D ein Prüfzertifikat, welches von einem Wirtschaftsprüfer ausgestellt wird und bestätigt, dass die Software gesetzeskonform arbeitet?
Hin und wieder werden wir in Bezug auf eine andere ERP-Software danach gefragt...

Grüße

B.

Hallo,

zunächst mal herzlich willkommen im Forum.

bezgl. des Testats solltest du hier fündig werden.

Gruß Fiddi

Mir ist aufgefallen, dass ich eine Artikelnummer nachträglich ändern kann, was an sich ja durchaus eine praktische Sache ist. Aber sagt unser Gesetzgeber in D nicht, dass Rechnungen nicht mehr verändert werden dürfen? Beim Rename der Artikelnummer wird aber auch die geb. VK_Rechnung geändert, was dem widersprechen würde.

Das ist eine Philosophiefrage und eine Frage der Arbeitsweise. Wenn man z. B. Kopien der gedruckten Rechnung aufbewahrt sind diese unveränderlich, alternativ in einer elektronischen Dokumentenverwaltung. Außerdem sind andere Daten in NAV ja auch veränderlich, z. B. Firmenlogo oder Geschäftsführerangaben, sofern man das Briefpapier aus NAV heraus druckt wäre es dann auch nicht mehr möglich den Beleg nochmal so auszudrucken wie er "damals" ausgesehen hat.

Meine Philosophie dazu wäre: Man sollte m. E. bebuchte Stammdaten (das gilt ja analog für Sachkonten, Debitoren, Kreditoren etc.) nicht umbenennen wenn diese im aktuellen oder im Vorjahr bebucht waren.

Im Zweifelsfall muss das jeder Nutzer mit seinem Prüfer absprechen.

Zuletzt geändert von enh am 8. Februar 2016 19:31, insgesamt 1-mal geändert.

Aber sagt unser Gesetzgeber in D nicht, dass Rechnungen nicht mehr verändert werden dürfen? Beim Rename der Artikelnummer wird aber auch die geb. VK_Rechnung geändert, was dem wiedersprechen würde.
Wie reagiert darauf denn der Wirtschafts- bzw. Steuerprüfer?

Mach doch mal eins:
Gehe in eine bereits gebuchte UND gedruckte VK-Rechnung....und "versuch" die mal zu löschen ;)

frag doch mal den Prüfer, was er dazu sagt

Aber sagt unser Gesetzgeber in D nicht, dass Rechnungen nicht mehr verändert werden dürfen? Beim Rename der Artikelnummer wird aber auch die geb. VK_Rechnung geändert, was dem wiedersprechen würde.
Wie reagiert darauf denn der Wirtschafts- bzw. Steuerprüfer?

Mach doch mal eins:
Gehe in eine bereits gebuchte UND gedruckte VK-Rechnung....und "versuch" die mal zu löschen ;)
frag doch mal den Prüfer, was er dazu sagt

Das Löschen geht nur mit entsprechenden (Benutzer-) Rechten, und Daten in wirklich relevanten Tabellen kann niemand mit Kundenlizenz löschen (Postentabellen).

Ansonsten kann man natürlich auch vieles machen was kein Prüfer gutheißen würde. Man kann auch an NAV vorbei direkt über SQL Daten manipulieren. Wenn man als Kunde selbst entwickelt und eine entsprechende Lizenz hat kann man das auch in NAV.

Das Löschen geht nur mit entsprechenden Rechten und Daten in wirklich relevanten Tabellen kann niemand mit Kundenlizenz löschen (Postentabellen).

Eine gebuchte und gedruckte Rechnung darf - im Standard - jeder löschen der die Berechtigung zum Ausführen des Reports zum Löschen von Rechnungen oder der die Gebuchte Rechnungen- Page öffnen kann, und dem die Rechte für die Tabellen nicht entzogen worden sind. D.h. nachdem du eine Rechnung gedruckt hast, kannst du Sie aus dem System löschen, und nie wieder drucken. Die Posten bleiben zwar vorhanden, der Beleg ist aber futsch.

Gruß Fiddi

Hallo zusammen!

Vielen Dank für die Antworten.

Dass man die Daten auf der Datenbank direkt ändern kann ist klar, aber in der Tat hat danach noch kein Prüfer wirklich gefragt. Da sollte dann jeder mit entsprechendem Zugang auch entsprechend "informiert" sein.

Gebuchte Rechnung können gelöscht werden. Interessant... Dann sollten wir da wohl auf die Berechtigungen achten!

@Fiddi:
Danke für den Link, den kannte ich nicht.

Grüße

B.

Man sollte an dieser Stelle nicht vergessen, das Navision kein Archivsystem ist.
Alle historischen Daten dienen eigentlich nur zur evtl. Bearbeitung zu einem späteren Zeitpunkt.

Die Verantwortung zur Archivierung liegt immer beim Anwender, nicht bei Navision.
Wie die Archivierung aussehen kann, dazu gibt es ja schon einige Posts hier.

Außerdem: Stammdaten in einem laufenden System umzubenennen, ist sowieso in meinen Augen Quatsch. Sobald einmal z. B. Auf einem Artikel gebucht wurde,
wird beim Umbenennen das gesamte System durchsucht, wo der Artikel noch verwendet wurde und das kostet Performance.
Dies führt u. U. sogar bis zum vollständigen Systemstillstand.
Also sollte man(n) das sein lassen und lieber einen neuen Artikel anlegen.

Gebuchte Rechnung können gelöscht werden. Interessant... Dann sollten wir da wohl auf die Berechtigungen achten!

Du hast die Voraussetzung übersehen: wenn der Print-Counter != 0 ist. Darüberhinaus hab /ich/ gerne beim on delete in salesinvheader (at.al.) gerne ein exit() oder error('') als erstes Statement eingebaut.

Gebuchte Rechnung können gelöscht werden. Interessant... Dann sollten wir da wohl auf die Berechtigungen achten!

Du hast die Voraussetzung übersehen: wenn der Print-Counter != 0 ist. Darüberhinaus hab /ich/ gerne beim on delete in salesinvheader (at.al.) gerne ein exit() oder error('') als erstes Statement eingebaut.

fiddi hat die Veraussetzung nicht übersehen, da diese bereits durch mich genannt wurden.
Weiterhin sollte man überlegen, ob man nun wirklich immer unbedingt in den Standard eingreifen muss, indem man den Trigger bearbeitet. Das wäre dann wieder ein Objekt mehr, welches "unnötige Kosten" bei einem
Update hervorruft.
Dann doch lieber die Berechtigungen anpassen.