Les exemples suivants illustrent des stratégies d'approbation au niveau de l'application, de la dimension, du type de noeud et de l'ensemble de hiérarchies. Ils montrent le traitement des approbations à l'aide de divers paramètres de stratégie.
Exemple 1 : stratégie d'approbation de niveau application
Tout d'abord, prenons un exemple simple pour démontrer le fonctionnement des approbations à un niveau basique. Dans cet exemple, il existe une stratégie d'approbation au niveau de l'application. Elle spécifie qu'au moins deux personnes du groupe GL Govern doivent approuver toutes les modifications apportées au plan de comptes.
Tableau 29-1 Exemple 1 : paramètres de stratégie de niveau application
Application Fusion GL | Dimension | Type de noeud | Ensemble de hiérarchies |
---|---|---|---|
Stratégie A
|
Dimension Compte | Type de noeud de compte | Ensemble de hiérarchies de compte |
Le groupe GL Govern se compose de Barry, Julie et Jane. Tom est le propriétaire de l'application Fusion GL.
Workflow d'approbation :
Exemple 2 : escalade pour cause de blocage
Prenons le même exemple, sauf que cette fois, Barry et Jane ont été exclus du groupe GL Govern.
Tableau 29-2 Exemple 2 : paramètres de stratégie avec escalade pour cause de blocage
Application Fusion GL | Dimension | Type de noeud | Ensemble de hiérarchies |
---|---|---|---|
Stratégie A
|
Dimension Compte | Type de noeud de compte | Ensemble de hiérarchies de compte |
Le groupe GL Govern se compose uniquement de Julie. Tom est le propriétaire de l'application Fusion GL.
Workflow d'approbation :
Bien que la stratégie exige deux approbateurs du groupe GL Govern, Julie est la seule personne dans ce groupe. Puisqu'il n'y a pas d'autre approbateur disponible pour remplir les critères de stratégie, la situation est bloquée. Par conséquent, la demande est remontée à des utilisateurs dotés de l'autorisation Gestionnaire de données pour l'application. Etant donné que Tom est le propriétaire de l'application, son autorisation Propriétaire inclut l'autorisation Gestionnaire de données.
Exemple 3 : stratégie d'approbation en série de niveau dimension
Maintenant, intéressons-nous à une stratégie en série au niveau de la dimension. Dans cet exemple, Josh doit approuver la demande en premier, puis Frank, et enfin une personne du groupe Accounting.
Tableau 29-3 Exemple 3 : paramètres de stratégie en série de niveau dimension
Application | Dimension | Type de noeud | Ensemble de hiérarchies |
---|---|---|---|
Application Planning |
Dimension Compte Stratégie A
|
Type de noeud de compte | Ensemble de hiérarchies de compte |
Le groupe Accounting se compose de James et Heather.
Workflow d'approbation :
Exemple 4 : stratégie d'approbation de niveau ensemble de hiérarchies et type de noeud
Alors que les stratégies d'approbation de niveau application et dimension s'appliquent à toutes les actions de demande, les stratégies de niveau ensemble de hiérarchies et type de noeud s'appliquent uniquement à certaines actions de demande. Les stratégies de type de noeud s'appliquent uniquement aux demandes qui ajoutent ou suppriment des noeuds, ou qui mettent à jour des propriétés de noeud. Les stratégies d'ensemble de hiérarchies s'appliquent uniquement aux demandes qui insèrent, enlèvent, déplacent ou réorganisent des noeuds dans un ensemble de hiérarchies, ou qui mettent à jour des propriétés de relation entre des noeuds.
Pour illustrer ces principes, prenons l'exemple de deux demandes dont les stratégies concernent à la fois le type de noeud et l'ensemble de hiérarchies. La première demande met à jour une propriété de noeud. Par conséquent, seule la stratégie sur l'ensemble de noeuds est appliquée. La seconde demande ajoute des comptes, avec un impact à la fois sur le type de noeud et l'ensemble de hiérarchies. Les deux stratégies sont donc appliquées.
Tableau 29-4 Exemple 4 : paramètres de stratégie de niveau ensemble de hiérarchies et type de noeud
Application | Dimension | Type de noeud | Ensemble de hiérarchies |
---|---|---|---|
Application Planning |
Dimension Compte |
Type de noeud de compte Stratégie A
|
Ensemble de hiérarchies de compte Stratégie B
|
Quelques informations supplémentaires sur ces demandes :
Tout d'abord, intéressons-nous à une demande de mise à jour des propriétés de noeud. Les mises à jour de propriétés de noeud sont régies uniquement par les stratégies de type de noeud.
Workflow d'approbation de la demande 1 :
Remarque :
Puisque la mise à jour des propriétés de noeud n'a aucun effet sur l'ensemble de hiérarchies, le groupe EssAdmins ne reçoit pas de demande d'approbation.Maintenant, intéressons-nous à une seconde demande, qui consiste cette fois à ajouter des noeuds. Comme auparavant, la stratégie de type de noeud est appliquée car l'action de la demande consiste à ajouter des noeuds. Toutefois, la stratégie d'ensemble de hiérarchies s'applique également car les actions d'ajout créent des actions d'insertion dans les points de vue hiérarchiques.
Workflow d'approbation de la demande 2 :
Remarque :
Etant donné que James possède une autorisation Participant (Lecture) implicite sur le type de noeud mais pas sur l'ensemble de hiérarchies, il doit approuver la demande dans l'inspecteur de demande. Reportez-vous à Stratégies et autorisations.Remarque :
Etant donné que Rachel possède une autorisation Participant (Lecture) implicite sur le type de noeud mais pas sur l'ensemble de hiérarchies, elle doit approuver la demande dans l'inspecteur de demande. Reportez-vous à la section Stratégies et autorisations.Remarque :
Etant donné que le groupe EssAdmins possède une autorisation Participant (Lecture) implicite sur l'ensemble de hiérarchies, il reçoit également une autorisation Participant (Lecture) implicite sur le type de noeud. Il peut ouvrir une vue et parcourir l'ensemble de hiérarchies pour approuver la demande. Reportez-vous à la section Stratégies et autorisations.Exemple 5 : approbation avec enrichissement activé
Si l'enrichissement est activé pour une stratégie d'approbation, les approbateurs dotés de l'accès Participant (Ecriture) sur un objet de données de la vue correspondant à la demande peuvent modifier cette dernière avant approbation.
Dans cet exemple, une demande est effectuée dans une vue de maintenance avec des points de vue pour trois applications : General Ledger, Planning et Consolidation. Chaque application comporte une stratégie d'approbation de niveau application, et l'enrichissement est activé dans les stratégies GL et Planning.
Tableau 29-5 Exemple 5 : approbation avec enrichissement
Application General Ledger | Application Planning | Application Consolidation |
---|---|---|
Stratégie d'approbation GL
|
Stratégie d'approbation Planning
|
Stratégie d'approbation Consolidation
|
Workflow d'approbation :