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

Pues cuando hacemos pruebas en un entorno no productivo, normalmente pedimos la solicitud con un empleado, la aprobamos con su manager y entonces ejecutamos el report online. Pero, en ocasiones, el report no te actualiza el dato. Ni siquiera nos da un error, simplemente ignora el absentismo que acabamos de crear. Así que nos volvemos locos pensando que se nos ha olvidado algo, probamos a volver a postearlo, comprobamos si el workflow está bien (y vemos que no se ha caído y permanece esperando el cambio de estado), si el documento tiene el estado correcto (sigue en APPROVED)... y cuando ya hemos desesperado, comenzamos a debuggear... que oye, que a lo mejor nos mola, pero debuggear el estándar puede ser todo un coñazo.

Y entonces descubrimos algo que ya nos ha pasado ya varias veces y de lo que nunca nos acordamos... que el registro de gestión está en "Liberado para nómina"... y que el report no nos avisa, simplemente no trata ese dato. Porque sí, mejor no avisar y volvernos locos a decirnos que no puede actualizarlo porque no se pueden hacer modificaciones en ese infotipo.

Afortunadamente, este es un error que sólo nos debería dar en entornos no productivos. ¿Por qué? Porque aquí, para pruebas que hacen otros compañeros, seguramente están toqueteando el registro de gestión y lo dejan liberado para nómina durante días y nadie se entera. En producción, tras el proceso de nómina, se volverá a dejar en su estado normal (liberado para corrección). Los RPTARQPOST programados que se ejecuten en esos momentos fallarán, sí, pero como es un job en fondo, acabarán haciéndolo bien, y nosotros no nos enteraremos. Pero en entornos no productivos, ay, eso es otro cantar.

Y el problema es que sé que, dentro de dos o tres meses, volverá a pasarme lo mismo. Por eso lo escribo, casi como terapia, para ver si no me vuelvo a olvidar. Pero, hay que admitirlo, tengo memoria de pez.