Ejemplos de políticas de aprobación

Ejemplo 1: Política de aprobación de nivel de aplicación

En primer lugar, echemos un vistazo a un sencillo ejemplo para mostrar el funcionamiento de las aprobaciones en un nivel básico. En este ejemplo, aparece una política de aprobación de nivel de aplicación en la que se indica que al menos dos personas del grupo Gobierno de libro mayor deben aprobar todos los cambios realizados en el plan de cuentas.

El grupo Gobierno de libro mayor está compuesto por Barry, Julie y Jane. Tom es el propietario de la aplicación Fusion GL.

Flujo de trabajo de aprobación:

1. Mark envía una solicitud para agregar una cuenta y actualizar la descripción de un centro de costes.
2. Puesto que el método de aprobación es paralelo, se envía una solicitud a los tres miembros del grupo Gobierno de libro mayor para su aprobación.
3. Julie aprueba la solicitud.
4. Barry aprueba la solicitud.
5. Se cumplen los requisitos de la política y se acepta la solicitud.

Ejemplo 2: Escalada de interbloqueo

Ahora, volveremos a utilizar el mismo ejemplo, pero esta vez se ha trasladado a Barry y a Jane fuera del grupo Gobierno de libro mayor.

El grupo Gobierno de libro mayor está compuesto solo por Julie. Tom es el propietario de la aplicación Fusion GL.

Flujo de trabajo de aprobación:

1. Mark envía una solicitud para agregar una cuenta y actualizar la descripción de un centro de costes.
2. Se envía una solicitud de aprobación a Julie.
3. Julie aprueba la solicitud.

   Aunque la política requiere dos aprobadores del grupo Gobierno de libro mayor, Julie es la única persona de ese grupo. Por tanto, como no hay más aprobadores disponibles para cumplir los requisitos de la política, se produce un interbloqueo. Como resultado, la solicitud se escala a los usuarios que tengan el permiso Gestor de datos en la aplicación. Puesto que Tom es el propietario de la aplicación, su permiso de Propietario incluye el de Gestor de datos.

4. Se escala la solicitud a Tom.
5. Tom aprueba la solicitud.
6. Se cumplen los requisitos de la política y se acepta la solicitud.

Ejemplo 3: Política de aprobación en serie de nivel de dimensión

A continuación, vamos a analizar una política de tipo en serie de nivel de dimensión. En este ejemplo, Josh debe aprobar la solicitud, después debe hacerlo Frank y, por último, alguien del grupo Contabilidad.

El grupo Contabilidad está compuesto por James y Heather.

Flujo de trabajo de aprobación:

1. Mark envía una solicitud para mover tres cuentas.
2. Se envía una solicitud de aprobación a Josh.
3. Josh aprueba la solicitud.
4. Se envía una solicitud de aprobación a Frank.
5. Frank aprueba la solicitud.
6. Las solicitudes de aprobación se envían al grupo Contabilidad (James y Heather).
7. Heather aprueba la solicitud.
8. Se cumplen los requisitos de la política y se acepta la solicitud.

Ejemplo 4: Política de aprobación de nivel de tipo de nodo y conjunto de jerarquías

Mientras que las políticas de aprobación de nivel de aplicación y dimensión se aplican en todas las acciones de solicitud, las políticas de nivel de tipo de nodo y conjunto de jerarquías lo hacen solo en acciones de solicitud específicas. Las políticas de un tipo de nodo se aplican solo a solicitudes que agregan o suprimen nodos, o bien que actualizan las propiedades del nodo. Las políticas de un conjunto de jerarquías se aplican solo a solicitudes que insertan, eliminan, mueven o reordenan nodos en un conjunto de jerarquías, o bien que actualizan las propiedades de relación de los nodos.

Para ilustrar dichos principios, vamos a consultar dos solicitudes de un ejemplo que dispone de políticas tanto de tipo de nodo como de conjunto de jerarquías. La primera solicitud actualiza una propiedad del nodo, por tanto, solo se aplica la política del nodo definido. La segunda solicitud agrega cuentas, acción que afecta tanto al tipo de nodo como al conjunto de jerarquías. Por tanto, se aplican ambas políticas.

Información adicional sobre estas solicitudes:

• El grupo Contabilidad está compuesto por James y Heather.
• El grupo TaxUsers está compuesto por Brian, Jane y Rachel.
• El grupo EssAdmins tiene siete administradores (de EssAdmin1 a EssAdmin7).

