Séminaire Autorisation

Séminaire Autorisation

Sommaire • Introduction • Concept des autorisations dans SIFAC • Définition des différents types de rôles • Présentation des autorisations livrées avec Sifac • Généralités sur les rôles souches • Matrice générale / matrice détaillée / listes des matrices détaillées • Méthodologie pour mettre en place les rôles • Définir les taches et les profils métiers • Préparation du fichier d’aide a la saisie • Charge de travail / Planning • Retour d’expérience de L’EHESP • Retour d’expérience des établissements de Montpellier • Mise en Œuvre technique des autorisations • Documentation • Conclusion

Introduction • Concept des autorisations dans SIFAC au niveau utilisateur • L’objectif des autorisations dans SIFAC : • Chaque utilisateur de SIFAC ne doit avoir que les accès nécessaires et suffisants afin d’effectuer ses tâches quotidiennes, tout en protégeant les données et les transactions d’une utilisation non souhaitée. • Les autorisations sont gérées via des rôles. • Mise en œuvre des autorisations dans SIFAC • Chaque utilisateur a un accès au système SAP • Aucune autorisation par défaut (droit de ne rien faire). • SIFAC permet de définir des droits d’accès différents pour chaque utilisateur

Les différents types de rôles • Différents types de rôles • Rôles simples • Rôles composites • Rôles souches • Rôles dérivés

Les différents types de rôles • Rôle simple Rôle Simple • Un rôle simple comprend un ensemble de transactions et d’objets d’autorisations nécessaires pour le bon fonctionnement des activités définies pour ce rôle. • La liste des transactions associées va permettre de délimiter un périmètre fonctionnel pour un rôle donné. • La liste des objets d’autorisations va permettre, pour une transaction, de délimiter un périmètre organisationnel(centre financier, centre de coût…). • La liste des objets d’autorisations dépend des transactions du rôle. Transaction 1 Ex : ME23N Transaction 2 Ex : ME21N Objet Autorisation 1 Ctrl société Valeurs autorisées Z100, Z200.. Objet Autorisation 2 Ctrl centre financier Valeurs autorisées 901* Objet Autorisation 3 Groupe Acheteur. Valeurs autorisées Z01 / Z02 / Z03

Les différents types de rôles SIFAC_AGENT_COMPTABLE_CPT SIFAC_AGENT_COMPTABLE_BUD SIFAC_AGENT_COMPTABLE_CPT_O2 FB01 MR8M FMKFR01 FB02 FMRP_RW… MIRO Société Société Périmètre financier Centre financier Centre financier Périmètre financier Périmètre financier • Rôle composite • C’est un regroupement de plusieurs rôles simples(comparable à un dossier ou une enveloppe). L’utilisateur qui reçoit le rôle composite se voit attribuer les droits cumulés des 3 rôles simples dans l’exemple. • Dans le cadre de SIFAC, les rôles composites ont été créés par profil métier (Agent comptable, gestionnaire CR …). • Exemples de Rôles composites SIFAC : on peut voir que le rôle composite SIFAC_AGENT_COMPTABLE_HMAND_O2 est composé de 3 rôles simples SIFAC_AGENT_COMPTABLE_HMAND_02 (Agent Comptable)

Les différents types de rôles • Ce sont tous les rôles simples et composites propres à SIFAClivrés avec la souche. Ils ont été conçus par l’équipe projet SIFAC. • Pour tous les rôles souches, seul lepérimètre fonctionnelest géré(liste des transactions). Les valeurs des objets d’autorisations permettant du périmètre organisationnel (société, cf..) ont été initialisées à ‘*’ce qui signifie qu’il n’y a aucune restriction. • Les rôles souches sont identifiables par leurs noms, ils commencent tous par SIFAC_ ….. • Si on applique un rôle souche « Gestionnaire CR » tel quel à un utilisateur, cela veut donc dire que cet utilisateur ne pourra accéder qu’à certaines transactions (ex : création de commandes) mais il pourra créer des commandes sur tous les niveaux organisationnels (toutes sociétés, tous les centres financiers…). • Exemple de rôles souche : SIFAC_GESTIONNAIRE_AGENT_MIS • Rôles souches transactions SIFAC_GESTIONNAIRE_AGENT_MIS PRMS – Afficher les données de base du personnel ZSIFAC_TRANSFO_AGFRS – Transformation des agents en fournisseur objets Société Valeurs autorisées *

