SAP HCM y Portal: Vacaciones a final y principio de año

Está claro que una de las principales aplicaciones a utilizar cuando se monta el portal del empleado (el Employee Self-Service, ya sea el de WebDynpro como el de Fiori), es la que nos va a permitir solicitar absentismos, My Leave Requests. Una utilidad que tiene alguna carencia, pero que siempre resulta muy interesante. En este artículo, voy a contar una curiosidad específica de esta aplicación, así que va destinado específicamente a aquellos consultores de SAP HCM que se pelean con el portal.

Vamos a ver cómo se comporta la aplicación a finales de año, cuando tenemos que coger las vacaciones de navidades y se nos solapa el contingente/derecho del presente año (que a lo mejor podemos gastarlo, por ejemplo, hasta el 31 de enero del año siguiente) con el derecho del año siguiente.

El ejemplo con la PA30

Imaginemos un caso específico: Cada empleado puede disfrutar de 24 días al año de vacaciones. Esos días (que se generan anualmente: vacaciones de 2018, vacaciones de 2019, etc.) se pueden disfrutar desde el 1 de enero del año hasta el 31 de enero del año siguiente. Las vacaciones que se me generan en 2018 las puedo gastar desde 1 de enero de 2018 hasta 30 de abril de 2019.

Ahora imaginemos que eso lo gestionamos por la PA30: Los empleados rellenan un excel y nosotros somos los pobres gestores de recursos humanos que picamos todas las solicitudes. Todo muy moderno ;).

Vamos al caso que nos interesa, ¿qué ocurre con el cambio de año?

Un empleado tiene aún 4 días de vacaciones pendientes de 2018. Va y se pide 3 días en enero de 2019. Guay, todavía le queda un día.

De repente, quiere disfrutar de 2 días en diciembre, pero sólo le queda uno. El gestor de recursos humanos le genera el contingente de 2019 (porque si no, no tendrá días... ay, a estas alturas ya debería haberlo creado para todos con la transacción PT_QTA00) e intenta crear el absentismos de dos días de diciembre. Eso da error, sólo le queda un día.

Me parece que nos faltan días

Así que tiene que bloquear el absentismo de enero (para que no contabilice, liberando así 3 días de 2018, con lo cual vuelve a tener 4 sin gastar), crea el absentismo de diciembre (consume dos y le quedan otros dos) y después el de enero (consume los dos que quedan de 2018 y uno de 2019). Aquello se reorganiza correctamente.

El ejemplo en el portal

¿Pero qué ocurre con el portal, donde el gestor de recursos humanos no puede gestionar eso?

Pues resulta que la aplicación de portal de solicitud de absentismos, es bastante inteligente. ¡Inteligencia artificial! :D.

El ejemplo está probado con la versión 2 de la aplicación My Leave Requests para Fiori, pero esto debería ser compatible con otras versiones (Fiori y Web Dynpro), ya que la funcionalidad que hace esto está en el back-end y, una vez superadas las clases de asistencia de las Web Dynpro o las clases DPC del servicio oData, la funcionalidad "profunda" es la misma, la que se acaba ejecutando mediante un job periódico programado del report RPTARQPOST, que se encargará de para pasar las solicitudes aprobadas de las tablas PTREQ* a los infotipos de tiempos (2001, 2002 y 2006).

Continuamos con el mismo caso: He solicitado días en enero y eso me ha consumido días de 2018. Pero ahora quiero consumir 2 días en diciembre y sólo me queda uno.

Si aún no se ha generado el contingente de 2019, me dará error. Hasta aquí, todo correcto. A ver, gestor de HR, por favor, genera de una vez el contingente del año que viene.

Una vez generado el contingente de 2019, al solicitar esos dos días, ¡no da error! ¿Cómo puede ser posible, si sólo me queda 1 día de 2018?

¡Pero si sólo me quedaba un día y no me da error! ¿Será magia?

Porque la aplicación comprueba que esos 3 días que consumí en enero podrían ser desplazados al contingente de 2019 y así podría pedir esas vacaciones de 2018. Así que lo permite. Y el manager, cuando aprueba, no obtiene ningún error, también se lo permite.

Si en lugar de pedir 2 días, hubiese pedido 5, habría fallado (me queda un día más los tres que he pedido para enero, así que si pido más de cuatro no me lo va a permitir).

La parte complicada podría ser la de la actualización de los datos en HR (pasar la solicitud del portal del estado "APPROVED" al estado "POSTED" al ejecutar el report RPTARQPOST). Si guardamos el  nuevo absentismo, ¿nos dará error? Porque una cosa es lo que simule la aplicación, y otra lo que ocurra cuando guardemos los datos.

Solicitud actualizada en tiempos sin error

Pues el sistema va más allá, y lo que hace es modificar también el absentismo de enero, para que el de diciembre se compense en 2018 y el de enero, con lo que le sobre. Automáticamente, sin que el empleado tenga que estar cancelando días. Así que esos dos días de diciembre consumirán 2 de contingente de 2018 y, los 3 días de enero, consumirían lo que nos falte de 2018 y, lo que sobre, para 2019.

Los dos absentismos han sido modificados a fecha de hoy.
Eso quiere decir que la aplicación se ha encargado de hacer los ajustes necesarios.

Y ya está, no nos tenemos que preocupar por estar lanzando luego el PT_UPD00 para reajustar derechos, el sistema ya lo ha hecho de forma automática (si comprobamos cuando se ha deducido cada absentismo, veremos que lo ha ajustado correctamente).

No, si al final va a estar bien pensado y todo.