En primer lugar, echemos un vistazo a una solicitud para actualizar las propiedades del nodo. Las actualizaciones de las propiedades del nodo solo se ven afectadas por las políticas del tipo de nodo.

Flujo de trabajo de aprobación de la solicitud 1:

1. Mark envía una solicitud para actualizar tres descripciones de cuenta (actualización de propiedades del nodo).
2. Las solicitudes de aprobación se envían a los grupos Contabilidad y TaxUsers.

   Nota:

   Puesto que la actualización de propiedades de un nodo no afecta al conjunto de jerarquías, el grupo EssAdmins no obtiene una solicitud de aprobación.
3. James aprueba la solicitud del grupo Contabilidad.
4. Rachel aprueba la solicitud del grupo TaxUsers.
5. Se cumplen los requisitos de la política y se acepta la solicitud.

A continuación, analizaremos una segunda solicitud, esta vez para agregar nodos. Al igual que antes, se aplica la política de tipo de nodo porque la acción de solicitud agrega nodos. Sin embargo, en esta solicitud se aplica también la política de conjunto de jerarquías, ya que las acciones de adición crean acciones de inserción en puntos de vista basados en jerarquías.

Flujo de trabajo de aprobación de la solicitud 2:

1. Mark envía una solicitud para agregar tres cuentas nuevas.
2. Las solicitudes de aprobación se envían a los grupos Contabilidad y TaxUsers.
3. Puesto que una acción de adición en un punto de vista basado en jerarquías también crea acciones de inserción en el conjunto de jerarquías, las solicitudes de aprobación se envían también al grupo EssAdmins.
4. James aprueba la solicitud del grupo Contabilidad.

   Nota:

   Como James dispone del permiso Participante (lectura) implícito en el tipo de nodo pero no en el conjunto de jerarquías, debe aprobar la solicitud en el inspector de solicitud. Consulte Políticas y permisos.
5. Rachel aprueba la solicitud del grupo TaxUsers.

   Nota:

   Como Rachel dispone del permiso Participante (lectura) implícito en el tipo de nodo pero no en el conjunto de jerarquías, debe aprobar la solicitud en el inspector de solicitud. Consulte Políticas y permisos.
6. Cinco administradores de Essbase aprueban la solicitud.

   Nota:

   Como el grupo EssAdmins dispone del permiso Participante (lectura) implícito en el conjunto de jerarquías, también se les otorga el permiso Participante (lectura) implícito en el tipo de nodo. Pueden abrir una vista y explorar el conjunto de jerarquías para aprobar la solicitud. Consulte Políticas y permisos.
7. Se cumplen los requisitos de la política y se acepta la solicitud.

Ejemplo 5: Aprobación con enriquecimiento activado

Si el enriquecimiento está activado en una política de aprobación, los aprobadores con acceso Participante (escritura) en cualquier objeto de datos de la vista para la solicitud pueden modificar la solicitud antes de la aprobación.

En este ejemplo, se realiza una solicitud en una vista de mantenimiento con puntos de vista para tres aplicaciones: General Ledger, Planning y Consolidation. Cada aplicación tiene una política de aprobación en el nivel de aplicación, y las políticas de GL y Planning tienen el enriquecimiento activado.

Flujo de trabajo de aprobación:

1. Mark envía una solicitud para agregar un centro de costos en la aplicación de General Ledger.
2. Se envía una solicitud de aprobación a Josh, el administrador de General Ledger.
3. Josh enriquece la solicitud agregando el centro de costos a la aplicación de Planning y, a continuación, aprueba la solicitud para la aplicación de General Ledger.
4. Dado que Josh ha agregado un nodo a la aplicación de Planning, se activa la política de aprobación de Planning y se envía una solicitud de aprobación a Julie, la administradora de Planning.
5. Josh enriquece aún más la solicitud agregando el centro de costos a la aplicación de Consolidation y, a continuación, aprueba la solicitud para la aplicación de Planning.
6. Se activa la política de aprobación de Consolidation y se envía una solicitud de aprobación al grupo Contabilidad.
7. Barry, un miembro del grupo Contabilidad, aprueba la solicitud para la aplicación de Consolidation. Debido a que el reconocimiento no está activado en la política de Consolidation, Barry no puede seguir enriqueciendo la solicitud.
8. Como se cumplen los requisitos de política de todas las políticas de aprobación, se confirma la solicitud y se agrega el centro de costos a las tres aplicaciones.