Les différents types de rôles transactions FB01 objets SOCIETE * Z12_SIFAC_AGENT_COMPTA_CPT_Z100 Z12_SIFAC_AGENT_COMPTA_CPT_Z200 transactions transactions FB01 FB01 Z200 Z100 objets objets SOCIETE SOCIETE Autorisation de créer une pièce comptable sur la société Z200 Autorisation de créer une pièce comptable sur la société Z100 Rôle souche : SIFAC_AGENT_COMPTABLE_CPT • Rôle dérivé • Pour gérer le périmètre organisationnel d’un rôle, il est nécessaire de dériver un rôle souche. Ce nouveau rôle appelé rôle dérivé va alors hériter automatiquement du périmètre fonctionnel (liste des transactions autorisées) du rôle souche. • Sur ce rôle dérivé, on va alors gérer le périmètre organisationnel, ce qui revient à affecter des valeurs aux objets d’autorisation. • Intérêt de la dérivation : il n’est pas possible de rajouter des transactions dans des rôles dérivés. Ainsi il n’y a pas d’écart fonctionnel possible entre le rôle soucheet le ou les rôles dérivés. • Seuls les rôles simples peuvent être dérivés. Valeur de l’objet Dérivation Rôles dérivés Valeur de l’objet

Les différents types de rôles * Z1 Z2 Z3 Z100 Z200 Role Souche 1 Role Souche 2 • Affectation aux utilisateurs * • Une fois que les rôles souches ont été dérivés, on peut alors les affecter aux utilisateurs. • Le travail de dérivation à partir des rôles souchesainsi que l’affectation aux utilisateurs sera à la charge de l’établissement. Rôle dérivé 1 Rôle dérivé 2 Rôle dérivé 3 Rôle dérivé 4 Rôle dérivé 5 Utilisateurs

SYNTHESE : Les différents types de rôles FB01 SOCIETE * FB01 SOCIETE Z300 Rôles souches • Seul le périmètre fonctionnel est géré (transactions). • Le périmètre organisationnel (objets autorisation) est renseigné à * Cas exceptionnel (ex : rôle technique) Dérivation À la charge de l’établissement Rôles dérivés • Gestion du périmètre organisationnel sur les rôles dérivés Affectation À la charge de l’établissement Utilisateurs • Affectation des rôles aux utilisateurs (relation n/n) Il n’y a pas de dérivation des rôles composites (enveloppes), il suffit de copier ou recréer une rôle composite avec le nom adéquat si pour plus de lisibilité les rôles dérivés doivent être regroupés

Présentation des autorisations livrées avec SIFAC Généralités sur les rôles souches : • Une centaine de rôles souches ont été conçus par le groupe projet et enrichis au fur et à mesure des vagues de déploiement. • Ils ont fait l’objet de réflexion durant les ateliers pour s’adapter le mieux possible aux organisations des universités. • Certains rôles souches dépendent du choix de la modélisation (Service fait valorisé ou Service fait non valorisé). • Toutes les informations sur les rôles souches se trouvent sur l’espace SIFAC dans : Partage de fichier / Documentation SIFAC/02_Technique/05_Gestion_des_Autorisations/03_Matrices_souche A / Les rôles souches ont été classés par profil métier (ex : Agent comptable) dans un fichier Excel « liste des rôles » SIFAC-DCD-GDA-Annexe-Liste-des-roles-V1.20xls. B / Un classement complémentaire a été fait de manière détaillée par domaine (ex : dépense). Chaque domaine est détaillée comme ci-dessous. SIFAC-DCD-GDA-Matrice-BUD-v1.15.xls (Budget) SIFAC-DCD-GDA-Matrice-CPA-v1.12.xls (Compta Analytique) SIFAC-DCD-GDA-Matrice-CPT-v1.18.xls (Compta ) SIFAC-DCD-GDA-Matrice-CPT-Regie-v1.0.xls (Régie) SIFAC-DCD-GDA-Matrice-DEP-v1.20.xls (Dépense) SIFAC-DCD-GDA-Matrice-MIS-v1.20.xls (Mission) SIFAC-DCD-GDA-Matrice-REC-v1.13.xls (Recette) SIFAC-DCD-GDA-Matrice-STA-v1.2.xls (Stage) SIFAC-DCD-GDA-Matrice-TECH-v1.8.xls (Technique)

