cancel
Showing results for 
Search instead for 
Did you mean: 

Field Control Problem for IT0009 in HRESS_AC_PERSINFO

Lukas_Weigelt
Active Contributor
0 Kudos

Hello folks,

System Info:

NW AS 7.03 ABAP Stack 731 Level 13, ECC 606 (EHP 6) with SAP_HR 604 Level 78 and EA_HR 607 (HR-Renewal 1) Level 29

Background:

We are currently using the old WDJ scenarios for Display/Editing of the Infotypes IT0006 and IT0009 but now want to switch to using the WDA-based solution HRESS_AC_PERSINFO. I have already enhanceed the FPM-Configs to allow for a dedicated selection of IT0006 and IT0009 and hid all the other UIBBs available in Standard. The field Control maintained in V_T588MFPROPC hasn't been changed since it should (and does) apply for WDA as well as for WDJ. Screen of the field control (Note: we are in Germany Public Sector, that's why it's 'OE' instead of '01'):

Note: In case you are wondering why most of the fields are set read-only, yet mandatory: All read-only fields should be available for display purposes only (naturally) and their content is drawn merely from the IBAN. However, if for some reason (choose any reason you like) one of these fields should not be polled correctly or be cleared the application has to crash at this point, i.e. the process has to break. That is the case because internally we still need bank account number and the bank code and there is no further "defense-line" for plausibility in our external FI System (non-SAP).

Problem:

When I enter into edit mode of the IT0009's UIBB it all looks good, i.e. the field control is correctly adapted:

However, what happens when an employee enters an incorrect IBAN, the plausibility check AND the field control go entirely haywire. The following screenshot shows what happens when I enter a wrong IBAN:

The first thing that's nonsensial, is that an error is thrown that states that the field EMFTX is not filled (as you can see it IS filled). Furthermore, what's even worse, the fields BANKL, EMFTX and BANKN become editable which must never never never happen.

What I tried so far / Analysis:

I have not yet debugged into the depths of the GUIBB, instead I used ANST to check for standard corrections. From ANST's output I have implemented Notes 2013604 and 2020932 to no avail. I also tried to implement Note 2049483, but it seems to be faulty and can't be cleanly implemented (I raised a message for BC-UPG-NA subsequently).

Has anybody ever encountered something alike? Is there something I'm missing?

Cheers, Lukas

Accepted Solutions (1)

Accepted Solutions (1)

siddharthrajora
Product and Topic Expert
Product and Topic Expert
0 Kudos

Please understand that setting the main bank fields "Bank key" (BANKL) and "Bank Account no." (BANKN) to READ-ONLY makes no real sense as it prevents the user from changing his bank data.

Now, if the user changes his bank account from Bank A to Bank B he can not enter this data in ESS. For that reason, kindly remove the READ-ONLY settings from table T588MFPROPC for these 2 fields.

Furthermore, if you really want to have these 2 fields shown as READ-ONLY you should rather use an implementation of the BADI HRPAD00INFTYUI to set the visibility to READ-ONLY. If you are using T588MFPROPC to set these fields to READ-ONLY this means that also the content of these 2 fields will be re-set to its initial value. check class CL_HRPA_MASTERDATA_BL' You can check via PUI_IT For that reason, I highly recommend to use BADI HRPAD00INFTYUI to set these fields as READ-ONLY.

Lukas_Weigelt
Active Contributor
0 Kudos

Please understand that setting the main bank fields "Bank key" (BANKL) and "Bank Account no." (BANKN) to READ-ONLY makes no real sense as it prevents the user from changing his bank data.

Now, if the user changes his bank account from Bank A to Bank B he can not enter this data in ESS. For that reason, kindly remove the READ-ONLY settings from table T588MFPROPC for these 2 fields.

