RPTARQPOST - Cuando tropezamos varias veces con la misma piedra

Hoy vengo dispuesto a contar una anécdota, de cuando tropezamos varias veces con la misma piedra. Un poco por llorar las penas y por ver si, al escribirlo, no me vuelve a pasar ya por tercera vez. Y es que parece ser que nunca aprendo.

Os voy a hablar del report RPTARQPOST, y de cuando decide no postear los absentismos recién aprobados.

¿Y eso qué es lo que es? Es un report de SAP HCM, relacionado con la aplicación de My Leave Requests (las de Web Dynpro y las de Fiori). Su tarea es actualizar los infotipos correspondientes (2001 y 2002) una vez un absentismo es aprobado por el manager. Vamos, que en el portal, yo pido vacaciones, mi manager me las aprueba, pero hasta que no se ejecuta este report (generalmente programado cada pocos minutos), no se guardan en mis infotipos. Hasta entonces, el portal simula que se ha actualizado en el sistema, pero aún siguen en su capa (las tablas PTREQ*), pendientes de actualizarse en SAP HCM.

Tanto Fiori y tanta leche, y al final, por detrás, tenemos nuestra bonita pantalla SAPera

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.

Fiori, ESS/MSS y la SPRO

Andaba yo navegando por la SPRO, en Gestión de personal (estamos hablando de SAP HCM), para revisar la configuración de los absentismos disponibles en portal (para que la gente pueda pedir vacaciones y cosas de esas), cuando me ha venido a la mente un problema que a veces nos ocurre cuando a uno le toca trastear, por primera vez, con las aplicaciones de HCM para Fiori: Volvernos locos con las entradas disponibles en la SPRO.

Los que ya hayáis configurado alguna vez algo del Employee/Manager Self-Service en Web Dynpro ABAP (con EHP5) ya sabéis en qué punto de la parametrización nos encontraremos. Si tenemos instalado al menos un EHP6, puede que veamos algo así:

¡Si es que tenemos donde elegir! Que si SAPUI5, que si Web Dynpro ABAP, que si Java...

Pues la pildorita de hoy dice: La entrada de SAPUI5 no es de Fiori, quitáoslo de la cabeza. Es específica de HR Renewal.

ESS: Migrando el recibo de nómina de WD ABAP a Fiori (y II)

Hace unos pocos post, contaba las anécdotas ocurridas, hace algún tiempo, al implementar la aplicación del recibo de nómina para Fiori. El resumen era que la aplicación de Fiori (versión 1 y 2) utilizaba la BAdI antigua del recibo de nómina, XSS_REM_INTERFACE, en lugar de la nueva, HRESS_PAYSLIP_BADI_DEF, ya que no estaba disponible para todas las EHPs, sólo hasta la 5 (en alguna nota dicen que hasta la 6).  La solución, implementar la vieja para que llame al mismo código que la nueva.

Bueno, pues resulta que, por "culpa" de la aplicación de una nota, descubrí otra nota (que ya tiene casi un año, pero para cuando se implementó la primera todavía no debía existir) que hace que esto cambie... y podamos usar cualquiera de las dos BAdIs.

Nuevas aplicaciones para Fiori HCM: Version 3

Andaba yo curioseando sobre la aplicación My Paystubs (mis recibos de nómina) en la librería de aplicaciones de Fiori, cuando descubro que no sólo tenemos una versión 1 y versión 2, ¡sino que hasta aparece una "Version 3"!

Así que me pongo a cotillear más y descubro que SAP ha liberado una nueva versión para varias aplicaciones de SAP HCM, ¡y para SAP Business Suite, no para SAP S4/HANA!

• Para el Employee Self-Service, tenemos My Leave Requests, My Paystubs, My Time Events (las tres en versión 3), Team Calendar (versión 2) y Employee Look Up (sin especificar versión, así que aparecen dos aplicaciones con el mismo nombre);

• Para el Manager Self-Service, tenemos Approve Leave Requests (versión 3).

La nueva aplicación de My Leave Requests recuerda a la antigua de Web Dynpro ABAP, siendo más accesible,
y yo que me quejaba hace poco de la falta de accesibilidad

Fiori roadmap y aplicaciones para SAP HCM "en nombre de"

De rebote, a raíz de un tweet de Nis Boy Naeve (jefazo de la parte de UI en SAP), me dio por echarle un ojo a la actualización del roadmap de Fiori del segundo trimestre de este año, que podéis descargar en la página de roadmaps de productos de SAP.

Un documento extenso, muy extenso (más que el hobbit, que no sé como le dio a Peter Jackson para sacar tres películas), en el que nos cuentan cómo mola Fiori, las mejoras que aporta Fiori 2.0 (tanto las que ya hay como las que vendrán) y las posibles arquitecturas que podemos tener, para luego comenzar con las innovaciones venideras de los productos relacionados: SAP UI5 (donde abunda el 2.0 y el oData V4), Fiori Launchpad, HANA Enterprise Search, SAP Smart Business, SAP Fiori for S/4HANA, Fiori Cloud y otros servicios de Cloud Platform relacionados. Vamos, básicamente todo aquello a lo que le podáis poner la etiqueta Fiori (incluyendo SAP Screen Personas).

Y tras todo este mogollón genérico (digamos más bien cross), entra al detalle con cada línea de negocio: Nuevas aplicaciones y mejoras de las existentes.

Pues yo, como consultor de SAP HCM que soy, voy y me planto en directo en la sección de aplicaciones para recursos humanos. Es lo suyo, ¿no? Y es que se van echando en falta algunas mejoras. Todo ello sin entrar en detalle de hacía donde va SAP HCM (eso nos lo cuenta mejor Antonio de Ancos en este post).

