HCM PF: Create multiple new records while displaying old ones

Question

Hiya (cross-posted to OSS & SDN),
I'm having some difficulties when trying to create new records to IT0014 while displaying old records at the same time, hope you can help me. The problem in brief is that existing records are removed from display when I create new ones and click on check.
My setup is as follows:
- SAP ERP 6.0 EhP4 SP29
- one form scenario with the following fields set up for backend service SAP_PA (two consecutive calls, first for I0014_xxxxx and the second for fields I0014_xxxxx_NEW):
o I0014_BEGDA Validity begin date 5 SAP_PA: Value for Effective Date Create 0014 * HCMT_BSP_PA_XX_R0014 BEGDA * PAD_BEGDA
o I0014_BETRG Amount 5 SAP_PA: Value for Effective Date Create 0014 * HCMT_BSP_PA_XX_R0014 BETRG * PAD_AMT7S
o I0014_ENDDA End date 5 SAP_PA: Value for Effective Date Create 0014 * HCMT_BSP_PA_XX_R0014 ENDDA * PAD_ENDDA
o I0014_LGART Wage Type 5 SAP_PA: Value for Effective Date Create 0014 * HCMT_BSP_PA_XX_R0014 LGART * LGART
o I0014_LGTXT Wage Type Text 5 SAP_PA: Value for Effective Date Create 0014 * HCMT_BSP_PA_XX_R0014 LGTXT * LGTXT
o I0014_WAERS Currency Manual Default Value: EUR Create 0014 * HCMT_BSP_PA_XX_R0014 WAERS * WAERS
o I0014_BEGDA_NEW Validity begin date Create 0014 * HCMT_BSP_PA_XX_R0014 BEGDA * PAD_BEGDA
o I0014_BETRG_NEW New Amount Create 0014 * HCMT_BSP_PA_XX_R0014 BETRG * PAD_AMT7S
o I0014_ENDDA_NEW New end date Create 0014 * HCMT_BSP_PA_XX_R0014 ENDDA * PAD_ENDDA
o I0014_LGART_NEW New Wage Type 1 ZS_ACTIONS: Value Help Create 0014 * HCMT_BSP_PA_XX_R0014 LGART * LGART
o I0014_WAERS_NEW New currency Manual Default Value: EUR 6 SAP_PA: Value Help Create 0014 * HCMT_BSP_PA_XX_R0014 WAERS * WAERS
- the PDF layout has two table controls: one for displaying the old values (I0014_xxxxx) and one for displaying the new entries to be created (customer requirement to display the tables side by side)
- old values are displayed all right and they get populated without any problems
The problem is that when I try to create a new entry with fields I0014_xxxxx_NEW, the first table entry in fields I0014_xxxxx is cleared out. This same problem currently occurs also with other table type entries (I0027, I0008).
I've looked very closely at note 1043692 and it states the following in its limitations:
- limitation 4:
a change to the field LGART is not allowed
=> I'm not doing a change, trying to create
- limitation 6:
Two front end fields mapped to the same backend (infotype) field cannot be used in the same table, though you have configured different default values and made one field as operation exclusive. The reason being that the field marked as Op-Exclusive will not be operated upon and there will be inconsistencies in the number of table lines generated.
=> could this be the reason for my problem?
I have also given a shot at creating a generic service for the job, but as the same note suggests it didn't work (testing the process timeouts if I return fields with multiple field values with separate indexes and subtypes).
Have you had any experiences with table controls showing both past and to-be values? Does the framework even support this kind of a requirement?
Best regards,
Mikko

Answer 1

Hi Aravind,
appreciate your input.
Not sure however if I followed you completely. When you wrote "values that needed to be displayed are made as optional" did you mean optional = operation-exclusive or optional = disabled with the help of a rule? 
Did you btw do this especially with subtype * and index * relevant infotypes? I tried your approach and upon initialization everything looks good (I didn't have the generic service in between SAP_PA:s because gs:s won't work in case of subtype * infotypes at least according to OSS and my initial tests), both the display and edit elements are populated all right.
However when I create a new entry into the new fields, their sort order is messed up upon check & send - the last entry suddenly becomes the first and check & sending for the second time I get errors about LGART and SUBTYpe not being the same (which is natural and according to the OSS note I referred to previously).
If you have been working with subty * related multiple fields, can you elaborate more on your solution?
Best regards,
Mikko