Bodo's Dynamics NAV und Business Central Blog
Bodo ist ein Dynamics NAV Urgestein. Er programmiert Navision seit DOS Zeiten und hat auch keine Scheu vor .NET und schon gar nicht vor Dynamics 365 oder Azure. Viele Neueinsteiger wurden von ihm in den letzten Jahren zu Entwicklern ausgebildet. In diesem Blog veröffentlichen Bodo und andere Superhelden Interessantes aus der Welt von Dynamics 365 Business Central / Dynamics NAV und Microsoft Azure.NAV 2009 – Security Filter, Buchungsdatum und Rec.READPERMISSION
Tags: 2009, securtiy, buchungsdatum, READPERMISSIONSzenario: Der Betriebsprüfer vom Finanzamt steht vor der Tür. Es soll das Geschäftsjahr 2010 geprüft werden. Ihre Aufgabe ist es, eine Dynamics NAV Rolle für den Betriebsprüfer einzurichten und dabei die Zugriffsrechte auf das Geschäftsjahr 2010 einzuschränken.
Für diese Art von Anforderungen kennt Dynamics NAV das Konzept der Security Filter. Security Filter definieren Sie in den Zugriffsrechten für Table Data-Objekte. Die unten stehende Abbildung zeigt die Definition für die Sachposten mit der Einschränkung des Buchungsdatums auf das Geschäftsjahr 2010. Wir haben für den Betriebsprüfer eine Rolle „FA“ (Finanzamt) angelegt. Die zusätzlichen Berechtigungen für die Table Data-Objekte Währung, Sachkonto und Bemerkungszeile sind notwendig, um den Kontenplan bzw. die Sachkontoarte öffnen zu können.
Zusammen mit der vordefinierten Rolle „ALLE“ des Demomandanten CRONUS AG sind die Berechtigungen ausreichend. Könnte man meinen.
Allerdings kommt es beim Öffnen des Kontenplans zu folgender Fehlermeldung:
Was ist die Ursache? Auf dem Kontenplan haben wir u.a. das Flow Field „Saldo“. Bekanntlich berechnet sich der Saldo aus allen Sachposten des Kontos. Da wir den Zugriff auf die Sachposten über den Security Filter eingeschränkt haben, können nicht mehr alle Sachposten gelesen werden und Dynamics NAV bringt die Fehlermeldung „Sie haben keine Berechtigung zum Lesen der Tabelle Sachposten“.
Und die Lösung? Wir brauchen eine zweite Rolle „FA-INDIREKT“ (Finanzamt – indirekte Rechte), mit der wir indirekte Leserechte auf die Sachposten erteilen, ohne einen Security Filter zu setzen. Damit erlauben wir dem Flow Field sich zu berechnen.
Die neue Rolle weisen wir ebenfalls unserem Benutzer zu.
Jetzt kann der Betriebsprüfer den Kontenplan öffnen. Die Spalte Saldo zeigt zwar per Definition immer den aktuellen Saldo an, wenn Sie allerdings den Drill Down auf die Sachposten machen, werden nur die Bewegungen des Geschäftsjahres 2010 angezeigt.
Diese Lösung lässt sich noch verfeinern: 1) Die Spalte „Saldo bis Datum“ soll immer den Saldo per Ende der Prüfungsperiode anzeigen. 2) Der Betriebsprüfer soll nicht die Möglichkeit haben, durch das Setzen des Flow Filters „Datumsfilter“ in der Spalte „Bewegung“ einen Wert für eine Bewegung außerhalb der Prüfungsperiode anzuzeigen.
Beide Anforderungen lassen sich erfüllen, wenn wir einen Security Filter für Sachkonto definieren und den Datumsfilter auf das Geschäftsjahr 2010 einschränken.
Geschafft. Könnte man meinen. Leider sind Teile des Dynamics NAV Standards nicht für den Einsatz von Security Filtern vorbereitet. So zum Beispiel das Navigate-Formular. Wenn Sie auf einem beliebigen Sachposten stehen und „Navigate“ ausführen, bekommen Sie die folgende Fehlermeldung:
Die Fehlermeldung kann einen wundern. Zumindest der eine Sachposten auf dem wir aktuell stehen, enthält unsere Kombination aus Belegnummer und Buchungsdatum. Ein Blick hinter die Kulissen des Navigate-Formulars verrät das Problem (Funktion „FindRecords“):
...
IF GLEntry.READPERMISSION THEN BEGIN
GLEntry.RESET;
GLEntry.SETCURRENTKEY("Document No.","Posting Date");
GLEntry.SETFILTER("Document No.",DocNoFilter);
GLEntry.SETFILTER("Posting Date",PostingDateFilter);
InsertIntoDocEntry(
DATABASE::"G/L Entry",0,GLEntry.TABLECAPTION,GLEntry.COUNT);
END;
...
Rec.READPERMISSION liefert FALSE zurück, wenn für die Tabelle ein Security Filter definiert ist. In solchen Fällen muss vorher Rec.SETPERMISSIONFILTER aufgerufen werden. Gleichzeitig dürfen wir danach kein Rec.RESET machen, damit der Rec.COUNT auch den Security Filter berücksichtigt und nicht die bekannte Fehlermeldung „Sie haben keine Berechtigung zum Lesen der Tabelle Sachposten“ liefert. Der Programmcode kann also wie folgt umgebaut werden:
// --- 001
GLEntry.RESET;
GLEntry.SETPERMISSIONFILTER;
// +++ 001
IF GLEntry.READPERMISSION THEN BEGIN
// --- 001
// GLEntry.RESET;
// +++ 001
GLEntry.SETCURRENTKEY("Document No.","Posting Date");
GLEntry.SETFILTER("Document No.",DocNoFilter);
GLEntry.SETFILTER("Posting Date",PostingDateFilter);
InsertIntoDocEntry(
DATABASE::"G/L Entry",0,GLEntry.TABLECAPTION,GLEntry.COUNT);
END;
Doch halt. Es geht auch anders. Weiter oben haben wir mit der Rolle „FA-INDIREKT“ indirekte Leserechte für die Sachposten definiert. Diese Berechtigung können wir nutzen, wenn wir dem Navigate-Formular über das Permissions-Property Leserechte auf die Sachposten einräumen:
Beide Varianten führen zum Erfolg.
Epilog. Das hier vorgestellte Konzept müssen Sie selbstverständlich auf Debitoren, Debitorenposten, detaillierte Debitorenposten, Kreditoren, Kreditorenposten, detaillierte Kreditorenposten und nicht zu vergessen, die Mehrwertsteuerposten, übertragen.