Présentation des autorisations livrées avec SIFAC A / Matrice liste des rôles souches : explication Classement par profil métier (sifac-DCD-GDA-annexe-liste des roles-v1.20.xls) Le rôle concerne le domaine indiqué par une croix Profil métier selon options Profil métier

Présentation des autorisations livrées avec SIFAC B / Les Matrices détaillées : explications • Les matrices détaillées répertorient les rôles par domaine (ex : dépense), et liste les transactions affectées à chaque rôle. • La matrice (dépense DCD-GDA-MatriceDEP-v1.20.xls) permet de faire un lien entre les transactions (dépense), et le ou les rôles souches dans lesquels on retrouve ces transactions. Tâche Cette transaction est présente dans ce rôle simple Tâche détaillée

Sommaire • Présentation technique des autorisations • Lien entre Transaction et objet d’autorisation • Lien entre Rôle, Transaction et objet d’autorisation • Mécanisme de dérivation • Attribution des rôles aux utilisateurs • Mécanisme de contrôle des autorisations • Transaction PFCG • Présentation de la transaction PFCG • Exemple de dérivation de rôle via PFCG • Affectation des rôles aux utilisateurs

Sommaire • Mise en œuvre technique des autorisations • Transport entre environnements • Mécanisme de mise à jour des autorisations • Transactions utiles • Points importants

Mise en Œuvre technique des autorisations • Présentation technique des autorisations

Mise en Œuvre technique des autorisations • Rappel de la structure d’un rôle Rôle Simple • Un rôle simple comprend un ensemble de transactions et d’objets d’autorisations nécessaires pour le bon fonctionnement des activités définies pour ce rôle. • La liste des transactions associées va permettre de délimiter un périmètre fonctionnel pour un rôle donné. • La liste des objets d’autorisations va permettre, pour une transaction, de délimiter un périmètre organisationnel (société, UB, centre financier…) • La liste des objets d’autorisations dépend des transactions du rôle Transaction 1 Ex : VA01 Transaction 2 Ex : ME21N Objet Autorisation 1 Ctrl société Valeurs autorisées Z100, Z200.. Objet Autorisation 2 Ctrl centre financier Valeurs autorisées 901* Objet Autorisation 3 Ctrl Domaine comm. Valeurs autorisées Z100 / Z1 / Z1

Mise en Œuvre technique des autorisations • Lien entre Transaction et objet d’autorisation • Dans chaque transaction SAP, des contrôles d’autorisations ont été codé. Ces contrôles d’autorisations se font via les objets d’autorisations. Ces contrôles se font via l’utilisation de modules fonctions (authority_check par exemple) ou de méthodes qui prennent en paramètre : • Le nom de l’objet d’autorisation que l’on veut contrôler • Les valeurs d’autorisations à contrôler pour cet objet. Transaction 1 Ex : VA01 (commande de vente) Transaction 2 Ex : FB01 (écriture comptable) Objet Autorisation 6 Ctrl société Objet Autorisation 5 Ctrl société Objet Autorisation 5 Ctrl société Objet Autorisation 4 Ctrl société Objet Autorisation 4 Ctrl société Objet Autorisation3 Ctrl société Objet Autorisation 3 Ctrl société Objet Autorisation 2 Ctrl société Objet Autorisation 2 Ctrl société Objet Autorisation 1 Ctrl sur le type de pîèce Objet Autorisation 1 Ctrl société

