Introducción

El sistema xPay (ex Payroll) surge de la necesidad del área de la Dirección de Factor Humano de consolidar información de los empleados del organismo. La inflexibilidad del sistema Payroll motivó la necesidad de una mejora sustancial en el manejo de la información como así también integrar los datos del empleados para poder administrar los legajos en forma eficiente. xPay también corrigió muchos errores de diseño de la herramienta original que era muy limitada en cuanto a la integración de sus módulos. Una de estas deficiencias era que los datos no estaban temporalizados, es decir, que no constaban con fechas desde y hasta y resultaba imposible recrear la información del empleado a un período en particular.

La incorporación del xPay agregó mayor cantidad de atributos a las distintas herramientas como ser el módulo de Carrera que permitió consolidar toda la información sobre la trayectoria laboral del empleado, como así también producir un informe de liquidaciones para el área que consume esta información.

xPay se implementa como una gran extensión del Payroll siendo enteramente compatible con este desde la base de datos. La estrategia fue entonces la de obtener datos desde la base de datos de Payroll, incorporarlos al xPay y así hacer una transición sin mayores inconvenientes dado que los usuarios del sistema podían verificar los mismos datos que en la herramienta original.

El desarrollo del xPay se basó en la estructura de base de datos del xPay y entonces hubo que recrear toda la lógica subyacente. El mayor desafío fue la implementación del módulo de licencias que debió recrear todos los cálculos de las licencias compensatorias detalladas.

xPay supera ampliamente la muestra de datos del sistema original incorporando varios módulos como ser Discapacidad, Subsidios, entre otras herramientas. xPay también absorbe el sistema de visor de documentos digitales pudiendo integrar el legajo en papel directamente al perfil del empleado.

La incorporación del portal Mi Portal resulta estratégica ya que proveerá a los empleados la facilidad de acceder a sus datos personales, como así también solicitar licencias en línea eliminando la necesidad de presentar esta información en papel y liberando al área de licencias de la gestión de un trámite engorroso. Para esto xPay incorpora un flujo de aprobación de licencias que permite validar los datos solicitados por el usuario

Por otra parte la aplicación xPay muestra cómo es posible tener dos templates o “skins” de la misma herramienta: uno el xPay basado en ExtJS y el otro MiPortal basado en Boostrap, permitiendo dos caras de la misma aplicación donde residen las mismas reglas de negocio para dos interfaces distintas. Es decir que la validación de las licencias es realizada por la misma porción de código que será descrita más adelante.

Configuración de xPay: config.xml

El archivo de configuración del xPay muestra en general cómo se configuran las herramientas de la red del organismo. Además de los datos de la base de datos en este archivo destaca:

 

• la información del caché de la aplicación y del ACL (Access Control List)
• la configuración del servidor del LDAP para las claves de usuario
• la configuración del servidor de correo y los remitentes para el flujo de aprobación de licencias

 

 

Inclusión de la serialización del proyecto Payroll e inclusión en el xPay:

xPay serializa la estructura de la base de datos de Payroll, permitiéndo poder acceder en línea a los datos de esta aplicación. Para ello incluye la serialización con el comando “include” sin la necesidad de reescribir las estructuras. Es modo de refrerencia, la aplicación Payroll (llamada xPayroll) no tiene lógica en sí ni tampoco puede ser accedida en forma autónoma, solamente a través del xPay:

 

Sincronización periódica con Payroll

Para facilitar la migración, acostumbrar al usuario a los mismos datos pero a una herramienta diferente y reducir la curva de aprendizaje, xPay toma los datos de Payroll desde la base MSSQL en la cual está desarrollado y los sincroniza incorporándolos a la base de datos MySQL. Hubo que identificar tabla por tabla que datos eran necesarios de la herramienta orginal y a medida que se implementaban estos módulos en xPay la sincronización era desafectada tabla por tabla.

El script a continuación muestra la forma que tiene la herramienta de poder sincronizar desde el CRON del servidor, los parámetros de filtro para no sincronizar toda la tabla siempre (para casos de tablas muy grandes como ser RESUMEN) o bien ejecutar procesos de notificaciones cada 5 minutos. Requere de la configuración del crontab en el servidor donde reside la aplicación:

 

 

Jerarquía y acceso a los módulos con menú de perfiles de acceso

Una de las características principales del xPay es la riqueza de perfiles de usuarios que enlazan a toda la organización en forma transversal. Tanto los empleados como los integrantes del las áreas de recursos humanos, auditoría y el plenario en sí pueden acceder a la herramienta, esta riqueza se observa en la forma que está organizado el menú de la aplicación. Este archivo permitirá mostrar y ocultar distintos módulos, a su vez cada módulo posee las restricciones correspondientes de acceso tanto en la configuración del ACL como así también a través del método main_sql() donde se pueden aplicar filtros particulares. En el fragmento de código que sigue, la estructura del menú en menu.xml:

 

Cálculo de compensatorias vía SQL

