Documentación Técnica-Funcional: Finiquitos/Liquidación V2 (Settlements)

• Producto: Nómina / HCM Rankmi
• Módulo: Finiquitos (Settlements)
• Versión: 2.0 (Motor persistente)
• Mercados: Latam (Chile, México, Perú)
• Última Actualización: 2025-12
• Palabras Clave: Recálculo, Proceso Mensual, Borrador, Persistencia, CFDI.

1. Definición y Propósito

El Motor de Finiquitos V2 es una evolución arquitectónica que transforma el cálculo de liquidaciones de un modelo de "fórmulas al vuelo" a un modelo de objetos persistentes.

Su propósito es permitir la misma flexibilidad de una nómina ordinaria en el proceso de egreso, permitiendo editar, guardar y trazar cada concepto indemnizatorio de forma individual o masiva, garantizando que el cálculo final sea inalterable una vez consolidado.

2. Tipo de Acción y Nivel de Riesgo

• Tipo de Acción: Gestión de Egreso / Cálculo de Haberes y Descuentos Legales.
• Nivel de Riesgo: 🔴 CRÍTICO.
  • Impacta directamente en el pago legal al trabajador.
  • Afecta obligaciones tributarias y de seguridad social.
  • En México, impacta el timbrado de CFDI de nómina extraordinaria.

3. Arquitectura del Proceso: El Contenedor Mensual

A diferencia de la nómina ordinaria que sigue ciclos de pago (semanal, quincenal), el motor de finiquitos opera bajo una lógica de Mes de Baja.

• Regla de Negocio 01: Existe un único "Proceso de Settlement" por mes calendario por entidad legal.
• Independencia de Frecuencia: Todas las terminaciones (independientemente de si el empleado es quincenal o mensual) se agrupan en este contenedor mensual.
• Relación: El finiquito referencia al mes de baja para efectos de acumulados y reportes contables.

4. Estados del Sistema y Ciclo de Vida (Objeto Persistente)

Cada finiquito posee un ID Único y transiciona por los siguientes estados:

1. Simulación: Cálculo temporal. No persiste en DB. No genera ID.
2. Borrador (Draft): El registro persiste. Es editable masivamente.
3. Pendiente de Firma/Pago: Bloqueo de edición básica para validación administrativa.
4. Pagado/Ejecutado: Cierre del registro.
   • Lógica de Retroceso: Si un finiquito en estado avanzado requiere corrección, el sistema elimina la foto anterior (borra el ID previo) y genera un nuevo ID en estado Borrador para reiniciar el ciclo con datos limpios.

5. Procedimiento de Operación

A. Gestión Masiva (Excel)

El sistema utiliza el modal de modificaciones masivas con dos capacidades:

• Carga inicial: Creación de nuevos registros (incluye históricos).
• Edición masiva: Modificación de valores en finiquitos que ya están en "Borrador".
• Trigger de Cálculo: Para que los cambios en el Excel impacten los totales, se debe activar el check "Procesar nóminas al cargar" en el modal de subida.

B. Edición Individual

• Se permite la sobrescritura manual de conceptos (días de vacaciones, gratificaciones, etc.).
• Los campos de identificación (RFC, NSS, Número de Empleado) ahora son editables directamente desde la vista de Payroll, centralizando la administración sin necesidad de ir al Máster de empleados.

6. Automatizaciones 

• Desactivación de Usuarios: El sistema ejecuta una tarea programada en segundo plano (cron job).
• Lógica: La desactivación del acceso del empleado al portal Rankmi ocurre automáticamente en la fecha estipulada durante la configuración del finiquito, sin intervención manual de CS o el Administrador.

7. Alertas Críticas y Prevención de Errores

• ⚠️ Pérdida de Ediciones Manuales: Al "retroceder a borrador", se genera un nuevo objeto. Cualquier edición manual específica realizada en el ID anterior se borrará.
• ⚠️ Sincronización de Bajas: Al consolidar el finiquito, la fecha de término se escribe automáticamente en el contrato del colaborador en el Core de HR.
• ⚠️ Conceptos en Cero: Para evitar errores de omisión, los conceptos con valor $0 se mantienen visibles con un indicador de edición disponible.

8. FAQ de Producto (Base de Conocimiento)

¿Cómo fuerzo el recálculo tras una carga masiva? Debes asegurarte de marcar la opción "Procesar nóminas al cargar" en el modal de importación de Odoo/Rankmi. Si no se marca, los valores subirán como texto plano sin pasar por el motor de reglas.

¿Qué pasa con los empleados de nómina semanal en este proceso mensual? El sistema detecta su fecha de baja y calcula los proporcionales correspondientes a su última semana trabajada, pero el registro del finiquito vivirá en el contenedor mensual de liquidaciones.

¿El sistema timbra automáticamente en México? No. El estado "Pagado/Ejecutado" habilita la disponibilidad para el timbrado, pero el proceso de firma de XML/CFDI sigue el flujo de autorización de la entidad legal.

Próximo paso recomendado: Validar que todos los conceptos indemnizatorios locales (ej. Artículo 161 en Chile o Prima de Antigüedad en México) tengan sus variables de estadísticos correctamente mapeadas en el nuevo motor.

¿Cuál es la fecha más importante para el cálculo de proporciones? La Fecha de Término del Contrato. Esta es la base para calcular aguinaldo, prima vacacional y vacaciones proporcionales.

¿Cómo incluyo Horas Extras o días festivos trabajados? Se deben registrar como Incidencias Fechadas y asociarse al periodo de finiquito para que el sistema los convierta de unidad a dinero.

¿El motivo de baja me obliga a pagar o no la liquidación? No. El motivo de baja es informativo. El usuario debe activar la bandera de Liquidación/Indemnización manualmente para realizar esos pagos, independientemente de la causa de término.

¿Qué debo hacer si la fecha de antigüedad es incorrecta? Debe corregir la fecha de alta o antigüedad directamente en el Contrato del colaborador antes de simular el finiquito.

¿Cuánto tiempo tengo para enviar la baja al IMSS? El límite reglamentario es de 5 días naturales a partir del día posterior al movimiento para evitar la extemporaneidad.

¿Por qué la simulación muestra varios impuestos (ISR)? Se calcula un ISR por conceptos de nómina, otro para Aguinaldo/PV, y un tercero para Liquidación/Indemnización, cada uno con reglas de exención y metodologías diferentes.