Use this file to discover all available pages before exploring further.
El módulo Hr gestiona el ciclo completo del empleado dentro de la empresa: estructura organizacional, expediente laboral, asistencia y horarios, solicitudes con aprobaciones, documentos firmados, nómina configurable por conceptos y motor de vacaciones. Es una función común del sistema: cualquier organización (tenant) puede activarla sin importar su categoría de negocio (Lotificación, Constructora, etc.), porque toda organización tiene personas.
Hr opera a nivel de Tenant, no de Branch (proyecto). Esta es una excepción explícita a RT-02. Las entidades de RH tienen solo TenantId, sin BranchId, con query filters condicionales (decisión 15, ADR-010). El personal corporativo a nivel raíz de la empresa tiene visibilidad transversal sobre todos los datos de RH.
Hr se ofrece en dos niveles controlados por el plan de la organización.
Plan
Qué incluye
Free
Registro de hasta 3 empleados y cálculo de nómina para esos empleados. Los 3 cupos son permanentes: no se reciclan al dar de baja a un empleado (cuentan todos los empleados creados, no solo los activos).
Plus
Todo lo demás: más de 3 empleados, asistencia, horarios, solicitudes, expediente documental, nómina completa por conceptos, vacaciones. El timbrado de CFDI de nómina es Plus y además add-on de pago por timbre.
Hr es un módulo físico único con 8 subdirectorios de contexto delimitado (decisión 14, ADR-009). Cada contexto tiene su modelo y sus reglas; todos comparten el mismo TenantId.
Org
Employees
Attendance
Schedules
Requests
EmployeeDocs
Payroll
Vacations
Estructura organizacional: razones sociales pagadoras, áreas, departamentos y puestos.La jerarquía es estricta: Razón social → Área → Departamento → Puesto. Los empleados se ubican en la organización a través de su puesto.
No existe jerarquía de reporte entre personas (no hay “jefe directo” como entidad, R14).
Una empresa puede tener varias razones sociales pagadoras, cada una con su propio FiscalIdNumber y TimeZone; un usuario puede pertenecer a varias.
Soft delete para eliminación; IsActive para pausar sin borrar.
El modelado final de la razón social pagadora está pendiente de decisión del arquitecto (punto abierto R20). Este punto bloquea la construcción de Org; el resto de contextos puede avanzar con un placeholder.
Expediente del empleado con su información laboral versionada, licencias e incidencias.Employee — datos del empleado:
Identidad: EmployeeNumber (único por razón social), nombres, apellidos, BirthDate, género, correo personal, estado civil, NationalIdNumber, geografía, dirección.
Laboral: HireDate, TerminationDate, CurrentVacationDays (saldo del motor de vacaciones), IsActive + InactiveReason + InactiveSince.
Auxiliares: teléfonos tipificados (solo uno primario), contactos de emergencia (solo uno primario).
Contract — información laboral versionada:
Versionado plano: mismo ContractNumber, VersionNumber incremental, solo una versión IsCurrent. Al cambiar condiciones (sueldo, puesto, horario, grupo de nómina) se crea una versión nueva con ChangeReason obligatorio.
Campo
Descripción
PositionId
Puesto asignado
ScheduleId
Horario de trabajo
PayrollGroupId
Grupo de nómina
VacationPolicyId
Tabulador de vacaciones
ContractTypeId
Indeterminado, Determinado, Por obra, Por temporada, Prueba, Capacitación
BaseSalary + SalaryTypeId
Salario base y su periodicidad (Mensual/Quincenal/Semanal/Por hora/Por obra)
Incidencias (registro manual):
Eventos disciplinarios o de seguimiento. El sistema no decide nada automáticamente ni afecta la nómina. Catálogo global fijo: Retardo, Falta injustificada, Amonestación verbal, Amonestación escrita, Incumplimiento de política.
Las licencias (R12) están confirmadas en alcance (con porcentaje de pago y bandera de quién cubre), pero su modelo de tablas está pendiente de entrega por parte del equipo. No construir hasta recibirlo.
Checadas y asistencia procesada.El contexto Attendance registra las marcas de tiempo individuales (ClockRecord) y las consolida diariamente contra el horario asignado, generando el registro de asistencia que alimenta la pre-nómina.Flujo:
Captura de marca (ClockIn / ClockOut) — manual o vía dispositivo.
Consolidación diaria: validación contra el horario del empleado.
Gestión de incidencias de asistencia (faltas, retardos, horas extra) — estas sí afectan la nómina, a diferencia de las incidencias disciplinarias de Employees.
Generación de pre-nómina desde asistencia.
Al correr la pre-nómina, la asistencia del período se bloquea (IsLocked) y no puede modificarse.
La validación biométrica (lector de huella conectado a PC) está fuera de alcance en esta versión. El modelo de integración con el lector depende de información técnica pendiente de entrega por el cliente.
Horarios de trabajo, patrones de turno y multiplicadores de festivo.Cada empleado tiene un ScheduleId en su contrato vigente. Los horarios definen:
Días laborables y horas de entrada/salida.
Tolerancias para retardo.
Patrones de turno (rotativo, fijo, etc.).
Multiplicadores de prima de festivo: si el empleado trabajó un día festivo, el multiplicador determina el factor de pago (normal y extra; 1.00 = sin prima). Los festivos provienen del catálogo global de festivos del tenant (ADR-021).
Solicitudes del empleado con flujo de aprobación.El contexto Requests usa el motor compartido Shared.Approvals (ADR-018) para gestionar solicitudes que requieren autorización. Tipos de solicitud:
Tipo
Descripción
Efecto en nómina
Vacaciones
Período de descanso solicitado
Prima vacacional como percepción en el período
Comisiones
Comisión por venta u objetivo
Entra como percepción en nómina
Tiempo extra
Horas trabajadas fuera del horario
Validadas contra solicitud aprobada antes de pagar
El flujo es: el empleado crea la solicitud → fluye por el árbol de aprobadores configurado en Shared.Approvals → al aprobarse, el efecto se propaga al contexto correspondiente (Vacations, Payroll).
Expediente documental del empleado y contratos laborales firmados.Gestiona los documentos del expediente de cada empleado:
Catálogo de documentos requeridos al contratar (INE, CURP, RFC, comprobante de domicilio, etc.).
Seguimiento de vencimiento de documentos (licencias de conducir, certificaciones).
Contratos laborales con firma electrónica: generados y firmados a través del módulo LegalDocs usando las mismas plantillas versionadas, motor de variables (catálogo de variables de empleado: employee.first_name, branch.legal_name, contract.base_salary) y proceso de firma de 4 fases.
El catálogo completo de variables para contratos laborales está pendiente de confirmación con el equipo. El catálogo actual de LegalDocs cubre contratos de venta; el catálogo de RH se construirá al implementar este contexto.
Motor de nómina configurable por conceptos, sin cálculo fiscal.La nómina de ArccNova es un motor de percepciones y deducciones donde cada empresa define sus propios conceptos. No es un sistema de cálculo fiscal ni genera CFDI.Modelo de 3 capas:Capa 1 — Configuración:
Entidad
Descripción
PayrollGroup
Grupo de nómina por razón social con frecuencia: Semanal, Catorcenal, Quincenal, Mensual
PayrollConcept
Percepción o deducción. Tipos de cálculo: FixedAmount, SalaryPercentage, DailySalary, HourlyRate, Formula, Manual
ContractPayrollConcept
Asignación por contrato con posibilidad de sobreescribir montos (OverrideAmount / OverridePercentage)
Capa 2 — Ejecución:
Entidad
Descripción
PayrollPeriod
Período por grupo: Year + PeriodNumber únicos, StartDate/EndDate/PaymentDate. Tipo: Ordinary o Extraordinary
PayrollRun
Corrida del período, una por período. Estados: Open → PrePayroll → Closed → Paid
PayrollRunDetail
Resultado por empleado/contrato: TotalEarnings, TotalDeductions, NetPay
PayrollRunDetailConcept
Desglose por concepto con snapshot inmutable (código, nombre y tipo copiados al cerrar)
Capa 3 — Recibos:
Generados bajo demanda desde PayrollRunDetail y sus conceptos, sin tabla persistida. Como la nómina cerrada es inmutable, el PDF generado es siempre idéntico. El recibo se genera en el backend (RT-30).Motor de fórmulas (R07, ADR-020):
Los conceptos tipo Formula se evalúan con una librería de expresiones (NCalc). Las variables disponibles en fórmulas provienen exclusivamente del catálogo global PayrollFormulaVariable. Variables iniciales: base_salary, daily_salary, worked_days, seniority_years. Las fórmulas inválidas se detectan al configurar el concepto, no al correr la nómina.Flujo de nómina ordinaria:
1
Abrir período
Manual: Year / PeriodNumber / fechas. Se crea la corrida en estado Open.
2
Pre-nómina
El sistema calcula tomando la asistencia del período (que se bloquea), la versión vigente del contrato y los conceptos asignados (con overrides). Estado PrePayroll. Etapa de revisión y ajustes manuales.
3
Cerrar
La corrida pasa a Closed y se vuelve inmutable. No se reabre; los ajustes van al período siguiente. Cada concepto aplicado guarda copia inmutable de su definición.
4
Pagar
Estado Paid con fecha. El pago real (transferencia, efectivo, etc.) ocurre fuera del sistema; ArccNova solo registra el estado.
5
Recibo
El empleado descarga su recibo en PDF bajo demanda desde su portal.
Conceptos que llegan de otros contextos:
Prima vacacional → desde Vacations; se paga en el período en que el empleado disfruta las vacaciones.
Prima de festivo → desde Schedules; según el multiplicador configurado en el festivo.
Horas extra → desde Requests; validadas contra solicitudes aprobadas.
Licencias cubiertas por la empresa → desde Employees; entran con su porcentaje de cobertura.
Comisiones aprobadas → desde Requests; entran como percepción.
Cálculo y saldo de vacaciones por empleado.El motor de vacaciones gestiona el tabulador de días por antigüedad, el cálculo del saldo disponible de cada empleado (CurrentVacationDays en Employee) y la prima vacacional que se paga en nómina cuando el empleado disfruta el período aprobado.
Los tabuladores de vacaciones se configuran por razón social (VacationPolicyId).
Las solicitudes de vacaciones fluyen por Shared.Approvals (contexto Requests).
Al aprobarse una solicitud de vacaciones, el saldo se descuenta y la prima vacacional queda disponible como concepto de nómina para el período correspondiente.
Los seeders de referencia MX/US incluyen tablas de días de vacaciones sugeridas, adoptables, modificables o ignorables por cada empresa.
Hr tiene su propia fase de construcción, independiente del roadmap de Lotificación. Sus únicos prerrequisitos duros son Identity RBAC, Shared.Approvals, LegalDocs y el catálogo de festivos. El punto abierto R20 (razón social pagadora) bloquea el contexto Org pero no impide avanzar con los demás contextos usando un placeholder.