Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
Hongjun_Qian
Product and Topic Expert
Product and Topic Expert
0 Kudos
255

In recent releases for both Public Cloud and Private Cloud/OP, there is one new functionality, named 'Liquidity Item Online Derivation', has been added to Flow Builder.

For OP customer, that configuration can be reached via IMG path: 'SAP Customizing Implementation Guide -> Financial Supply Chain Management -> Cash and Liquidity Management -> Cash Management -> Data Setup -> Define Liquidity Item Derivation Mode for Flow Builder'.

The configuration provides a company code based setup:

Hongjun_Qian_0-1723629736209.png

With this configuration, you can choose the liquidity item derivation mode with:

  • Derive Liquidity Item Online
  • Fetch Liquidity Item from table BSEG

By default, S/4 system treat all company codes as 'Fetch Liquidity Item from table BSEG'. And the liquidity item is derived for each accounting document line item during accounting document posting, and it will be saved into table BSEG directly with field 'LQITEM'.

‘Derive Liquidity Item Online’ offers one additional approach. Within this approach, system won't read the liquidity item information stored in accounting document line item, but perform the liquidity item derivation logic when building the flows, with Flow Builder.

This new approach is in favor of certain ECC customers who prefer combining 'Liquidity Item derivation' logic with 'document chain tracing' logic. In ECC era, liquidity item will be recalculated every time when building flows, and liquidity item won’t store in accounting document line item.

Storing liquidity item in accounting document line item gain lots of advantages, for example, it ensures an automatic processing, and customer can check the correctness of 'Liquidity Item Derivation' logic directly with checking the data (BSEG-LQITEM), and 'Liquidity Item Derivation' logic is treated as a prerequisite before run Flow Builder. But it also have disadvantages, that you have to perform one additional step to update liquidity item in accounting document line item (via program FCLM_UPDATE_LQITEM) after you changed the liquidity item derivation logic. If you forget to run it, the liquidity item will stay unchanged in both accounting document line item table and flows.

But it does not mean the 'Online derivation logic' is perfect, it also got disadvantages:

  • Rebuild step is still a mandatory unless you expect your updated liquidity item derivation logic impacts only the new flows. Instead of updating liquidity item in accounting document line items, rebuild the existing flows to reflect the updated liquidity item derivation logic is a must. If you forget the rebuild the flows, the situation is the same.
  • It will hurt flows' building performance. If you have a complexity setup of query/query sequence, it may impact the performance much more.
  • It will make the trouble shooting more complicated, and you need firstly identify the issue located in liquidity item derivation or liquidity item chain tracing.

So, when to use Liquidity Item Online Derivation? 

I will suggest to enable 'Liquidity Item Online Derivation' for the following scenarios:

  • You are ECC customers, and you get used to the ECC data build approach. Means, you will build flows with a periodically manner hence the 'Liquidity Item Derivation' can be merged into flow building phase.
  • You have a frequently updated liquidity item rule setup. Depends on the business needs, if the liquidity item per accounting document line item are unstable, saving liquidity item in BSEG making no sense because you have to rebuild them time to time.

 

For all other cases, I will suggest use the default approach where the system perform the automatic operations for liquidity item derivation logic, you will only manually change certain data via rebuild programs.

Finally, we understand that currently the two-steps rebuilding (rebuild liquidity item in accounting documents, then rebuild flows) is somehow the root reason for forgetting the rebuild. Maybe in a near future, we will reduce such rebuilding steps as 1, means, rebuilding flows automatically for those document items who got a new liquidity item.

Feel free to leave comment or contact me for better ideas. 😀