Buenas tardes Gurus:
De nuevo acudo a vosotros! Hace meses que estoy usando el nuevo ITF del infotipo 0062 para actualizar los datos fiscales; por lo general me va super bien; aunque he tenido la oportunidad de reportar algunos que otros fallos en el estándar que ya han sido objeto de correcciones.
Ese fue el post original que se resolvió gracias al apoyo de .
Esta vez el problema que tengo se ubica en el método START_COMPUTATION de la clase CL_HRPADES_IRPF_INFOTYPE. Este metodo pretende modificar la entrada correspondiente al tramo que se esta "tocando" con los datos de entrada via la siguiente lógica extraída de dicha clase:
LOOP AT mt_p0062 ASSIGNING <ls_p0062> WHERE begda <= me->ms_p0062-begda AND
endda >= me->ms_p0062-begda.
MOVE-CORRESPONDING me->ms_p0062 TO <ls_p0062>.
EXIT.
ENDLOOP.
En modificación parece que funcionaria correctamente, pero en creación veo que es incorrecto.
Vamos a poner un ejemplo sencillo - estoy intentando crear una entrada al 01.10.2014 - 31.12.9999 dentro del infotipo de datos fiscales cuyo ultimo registro va del 01.09.2014 hasta finales de los tiempos. La lógica del metodo START_COMPUTATION me elimina el registro del 01.09.2014 (que es el registro valido a la fecha me->ms_p0062-begda) forzando 01.10.2014 con el move-corresponding.
Esto provoca que los porcentajes de calculo suben indebidamente porque la lógica que se ejecuta en métodos posteriores no tiene en cuenta el registro existente entre el 01.09.2014 y el 30.09.2014.
Se hace obvio cuando se ejecuta el metodo SET_PREVIOUS_PERCENTAGE que busca el registro vigente a fecha de inicio registo - 1 (30.09.2014) y encuentra un 0%.
En cambio lo mismo con modificar funciona perfectamente.
¿el análisis de la situación es incorrecto o realmente es un problema del código estándar?
No he visto notas al respecto. De todos modos sigo con el problema de tener el EHP4; las aplicaciones de notas correctivas solo son disponibles para el EHP7/8 - por lo estoy limitado a subidas de parches para aplicarlas al sistema del cliente.
De momento he picado una by-pass casero para que la lógica sea adecuada a la operación que se realiza y de nuevo el % de IRPF es lo esperado. No me gusta mucho tener que requerir a desarrollos cliente para corregir este tipo de errores.
Algún otro cliente se ha encontrado con el mismo problema?
Gracias gurus
Otra cosita menor que en si no es merecedor de un post... si activo la lógica decoplada para el legacy en la V_T582ITVCLAS para el IT0062; modificar un registro de datos fiscales me da un dump porque MO_HRPADES_IRPF_INFOTYPE no esta creado (via la sentencia CREATE OBJECT). ¿me parece también incoherente? (en el fondo no entiendo muy bien porque la CL_HRPA_INFOTYPE_0062 se apoya en otra clase de tratamiento externa para los cálculos - el modelo es extraño).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.