Modelo de datos para nomina pensionados

El modelo de datos TITAN fue desarrollado de manera generalizada para que fuera funcional con todas las nóminas, sin embargo, para el caso de la nómina pensionados, el modelo tuvo que desarrollarse partiendo de la documentación existente y las diferentes relaciones con las demás tablas de TITAN, teniendo en cuenta que los pensionados tienen ciertas particularidades tanto en la liquidación como en la base de datos de sustitutos, se tuvo que adicionar algunas tablas para su manejo.

Todo el proceso para la creación del modelo de pensionados parte del análisis realizado al Marco normativo y procedimental Nomina Funcionarios y Pensionados Universidad Distrital, dicho documento estipula toda la reglamentación bajo la cual se debe regir el aplicativo para la liquidación de la nómina. Durante este proceso se mantuvieron constantes reuniones con los encargados del proyecto para discutir de qué forma se debía estructurar el modelo sin duplicar información y garantizando que todos los conceptos que fueran requeridos estuvieran contenidos, una gran ventaja a la hora de construir toda esta estructura radica en el conocimiento mixto en el tema de software y la normatividad por parte de los directivos, lo cual ayudó en gran medida a que este modelo fuera desarrollado en tan poco tiempo y de manera complemente funcional, por lo cual fue sencillo ajustarlo al modelo general de TITAN.

56 Figura 22. Modelo de datos nomina pensionados

57 10.4.1 Descripción al modelo de datos pensionados

El modelo de datos permite realizar una correcta gestión a la información propia para la nómina de pensionados, de forma que las consultas y el resultado final al liquidar la nómina sea preciso.

 Informacion_persona_pensionado: Esta tabla almacena información referente al pensionado, obtiene toda la información que ya ha sido almacenada en la tabla Agora.informacion_proveedor, y adicional a esta, almacena otros datos como son la fecha de nacimiento, el estado civil, un campo persona fallecido (S ó N, según sea el caso), estado (Activo e Inactivo), persona en exterior (S ó N, según sea el caso), tipo pensionado, valor de pensión (valor calculado), estado de la pensión (Activa ó Inactiva), como se verá más adelante, esta información es importante para las reglas de negocio.

 Beneficiario: Esta tabla almacena información referente a cada beneficiario de un pensionado, como pueden ser hijos, padres o hermanos que dependan totalmente de este, estos deben estar registrados en la tabla agora.informacion proveedor, y adicionalmente se le asigna una categoría de beneficiario (Esposa, Padre, Madre, Hijo), y se registran dos campos más: sub_familiar y aux_estudio en los cuales se asigna una ‘S’ o una ‘N’, dependiendo si le aplica o no le aplica el subsidio respectivo.

 Sustituto: Este término hace referencia a la pensión de sobrevivientes, la cual se resume en el reconocimiento que se le hace al beneficiario cuando ha fallecido el pensionado. En esta tabla relacionamos al pensionado con el beneficiario que pasa a ser su sustituto luego del fallecimiento, adicionalmente se maneja un campo estado (activo ó inactivo), y un campo tutor que tiene efecto cuando el beneficiario es menor de edad.

 OTRAS TABLAS: Las demás tablas (Estado_civil, resolución, categoría_beneficiario, tipo_pensionado, tipo_pension), almacenan información secundaria sobre cada persona según sea el caso.

58 10.5 Integración de información y generalización para gestión de nomina Debido a que el proyecto TITAN debe realizar la liquidación de diferentes categorías (pensionados, funcionarios de planta, contratistas, docentes de hora catedra etc.), cada nomina cuenta con reglas de negocio propias, por lo cual surgió la necesidad de generalizar el proceso con el fin de minimizar el esfuerzo al momento de añadir novedades a cada nómina, de esta manera en la relación entre el api y la nómina, solo habrá que agregar el respectivo controlador y administrador de reglas de Golog.

Este proceso comienza con el uso de la interfaz gráfica, las nóminas están almacenadas en la base de datos con un respectivo ID de dominio, cuando el usuario selecciona una nómina a liquidar, el api gestiona el id relacionado

Figura 23. Interfaz de nominas registradas

Para seleccionar la nómina que se desea consultar, se selecciona en pre liquidaciones, en este enlace se mostrara la pre liquidación que está asociada a dicha nómina, y dentro de la misma se listan las personas que están registradas en ella.

Figura 24. Interfaz preliquidacion de nomina

Cada persona tiene asociado un numero de resolucion, el cual se usa en un query que selecciona todas las personas dentro de la preliquidacion mostrada en la figura anterior

59 Los datos obtenidos de este proceso, son enviados al MidApi el cual, si la información es enviada correctamente, comienza a realizar los procesos respectivos de la nómina escogida (verificar el dominio de la nómina, cargar las reglas para dicho dominio), en este caso: nomina pensionados.

