on 04-03-2014 7:35 PM
Buenas tardes Gurus,
Acudo una vez mas a vuestra sabiduría sabia.
Me pregunto si alguien de vosotros usan esta clase para manejar datos del infotipo de datos fiscales.
Me iba bien hasta hoy porque teníamos la versión del 19.08.2010, ahora hemos nivelado parches hasta el 72 (604) y se ha actualizado la clase con con nuevas implementaciones de metodos
SAP_HRCES | 604 | 0072 | SAPK-60472INSAPHRCES | Sub component SAP_HRCES of SAP_HR |
EA-HR | 604 | 0072 | SAPK-60472INEAHR | SAP R/3 Enterprise Extension HR |
EA-HRCES | 604 | 0072 | SAPK-60472INEAHRCES | Sub component EA-HRCES of EA-HR |
Ahora tengo un problema en el método CHECK_TAX_MOD_VALID_IN_PROVN; pero revisando la lógica no me cuadra el código ABAP:
Según veo en la línea 16 se lee la parametrización en la tabla T5E20 (en mi caso la estructura acaba con datos Provincia 07, Inicio/Fin, Modificador 99); correcto; despues viene el IF problematico que pregunta por si la estructura tiene valor; y si tiene valor se genera un mensaje de error Línea 42/43... la generacion del mensaje en si genera el dump porque las variables sy (msgid/msgty/msgvx) estan sin informar - no se puede geenrar un mensaje sin tipo.
Anál.errores
Only message types A, E, I, W, S, and X are allowed.
Parece que hay una mezcla entre los IF porque si entras por el IF (T5E20 sin datos) y el campo Modificador de impuestos (IRPF) del infotipo 0062 tiene valor, luego fuerza de nuevo la asignación del modificador de impuestos - que acabaria en blanco porque T5E20 no tiene valor??
METHOD check_tax_mod_valid_in_provn .
* Verificar provincia contra Modificador de impuestos (IRPF)
DATA lt_field_list TYPE hr_fieldlist_tab.
DATA ls_t5e20 TYPE t5e20.
DATA ls_p0062 TYPE p0062.
ls_p0062 = mo_hrpades_irpf_infotype->get_p0062( ).
* Provincias
ls_t5e20 = cl_hr_t5e20=>read( provn = ls_p0062-provn
date = ls_p0062-begda ).
IF ls_t5e20 IS INITIAL. MI PROBLEMA EMPIZA AQUI
IF ls_p0062-codau <> space AND ls_p0062-codau <> ls_t5e20-regfi.
REFRESH lt_field_list.
APPEND 'CODAU' TO lt_field_list.
* El código geográfico correspondiente al empleado es &
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 INTO me->g_msg_txt.
CALL METHOD me->add_message
EXPORTING
message_handler = io_message_handler
p_field_list = lt_field_list[]
CHANGING
p_is_ok = ev_is_ok.
ELSE.
ls_p0062-codau = ls_t5e20-regfi. SIGUE POR AQUI... forzar codau con un regi initial?
mo_hrpades_irpf_infotype->set_p0062( is_p0062 = ls_p0062 ).
ENDIF.
ELSE.
REFRESH lt_field_list.
APPEND 'CODAU' TO lt_field_list.
* No existe entrada en & para & & & &
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno y mi dump se genera aqui porque mi ls_t5e20 tiene datos...
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 INTO me->g_msg_txt.
me->add_message(
EXPORTING
message_handler = io_message_handler
p_field_list = lt_field_list[]
CHANGING
p_is_ok = ev_is_ok ).
ENDIF.
ENDMETHOD. "check_tax_mod_valid_in_provn
Mi pila ABAP es la siguiente (orden de ejecución de los procesos/metodos); todo muy estándar (salvo el programa claro) y no tengo redefiniciones de metodos raras en el programa.
EVENT | START-OF-SELECTION | ZHR_PY_ES_EI20 |
METHOD | IF_HRPA_MASTERDATA_BL~INSERT | CL_HRPA_MASTERDATA_BL=========CP |
METHOD | IF_HRPA_INFTY_BL~INSERT | CL_HRPA_INFTY_NNNN============CP |
METHOD | GENERIC_INSERT_COMPUTATIONS | CL_HRPA_INFTY_NNNN============CP |
METHOD | SPECIFIC_INSERT_COMPUTATIONS | CL_HRPA_INFOTYPE_0062=========CP |
METHOD | GENERIC_COMPUTATIONS | CL_HRPA_INFOTYPE_0062=========CP |
METHOD | CHECK_TAX_MOD_VALID_IN_PROVN | CL_HRPA_INFOTYPE_0062=========CP |
Algunos de vosotros gurus, habéis encontrado el mismo problema? Que os parece mi planteamiento? Merece que me ponga en contacto con la santa sede en Torre Laguna (aka service.sap.com/message) ?
Muchas gracias de ante mano por vuestra ayuda.
Buenas tardes Gurus,
Al final parece que los cambios están en una nota liberada Note 1927845 PA: Infotype framework corrections for Spain - III. El inconveniente es que al no tener un sistema a nivel EHP7 no podemos aplicar las corrects instructions contenidas que corrigen entre otros este fallo [lo raro es que parece que hay un desfase de nivel entre el nivel de parche en la nota y la realidad (porque la maquina súper ese nivel) ]. En fin, tenemos que esperar a la próxima subida de parches para que se apliquen las correcciones.
Al final he aplicado una solución temporal que consiste en hacer una copia de la clase y modificar el método que daba problemas. Esta solución requiere que se modifique un poco el customizing estándar bajo la sección infotipos "desacoplado" en la SPRO (gestión de personal/gestión de personal/adaptación de las superficies/infotype/...) y listo.
Claro, cuando las correcciones estarán en el sistema retrocederé estos cambios para volver a usar la clase estándar.
Gracias a SAP y a los compañeros de la OSS por la ayuda.
Cierre el post.
Saludos,
Antoine
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Gracias Guillermo. Ahora abrir una nota OSS con baja prioridad.
Un saludo.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Buenos días Antoine,
Me han informado que la actualización para ese método se entregará para EhP4 en el próximo Support Package que está siendo cerrado actualmente. Disculpa las molestias.
Saludos,
Guillermo
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Gracias por tu mensaje de seguimiento.
Tengo un pregunta adicional sobre el tratamiento de datos en la clase CL_HRPA_INFOTYPE_0062 porque una usuario me ha informado que uno de los reports (de cliente) que usa le esta indicando datos que no son correctos - este report usa el campo PORDB de la estructura P0062.
¿Es possible que haya también un fallo sobre la actualización del campo P0062-PORDB desde el campo Q0062-PORCL vía la lógica decoplada?
He revisado la clase estándar de arriba a bajo y nada sobre este campo que en el legacy se materializa en la lógica ubicada en la subrutina SET_PORDB. Tan poco he visto nada respecto a notas de correcciones
¿Como este campo es un campo de explotación exclusiva de cliente quizás desde desarrollo no se ha tenido en cuenta?
Como aun no hemos subido de parches para recuperar las correcciones de la nota 1927845 PA: Infotype framework corrections for Spain - III; y que tampoco se podrá liberar correcciones vía una nota para nuestro nivel de EHP, he añadido lógica adicional en la copia de la clase CL_HRPA_INFOTYPE_0062 para poder actualizar este dato con el valor almacenado en mo_hrpades_irpf_infotype->ms_q0062-porcl replicando así el comportamiento del legacy.
¿me recomiendas de abrir una petición OSS?
Muchas gracias de ante mano.
Antoine
Creo que tienes razón, y parece que esta lógica del antiguo framework no habría sido traspasada al New ITF.
En la clase se ve por ejemplo el código que actualiza el PORNM:
IF expatriate = abap_true.
ms_p0062-pornm = ms_p0062-pora4.
MESSAGE w238(5e) RAISING indic_irpf_manually.
ELSE.
IF ms_p0062-pora4 < ms_q0062-porcl AND ms_p0062-motiv IS INITIAL.
ms_p0062-pornm = ms_q0062-porcl.
ELSE.
ms_p0062-pornm = ms_p0062-pora4.
ENDIF.
ENDIF.
Pero después ya no parece actualizarse el PORDB. No me parece que vaya a haber ningún cambio a la operativa habitual para esto, por lo que posiblemente sea necesario añadirlo.
Ahora mismo los ajustes en este framework tienen baja prioridad, viendo que has podido resolverlo temporalmente y que es un uso exclusivo de cliente (por el momento), creo que lo mejor es que reportéis un mensaje low para que este tema quede pendiente de tratarse cuando sea posible y no caiga en el olvido. Si te parece podrías remitir esto mismo que has indicado en el hilo, ya que está bastante bien descrito el problema.
Gracias y saludos,
Guillermo
Hola de nuevo,
Al final, mi cliente me indico que necesitaba una solución rápida así que no he podido esperar y he abierto una consulta a los compis de la OSS con el mismo detalle de mi anterior post.
De momento me dijó (gracias) que parece que sea un problema de sincronización y que lo estaba(n) investigando. He solicitado que internamente mi cliente revise sincronizaciones post-parches de la maquina. Actualizare este mensaje con la solución final.
Buen finde a todos.
Saludos,
Antoine
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
89 | |
8 | |
7 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.