Evolución del portal del empleado de SAP (Parte 3 de 3 – El futuro insondable)

 

En este tercer y último post sobre la evolución del portal del empleado, terminamos de ver como SAP ha seguido creando nuevas versiones, y poniendo las cosas más bonitas (y más interesantes para los que tenemos que meterle mano jejeje).

 

En el post anterior (Parte 2), vimos la versión del ESS hecha con Web Dynpro´s ABAP.  Hasta ahí todo va más o menos bien.

 

Estos portales hasta entonces estaban limitados a funcionar con muy pocos exploradores de internet (principalmente Internet Explorer 8 y 9) y sólo en ordenadores de sobremesa.

 

Con el tiempo surgió un problema con este tipo de portales, motivado por la necesidad que había de que estos servicios fuesen accesibles por cualquier tipo de dispositivo (móvil, tablet, sobremesa).

 

Esto hizo que SAP fuese desarrollando nuevas tecnologías, creó aplicaciones móviles nativas, nuevas versiones del netweaver portal,... y llegó un punto en el que surgieron dos caminos diferentes en la evolución del portal del empleado:

• Aplicaciones de Fiori para el empleado.
• HR Renewal 1.0 y 2.0.

 

 

Que profunda es la gente de SAP, madre mía.

 

Evolución del portal del empleado de SAP (Parte 2 de 3 – ESS con WD ABAP)

En este segundo post vamos a continuar hablando sobre las versiones que SAP ha ido creando del portal del empleado.

En el post anterior (Parte 1),  acabamos viendo el autoservicio del empleado hecho con Web Dynpro´s Java.

Como este tipo de portal era muy  engorroso de gestionar y tenía limitaciones MU gordas (como no poder modificar las Web Dynpro Java (a efectos prácticos)), SAP decidió simplificar todo este sistema e iniciar un proceso para convertir los servicios a Web Dynpro ABAP.

 

En honor a la verdad los servicios estándar con WD Java se podían personalizar (editar etiquetas, ocultar campos,...) pero no permitía realizar modificaciones más complejas.

 

Con este cambio SAP simplificó la parametrización que había que realizar en el portal (creó los llamados roles ligeros del portal que sólo tenían en este caso del ESS, una iView, un workset y un rol del portal). Casi toda la parametrización estaba definida en el ERP.

Evolución del portal del empleado de SAP (Parte 1 de 3 – Orígenes y ESS Java)

En mi post sobre portales de SAP me gustaría que tratase sobre cómo ha ido evolucionando el portal del empleado. Como veis por el Parte 1 de 3 me gustan las trilogías XD.

 

La primera vez que vi un portal del empleado fue en un ERP de la versión 4.7, pero anteriormente a esta versión existir, existían.

Estos servicios eran BSPs (código ABAP + HTML) y se podían lanzar directamente desde el ERP.

 

Periodo Desfasado / Lagged Period (parte 4 de 4)

En este cuarto y último post, vamos a dejar de incordiar con este tema y os vamos a mostrar algunos ejemplos de uso y algunas reflexiones al respecto:

 

Ejemplos de uso

 

Se va a suponer que estamos trabajando con un sistema en el que se activa el periodo desfasado el 01 de enero del 2016.

 

Tomando esto como punto de partida se van a analizar los siguientes ejemplos:

• En enero del 2016 se lanza la nómina a un empleado sin retroactividad.
• Suponiendo que no ha tenido cambios posteriores al cierre de nómina, no se ha lanzado ninguna nómina provisional el mes siguiente que haya que tener en cuenta.
• En este caso, se lanzará el programa del fichero de bases con los siguientes parámetros para generar la declaración ordinaria (no habrá complementaria en este mes):
• Periodo de cálculo: enero 2016.
• Periodo liquidación: enero 2016.

 

Periodo Desfasado / Lagged Period (parte 3 de 4)

En este tercer post, continuamos analizando algunos temas relacionados con el periodo desfasado como son los programas auxiliares que ha creado SAP o una reflexión sobre si es obligatorio utilizar este mecanismo o no:

¿Qué programas auxiliares ha creado SAP para gestionar estos datos?

SAP ha creado dos programas para poder analizar los datos que se almacenan en el clúster PCL4:

• Programa RPCL4DE0: Este programa permite visualizar las ejecuciones productivas que se hayan creado para un empleado, para un periodo o para un determinado CCC.

Periodo Desfasado / Lagged Period (parte 2 de 4)

En este segundo post, seguimos dándole periquito al torno con el periodo desfasado, y vemos más en detalle cómo funciona (os dejo un enlace a la primera parte Periodo desfasado parte 1):

 

¿Cómo se activa esta funcionalidad?

 

Este mecanismo es muy sencillo de activar y se controla mediante la constante SPDES de la vista V_T5EU3.

Periodo Desfasado / Lagged Period (parte 1 de 4)

En este primer post sobre nómina española me gustaría hablaros sobre una funcionalidad estándar que hace tiempo se usaba menos (o para mi era menos conocida), y que ahora con el sistema de liquidación directa de la Seguridad Social, se ha vuelto más interesante.

El periodo desfasado es una funcionalidad estándar de SAP, que permite utilizar automáticamente los resultados de nómina más actuales que existan en el sistema, para presentar las cotizaciones de los empleados a la Seguridad Social.

Con el nuevo sistema del SLD/Cret@ es mucho más crítico el poder utilizar los datos más actuales, para conciliar las cotizaciones de los empleados sobretodo en lo relativo a los últimos procesos de IT del mes.

La Leyenda dice…