Usando el dominio de la nómina se envía una petición al CrudApi, el cual se encarga de realizar las diferentes consultas a la base de datos, se hace una solicitud de los conceptos (devengos, descuentos) relacionados a cada persona, y de los predicados disponibles para dicha nómina.

La pre liquidación está definida para cada nomina en su respectivo controlador, es la encargada de procesar la información de cada pensionado que ha sido cargado en la tabla información_persona_pensionado y de relacionar las reglas de negocio para cada pensionado. Luego el controlador genera unos hechos que se necesitan para la correcta operación de las reglas de negocio, hechos que pueden cambiar dependiendo del pensionado (valor de la pensión asignada, lugar de residencia nacional o internacional etc.), el resultado es la construcción de reglas de negocio, donde se incluyen los hechos, unas reglas estáticas para todos los pensionados y los conceptos de devengos y descuentos de cada pensionado.

Finalmente, toda la información es guardada y enviada a la tabla detalle_preliquidacion, una vez los datos son definitivos se crean las liquidaciones.

Este procedimiento generalizado permite un procesamiento más rápido de la información, y un método eficiente al momento de adicionar nuevas nóminas, ya que su procedimiento interno no afectara las demás nóminas, reduciendo la posibilidad de error en la creación de novedades, liquidación de nóminas e inserción de información adicional.

Toda la información usada como prueba en cada nomina se extrajo por medio de diferentes querys, de la base de datos de prueba a la cual se tiene acceso, esta base de datos contiene información actualizada referente a la base de datos productiva que tiene en uso la oficina asesora de sistemas, el modelo diseñado para la nómina de pensionados, permite integrar de la misma manera los sustitutos (pensión de sobrevivientes), teniendo en cuenta detalles como un porcentaje sobre el valor de la pensión que le corresponda. Dentro del api se diseñaron reglas de negocio para manejar los conceptos que refieren a los sustitutos:

60 Para cada registro de pensionados, beneficiarios y sustitutos, se escribieron querys para realizar las debidas inserciones en la base de datos:

Figura 27. Insert para informacion sustituto

Figura 28. Insert para informacion beneficiario

De esta manera llenamos cada tabla del esquema con la informacion necesaria para ser trabajada en las reglas de negocio.

61 10.6 Interfaces de programación de aplicaciones (API)

Figura 30. Interfaces de programación de aplicaciones

El desarrollo de este proyecto de nómina se rige bajo un patrón de diseño de software MVC (Modelo-vista-controlador) que propone separar el código de los programas por sus diferentes responsabilidades, esto permite una mayor facilidad en el mantenimiento y la reutilización de código.

Modelo: Es la capa que permite trabajar con los datos, contiene funciones que permiten acceder a la información o actualizar su estado, información almacenada en bases de datos. En los modelos se tienen las funciones básicas de bases de datos como son select, update, insert etc

Controlador: contiene el código necesario para la lógica de la aplicación, mostrar un elemento, realizar una búsqueda de información etc

Vista: contiene la parte fronted del aplicativo (HTML, CSS, JS) que permite armar una estructura, una interfaz de usuario como salida visible al usuario. Aplicando este patrón de diseño se crean los siguientes Api’s para el desarrollo del proyecto “nominas”

Titán crud_api:

Esta capa crud nos permite crear, leer, actualizar o borrar (Create, Read, Update, Delete) que son las funciones básicas para ser usadas en una base de datos. Titan_crud_api se encarga de hacer la gestión de las conexiones a la base de datos según la información que se necesita, realiza consultas a los esquemas: Argo (Registro de contratos), Ágora (registro de proveedores), pensiones, ruler (almacena reglas de negocio), extrae la información necesaria y la envía al Titan_mid_api para ser gestionada allí.

62 Titán mid_api

Contiene un controlador específico para cada nomina e implementa funciones específicas según el tipo de nómina escogido, hace uso de las reglas de negocio según los requerimientos de las distintas variaciones de nómina.

Figura 31. Lista de funciones Golog

Titan_mid_api contiene los controladores especificos para la parte de preliquidacion y liquidacion de cada nomina, informacion que es enviada a Titan_crud_api para ser almacenada en las tablas correspondientes:

63 Ruler Api

El Ruler es donde se insertan las reglas de negocio para cada nomina, cuenta con tres archivos (dominio.go, predicado.go, tipo_predicado.go), es allí donde la nómina recibe un dominio asociado y un predicado que se relaciona con el dominio, así se distribuye que regla en específico le pertenece a una nómina. Estos datos son procesados y se envía a titan_mid_api que a su vez los envía a la interfaz para ser consultados por el usuario.

Figura 33. Lista de Ruler

10.7 Parametrización de obligaciones de ley por medio de reglas de