El saldo de compensatorias se obtiene de realizar un JOIN entre la licencia, la compensatoria y la licencia que provee los días a compensar. Luego de una sumatoria agrupada por el grupo de la licencia denominado “compensatorias”, xPay provee la solución para obtener los saldos restantes. Este mecanismo permite identificar unívocamente que compensatoria compensa qué licencia. El llamado a la función SUM() provee los saldos como escalares:

Las licencias pueden ser cargadas interactivamente por el usuario, y estas a su vez pueden estar pendientes de aprobación o bien que hayan sido rechazadas o anuladas, es por ello que deben ser filtradas para que no afecten el resultado final de la sumatoria de compensatorias restantes:

 

Análisis detallado de compensatorias restantes para el área de Licencias a través del xPay

Adjunto un video explicativo para el usuario final y descriptivo para ver la operación del sistema:

 

Validación de Licencias

La carga de licencias tanto sea por el operador en el área administrativa correspondiente como el usuario que carga las licencia a través de miPortal deben estar previamente validadas. Hay una gran cantidad de validaciones que deben realizarse, en principio saldos restantes, límites de cantidad de días tomados al mes, al año o de una sola vez. La enumeración de las validaciones que se realizan son:

• Que tenga un tipo válido de licencia
• Que las fechas no estén invertidas
• Si son guardias o licencias que deban aplicar a guardias existentes
• Que las guardias se correspondan a días de feria
• Que no esté repetida la licencia para un mismo período, del mismo tipo y del mismo empleado
• Que sean superponibles, es decir, que puedan cohexistir en el mismo período de tiempo (con el campo “superponible” = sí)
• Que sean igual o menor a los días restantes
• Que estén dentro de los topes válidos

 

Estas validaciones son realizadas en el siguiente fragmento de código:

 

 

Los topes son provistos por la consulta  “s_licencia” con los totales de las compensatorias o los saldos por tipo de licencia.

 

Post proceso de las licencias

Una vez validadas y guardadas, en método post_check() se ejecutan nuevas acciones, en principio, las siguientes:

