Issue in processing multiple PO in behavior class using MODIFY EML statement

[Renuga]

Hello All,

We have a requirement to create new entries in existing PO Item-> Pricing Element where the values are passed from a behavior implementation class of a custom table in a loop.

MODIFY EML update statement (to create NEW entries inside a particular po item) works only for last PO in the loop, but not the earlier PO's passed from the loop. Note: COMMIT statement not allowed in a behavior class. I too tried with just hardcoded values outside any loop, by executing MODIFY EML statement twice for different POs one by one. Here too, only the last hardcoded unique PO->PO item-> pricing elements were created in the system.

How to make all POs inserted with new pricing elements when different POs are passed dynamically?

MODIFY EML statement:

MODIFY ENTITIES OF i_purchaseordertp_2 PRIVILEGED

ENTITY purchaseorderitem

CREATE BY \_purordpricingelement SET FIELDS WITH VALUE #(

( %key-purchaseorder = 'PO1'

%key-purchaseorderitem = '0010'

%target = VALUE #( (

%cid = |CID{ sy-tabix }|

conditiontype = 'FVA1'

conditionrateamount = '1'

conditioncurrency = 'USD' ) ) ) )

MAPPED DATA(mapped_pe1)

FAILED DATA(failed_pe1)

REPORTED DATA(reported_pe1).

MODIFY ENTITIES OF i_purchaseordertp_2 PRIVILEGED

ENTITY purchaseorderitem

CREATE BY \_purordpricingelement SET FIELDS WITH VALUE #(

( %key-purchaseorder = 'PO2'

%key-purchaseorderitem = '0010'

%target = VALUE #( (

%cid = |CID{ sy-tabix }|

conditiontype = 'FVA1'

conditionrateamount = '2'

conditioncurrency = 'USD' ) ) ) )

MAPPED DATA(mapped_pe2)

FAILED DATA(failed_pe2)

REPORTED DATA(reported_pe2).

In the above code, only the last PO - 'PO2' is getting executed by creating new entries of pricing element in the 'PO2', Line item '0010'.

[suzanne_alivand]

Hi @Chuma,

[suzanne_alivand]

Hi @Chuma, using " In local Mode" for MODIFY ENTITIES OF i_purchaseordertp_2, gives error: The operation can only be used in implementations of behavior definition "I_PURCHASEORDERTP_2".

[Chuma]

Hello @Renuga 

You are seeing this because EML functions within RAP's behaviour logic.:

• When you modify another BO (here: I_PurchaseOrderTP_2) from a behaviour class, your EML must run IN LOCAL MODE so the changes are buffered in the same save sequence as your outer BO
• If you fire several MODIFY ENTITIES calls without IN LOCAL MODE, only the last call is recorded in the interaction buffer; earlier ones do not make it to the final save.
• Also ensure each generated child row has a unique %cid (per request)

Use this alternative (single shot, local mode, unique CIDs)

DATA lt_create TYPE TABLE FOR CREATE

  I_PurchaseOrderTP_2\purchaseorderitem\_PurOrdPricingElement.

APPEND VALUE #( %key-purchaseorder     = 'PO1'

                %key-purchaseorderitem = '0010'

                %target = VALUE #( (

                  %cid                   = 'CID_PO1_0010'

                  conditiontype          = 'FVA1'

                  conditionrateamount    = '1'

                  conditioncurrency      = 'USD' ) ) ) TO lt_create.

APPEND VALUE #( %key-purchaseorder     = 'PO2'

                %key-purchaseorderitem = '0010'

                %target = VALUE #( (

                  %cid                   = 'CID_PO2_0010'

                  conditiontype          = 'FVA1'

                  conditionrateamount    = '2'

                  conditioncurrency      = 'USD' ) ) ) TO lt_create.

MODIFY ENTITIES OF I_PurchaseOrderTP_2 **IN LOCAL MODE**

  ENTITY PurchaseOrderItem

    CREATE BY \_PurOrdPricingElement

      SET FIELDS WITH lt_create

  MAPPED   DATA(mapped)

  FAILED   DATA(failed)

  REPORTED DATA(reported).

" Optional: check failures

IF line_exists( failed-purchaseorderitem[  ] ).

  " handle/log messages from 'reported'

ENDIF.

If you prefer separate calls

You can still issue the MODIFY ENTITIES command twice, but make sure to add IN LOCAL MODE to each call and use different %cids.

MODIFY ENTITIES OF I_PurchaseOrderTP_2 IN LOCAL MODE ...

MODIFY ENTITIES OF I_PurchaseOrderTP_2 IN LOCAL MODE ...

Extra checks

• Ensure the PO items exist and aren’t locked by another LUW.
• Avoid using COMMIT WORK within behaviour classes—the framework commits after SAVE is triggered.
• Inspect FAILED/REPORTED after the first call; if it’s not in local mode, you’ll usually see no hard error, just the earlier changes being overwritten by the next interaction.

Below are some helpful SAP Documentation

1. SAP Help – Entity Manipulation Language (EML): explains IN LOCAL MODE and how it affects buffering and checks in the save sequence. SAP Help Portal-Entity Manipulation Language (EML)
2. ABAP Keyword Doc – MODIFY ENTITY/ENTITIES: full syntax and usage for RAP MODIFY with CREATE BY/associations. SAP Help Portal-MODIFY ENTITY, ENTITIES-ABAP Keyword Documentation

With kind regards

Chuma