on 2019 Jun 23 12:01 PM
Hi All,
We are currently implementing Real Time Consolidation (RTC) for S/4HANA 1709 (which utilizes BPC Embedded model) and want to get some clarifications/guidance on the following questions (mainly with regards to Balance Carry Forward configuration).
Q1) Data coming from S/4HANA (ACDOCA) for balance sheet accounts is already in YTD nature (as balance sheet items are point accounts), for e.g. Feb.2018 data for BS accounts will be YTD values, Correct?
Q2) Data coming from S/4HANA (ACDOCA) for P&L accounts is Periodic in nature and BW will process that data on periodic basis, therefore at the query level we can just use restricted key figures to present the YTD totals, for e.g FY19 Totals, Correct?
Q3) Within the /ERP/GL_ACCOUNT dimension we have ACCTYPE property where P&L accounts are INC or EXP and BS accounts are AST or LEQ. Does this have any impact on how the data is retrieved/viewed from S/4HANA? For e.g. the way it use to determine how data is displayed in reports for BPC Standard?
Q4) If we run BCF once in the beginning of the year then Dec.2018 (closing flow) will be copied to Jan.2019 (opening flow). But what about the opening balances for all the other months, e.g. Feb.2020, Mar.2020 etc? Do we have to run BCF each month?
Q5) My understanding is that the END flow is a hierarchy parent node which rolls up the OPENING and MOVEMENTS flow, Correct? Asking because in S4F90 guide, page 86 it uses the term "calculated parent" for END flow, whereas in Figure 88 use term "Hierarchy Parent" so just wondering if there is any difference.
Really appreciate your help.
Best Regards,
Syed Wasay
Request clarification before answering.
Hi Syed,
Refer my answer below:
Both P & L and B /S data will be in periodic format in ACDOCA. You can use BW variable to calculate YTD values for both account types. From B/F perspective, you would use BPC carry forward business rules to carry forward balances to next year. The foundation view of ACDOCA is filters out period "000" which stores opening balances
Unlike BPC Standard, Account type property has no impact to values in BPC embedded
You don't need to carry forward balances to each month in next year. You can either c/f them to period "000" or "001". The flow will segregate it from other movements. The consolidation in BPC embedded is based on periodic values. However please note, by default, business rules are processed on YTD value (calculated on fly)
Q5) My understanding is that the END flow is a hierarchy parent node which rolls up the OPENING and MOVEMENTS flow, Correct? - yes correct
Regards,
Manish
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for your response manishu.jain. Please see comments below and share your thouhgts.
1) We are going to use perioid 001 for BCF, does it mean we have to update the foundation view script with value 001?
2) Can you please explain a bit more about the BW Variable to calculate YTD? Currently we are using this approach and it works well for static reports (where time perioid in columns are fixed), however for dynamic reports where the finance user has to select the period in prompts, we are struggling. Did you use any variable exit etc?
3) How do we provide the YTD values in ad-reports to Finance users who will be creating them in AO e.g. drag and drop BS accounts on rows acorss periods in columns and then expect to see YTD values?
Appreciate your help.
Best Regards,
Syed Wasay
Hi @Manish U Jain,
I am also having the same business requirement with Balance sheet query preparation. Need to display current year and prior year data with each year months (amount needs to carry forward to next month), and current-year first month will be Prior year data + Current year current month data. Please suggest.
Thanks & regards,
Satya Pavan
| User | Count |
|---|---|
| 8 | |
| 8 | |
| 6 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.