La nómina tiene una segunda mitad.
La primeira mitad es: ¿contamos las horas correctamente? Eso es lo que cubren nuestra prueba de recibo portugués y nuestra prueba de restaurante.
La segunda mitad es: ahora que tenemos el salario bruto, ¿qué se suma, qué se resta, y puede alguien cambiar una ejecución pagada después del hecho?
Creamos una prueba para la segunda mitad también. Aquí está lo que verificamos.
Lo que probamos
Configuramos adiciones y deducciones individuales de empleados através del mecanismo JSON de componentes de devengado del engine — el mismo mecanismo que usa el flujo de nómina real:
- Bonos y subsidios — configurables como tributables o no tributables, sujetos a Seguridad Social o no.
- Recuperación de adelanto salarial — una deducción atada a un adelanto previo.
- Deducciones de seguro — montos fijos mensuales.
También probamos el comportamiento de bloqueo del motor: una vez que una ejecución de nómina es aprobada, debe rechazar cualquier recalculo posterior.
Lo que encontramos
2 de 2 pruebas pasaron, 0 fallas.
- Adiciones y deducciones individuales — bonos, subsidios, recuperación de adelanto y seguro se aplicaron limpiamente por empleado, con el tratamiento tributable/no tributable y de Seguridad Social correcto. Sin doble-conteo.
- Bloqueo de nómina — los cálculos asociados a una ejecución aprobada lanzaron correctamente una excepción cuando intentamos recalcularlos sin pasar por el camino correcto de correción.
Ninguna de las pruebas existentes se regresó. El aislamiento que probamos en las pruebas de estrés se mantuvo: el bono del empleado A no se filtró en el pago del empleado B.
Por qué esto importa
Si ejecutas nómina para personas reales, tres cosas deben ser verdad:
- Las adiciones y deducciones son configurables, no hardcodeadas. No quieres que un dev toque el motor cada vez que agregas un nuevo tipo de subsidio.
- El bloqueo es real. Una ejecución pagada o aprobada no puede ser sobrescrita silenciosamente por un recalculo accidental.
- El aislamiento se mantiene bajo adiciones también. El bono de un empleado no infla el pago de otro.
Verificamos las tres. El engine es configurable a través del mismo mecanismo de componentes JSON que el resto del flujo de nómina, y las ejecuciones aprobadas están bloqueadas.
Lo que somos honestos sobre
No construimos una UI completa de flujo de aprobación de ajustes multi-paso en esta fase. El cálculo central y el bloqueo son sólidos; la experiencia más rica de transición de aprobación es una extensión encima. Lo decimos en nuestra propia audit.
Tampoco certificamos las tablas de impuestos con un contable. Las matemáticas son correctas y configurables. Los detalles legales específicos necesitan una revisión local antes de ejecutar nómina real — eso es verdad para cualquier producto de nómina, y lo decimos abiertamente.
Dónde encaja esto
- Probamos la nómina de Chegatta contra un recibo portugués real — la mitad de horas-y-tarifa de la nómina.
- La nómina de restaurante es más difícil que la nómina de oficina — esto es lo que probamos — los escenarios de turnos del mundo real.
- Probamos que no hay fuga cruzada entre empleados en los cálculos de nómina — la garantía de aislamiento.
- Lo que significa realmente "nómina lista para producción" — nuestra lista de verificación de la Fase 4 — el panorama completo de lista para producción, incluyendo PDF, SEPA y bloqueo.
- Por qué publicamos los resultados de nuestras pruebas de nómina en lugar de fingir que todo es perfecto — el resumen honesto de todo lo anterior.