Introducción
La lista de usuario es la herramienta que se encarga de definir, para un momento dado, quienes serán los operadores a cargo de la aprobación de un paso del circuito de aprobación. Si bien para definir un circuito se necesita tener creada la lista de usuarios previamente, me tomo el atrevimiento de explicarlos como temas separados a fin de poder concentrarnos mejor en las características que ofrece. La lista de usuarios se define desde la siguiente ruta:
Finanzas: Menú Principal > Componentes de Empresa > Aprobaciones > Aprobaciones > Definición Lista Usuarios
Recursos Humanos: Menú Principal > Definir HRMS > Definiciones Comunes > Aprobaciones > Definición Lista Usuarios
Como cualquier proceso la lista de usuarios tiene una entrada, realiza un procesamiento y genera una salida de datos. Entonces tiene como entrada de datos a la solicitud de aprobación con su estado actual, y genera como salida una lista de usuarios (que serán los aprobadores).
Existen 4 formas de determinar a los usuarios aprobadores y estas son:
- Rol
- Definición SQL
- Consulta
- Clase de Aplicación
1 – Rol
La definición por Rol nos permitirá seleccionar como aprobador a todos aquellos usuarios que dentro de su parametría de seguridad cuenten con un Rol determinado. La parametría de seguridad por usuario se define en el la siguiente ruta:
Menú Principal > PeopleTools > Seguridad > Perfiles de Usuarios > Perfiles de Usuario
Si el usuario tiene el rol definido en la lista de usuarios, entonces será seleccionado como aprobador.
Por otra parte se pueden definir los atributos de Control de Ruta. El control de ruta se utiliza para clasificar al conjunto de usuarios que poseen el Rol definido, por algún atributo en particular (por ejemplo la Unidad de Negocios). La idea es filtrar dentro del conjunto de usuarios que poseen el rol definido, a aquellos que posean un atributo en particular que se relaciona con algún dato de la transacción. A
Tomaremos como caso de estudio una empresa que se encuentra dividida en sucursales, donde cada sucursal tiene empleados que pueden cargar una transacción y un gerente por sucursal que debe aprobarla. La solicitud debe ser aprobada únicamente por el gerente de la sucursal desde donde se originó la transacción. Para definir a los aprobadores podemos utilizar la lista de usuarios por rol, definiendo un rol para los gerentes de sucursal. Así cuando se genere una transacción y se envíe la solicitud de aprobación, la lista de usuarios seleccionará a todos los operadores que posean ese rol de gerente. Pero en este caso, queremos que solo se seleccione a aquel operador que sea gerente de la sucursal que originó la transacción. Para ello utilizamos el control de ruta, para decirle a la lista de usuario de que sucursal es cada operador y a que sucursal pertenece esa transacción.
Para utilizar el control de ruta debe estar predefinido:
- la categoría o tipo de control de ruta (clasificación)
- los perfiles o valores que puede adoptar una solicitud/transacción (clase)
- la asociación de estos perfiles a los usuarios
La categoría o tipo de control se define la siguiente ruta:
Menú Principal > PeopleTools > Workflow > Rutas y Roles > Tipos de Control de Rutas
A continuación se explica que información se completa en cada campo:
1. Tipo Control Ruta: Identifica al control de ruta, es un literal que será utilizado como clave (para nuestro ejemplo sería SUCURSAL).
2. Tabla Validación: Se define aquí la tabla de catálogo (o tabla maestra) que contiene los valores del atributo de clasificación. Será utilizada para controlar que los valores de la transacción se encuentren en ella (para nuestro ejemplo sería la tabla que lista las distintas sucursales).
Creado el tipo de control de ruta, tenemos que definir los distintos valores o perfiles que va a poseer. El perfil es la clase a la que pertenecerá una transacción, de acuerdo a su valor de control. En el ejemplo dado anteriormente tendríamos que crear un perfil por cada sucursal. El perfil se define desde la siguiente ruta:
Menú Principal > PeopleTools > Workflow > Rutas y Roles > Perfiles de Control de Rutas
A continuación se explica que información se completa en cada campo:
1. Perfil Control Ruta: Identifica al perfil, es un literal que será utilizado como clave. Acepta espacios en blanco. Recomiendo ser lo más descriptivo posible.
2. Tipo Control Ruta: Identifica al control de ruta. Aquí seleccionaremos la clasificación creada anteriormente.
3 y 4. Valor de Origen, Valor Dest: Se ingresará aquí el rango de valores que definirán al perfil. Cada transacción que posea un valor dentro de este rango, se considerará como perteneciente a este perfil. Vale aclarar que una transacción puede pertenecer a más de un perfil.
Definidos el tipo de control de ruta y los perfiles, restan dos pasos: A
El perfil se asocia desde la siguiente ruta:
Menú Principal > PeopleTools > Seguridad > Perfiles de Usuarios > Perfiles de Usuario
Para configurar el perfil se deberá:
- Seleccionar al operador.
- Ir al Tab de Roles, agregar el Rol y presionar sobre el Link Control de Ruta.
- Dentro del Control de Ruta, se selecciona el Perfil correspondiente.
Resta configurar la lista de usuarios.
A continuación se explica que información se completa en cada campo:
1. Lista Usuarios: Identifica a la lista de usuarios, es un literal que será utilizado como clave.
2. Nombre Rol: Identifica al Rol que se utilizará para seleccionar a los operadores como aprobadores.
3. Perfil Ruta Control: Se debe seleccionar un perfil de ruta de control que esté relacionado al tipo de control de ruta que deseamos utilizar. Identifica así por esta relación, al control de ruta que se utilizará para filtrar a los operadores. Podemos seleccionar cualquier perfil que utilice el tipo de control que deseamos. Puede resultar un poco confuso tener que seleccionar un perfil en lugar de un tipo, pero no vamos a cuestionar a PeopleSoft, simplemente nos adaptaremos.
4. Nombre Registro: Identifica al registro/tabla/vista que contiene el valor de clasificación de la transacción. Este registro deberá tener las claves de la transacción. Si consideramos el ejemplo expuesto, en este campo se utilizaría la tabla que guarda la información de la transacción donde reside el campo sucursal.
5. Nombre Campo: Identifica al campo que será evaluado para definir el perfil al que corresponde la solicitud/transacción de acuerdo al tipo de control de ruta. De acuerdo al ejemplo planteado, se debería identificar aquí al campo que posee el código/identificador de la sucursal.
Entonces cuando se ejecute un paso del circuito, verificará en primer lugar el paso y su lista de usuario relacionada. Al ser por rol, seleccionará a todos los operadores que posean el rol definido. Acto seguido, si es que está configurado el control de ruta, tomará el valor del perfil parametrizado y buscará el tipo de ruta de control definido. Luego obtendrá de la tabla definida, el valor del campo de clasificación. Se evaluará el valor, y se tratará de mapear con las condiciones de inicio y fin cargadas para todos los perfiles existentes para el tipo de ruta de control obtenido. Finalmente excluirá del listado de usuario que poseen el rol, a todos aquellos que no tengan definido los perfiles a los que pertenece la transacción.
2 – Definición SQL
La definición por SQL nos seleccionará como aprobador a todos aquellos usuarios que sean retornados por la ejecución del Objeto SQL.
A continuación se explica que información se completa en cada campo:
1. Lista Usuarios: Identifica a la lista de usuarios, es un literal que será utilizado como clave.
2. Identificador Objeto SQL: Identifica al Objeto SQL que se utilizará para seleccionar a los operadores como aprobadores (el objeto sql deberá ser creado desde el Application Designer).
3. Incluir Usuarios como Entrada: Indica si se utilizará el usuario originador de la solicitud de aprobación como parámetro en el Objeto SQL.
4. Claves Transacción como Entrd: Indica si se utilizarán las claves del registro de transacción (aquel que fuera definido en la transacción del AWE) como parámetros en el Objeto SQL.
El Objeto SQL debe cumplir con algunas características a saber:
- Debe retornar un único campo, y este debe contener el valor de los operadores que serán los aprobadores (preferentemente utilizar el campo OPRID).
- Si se incluyen los campos Usuario y/o Claves como entrada, los mismos serán utilizados dentro de la sentencia como parámetros de la siguiente manera:
SELECT A.OPRID
FROM %TABLE(PSOPRDEFN) A
,%TABLE(TRANSACTIONTABLE) B
WHERE B.TRANSACTIONID = :1
AND A.OPRID <> :2
AND ...
Los parámetros se mapearan utilizando como “bind” los dos puntos (:), y se enumeran a partir del ‘:1’ en adelante, teniendo en primer lugar las claves de la transacción (en el orden en que fueran definidas en la tabla de referencia cruzada) y por último el usuario originador de la solicitud. Por ejemplo si las claves de la transacción no se utilizan como entrada, entonces el ‘:1’ hará referencia al operador que originó la transacción.
3 – Consulta
La definición por Consulta nos seleccionará como aprobador a todos aquellos usuarios que sean retornados por la ejecución de la misma.
A continuación se explica que información se completa en cada campo:
1. Lista Usuarios: Identifica a la lista de usuarios, es un literal que será utilizado como clave.
2. Nombre Consulta: Identifica la Consulta que se utilizará para seleccionar a los operadores como aprobadores.
3. Incluir Usuarios como Entrada: Indica si se utilizará el usuario originador de la solicitud de aprobación como parámetro en la consulta.
4. Claves Transacción como Entrd: Indica si se utilizarán las claves del registro de transacción (aquel que fuera definido en la transacción del workflow) como parámetros en la consulta.
La Consulta debe cumplir con algunas características a saber:
- Debe retornar un único campo, y este debe contener el valor de los operadores que serán los aprobadores (utilizar el campo OPRID).
- Si se incluye el campo Usuario como entrada, deberá definirse un Prompt con el campo OPRID. Al momento de ejecutar la Consulta, este Prompt será llenado con el valor del operador que originó la solicitud de aprobación.
- Si se incluyen los campos Claves de la transacción como entrada, deberá crearse un Prompt por cada uno de ellos utilizando el mismo nombre del campo que existe en la tabla de la transacción.
4 – Clase de Aplicación
La definición por Clase de Aplicación nos permitirá seleccionar una lista de operadores a través de una clase. Esta clase deberá recibir ciertos parámetros de la solicitud, y en base a esta generará como salida un listado de operadores.
A continuación se explica que información se completa en cada campo:
1. Lista Usuarios: Identifica a la lista de usuarios, es un literal que será utilizado como clave.
2. ID Paquete Raiz: Identifica el Paquete de Aplicación donde recide la clase que queremos utilizar.
3. Ruta Clase Aplicación: Identifica la Clase que queremos utilizar para definir los aprobadores.
4. Incluir Usuarios como Entrada: Indica si se utilizará el usuario originador de la solicitud de aprobación como parámetro en la consulta.
5. Claves Transacción como Entrd: Indica si se utilizarán las claves del registro de transacción (aquel que fuera definido en la transacción del workflow) como parámetros en la consulta.
6. Nombre Atributo: Identifica el nombre de un atributo, es un literal que será utilizado como clave. Este atributo podrá luego ser tomado desde la clase, y utilizarlo a según se lo necesite.
7. Atributo 1: Identifica el primer valor que va a tomar ese atributo.
8. Atributo 2: Indica un segundo posible valor que va a tomar ese atributo.
La Clase debe cumplir con algunas características a saber:
- Debe extender de la clase EOAW_CORE:DEFN:UserListBase.
- El constructor de la clase debe recibir como parámetro un record. Este record en la ejecución será el registro de referencia cruzada.
- Debe implementar el método GetUsers, definido abstractamente en la clase EOAW_CORE:DEFN:UserListBase.
- El método GetUsers debe retornar un Array de Strings, donde cada valor es un operador aprobador.
A continuación se muestra un ejemplo de una clase:
import EOAW_CORE:DEFN:UserListBase;
class MiListaDeAprobadores extends EOAW_CORE:DEFN:UserListBase
method MiListaDeAprobadores(&rec_ As Record);
method GetUsers(&prevOprid As array of string, &recTxn As Record) Returns array of string;
private
instance Record &rParam;
end-class;
method MiListaDeAprobadores
/+ &rec_ as Record +/
&rParam = &rec_;
%Super = create EOAW_CORE:DEFN:UserListBase(&rec_);
end-method;
method GetUsers
/+ &prevOprid as Array of String, +/
/+ &recTxn as Record +/
/+ Returns Array of String +/
/+ Extends/implements EOAW_CORE:DEFN:UserListBase.GetUsers +/
Local array of string &arrOprid;
&arrOprid = CreateArrayRept("", 0);
/* Obtención de los operadores
*
* &arrOprid.Push(&sOprid);
*
*/
Return &arrOprid;
end-method;
Nótese que al utilizar peoplecode, nosotros tendremos la posibilidad de utilizar los valores definidos en la lista de usuario (ya sea si utiliza o no ciertos valores como entrada, o bien los atributos allí definidos). Esto nos permite utilizar la misma clase para distintas listas de usuario.
Notas Finales
Como puede observar, cada lista de usuario tiene sus ventajas y desventajas. También debe pensar en como está organizada la empresa donde se requiera implementar: por ejemplo, si la empresa cuenta con un área específica que administra los perfiles de los operadores, puede darse que configurar los perfiles para el control de ruta necesite de su participación. Por otro lado si utiliza una clase de aplicación, siempre va a requerir de un técnico para analizar y modificar la lista de usuarios.
En lo personal, recomiendo como siempre considerar todas las alternativas, y optar por aquella que solucione el problema de manera más simple.