Cerrar la nómina a tiempo cuando la replicación de Employee Central falla en silencio

Cadena de retail con operación en cuatro países de Latinoamérica y nómina centralizada. Empleados con alta rotación, contratos por temporada y estructuras organizacionales que cambian todos los meses.

Employee Central era el maestro de datos y Employee Central Payroll el motor de nómina, conectados por PTP. Cada cierre mensual aparecían diferencias: empleados sin replicar, cambios de centro de costo que no llegaban, y ajustes que el equipo de RR.HH. terminaba cargando a mano contra reloj. El cierre se estaba estirando cada mes y nadie sabía con certeza qué se había replicado y qué no. El archivo de pago hacia los bancos —HSBC, Santander, BCI, según el país— heredaba las mismas diferencias: un empleado sin replicar tampoco llegaba a la dispersión de haberes.

• La fecha de cierre de nómina no se mueve. El diagnóstico había que hacerlo con la operación andando.
• Cuatro países con reglas laborales y calendarios distintos sobre la misma instancia.
• El equipo de RR.HH. no tenía visibilidad técnica: reportaba síntomas, no errores.
• Sin ambiente de pruebas con volumen representativo.

La causa raíz no estaba en los errores visibles del log de replicación, sino en los registros que el delta descartaba sin generar error: cambios con fecha efectiva fuera de la ventana consultada, y modificaciones hechas sobre registros ya replicados que no alteraban los campos que PTP observa.

La decisión fue no perseguir errores individuales sino cambiar qué se considera un fallo. Se instrumentó la replicación para reconciliar recuento y no solo estado: comparar cuántos registros existían en EC con fecha efectiva en el período contra cuántos habían llegado a ECP, y alertar sobre la diferencia antes del cierre, no después.

Esto convirtió un problema de soporte reactivo en un control preventivo. Un registro que no llega deja de ser invisible.

Se levantó la trazabilidad completa de cada corrida de replicación con identificador de correlación, de forma que un empleado pudiera seguirse desde el cambio en EC hasta el resultado en ECP y, de ahí, hasta el archivo de pago bancario. Se corrigieron los mapeos de los campos que efectivamente disparaban el delta, se ajustó la ventana de fechas efectivas para cubrir los cambios retroactivos que el retail genera de forma habitual, y se estableció una corrida de reconciliación programada antes de cada cierre y antes de generar el archivo hacia cada banco.

El tiempo de cierre dejó de alargarse mes a mes, los ajustes manuales de RR.HH. bajaron de forma sostenida, y el archivo de pago hacia los bancos deja de generarse hasta que la reconciliación cierra limpia. Más relevante que las cifras: el equipo dejó de descubrir los problemas durante el cierre y pasó a resolverlos con días de anticipación.

En integraciones de nómina, el error que se ve casi nunca es el que cuesta caro. El que cuesta caro es el registro que nadie contó.