|
Verwendung: Definition von Zugriffsberechtigungen.
Die Tabelle SYACC regelt die Zugriffsberechtigungen für Tabellen, Tabellenfelder, Berichte und Funktionen. Berechtigungen werden auf Benutzer- oder Benutzergruppenebene hinterlegt. Eines dieser beiden Felder ist bei jeder Art der Berechtigungsvergabe notwendig. Da ein Benutzer auch mehreren Benutzergruppen angehören kann, wird das für ihn gültige Zugriffsprofil aus der Summe der hinterlegten Definitionen ermittelt. Die Werte werden manuell oder mit dem MD-Administrator verwaltet. Im Userinterface ist die Dateneingabe über "Systemdaten/Zugriffsberechtigungen" oder "Systemdaten/Klienten/Benutzer/Berechtigungen" möglich.
Tabellenfeld
|
Beschreibung
|
USER_ID
|
Benutzer
|
USERGR_ID
|
Benutzergruppe
|
PRREP_ID
|
Report
|
EXP_ID
|
Export
|
TABLE_NAME
|
Tabelle
|
COLUMN_NAME
|
Feldname
|
PRM_NAME
|
Logische Zugriffsberechtigung.
|
ACC_MODE
|
0 = Lesen
1 = Einfügen
2 = Ändern
3 = Löschen
|
REVOKE_KZ
|
0 = Recht wird erlaubt
1 = Recht wird entzogen
|
Ist für einen Bericht kein Eintrag vorhanden, haben nur Administratoren Ausführungsberechtigung. Um das Ausführen zu gestatten, ist die ID des Reports (PRREP_ID) sowie das Feld REVOKE_KZ mit dem Wert "0" anzugeben.
|
Ist für einen Export kein Eintrag vorhanden, haben nur Administratoren Ausführungsberechtigung. Um das Ausführen zu gestatten, ist die ID des Exports (EXP_ID) sowie das Feld REVOKE_KZ mit dem Wert "0" anzugeben.
|
Logische Berechtigungen werden durch das Feld PRM_NAME und REVOKE_KZ angegeben. Die Tabelle SYACCPRM enthält alle im System möglichen logischen Zugriffsberechtigungen. Ist für eine solche Berechtigung kein Eintrag in der Tabelle vorhanden, wird nur Administratoren Zugriff gewährt. Um die Berechtigung zu erteilen, ist PRM_NAME zu definieren und das Feld REVOKE_KZ auf Wert "0" zu setzen.
|
Um Zugriffsberechtigungen für Tabellen zu hinterlegen, sind vorerst einige wichtige Grundsätze darzustellen. Da eine Tabelle aus verschiedenen Teilen des Userinterfaces geändert werden kann, wäre eine Hinterlegung von Berechtigungen auf reiner Tabellenebene unzureichend. So wird z.B. auf die Tabelle MDJOU (speichert alle Auftragspositionen) sowohl aus einem Kundenauftrag als auch aus einem Lieferantenauftrag zugegriffen. Die Tabelle für das Speichern der Kundenaufträge ist MDFAKT und die für Lieferantenaufträge MDBAKT. Diese Tabellennamen werden nun kombiniert und daher ergibt sich für die Auftragspositionen des Kundenauftrages die kombinierte Tabellenbezeichnung MDFAKT_MDJOU und für die des Lieferantenauftrages MDBAKT_MDJOU. Diese Regel wird generell angewendet und hat in der kompletten Applikation Gültigkeit. Ansprechpersonen (Tabelle MDZHD) werden im Kunden- und im Lieferantenstamm angelegt. Zugriffsberechtigungen für die Ansprechpersonen der Kunden werden mit MDKND_MDZHD und für die Lieferanten mit MDLIE_MDZHD angegeben. Eine Besonderheit für die kombinierten Tabellenbezeichnungen gibt es in Verbindung mit Auftragspositionen. Hier wird zusätzlich der aktuelle Auftragsstatuscode verwendet, um Berechtigungen für bestimmte Auftragsstati vergeben zu können (siehe kommendes Beispiel).
Um die Berechtigung für eine bestimmte Tabelle zu ermitteln wird hierarchisch vorgegangen. Anhand der Kundenauftragsposition, die sich im Status "AR" (Auftrag mit Reservierung) befindet, wird dieses Modell erklärt:
1.MDFAKT_MDJOU_AR 2.MDFAKT_MDJOU 3.MDJOU
Sobald einer der oben angeführten Einträge vorhanden ist, wird die Berechtigungsermittlung abgebrochen und eventuell vorhandene Einträge nicht mehr behandelt. Innerhalb einer Ebene wird zuerst nach einem Benutzerrecht gesucht. Wenn keines vorhanden ist, wird das Recht aus der Benutzergruppe verwendet. Gibt es innerhalb der Benutzer bzw. Benutzergruppen überschneidende Berechtigungseinträge, hat der Eintrag mir niedrigster Priorität (siehe Reihenfolge bei ACC_MODE) Gültigkeit.
|
Zugriffsberechtigungen für einzelne Felder von Tabellen werden nach dem gleichen Schema wie bei den Tabellen vergeben. Der einzige Unterschied besteht darin, dass zusätzlich zur Tabelle auch der Feldname anzugeben ist. ACC_MODE kann in diesem Fall aber nur den Wert LESEN oder ÄNDERN annehmen. Wenn die Leseberechtigung mit REVOKE_KZ entzogen wird, gibt es ein Eingabefeld in der Bildschirmmaske im Passwortmodus. Handelt es sich um kein Eingabefeld, sondern z.B. um eine Checkbox, wird das Feld nicht angezeigt. Wenn die Änderungsberechtigung entzogen wird, sind alle Felder der Eingabemaske deaktiviert.
Ändern von Feldern bereits übergeleiteter Aufträge
Ermöglicht das Ändern von Feldern von bereits in die MD-Premium.NET Finance übergeleiteten Aufträgen. Dazu muss auf Tabellenebene eine logische Berechtigung für jenes Feld, das geändert werden soll, erstellt werden. Als Tabelle muss das LOG_ Äquivalent jener Tabelle verwendet werden, die das gewünschte Feld enthält. Das Zusammenfassen mehrerer Berechtigungen zu einer Benutzergruppe ist ebenfalls möglich.
Felder folgender Tabellen können nach Überleitung bearbeitet werden:
LOG_MDJOUBS_FIBU
LOG_MDJOUCH_FIBU
LOG_MDJOU_FIBU
LOG_MDPAKT_FIBU
LOG_MDBAKT_FIBU
LOG_MDFAKT_FIBU
Beispiel: Das Register Notiz (= Notiz3 in MdFakt) in bereits übergeleiteten Kundenaufträgen soll änderbar sein:

|
Liefersperre aufheben
PRM_NAME = CREDITLIMIT, REVOKE_KZ = 1
Bestellvorschlag erstellen und ändern
TABLE_NAME = MDARTBST, ACC_MODE = 1, REVOKE_KZ = 0
TABLE_NAME = MDARTBST, ACC_MODE = 2, REVOKE_KZ = 0
TABLE_NAME = MDARTBST, ACC_MODE = 3, REVOKE_KZ = 0
PRM_NAME = ART_ORDER_PROPOSAL, REVOKE_KZ = 0
Einstandspreis im Kundenauftrag unterdrücken
TABLE_NAME = MDFAKT_MDJOU, COLUMN_NAME = ESP, ACC_MODE = 0, REVOKE_KZ = 1
Einstandspreis in den Auftragspositionen generell unterdrücken
TABLE_NAME = MDJOU, COLUMN_NAME = ESP, ACC_MODE = 0, REVOKE_KZ = 1
|
|