📘Recontratación

El evento Rehire, o recontratación, ocurre cuando una persona que ya trabajó en la organización y se desvinculó vuelve a ser contratada. Lo importante, y lo que muchos consultores nuevos manejan mal, es que EC no crea un empleado nuevo desde cero como si fuera un desconocido: reconoce que esa persona ya tiene una historia en el sistema y la preserva. En términos concretos, EC mantiene intacto el historial del período anterior de empleo y genera un nuevo employment record —un nuevo registro de relación laboral— con su propio employmentId y su nueva fecha de inicio. De este modo, bajo una misma persona pueden convivir dos o más "empleos" separados en el tiempo, cada uno con su propia línea de eventos, sus propios bloques de datos y sus propias fechas efectivas. Este comportamiento es clave por varias razones prácticas. Para el reporting de rotación, permite distinguir entre alguien que ingresó por primera vez y alguien que regresó, lo cual cambia por completo las métricas de retención y de "boomerang employees". Para el cálculo de antigüedad, habilita decidir —según la política de la empresa y la normativa local— si la antigüedad se cuenta desde el primer ingreso, desde el rehire, o de forma acumulada; y como EC conserva ambos períodos, cualquiera de esas reglas es posible sin perder información. Para la trazabilidad completa, garantiza que nunca se pierda el rastro de lo que la persona hizo en su etapa anterior: sus puestos, sus evaluaciones, sus capacitaciones. El rehire se distingue de un simple hire justamente porque no arranca de una hoja en blanco, y se distingue de una reactivación porque implica una nueva relación laboral formal, no la continuación de la anterior. Desde el punto de vista del ciclo de vida, el rehire abre una nueva sub-línea de tiempo dentro de la misma persona, y su event reason (motivo de recontratación) permite después segmentar reportes específicos. Un error habitual es crear un usuario nuevo en lugar de recontratar sobre la persona existente, lo que fragmenta la historia y genera duplicados que después hay que fusionar con dolor. La buena práctica es siempre verificar si la persona ya existe en el sistema antes de dar de alta, y usar el flujo de rehire para mantener la continuidad de su identidad y su historial dentro de Employee Central. Esta capacidad de sostener varios períodos de empleo bajo una misma persona es especialmente valiosa en mercados con alta movilidad o con temporadas, donde los "boomerang employees" —gente que se va y vuelve— son frecuentes. Reconocer a esa persona como quien ya fue, y no como un alta desde cero, mejora su experiencia (no tiene que recargar todo), enriquece la data de la organización (se ven patrones de retorno) y evita el trabajo penoso de detectar y fusionar duplicados más adelante.