It does make sense process-wise, let me elaborate: As of a legal change approximately a year ago, our employees must maintain their bank info via IBAN only (BIC not needed because it's conceptionally superflous). The Bank Account Number and Bank Key are then automatically calculated from the System (T77S0 ADMIN-IBAN = 'S'). At this point you might ask "Why are you displaying all the other information as well if they're not to be changed by the enduser?" - it's for usability purposes. Displaying only the IBAN created some confusion amongst our employees, i.e. "how do I know this is really the right bank info with my Bank Account Number and my Bank Key" (. . .) Let's not go into more detail here, though -_-

Furthermore, if you really want to have these 2 fields shown as READ-ONLY you should rather use an implementation of the BADI HRPAD00INFTYUI to set the visibility to READ-ONLY. If you are using T588MFPROPC to set these fields to READ-ONLY this means that also the content of these 2 fields will be re-set to its initial value. check class CL_HRPA_MASTERDATA_BL' You can check via PUI_IT For that reason, I highly recommend to use BADI HRPAD00INFTYUI to set these fields as READ-ONLY.

Ok, now this I didn't know, thanks for pointing this out. It's a bit weird. though, that our business process has been working the way we intended it with the WDJ-Frontend (using the field-control in T588MFPROPC as I described). But maybe we were just "lucky" it worked for some reason. I'll check out the BADI you mentioned and give you a feedback.

Cheers, Lukas

siddharthrajora
Product and Topic Expert
Product and Topic Expert
0 Kudos

Sure I agree with your process, we had similar situation with another customer,so recommended above badi

Lukas_Weigelt
Active Contributor
0 Kudos

Alright, Siddharth! With your hint pointing to BADI HRPAD00INFTYUI I got it working the way I want it, though it was a lot more confusing than I thought (my own fault, though).

In case anybody should ever have the same task, i.e. moving logic from customizing table T588MFPROPC Into the BADI HRPAD00INFTYUI Method IF_EX_HRPAD00INFTYUI~OUTPUT_CONVERSION: Do not blue-eyedly adapt the field names. This is what I did at first, unfortunately (although it's even mentioned in the BADI-Documentation...). In the worst case (my case) some of the field names from P0009 match the field names from the Screen structure, i.e. HCMT_BSP_PA_XX_R0009.

Additionally I now understand, that the prior Parameters I had set in T588MFPROPC were completely nonsensial. When the dugging the runtime I could see the Obligatory Flag "winning" over the Read-Only flag, though the Infotype fields were cleared (as you said in your post), however the screen-fields were not, additionally they were set mandatory and cried "fill me, fill me" although they were supposedly filled already (in the screen, but not in the infotype structure). I'll allow myself to be weisenheimer here and want to point out that the three checkboxes "Obligatory", "Invisible" and "ReadOnly" in T588MFPROPC should be a radio button instead of checkboxes, because only one of them should be selected 😜

Last but not least, here's what I did to get it working bottom line:

Implemented Enhancement Spot HRPAD00INFTYUI Method IF_EX_HRPAD00INFTYUI~OUTPUT_CONVERSION and set the fields BANKS, BANKL, BANKA, EMFTX ReadOnly and IBAN00 Obligatory for the "red star" in the UI. Additionally I kept entry "OE P0009 IBAN" with the obligatory checkbox in T588MFPROPC for the plausibility check (otherwise it can be left initial).

Cheers, Lukas

siddharthrajora
Product and Topic Expert
Product and Topic Expert
0 Kudos

well I had a badi implementation for it, Sorry, I tried pasting it, but was going out of format 😞 so didn't paste it. I need to use chrome more 😉

Lukas_Weigelt
Active Contributor
0 Kudos

No problem at all! In fact I like to try things out myself rather than just pasting in example code and after all the BADI documentation is surprisingly detailed and well written: Conversion Classes - Developing an Infotype in Personnel Administration - SAP Library. After all, now I do understand the process in-depth. If you had pasted a sample solution, I probably would not have debugged as deep as I have

Cheers, Lukas

Answers (0)