AWE – Un AWE con Criterio

Fecha: 11 abril, 2020

Introducción

Empezamos preguntándonos ¿Qué es un criterio?. Algunos diccionarios lo definen de la siguiente manera:

  • Regla o norma conforme a la cual se establece un juicio o se toma una determinación: ‘falta de criterio; criterio de selección de candidatos’
  • Juicio o discernimiento
  • Juicio para discernir, clasificar o relacionar una cosa: ‘ese no es un buen criterio de clasificación’

Entonces el criterio se define como un conjunto de reglas, que nos permiten realizar una evaluación sobre algo determinado, con el objetivo de poder clasificar lo evaluado.

Dentro de la definición del circuito de aprobación, nos encontramos con la posibilidad de definir distintos criterios a fin de evaluar a la solicitud y determinar si cumple o no con las reglas establecidas. Si cumple significa que va a poder continuar con el circuito de aprobación.

//AWE – Un AWE con Criterio – Barrera de Criterios ESP

De esta manera el criterio actúa como una barrera, que va a dejar o no a la solicitud recorrer los distintos circuitos de aprobación. Existen 3 niveles de criterio que pueden definirse dentro del circuito de aprobación:

  • Nivel de Circuito
  • Nivel de Ruta
  • Nivel de Paso

Definiendo un Criterio

Tal como venimos mencionando, el criterio es una opción que se establece al momento de definir el circuito de aprobación. Este se hace desde la siguiente ruta:

Finanzas: Menú Principal > Componentes de Empresa > Aprobaciones > Aprobaciones > Definición Proceso Aprobación

Recursos Humanos: Menú Principal > Definir HRMS > Definiciones Comunes > Aprobaciones > Definición Proceso Aprobación

//AWE – Un AWE con Criterio – Definición de Proceso de Aprobación ESP

Como se observa en la imagen anterior, existen 3 niveles para definir un criterio y son totalmente independientes.

Criterio de Circuito: Un mismo proceso de aprobación puede tener definido distintos circuitos de aprobación. Pero una solicitud solo puede recorrer un único circuito. Es por esto que utiliza este criterio para evaluar la solicitud y determinar cual circuito debe ejecutar. Los criterios de aceptación de los distintos circuitos asociados a un proceso de aprobación deberían ser excluyentes, a fin de poder identificar un único circuito para cada solicitud. Si una solicitud cumpliera con el criterio de aceptación de dos o más circuitos, entonces AWE determinaría de manera unilateral cual ejecutar. Por otro lado, si la solicitud no cumpliera con el criterio de ningún circuito entonces, significará que la solicitud no requiere aprobación. No requiere aprobación NO es sinónimo de Aprobado automáticamente.

Criterio de Ruta: Cada Ruta tiene la posibilidad de definir un criterio, para ver si los pasos que incluye deben o no ser ejecutados. El criterio de cada ruta es independiente, y se evalúa en el momento en que la solicitud va a recorrer esa ruta.

Criterio de Paso: Cada paso tiene la posibilidad de definir un criterio, para ver si el paso debe ser ejecutado o no. El criterio de cada paso es independiente, y se evalúa en el momento que la solicitud va a transitar ese paso.

Por otro lado, al momento de definir un criterio existen 3 posibilidades a saber:

  • Criterio Verdadero
  • Criterio Introducido por el Usuario
  • Criterio Definido por Clase Aplicación

Criterio Verdadero

El criterio Siempre Verdadero, como lo indica su nombre, es aquel que siempre aceptará a la solicitud sin importar sus características. Este criterio es el que utilizaremos por defecto al momento de definir el circuito. Es importante siempre definir al menos un criterio, caso contrario el criterio se considerará ‘Siempre Falso’ y no aceptará a ninguna solicitud.

//AWE – Un AWE con Criterio – Criterio Siem Verdadero ESP

Criterio Introducido por el Usuario

Este criterio gana su nombre a partir de la premisa que un usuario lo puede configurar y definir. En lo personal creo que el nombre no se adecua al a realidad, dado que para definir este criterio el usuario debería entender qué es la tabla de referencia cruzada, cuales son las claves de la solicitud, y en que tabla o vista se encuentran los datos que utilizará para evaluar.

//AWE – Un AWE con Criterio – Criterio Introd pUsuario ESP

Como puede observar en la imagen, pueden definirse distintas reglas agregando líneas al Scroll ‘Crit Introd p/Usuario’. Dentro de este Scroll vamos a poder definir dos tipos de reglas, una a nivel de campo genérico y otra a nivel de campo monetario (permitiendo la conversión de moneda para evaluar el criterio). A continuación procedo a explicar los campos:

1. Cumplimento Todos Criterios: Este checkbox nos permitirá definir si el operador lógico que une todos los criterios es un AND o un OR. Si está tildado, significa que el criterio aceptará la solicitud si solo si esta cumple con todos los criterios introducidos. Si el campo no se encuentra tildado entonces bastará que la solicitud cumpla con al menos un criterio para ser aceptada.

2. Registro: Este campo identifica el registro que se utilizará para evaluar un campo determinado. El registro seleccionado será mapeado con el registro de referencia cruzada de la solicitud, igualando así las claves para encontrar una única línea del registro para evaluar. Entonces tenemos que tener en mente, que el registro utilizado (que puede ser una vista) debe traer para cada solicitud una única línea.
3. Nombre Campo: De los campos que tiene el registro seleccionado en 2), se seleccionará aquel que deseamos evaluar.
4. Operador Criterio: En este campo se define el operador que se desea utilizar para con el campo seleccionado en 3). Se pueden definir distintos criterios, por ejemplo: se solicita que el valor del campo no sea mayor que 100, pero a la vez, que el valor del campo no sea menor que 50. Para este ejemplo se deberán agregar dos líneas.
5. Valor: El campo valor es que se utilizará para evaluar el campo 3) de acuerdo al operador 4).

6. Registro Impte: Este campo identifica el registro que se utilizará para evaluar un campo monetario. El registro seleccionado (como en 2) ) será mapeado con el registro de referencia cruzada de la solicitud.
7. Cpo Importe: Este valor define que campo posee el valor monetario a ser evaluado, dentro de los campos que posee el registro 6).
8. Campo Moneda: Esta campo define cual de los campos del registro 6) posee el valor de la moneda en que se expresa el importe a ser evaluado definido en 7).
9. Operador: Este campo define el operador que se desea utilizar para evaluar el monto seleccionado por el campo 7).
10. Importe: En este campo se define el importe de referencia que actúa de acuerdo al operador definido en 9).
11. Moneda: En este campo se define la moneda en que se encuentra expresado el importe 10).
12. Cls Cambio: En este campo se define la clase que realizará la conversión de monedas entre el importe del campo 7) de acuerdo a su moneda 8) y el importe definido en 10) y su moneda 11). Es importante definir la clase ya que permitirá evaluar a la fecha del día, los valores en distintas monedas.

Criterio definido por Clase Aplicación

El último método para definir un criterio es el definido por una Clase de Aplicación.

//AWE – Un AWE con Criterio – Criterio Clase Aplicacion ESP

Para definir el criterio, debemos seleccionar el paquete de aplicación 1) y la clase 2) que definirán el criterio. Como lo explica la descripción de la imagen, la clase a utilizar debe cumplir con dos características:

  • Extender de la clase EOAW_CRITERIA:CriteriaBase
  • Implementar el método de comprobación Check: el método recibe como parámetro un registro que posee las claves del registro de referencia cruzada ,y debe retornar un valor Booleano de acuerdo a si acepta o no a la solicitud (true o false)

A continuación se deja un ejemplo de como debería ser implementada una case criterio:

import EOAW_CRITERIA:DEFINITION:*;
class Criterio extends EOAW_CRITERIA:DEFINITION:CriteriaBase
    method Criterio(&rec As Record);
    method Check(&thread_ As Record) Returns boolean;
end-class;

method Criterio
    /+ &rec as Record +/
    %Super = create EOAW_CRITERIA:DEFINITION:CriteriaBase(&rec.EOAWCRTA_ID.Value);
end-method;

method Check
    /+ &thread_ as Record +/
    /+ Returns Boolean +/
    /+ Extends/implements EOAW_CRITERIA:DEFINITION:CriteriaBase.Check +/

    Local Record &rXREF = CreateRecord(Record.XREF);
    &thread_.copyFieldsTo(rXREF);
    rXREF.selectByKey();

    /* Procesar Solicitud, evaluar valores, etc. */

    If ( CONDICION ) Then
        return true;
    Else
        return false;
    End-If;
end-method;

Palabras Finales

Como es costumbre me gusta dejar un pensamiento final para tener en cuenta…

Si no sabemos o no tenemos definido el criterio, siempre utilizamos el Siempre Verdadero (recordar que si no definimos ninguno, AWE considerará Siempre Falso).

Si los valores de referencia del criterio pueden cambiar a lo largo del tiempo (como ser topes monetarios), podemos utilizar el criterio Ingresado por el Usuario a fin de que el pueda cambiar los valores (pero debería ser un técnico el que defina el criterio inicialmente).

Finalmente si el criterio es muy complejo y tiene muchas condiciones, o bien creemos que podemos reutilizarlo a lo largo del mismo o distintos circuitos, recomiendo utilizar el definido por la Clase Aplicación (de esta manera el criterio se define una única vez).

Comentarios... ( 0 )

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *