Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
I am exploring Draft based Fiori list report applications and usage of re-use components in Fiori List Report.

One of the most common requirement in Transactional List Report applications is to determine the values of fields or set of fields based on other fields. So how can we achieve this. Yes BOPF determination is the answer.

But there is an issue which developers come across. "I have done the determination. My determination is taking place successfully but the data is not reflecting in UI".

This behavior of fields getting influenced based on other field content is named as Side Effects.(Name given by SAP)

Standard SAP documentation says.. If a user changes the content of a field, this change could potentially influence other fields on the UI.This system behavior is called a side effect.

I will put this blog content into below sections.


  • Requirement

Derive the partner functions based on the customer and sales area information.

In this blog I will try to explain the steps involved in achieving this requirement. Creating an application from scratch is not part of this blog.

In the Header section, I gave Customer details and Sales Area information and the expectation is to have the derived partners under the section "Partners"


Partner section : Currently Empty.


  • Observations

Two questions that popped up

  1. Is my determination logic triggering?

  2. Are the determined partner nodes being added as child nodes.

Straight away placed an external break point and both my questions were answered. The create method is creating the partner nodes.

Debugging and UI rendering:

But is the application completely ignoring the changes? No. I can see the derived entries in two cases.

  1. If I click on 'Create' button

2.Moving out of the draft entry and coming back to object page.

After performing either one of the above steps I can see the partner information rendered on screen

  • Implementation

But this is not what we are looking for. We need to have the partner information as and when we move from the sales area fields or by pressing 'Enter'.

This is where the Side Effects comes into picture. Though the determination logic in place, the UI should be aware of the influence the changed fields brings on to the screen.

Side effects can be incorporated in two ways.

  1. Code based annotations in DEFINE method of MPC EXT class.

  2. Local Annotations.

I took the second approach and created local annotations for the fields.

  1. Choose the annotation 'SideEffects'

2. Choose the source properties. In my case the source properties are Sold to Party/Ship to Party, Sales Org, Distribution Channel and Division.

3.Choose the Item and select the properties

Repeat the step 3 for all properties.

4. Choose the Target property/entity which gets influenced by the source fields. In my case its the partner entity

5. Refer to the target property/entity. In my case its to_Partner


That's it!! Create an entry, key in the fields for which you want the determination to trigger.


  • Code for Determination

Below is the code for BOPF determination.

  1. Read the Header node details

  2. Get the sales area and customer information to derive the partner functions

  3. Loop of the partner functions and create nodes for partners using io_modify->create( ).

** Get the Header Information. In my case the its Sales Order Header 
iv_node = zif_i_salesordertp_c=>sc_node-z_i_salesordertp
it_key = it_key
iv_fill_data = abap_true
et_data = lt_header


lv_header_key = lr_header-key.

**Derive the partner functions
iv_kunnr = lr_header->soldtoparty
iv_vkorg = lr_header->salesorganization
iv_vtweg = lr_header->distributionchannel
iv_spart = lr_header->organizationdivision
et_e1knvpm = lt_partners.

ls_partner-root_key = lr_header-key.
ls_partner-parent_key = lr_header-key.
ls_partner-salesorder = lr_header-salesorder.

LOOP AT lt_partners INTO DATA(ls_partners).

ls_partner-customer = ls_partners-kunn2.
ls_partner-partnerfunction = ls_partners-parvw.
**Create the entries for Partner Node which is a child node for Sales Order Node
iv_node = zif_i_salesordertp_c=>sc_node-z_i_hpartner_tp
is_data = REF #( ls_partner )
iv_assoc_key = zif_i_salesordertp_c=>sc_association-z_i_salesordertp-_partner
iv_source_node_key = zif_i_salesordertp_c=>sc_node-z_i_salesordertp
iv_source_key = lv_header_key
ev_key = DATA(lv_item_key)


io_modify->update( iv_node = zif_i_salesordertp_c=>sc_node-z_i_salesordertp
iv_key = lv_header_key
is_data = lr_header ).


I would also like to share two of the methods to check which property has changed in the node.
**Gets the change object for the given node keys
iv_node_key = is_ctx-node_key
it_key = it_key
iv_fill_attributes = abap_true
* iv_scope = /bobf/if_frw_c=>sc_scope_local
eo_change = DATA(lo_change)
**From the change object, get the properties which underwent a change. LT_CHANGE-ATTRIBUTES hold the **changed property names
iv_sorted = /bobf/if_frw_c=>sc_change_sort_key
iv_no_load = abap_true
et_change = DATA(lt_change)
et_content_change = DATA(lt_con_change)


  • References

Side Effects:

Side Effect Annotations:

Also please refer the standard application "Manage Purchase Order" which itself is an excellent guide for Fiori List Report. This application uses the components for Attachments, Standard Text(Notes) and Pricing Conditions.

Thanks to maheshkumar.palavalli for hinting me to write a blog post on this topic.

Finally, please share your valuable feedback.
Labels in this area