Interfaz Integración

Maria Victoria Miranda Quiros Actualizado por Maria Victoria Miranda Quiros

Esta opción permite ingresar las altas y cambios a trabajadores cargados en las tablas de integración.

  • La información que se muestra en el reporte interactivo en la región de "Altas y Cambios Anidados" es la información cargada en las tablas de la interfaz de integración, que tienen registros para las 3 tablas con la misma clave COD_EMPRESA, COD_TRABAJADOR, FECHA_INTEGRACION).
  • La información que se muestra en el reporte interactivo en las regiones de “Altas/Cambios Solos Expediente”, “Altas/Cambios Solos Históricos” y “Altas/Cambios Solos Bancos” (si es que la hay), son los cambios que llegan "solos" en las distintas tablas, sin necesidad de tener registros relacionados con las mismas claves en las otras tablas o bien registros de altas sin un registro de bancos (porque tienen tipo de pago distinto de banco 'B').

Transferir a Legadmi

  • Tras revisar la información del reporte, para cargar las altas o cambios a Legadmi debe presionar el botón azul llamado "Transferir a Legadmi".
  • Solo se van a procesar los registros de los empleados que pertenezcan a la empresa en la que se encuentra conectado el usuario. El botón "Transferir a Legadmi" procesará las siguientes validaciones:

  1. INGRESOS O ALTAS DE PERSONAL:

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.

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.

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.
  1. EGRESOS O BAJAS DE PERSONAL:

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||SEGUN DO_APELLIDO, FECHA_EGRESO, SITUACION_SSO, COD_RETIRO, COD_RAZON, COMENTARIO.

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.

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.
  1. CAMBIOS:
  • Si el trabajador ya tiene un valor en ULTIMA_NOMINA, automáticamente se bloquea la posibilidad de modificar FECHA_INGRESO y COD_CAUSA_INGRESO.
  • 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.
  • 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).
  • 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 RPS Legadmi Nómina. El proceso de actualización de información tendrá las siguientes validaciones: a. Solo se podrán actualizar los campos del instructivo que fueron 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. b. 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.
  • 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: >>Error tabla [NOMBRE TABLA]: La fecha inicial de _____ ingresada debe ser mayor a la fecha de última nómina del trabajador.
  • 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.
  • 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.
  • 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 (vacía) 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.
  • 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.
  • 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.
  • 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.

Bajas de Empleado

  • Aprobación de Bajas de Empleados

Para visualizar completo el campo de "Observaciones", haga doble click sobre el para "editarlo" aunque no es editable, esto abrirá el campo para su lectura.

  • Proceso de aprobación de Baja

Para aprobar una baja se debe realizar primero la baja en el sistema de Legadmi. Una vez realizada la baja se podrá aprobar la baja haciendo click sobre la columna. El sistema valida si el trabajador está egresado en la empresa antes de aprobar la baja del trabajador.

Registros Procesados

Registros Procesados

La información que se muestra en el reporte no es editable, aquí pueden visualizarse los distintos estatus (Procesado, Rechazado y Parcialmente Procesado)de los registros organizados por tabla, trabajador y empresa.

Definición de los distintos estatus:

  • Procesado: Los datos del registro cumplieron todas las reglas de validación y fueron aplicados por completo en las tablas finales del expediente básico en RPS.
  • Rechazado: Los datos del registro no cumplieron todas las reglas de validación y no fueron en las tablas finales del expediente básico en RPS.
  • Parcialmente Procesado: Solo algunos de los datos del registro cumplieron las reglas de validación y fueron aplicados por completo en las tablas finales del expediente básico en RPS. Este estatus solamente se genera para las tablas de EXPEDIENTE_INTEGRACION e HISTORICOS_INTEGRACION ya que son las únicas en las que se valida que las fechas iniciales sean mayores a la última nómina del trabajador. En este estatus se brindará un detalle de la tabla final que aceptó datos indicando >>Tabla [NOMBRE TABLA]: Procesada y para la tabla final que no aceptó datos indicando: >>Error tabla: [NOMBRE TABLA]: La fecha inicial de ___ ingresada debe ser mayor a la fecha de última nómina del trabajador.

¿Te resultó útil este artículo?

Reporte (Interactivo)

Consulta Errores Web Services

Contact