Skip to content

Plataforma técnica · Orchestrator

Servicios de Remuneraciones

Orchestrator Remuneraciones Servicios

Servicios de dominio del Orchestrator para el módulo de Remuneraciones. La sección está organizada en seis subdominios paralelos a la lectura contable: maestro laboral, régimen previsional, tiempo trabajado, liquidaciones e imposiciones, honorarios y finiquitos.

Cada subdominio mantiene su responsabilidad clara: el maestro laboral aporta las entidades base, el régimen previsional los parámetros institucionales, el tiempo trabajado los insumos mensuales, las liquidaciones materializan la obligación, honorarios cubre el régimen sin vínculo laboral y finiquitos cierra el ciclo.

SubdominioServices principalesDoc
Maestro laboralEmployeeService, CargoService, ContractService
Régimen previsionalAfpService, IsapreService
Tiempo trabajadoWorkingDayService, AttendanceService, PermissionService, VacationService
Liquidaciones e imposicionesPayrollService, PrevisionsService
HonorariosHonorariosService
FiniquitosFiniquitoService

Trece services en total, todos heredan de BaseService (template method con validaciones, logging y pool de conexión tenant).

flowchart LR
  ML["Maestro laboral<br/>(empleado · cargo · contrato)"] --> TT["Tiempo trabajado<br/>(jornada · asistencia · vacaciones)"]
  RP["Régimen previsional<br/>(AFP · Isapre)"] --> LI
  ML --> LI["Liquidaciones e imposiciones<br/>(payroll · previsions)"]
  TT --> LI
  LI --> FN["Finiquitos"]
  ML --> FN
  HN["Honorarios<br/>(régimen sin vínculo laboral)"]

El maestro laboral es la fuente: sin empleado y contrato vigente no hay nada que liquidar. El tiempo trabajado y los parámetros previsionales son insumos mensuales que payroll consume. El cálculo materializa la obligación; previsions la consolida por institución. Finiquitos toma el último contrato y la última liquidación para cerrar. Honorarios convive operativamente pero sigue su propio régimen (BHE del SII).

ConvenciónAplicación
BaseServiceTodos los services heredan validaciones, logging y getPool(tenantDb).
ServiceContextCada operación recibe ctx con tenantDb y userId.
Repository patternSQL aislado en *Repository.ts; el service nunca toca el pool directamente.
Preview vs. definitivoPayrollService y FiniquitoService exponen ambos modos; sólo el definitivo persiste obligación.
Eventos post-COMMITHooks emitidos después del commit para que consumidores reaccionen sin bloquear el commit principal.