AUTSW PERNR (HR : données de base - contrôle par matricule) 

Définition

Objet d'autorisation utilisé pour affecter plusieurs autorisations aux utilisateurs, afin de leur permettre d'accéder à leur propre matricule. Ces autorisations sont différentes de celles définies dans les profils P_ORGIN des utilisateurs. Si ce contrôle est activé et qu'un matricule a été affecté à l'utilisateur dans le système, il peut écraser directement tous les autres contrôles, exception faite de la méthode de contrôle. Ce contrôle n'a pas lieu si aucun matricule n'a été affecté à l'utilisateur ou si ce dernier accède à un autre matricule que le sien.

Vous pouvez affecter un matricule à un utilisateur à l'aide de l'infotype 0105, sous‑type 0001 (dans les versions précédentes, à l'aide de la vue V_T513A).

Structure

L'objet d'autorisation P_PERNR contient les zones suivantes, qui sont testées pendant un contrôle des autorisations :

Zone d'autorisation	Texte descriptif
AUTHC	Niveau d'autorisation
PSIGN	Interprétation de l'autorisation affectée
INFTY	Infotype
SUBTY	Sous‑type

Plus d'informations sur ces zones

La zone PSIGN (Interprétation de l'autorisation affectée) peut prendre les valeurs suivantes :

I : insertion (pour des autorisations supplémentaires)

E : exclusion (pour des autorisations à supprimer)

Exemple

Les contrôles des autorisations pour P_ORGIN et P_PERNR sont activés dans le système. En outre, il existe des affectations d'utilisateurs pour certains matricules.

L'utilisateur de notre exemple est affecté d'un matricule ; il est le gestionnaire responsable de l'infotype Rémunération de base (0008) d'un domaine du personnel (en d'autres termes, cet utilisateur dispose de l'autorisation P_ORGIN correspondante). Ce salarié devrait également être autorisé à afficher ses propres données, mais pas à modifier sa rémunération de base, indépendamment du domaine du personnel dont il est responsable. Les autorisations correspondantes pour l'objet d'autorisation P_PERNR doivent être configurées comme suit :

AUTHC = R, M

PSIGN = I

INFTY = *

SUBTY = *

 

AUTHC = W, S, D, E

PSIGN = E

INFTY = 0008

SUBTY = *

La première autorisation accorde au salarié l'autorisation de lecture pour tous les infotypes archivés sous son matricule. La seconde autorisation refuse l'autorisation d'écriture pour tous les enregistrements de données de l'infotype Rémunération de base (0008) archivé sous le matricule du salarié.

Les contrôles des autorisations pour tous les autres matricules et pour les autorisations d'écriture pour tous les infotypes (à l'exception de Rémunération de base (0008)) s'exécutent d'après P_ORGIN.

Comme les exemples ci‑dessous l'illustrent, il arrive que des autorisations incohérentes soient accordées.

Exemple 1 :

AUTHC = *

PSIGN = I

INFTY = 0014

SUBTY = M*

 

AUTHC = W, S, D, E

PSIGN = E

INFTY = 0014

SUBTY = *

La première autorisation accorde au salarié l'autorisation de lecture (AUTHC = R) pour l'infotype Ind./retenues permanentes  (0014), sous‑type M120, ce qui lui permet d'accéder aux données archivées sous son matricule. Dans ce cas, la seconde autorisation n'est pas pertinente.

La première autorisation accorde au salarié l'autorisation d'écriture (AUTHC = W) pour l'infotype Ind./retenues permanentes  (0014), sous‑type B030, ce qui l'empêche d'accéder aux données archivées sous son matricule. Dans ce cas, la première autorisation n'est pas pertinente.

La première autorisation accorde au salarié l'autorisation d'écriture pour l'infotype Ind/retenues permanentes  (0014), sous‑type M120, alors que la seconde autorisation la lui refuse. Dans cet exemple, la réponse système attendue est incertaine. D'après la documentation, la réponse système est non définie dans de tels cas. En réalité, le contrôle des autorisations refuse toujours l'autorisation dans les cas incertains : E primant sur I, l'autorisation n'est donc pas accordée.

Exemple 2 :

AUTHC = *

PSIGN = *

INFTY = *

SUBTY = *

Ce type d'autorisation répond, par exemple, aux besoins des super‑utilisateurs avec accès illimité. L'autorisation ci‑dessus est adaptée au cas d'un salarié souhaitant accéder à un infotype. Toutefois, comme il est possible de remplacer toute valeur par PSIGN = * et *, PSIGN et E peuvent également être interprétés comme I, ce qui peut aussi entraîner une situation non définie. Dans les versions précédentes, l'autorisation était rejetée selon la règle voulant que E primant sur I. Les super‑utilisateurs avec des matricules affectés ne pouvaient alors pas accéder à leur propre matricule. Les programmes ont depuis été modifiés et * est désormais interprété comme I et considéré comme primant sur E. En d'autres termes, * prime sur E, E a priorité sur I, d'où * est interprété comme I.

Comme précédemment indiqué dans l'exemple 1, la combinaison de différentes autorisations peut produire un résultat complexe. SAP recommandé donc d'éviter toute combinaison dans laquelle les autorisations P_PERNR peuvent être interprétées différemment pour la même combinaison de AUTHC (niveau d'autorisation), INFTY (infotype) et SUBTY (sous‑type).

Les erreurs liées aux cas complexes décrits ci‑dessus ne sont cependant pas les motifs les plus fréquents des demandes client. En fait, la supposition erronée que les autorisations par matricule ne sont pas sans conséquences sur les autorisations pour des matricules non affectés constitue la cause la plus fréquente. Ce n'est en réalité pas le cas du tout.

Si vous utilisez des autorisations par matricule, vous devez toujours commencer par configurer toutes les autorisations non liées aux matricules. Ceci fait, vous devez créer des autorisations d'accès différentes pour les matricules affectés aux utilisateurs disposant d'autorisations P_PERNR appropriées. Rien ne peut vous en empêcher, puisque les autorisations P_PERNR écrasent directement toutes les autres autorisations (exception faite de la méthode de contrôle).

Les contrôles des autorisations P_PERNR ne peuvent en aucun cas contourner la méthode de contrôle directement. À titre d'exemple, une méthode de contrôle est exécutée sur l'infotype Ind./retenues permanentes (0014) uniquement si l'autorisation P_PERNR correspondante (avec PSIGN = I) existe. Si une autorisation appropriée pour le sous‑type correspondant de l'infotype 0130 existe, elle peut servir efficacement à exécuter la méthode de contrôle.