Mise en Œuvre technique des autorisations • Lien entre Rôle, Transaction et objet d’autorisation • La création d’un rôle commence par l’identification des transactions à lui affecter. • Une fois la liste des transactions affectée, le système va alors automatiquement nous fournir tous les objets d’autorisations qui ont été implémentés dans ces transactions Role Ex : affectation des transactions VA01 et FB01 Objet Autorisation 6 Ctrl société Objet Autorisation 5 Ctrl société Objet Autorisation 4 Ctrl société Exemple : Création d’un rôle contenant les transactions VA01 et FB01 : Tous les objets d’autorisations de ces 2 transactions sont alors remontés dans le rôle Objet Autorisation 3 Ctrl société Objet Autorisation 2 Ctrl société Objet Autorisation 1 Ctrl société Objet Autorisation 5 Ctrl société Objet Autorisation 4 Ctrl société Objet Autorisation3 Ctrl société Objet Autorisation 2 Ctrl société Objet Autorisation 1 Ctrl sur le type de pîèce

Mise en Œuvre technique des autorisations • Ce n’est pas parce qu’un objet d’autorisation est présent dans un rôle que le contrôle d’autorisation se fera sur toutes les transactions présentes dans ce rôle. Le déclenchement d’un contrôle d’autorisation se fait via l’algorithme du programme et non via la présence d’un objet d’autorisation dans un rôle Role Ex : affectation des transactions VA01 et FB01 • Si un même objet d’autorisation (même nom d’objet) est présent dans plusieurs transactions d’un même rôle, on ne pourra pas dissocier le contrôle fait sur une transaction ou sur l’autre (1 société différente par transaction…) Objet Autorisation 6 Ctrl société Objet Autorisation 5 Ctrl société Objet Autorisation 4 Ctrl société Objet Autorisation 3 Ctrl société Objet Autorisation 2 Ctrl société Objet Autorisation 1 Ctrl société Objet Autorisation 5 Ctrl société Objet Autorisation 4 Ctrl société Objet Autorisation3 Ctrl société Objet Autorisation 2 Ctrl société Objet Autorisation 1 Ctrl sur le type de pîèce

Mise en Œuvre technique des autorisations • Mécanisme de dérivation

Mise en Œuvre technique des autorisations transactions FB01 objets SOCIETE * Z12_SIFAC_GEST_COMPTA_GEN_CPT_0001 Z12_SIFAC_GEST_COMPTA_GEN_CPT_0003 transactions transactions FB01 FB01 Z200 Z100 objets objets SOCIETE SOCIETE Autorisation de créer une pièce comptable sur la société Z200 Autorisation de créer une pièce comptable sur la société Z100 Rappel du principe de dérivation Rôle Maître Valeur de l’objet Dérivation Rôles Dérivés Valeur de l’objet

Mise en Œuvre technique des autorisations Nom de l’objet • Détail d’un objet d’autorisation • Un objet d’autorisation est identifié via un nom d’objet : F_FICA_CTR, F_BKPF_BUK … • Un objet d’autorisation n’est pas toujours pas composé d’une seule zone mais de plusieurs. Chaque zone va correspondre à un paramètre lors de l’appel du contrôle d’autorisation par une transaction. • Parmi ces paramètres, il y a 2 catégories : • Les paramètres de niveaux organisationnels (société, CF …) • Les ‘autres’ (type de commande, activité…) • Les champs de niveau organisationnel devront être obligatoirement gérés dans chaque rôle alors que la gestion des autres champs est facultative. Nom d’un paramètre

Mise en Œuvre technique des autorisations • Détail d’un objet d’autorisation (suite) • Les champs de niveau organisationnel devront être obligatoirement gérés dans chaque rôle alors que la gestion des autres champs est facultative. • Lors de la livraison d’un rôle SIFAC, certains paramètres sont déjà renseignés (activité par exemple) • Dans le cadre du projet Sifac, seul les paramètres de type organisationnel (société, CF…) sont gérés. Tous les autres paramètres seront automatiquement renseignés dans les rôles Sifac Exemple de paramètre d’un objet d’autorisation pré-alimenté dans un rôle SIFAC

