Sistema de personal y nóminas · RR. HH. y nóminas
Nóminas para más de 500 personas según la legislación eslovaca.
Sobre la base abierta de Horilla ayudamos a ampliar los procesos de RR. HH. y a separar un motor de nómina eslovaco para más de 500 empleados. El sistema del cliente es confidencial. Esto es la demo.
Del diseño al despliegue
- 01Mapear entradas de RR. HH. y nómina
- 02Definir los límites de la plataforma
- 03Ampliar los procesos de RR. HH.
- 04Aislar la lógica de nóminas eslovaca
- 05Verificar y preparar el despliegue
Información
- Tipo de proyecto
- Plataforma confidencial de RR. HH. y nómina
- Plataforma
- Aplicación web
- Nuestro papel
- No construimos el sistema desde cero. Ampliamos la plataforma abierta Horilla con la lógica de nóminas eslovaca y los informes oficiales.
- Escala
- 500+ empleados
Tecnología
- Horilla
- Django
- Python
- Django REST Framework
- PostgreSQL
- ReportLab
- XML/XSD
Lo que aprenderá
- 01Cómo los datos del empleado, el contrato y la asistencia bloqueada forman un periodo de nómina.
- 02Por qué la lógica de nómina eslovaca se separa de las pantallas diarias de RR. HH. y se vincula a un periodo.
- 03Por qué ampliamos una base de RR. HH. probada en lugar de reconstruir los procesos habituales de personal.
01
La escala cambia el diseño
Con más de 500 empleados, un contrato ausente afecta a cientos de cálculos. Con un periodo de asistencia abierto pasa lo mismo. La nómina solo lee registros trazables y asistencia mensual bloqueada.
La configuración de nómina se vincula a un periodo. Cada recibo conserva los valores de su cálculo, así que un cambio de regla no sobrescribe un resultado ya revisado.
“En nómina, la exactitud no es un detalle. Es el límite de la confianza.”
02
Base de RR. HH. probada, capa de nómina eslovaca
Horilla ya ofrecía registros de empleados, asistencia, permisos, selección e incorporación. La capa de aplicación es Django, API REST y permisos por rol. PostgreSQL mantiene el registro común.
La capa de nómina eslovaca lee asistencia bloqueada, contrato, elementos salariales y configuración del periodo. De ahí salen bruto, cotizaciones, impuestos, neto y salidas. RR. HH. queda sin leyes.
03
Cómo abordamos el diseño
Primero mapeamos roles, registros fuente de RR. HH., entradas de nómina y salidas necesarias. Después definimos qué cubría Horilla y dónde debía comenzar la extensión propia de nómina eslovaca.
Las reglas de cálculo, los pasos de usuario y las exportaciones tienen límites claros. Así se revisan por separado permisos, configuración por periodo, cálculos, estado del recibo y archivos.
04
Un ciclo de nómina, paso a paso
El equipo de RR. HH. cierra el periodo y bloquea la asistencia. El contrato, el tiempo trabajado, las ausencias, los complementos y las deducciones forman un borrador de recibo por empleado.
Un recibo empieza como borrador y pasa por revisión, confirmación y pagado. Solo el borrador recalcula. Lo confirmado se convierte en PDF y alimenta informes, auditoría y salidas XML o SEPA validadas.
05
Por qué no reconstruimos RR. HH. desde cero
La base madura de Horilla cubre los procesos habituales de personal que no había que reinventar. Así el trabajo pudo centrarse en la nómina eslovaca, los límites de permisos y las necesidades propias.
El resultado es un flujo trazable de RR. HH. y nómina para más de 500 empleados.
Un objetivo parecido, adaptado a sus necesidades