Si se está cargando una licencia compensatoria, se realizará un loop hasta que sean agotadas las compensatorias restantes por su saldo total (que era menor o igual a los días restantes se validó antes en el check() de la función. El listado de las compensatorias restantes es provisto por un lookup sobre la consulta “v_compensatoria” ordenado por fecha ascendente, así tomará las compensatorias más antiguas y proveer el cálculo adecuado.

 

 

Para las licencias que interrumpen feria ejecuta la funcion “consulta_interrumpe_feria()” que es un llamado a una consulta dentro de esa función. Esto agrega automáticamente un tipo de licencia que se llama “interrupción por feria” para ajustar los saldos en forma adecuada.

Por otra parte para las razones particulares en guardia, se debe descontar un día del stock de licencias compensatorias, ya que se efectúa la liquidación de esa licencia durante una feria, no computa entonces positivamente. Para ello se realiza un llamado a la función consulta_razones_particulares_en_guardia() que también posee una consulta SQL.

El uso de consultas SQL completas dentro del código PHP permite hacer las operaciones más rápidas y el código resulta independiente de la implementación.

 

 

en la opción “Tipos de Licencias” del xPay

http://xpay.jusbaires.gov.ar/xpay/?m=_t_licencia

con el campo “dias_prev” se configura con un número negativo cuantos días de plazo se tiene para solicitar una licencia ya tomada. El xPay permite especificar licencia por licencia cuantos días se permitirá solicitar una licencia ya tomada anterior.

El mantenimiento de estas variables resulta central para la operación de los límites y topes del sistema, deben gozar “de buena salud” y ser mantenidos cada vez que cambie la regulación marco de la solicitud de licencias.

 

 

Los días previos (dias_prev) son siempre negativos. Para los numeros positivos el sistema inhibira de cargar la licencia hacia el futuro.

Flujo de aprobación de licencias

El flujo de aprobación consiste en emular la cadena de autorizaciones que se da en un proceso manual ahora automático. El mecanismo en general consiste en sucesivas aprobaciones que son notificadas a través de correo electrónico. El usuario solicita la licencia a través del portal y se disparan los eventos que esto conlleva, en principio notificar al jefe inmediato superior que tiene una licencia para aprobar. EL sistema contempla varios niveles de aprobación:

• jefe inmediato
• jefe superior
• licencias (valida si la licencia es correcta)
• plenario (para aquellas licencias que lo requieran)

En los pasos está la posibilidad de aprobar el pedido como también de rechazar en todos los casos se notifica al interesado.

xPay tiene una función que se ocupa de implementar el flujo de aprobación del workflow. La función consiste básicamente en una secuencia if … else if … else, con una entrada por cada paso del workflow donde primero se valida (a través de la propia sentencia condición de if) y luego  se asignan los valores correspondientes, se notifica y se guarda el nuevo estado de la licencia. Cada bloque tienen estructuras similares (de acuerdo al tipo de validación) y termina con la remisión del email para “empujar” el flujo a su nuevo estadío.

 

 

Generación de Notificaciones para el Flujo de Aprobación de Licencias

La notificación en si es muy clara y fácil de mantener. Están separados los componentes para ofrecer flexibilidad al momento de realizar cambios. El código que sigue, parte del controlador ejecutándose es una función que genera la notificación, que será grabada en un registro hasta que un proceso en el CRON envíe las notificaciones (hay que configurar el sistema operativo, el archivo /etc/crontab o similar para poder activar esto) cada 5 minutos.

La función específica de generar la notificación serializa el objeto actual (una licencia) y la transforma con un template (miportal/licencia/email). Los parámetros adicionales quedan en la función $param donde se enlazan datos del PHP al XML; se asignan las variables $n de la notificación y luego se guarda para ser remitida luego:

 

 

Notificaciones en email vía XSL

La transformación se realiza tomando como raíz un objeto serializado de la tabla “licencia”: las entidades locales son atributos del la solicitud en proceso de aprobación. Los parámetros quedan entonces como variables iniciadas con $

 

 

Acceso al legajo digital del empleado

Para los legajos xPay migra los datos de las carpetas del software ADB utilizado por el organismo para la digitalización y acceso a los documentos digitales (aún se sigue haciendo la carga en un solo puesto de trabajo a través de este). El procedimiento de incorporación de los documentos visibles debe realizarse a través de la operación del método cargar_imágenes que busca en el filesystem de red los escaneos que resulta trivial para el usuario. El siguiente video explicativo para el usuario muestra cómo se accede, se busca en el sistema el empleado y se cargan sus imágenes o las últimas novedades (es necesario realizar esta operación si se ha actualizado el ADB se quieren reflejar esos nuevos documentos en el sistema):

Exportar Imágenes a PDF vía system()

Un legajo o expediente puede contener fácilmente más de 500 imágenes a escanear: esto desafía al sistema al responder inclusive con una respuesta rápida al usuario. Las liberías PHP que proveen herramientas para la generación de PDF lo hacen todo en memoria, saturando rápidamente el servidor. Para ello la mejor solución resulta hacer un llamado al sistema y proveer todos los parámetros de generación de expedientes. El comando “tiffcp” provee esta solución en forma adecuada al utilizar buffers en archivos o bien escribir directamente sobre el resultado final y así obtener un expediente con mucha cantidad de páginas. La colección de los nombres de archivos como parámetros de la instrucción se fabrica a partir de un group_concat() directamente sobre la consulta SQL. Seteando “group_concat_max_len” hace que los devuleva todos en un solo string. La constante XPAY_CAN_MAX_PDF_EXPORT limita la cantidad de archivos a exportar:

Finalmente son borrados los archivos temporales..

Generación de PDF vía FOP

FOP provee una herramienta muy valiosa para la generación de PDF con un lenguaje XML. Para la información sobre FOP revisar http://xmlgraphics.apache.org/fop/quickstartguide.html. En el “<template match=”/”>” se definen las particularidades de la página, en este caso una hoja del tipo A4, los colores de las regiones y los márgenes. Con fo:flow se define el flujo de datos pricipal, aqui el template directamente sobre el objeto //c_/_licencia:

El resultado será el siguiente, la planilla de licencias que el xPay y miPortal proveen para la firma y remisión a licencias como método manual alterntavo:

 

Llamado vía la interfaz ext a un documento PDF

Este ejemplo muestra como asociar un botón del objeto liquidación a un URL en donde se codifica el llamado al template FO

 

 

MiPortal

La implementación del MiPortal es simplemente cambiar el parámetro del template a los xpotronix. Es un “skin” del xpay, un template, una nueva forma de mostrar la aplicación a través de los templates de bootstrap que proveen una interfaz moderna y apta para celulares. La implementación del template es la SmartAdmin, un completo formato para el desarrollo de paneles de control, muy útil para un portal con datos personales.

 

miPortal en celulares

Selección automática del template para mostrar MiPortal en base al URL

Para alternar entre un portal y el otro (el xPay y miPortal) en common.php dentro de code.xml se hace la elección en base al URL:

 

 

Template MiPortal

 

Grillas de Datos en XSL

 

 

Validación y envío de formularios para el workflow de aprobación

 

El template SmartAdmin provee una interfaz para la incorporación de formularios a través de la definición de un objeto y todas las funciones de overdrive. Estas últimas manejan la respuesta del ajaxSubmit:

 

 

Claves foráneas en base a consultas para el Informe de Liquidaciones

Las consultas de liquidaciones requieren de claves foráneas complejas. Xpotronix provee una interfaz para poder generar fácilmente cuál es la consulta que proveerá el set de datos que será serializado y luego transformado un un PDF:

 

Lista de deseos (wishlist) para xPay

•  Migrar las tablas clasificadoras originales del Payroll y realizar la sincronización inversa para actualizar en xPay
• Completar el módulo de “Altas de Empleado” y sincronizar Payroll
• Mejor módulo de organigrama
• Liquidaciones en xPay y desafectar Payroll
• Brindar mejores estadísticas
• Calendario de licencias