Mise en Œuvre technique des autorisations Rôle dérivé 1 Rôle dérivé 2 PR05 PR05 activité activité * * Périmètre Financier Périmètre Financier Z100 Z100 F_FICA_CTR F_FICA_CTR Centre Financier Centre Financier 902 901 • Lors de la dérivation d’un rôle, on affecte des valeurs aux zones de type Organisationnel (société, cf…) Un utilisateur avec ce rôle pourra créer une mission sur les agents créés sur un CF901 Un utilisateur avec ce rôle pourra créer une mission sur les agents créés sur un CF902

Mise en Œuvre technique des autorisations • Attribution des rôles à un utilisateur

Mise en Œuvre technique des autorisations Rôle dérivé 1 PR05 actvt * F_FICA_CTR Per Fi Z100 CF 901 F_FICA_CTR * / Z100 / 901 M_BEST_WRK * / Z200 F_BKPF_BUK * / Z100 S_TCODE PR05 S_TCODE ME21N S_TCODE VA01 Rôle dérivé 2 Rôle dérivé 3 ME21N VA01 actvt * actvt * M_BEST_WRK Div Z200 F_BKPF_BUK Soc Z100 • Lors de l’attribution du rôle à un utilisateur, celui-ci reçoit alors l’ensemble de ses objets d’autorisations qui vont se cumuler avec ceux hérités de ses autres rôles. • Les transactions autorisées sont gérées via l’objet d’autorisation S_TCODE • La transaction SU56 permet de connaître tous les objets d’autorisations pour un utilisateur. Affectation des 3 rôles à un utilisateur

Mise en Œuvre technique des autorisations Rôle dérivé 1 Rôle dérivé 2 PR05 ME21N activité activité * * Périmètre Financier Périmètre Financier Z100 Z100 F_FICA_CTR F_FICA_CTR Centre Financier Centre Financier 902 901 • Si, dans 2 rôles différents, 2 transactions font appel au même objet d’autorisation (même nom), l’utilisateur aura accès au cumul des valeurs positionnées sur cet objet. PR05 : Création d’une mission ME21N : Création d’une commande d’achat

Mise en Œuvre technique des autorisations Rôle dérivé 2 ME21N actvt * F_FICA_CTR Per Fi Z100 CF 902 Rôle dérivé 1 PR05 actvt * F_FICA_CTR Per Fi Z100 CF 901 • Dans cet exemple, l’utilisateur pourra donc créer des missions et des commandes d’achats sur les CF 901 ET 902. F_FICA_CTR 901 F_FICA_CTR 902 S_TCODE PR05 S_TCODE ME21N

Mise en Œuvre technique des autorisations • Mécanisme de contrôle des autorisations

Mise en Œuvre technique des autorisations F_FICA_CTR * / Z100 / 901 M_BEST_WRK * / Z200 F_BKPF_BUK * / Z100 S_TCODE PR05 S_TCODE ME21N S_TCODE VA01 • A chaque lancement d’une transaction par un utilisateur, le système va déclencher des contrôles d’autorisations. A partir des données saisies à l’écran, le système va alors lire le profil de l’utilisateur et vérifier qu’il a les droits nécessaires sur chaque objet rencontré : Lancement d’une transaction Vérification que l’utilisateur a bien l’objet d’autorisation F_BKPF_BUK demandé dans un des ses rôles et qu’il a bien la valeur 01 / Z100associée contrôle d’autorisation sur un objet de cette transaction Lecture des rôles affectés a l’utilisateur. F_BKPF_BUK 01 / Z100 Nom de l’objet à contrôler Valeur saisie à l’écran Ok ? NON Message d’erreur OUI Poursuite du programme

Mise en Œuvre technique des autorisations Exemple : Un utilisateur veut créer une commande sur le domaine commercial Z200 Z1 Z1 Lancement VA01 Contrôle objet S_TCODE • L’utilisateur a-t-il l’objet S_TCODE dans sa fiche avec les paramètres suivant : • TCD = ‘VA01’ Contexte utilisateur S_TCODE Ok ? NON OUI Message Lancement du 1er écran de saisie de commande L’utilisateur saisie les valeurs Z200 Z1 Z1 dans le domaine commercial puis valide Contrôle objet V_VBAK_VKO Contexte utilisateur V_VBAK_VKO • L’utilisateur a-t-il l’objet V_VBAK_VKO dans sa fiche avec les paramètres suivant : • VKORG = ‘Z200’ • VTWEG = ‘Z1’ • SPART = ‘Z1’ • ACTVT = ’01’ ( création ) Ok ? NON OUI Message

Mise en Œuvre technique des autorisations • Présentation de la PFCG

Mise en Œuvre technique des autorisations • Profil Generator (Transaction PFCG) • Le PG aide l’administrateur des autorisations à créer, générer et assigner les profils d’autorisation. Toute la gestion des autorisations est centralisée dans la transaction PFCG. • L’administrateur sélectionne les transactions à assigner à un rôle. Les objets d’autorisations dépendants sont automatiquement générés et groupés dans des profils d’autorisations. • Le PG permet de gérer les composants suivants : • Les rôles simples • Les rôles composites • Les rôles dérivés • Les assignations aux utilisateurs

Mise en Œuvre technique des autorisations Permet de créer un rôle simple Permet de modifier un rôle simple ou composite déjà existant Permet d’afficher un rôle simple ou composite déjà existant Permet de créer un rôle composite

Mise en Œuvre technique des autorisations Identifiant du rôle Identifiant du rôle « maître » si on est sur un rôle dérivé Descriptif du rôle

Mise en Œuvre technique des autorisations Liste des transactions sélectionnées

Mise en Œuvre technique des autorisations Pour afficher/modifier les données d’autorisations

Mise en Œuvre technique des autorisations Classe d’objet : SD Objet d’autorisation : V_VBAK_VKO Autorisation : T-RC72004600 Champs d’autorisation : ACTVT, SPART, VKORG, VTWEG Valeur des champs d’autorisation

Mise en Œuvre technique des autorisations Permet de lister chaque transaction où est utilisé ce champ d’autorisation

Mise en Œuvre technique des autorisations • Ce n’est pas parce que le niveau organisationnel apparait dans la fenêtre qu’il est géré sur toutes les transactions du rôle. Il faut s’assurer que l’objet est bien géré dans la transaction. Permet de gérer, de manière centralisée, tous les objets d’autorisations comportant en paramètre des données organisationnelles

Mise en Œuvre technique des autorisations Permet de gérer les valeurs du champ d’autorisation

Mise en Œuvre technique des autorisations Permet de gérer, de manière centralisée, tous les objets d’autorisations en leur affectant la valeur ‘*’ • Après avoir géré tous les objets de niveau organisationnel, il est important de faire passer tous les voyants au ‘vert’ via cette fonction centralisée. En effet, même si en théorie les voyants ‘non verts’ portent sur des objets facultatifs à gérer, il se peut que ces objets soient quand même testés dans les programmes et entrainent des problèmes d’autorisations.

Mise en Œuvre technique des autorisations Exemple de problèmes possibles : Transaction XD03 (affichage d’un client) L’objet Client : autorisation pour groupe de comptes n’est pas géré (voyant orange) Lancement de la transaction XD03 : Problème d’autorisation

Mise en Œuvre technique des autorisations Gestion de l’objet Client : autorisation pr groupe de comptes: L’objet Client : autorisation pour groupe de comptes est maintenant géré avec la valeur ‘*’ Lancement de la transaction XD03 : Le client est correctement affiché

Mise en Œuvre technique des autorisations Permet d’affecter des utilisateurs pour ce rôle

Mise en Œuvre technique des autorisations • Exemple de dérivation d’un rôle via la transaction PFCG

Séminaire Autorisation