Tabla de Contenido

Reglas y Validaciones de la Integración

Luis Ascanio Actualizado por Luis Ascanio

Reglas y Validaciones

La información que se reciba y pueda ser ingresada en las tablas de integración, es data estructural y relacionalmente correcta. Constituyen los registros elegibles para una inserción final en las tablas finales del sistema Legadmi RPS, a través de un programa final realizado por Legadmi, que además incluye reglas de negocio, permite que solo los registros que superen esas reglas y validaciones pasen íntegros a las tablas finales de Legadmi RPS.

A continuación, se enumeran las reglas que incluyo dicho programa de lectura, validación e inserción:

  1. Hay validaciones a nivel de base de datos, se comprobará que los registros a introducir en las tablas cumplan con las exigencias, especificación y formatos indicados en las estructuras requeridas por Legadmi e indicados en el presente documento. 
  2. Las tablas tienen llaves primarias constituidas por los campos indicados en la columna CLAVE. Son:
    1. Tabla EXPEDIENTE_INTEGRACION: COD_EMPRESA, COD_TRABAJADOR, FECHA_INTEGRACION.
    2. Tabla HISTORICOS_INTEGRACION: COD_EMPRESA, COD_TRABAJADOR, FECHA_INTEGRACION.
    3. Tabla BANCOS_INTEGRACION: COD_EMPRESA, COD_TRABAJADOR, COD_BANCO, FECHA_INTEGRACION.
  3. Las tablas tendrán Foreing Key con tablas definitivas existentes en Legadmi, con datos básicos ya cargadas o de tipo catálogo.
  4. Se utilizarán diferentes triggers, para garantizar validez de información y asegurar la integridad de la data entre los estándares de ambos sistemas.
  5. El orden de lectura de las tablas es:
    1. Primer registro de tabla EXPEDIENTE_INTEGRACION.
    2. Registro relacionado de la tabla HISTORICO_INTEGRACION.
    3. Registro relacionado de la tabla BANCOS_INTEGRACION.

Además, los registros de cada tabla serán leídos en orden creciente (de menor a mayor fecha) de acuerdo con el campo FECHA_INTEGRACION.

  1. Al momento que la lógica detecta que se trata de un nuevo ingreso donde existen tablas con datos relacionados (Maestro y Detalles), en el momento que se detecte un error en los datos de la tabla maestro, el programa descarta por completo los datos de las tablas detalles relacionadas, colocando el mismo error en cada una de ellas. Mientras que cuando se trata de modificaciones, cada tabla se valida individualmente.
  2. No hay eliminación de registros en ninguno de los procesos. Todos los procesos solo contemplan ingresos y modificaciones de datos con todas validaciones y reglas de negocios aquí descritas.

Lógica para nuevos ingresos o altas de personal

  1. Como regla general, si el trabajador (COD_EMPRESA, COD_TRABAJADOR) no existe en Legadmi como trabajador con esta misma clave, lo toma como un nuevo ingreso o alta. Confirmado que se trata de un nuevo ingreso o alta, las validaciones serán:
  2. Que exista en la interfase un registro relacionado entre la tabla EXPEDIENTE_INTEGRACION y la tabla HISTORICOS_INTEGRACION con la misma clave primaria (COD_EMPRESA, COD_TRABAJADOR, FECHA_INTEGRACION). En caso de que no exista, RECHAZO POR: Falta de datos de estructura para un nuevo ingreso. También se valida que el registro correspondiente en la tabla de HISTORICOS_INTEGRACION, en las columnas de fecha: FECHA_CONTRATO, FECHA_CLASIFICACION, FECHA_AREA, FECHA_CARGO, FECHA_ACTIVIDAD, FECHA_DEPARTAMENTO, FECHA_SUELDO, tengan la misma fecha de ingreso del trabajador. También valida que el registro correspondiente en la tabla de HISTORICOS_INTEGRACION columna COD_CONTRATO sea igual al COD_CONTRATO de la tabla EXPEDIENTE_INTEGRACION.
  3. Otra validación inmediata, si en la tabla EXPEDIENTE_INTEGRACION, se indica que TIPO_PAGO=B, debe existir un registro relacionado entre la tabla EXPEDIENTE_INTEGRACION y la tabla BANCOS_INTEGRACION con la misma clave primaria (COD_EMPRESA, COD_TRABAJADOR, FECHA_INTEGRACION), para unos o varios registros de COD_BANCO. En caso de que no exista un registro de banco, RECHAZO POR: Falta de datos bancarios y se ha indicado como obligatorio para un nuevo ingreso.
  4. Si un trabajador nuevo, ya está ingresado al sistema, se cambia la fecha de ingreso del mismo trabajador antes de hacerle una primera nómina, todos sus históricos, incluyendo la tabla turnos trabajadores, se actualizarán con la nueva fecha de ingreso para aquellos que coincidan con la fecha de ingreso anterior.

