OrphanPerson e InvalidEffectiveEndDate son dos comprobaciones de la herramienta de verificación que aparecen seguido en los proyectos de Employee Central, y que la lección incluye en la Tabla 5.3. Las dos detectan datos que quedaron en un estado que el sistema no espera, casi siempre como consecuencia de una carga o de una corrección incompleta.
OrphanPerson detecta identificadores de persona sin empleo. La nota de SAP 2438812 la describe. Recordemos la estructura que vimos en la U3: los objetos de persona, como la información biográfica y los datos personales, cuelgan del identificador de persona; los objetos de empleo, como los detalles del empleo y la información del puesto, cuelgan del empleo. Una persona sin empleo es una persona que existe en los datos, pero no tiene ningún empleo asociado. No aparece en las búsquedas de empleados, no tiene un perfil completo y puede generar errores en informes e integraciones que esperan encontrar un empleo para cada persona.
Las causas típicas son importaciones que cargaron la información biográfica de una persona pero fallaron en los detalles del empleo, o una secuencia de carga que no respetó el orden que vimos en la U4. También puede aparecer después de borrados parciales. La solución depende del caso: completar el empleo que falta, si la persona tiene que existir, o eliminar los datos de persona, si quedaron por error.
InvalidEffectiveEndDate detecta objetos de fundamento o genéricos sin un registro abierto hasta el 31/12/9999. La nota 2664552 la describe. En un objeto con fecha efectiva, el último registro tiene que terminar el 31/12/9999; si termina antes, el objeto deja de existir a partir de esa fecha. Un departamento o una ubicación sin registro abierto puede desaparecer de las listas de selección, y los empleados asignados a él quedan apuntando a un objeto que ya no es válido.
Las causas también suelen estar en las importaciones de objetos de fundamento con fechas de fin explícitas, o en correcciones que cerraron un registro sin crear el siguiente. En la U2, al crear las estructuras de Best Run Argentina, cada objeto se creó con un registro abierto; una importación posterior mal armada podría romper eso.
Las dos comprobaciones comparten un patrón con el resto de la Tabla 5.3: el problema que detectan es el síntoma de un proceso. Corregir los registros sin revisar el proceso garantiza que el problema vuelva. La lección lo resume en su error común: primero la causa, después los datos.
Para un consultor, son dos comprobaciones útiles después de una migración. Una carga de prueba que deja personas sin empleo u objetos de fundamento sin registro abierto indica un problema en los archivos o en el orden de carga, y es mucho mejor descubrirlo en la prueba que en productivo.
Cuando aparezcan en una revisión periódica, conviene mirar la fecha de creación de los registros afectados. Si todos son de la misma fecha, casi seguro hay una carga o una corrección puntual detrás.