Lógica para egresos o bajas de personal

  1. Como regla general, si el trabajador (COD_EMPRESA, COD_TRABAJADOR) existe en Legadmi como trabajador activo, (Sin FECHA_EGRESO) con esta misma clave, y en el registro enviado de la tabla EXPEDIENTE_INTEGRACION indica un valor nuevo en FECHA_EGRESO, se traduce en una notificación para procesar la liquidación del colaborador y al registro se coloca WARNING POR: Debe procesar liquidación de: COD_EMPRESA||NB_EMPRESA, COD_TRABAJADOR, PRIMER_NOMBRE||SEGUNDO_NOMBRE||PRIMER_APELLIDO||SEGUNDO_APELLIDO, FECHA_EGRESO, SITUACION_SSO, COD_RETIRO, COD_RAZON, COMENTARIO. 
  2. En el caso que se envíe un trabajador que no existe, pero se envía nueva con fecha de egreso, se asume que se está ingresando un histórico de un trabajador egresado. 
  3. Si se envía una actualización del Expediente Integración con fecha de egreso, por defecto asume el procedimiento que se trata de una baja y advertencia que se debe hacer una liquidación. No aplicará ningún cambio aun cuando venga en el mismo registro. Si requieren aplicar un cambio, primero se deberá enviar el registro de cambio con una fecha de integración inferior.

Lógica para cambios en el expediente de personal o cambios en cualquier otra tabla del expediente

  1. Si el trabajador ya tiene un valor en ULTIMA_NOMINA, automáticamente se bloquea la posibilidad de modificar FECHA_INGRESO y COD_CAUSA_INGRESO.
  2. Si solo se modificó un campo de la tabla, debe enviarse el registro completo con todos los campos anteriores iguales, pero con nueva fecha de integración. Si un campo opcional se deja nulo y tenía un valor enviado en anterior interfase, la actualización se realizará por dicho nulo.
  3. Si el trabajador (COD_EMPRESA, COD_TRABAJADOR) existe en Legadmi como trabajador retirado (FECHA_EGRESO NOT NULL), RECHAZO POR: Intento de modificar registros de un trabajador egresado. Inmediatamente también RECHAZO por la misma causa en el registro relacionado de las siguientes tablas con la misma clave primaria (COD_EMPRESA, COD_TRABAJADOR, FECHA_INTEGRACION).
  4. Si el trabajador (COD_EMPRESA, COD_TRABAJADOR) existe en Legadmi como trabajador activo (Sin FECHA_EGRESO) con esta misma clave, lo toma como una modificación de alguno de los datos del expediente del trabajador o core de Legadmi Nómina. El proceso de actualización de información tendrá las siguientes validaciones:
    • Solo se podrán actualizar los campos marcados en la columna OBSERVACION O VALORES con la palabra ACTUALIZABLE considerando el comentario adicional de validación que pueda aplicar según el campo.
    • Luego se determina si en la interfase existe un registro relacionado entre el registro procesado de la tabla EXPEDIENTE_INTEGRACION y la tabla HISTORICOS_INTEGRACION con la misma clave primaria (COD_EMPRESA, COD_TRABAJADOR, FECHA_INTEGRACION), lo cual representa además una modificación de los datos suministrados para HISTORICOS_INTEGRACION.
  5. La validación principal para una modificación de los registros indicados en HISTORICOS_INTEGRACION, es que cualquiera de estas fechas: FECHA_CONTRATO, FECHA_CLASIFICACION, FECHA_AREA, FECHA_CARGO, FECHA_ACTIVIDAD, FECHA_DEPARTAMENTO y FECHA_SUELDO, obligatoriamente deben tener un valor superior que la ULTIMA_NOMINA del colaborador. En caso de que alguna de las fechas sea menor, RECHAZO POR: Intento de un movimiento de personal anterior a la última nómina procesada del colaborador.
  6. Si el registro no es rechazado, primero se intenta actualizar el movimiento enviado y en caso de que no exista un registro para actualizar, se procede a realizar el ingreso de un nuevo registro en la tabla histórica que corresponda.
  7. Si se envían dos cambios de históricos, con la misma fecha válida, pero con diferentes datos del catálogo correspondiente, debido a la regla de actualización, solo se mostrará el último cambio enviado.
  8. Si FECHA_DEPARTAMENTO contiene un valor superior que la ULTIMA_NOMINA del colaborador se actualizarán los centros de costos del nuevo departamento en los registros de la tabla ASISTENCIAS con fecha pagado nula y en los registros de la tabla CONCEPTOS_TRABAJADORES con fecha final nula o que la fecha final sea mayor o igual a la ULTIMA_NOMINA del colaborador.
  9. Para los datos de BANCOS_INTEGRACION, siempre se intentará hacer primero una actualización en BANCOS_TRABAJADORES de la información existente del trabajador para la base existente, si no coincide la base del registro, entonces se insertará un nuevo registro con dicha base.
  10. Una vez que se procesaron todos los registros de EXPEDIENTE_INTEGRACION, se verifica si hay registros sin procesar de HISTORICOS_INTEGRACION, lo cual se le dará el procesamiento según el punto 4 y 5, ya que son movimientos de personal sin cambios en su expediente.
  11. Una vez que se procesaron todos los registros de HISTORICOS_INTEGRACION, se verifica si hay registros sin procesar de BANCOS_INTEGRACION, lo cual se le dará el procesamiento según el punto 6, ya que son movimientos bancarios del personal sin cambios en su expediente no en movimientos.

¿Te resultó útil este artículo?

Introduccion

Estructura por considerar

Contact