Consolidation Data Release Monitor
Application component: Real-Time Consolidation
App type: Transactional
Line of business: Finance
Leading industry: Cross Industry
Solution capability: Corporate Close (S/4)
Description: With this app, group accountants monitor status of released data for specified consolidation model and fiscal year/period. Furthermore, they can perform mass actions for all or selected entities, including period initialization, currency translation, data validation, release, defer, and approval in sequential order. To ensure flawless data processing, system controls each task by verifying results of its preceding tasks.
An app to display consolidation data status and to manage the data release process
Key features:  Data Status Overview After specifying the model, version, fiscal period, and optionally the group and entities, you get an overview of the following statuses for each entity:  Lock Status: Shows whether the period is still open for data release.  Period Status: Shows the status of the reported data for a timespan from the beginning of the period until the time that it is released. Adjustment Status: Shows the status of the adjusted data after the last release, that is, which data is undergoing translation, validation, or release phase. New Posting: Shows if a new posting is detected in the universal journal or through flexible upload, the data of which has not entered the data release cycle.  There are two types of Data Release Request (DRR): Periodic Release Request (PRR), and Adjustment Release Request (ARR), corresponding to the period status and adjustment status respectively. A PRR is mandatory for each entity and each period. If a PRR is missing for an entity in a period, the data is incomplete, and the consolidation process cannot proceed. If a PRR is rejected, then a new PRR is automatically created without initializing the package again. A PRR must be approved for each entity and each period, because only an approved PRR can expose data to the SAP BPC consolidation engine. A PRR cannot be deferred to the next fiscal period; in other words, the journal entries cannot be copied to the next period. An ARR only takes place if there is a new posting, that is, a data variation in the table ACDOCA or ACDOCC, after the PRR is approved. Once a new posting is detected, you can run Currency Translation and Validation again to include the new changes, and record the timestamp in an automatically-generated ARR. The ARR can then be released. The ARR works the same way as the PRR, except an ARR can be deferred. If deferred, the journal entries posted between the last approved DRR and this ARR are copied to the next period. Along the data release cycle, reported data can have any of the following statuses illustrated in the figure below:    The figure below is a screenshot of the app that helps you understand the process (English only):  See the sections below for explanations of each step. Initialize Package To start collecting data from subsidiaries, group accountants need to open the fiscal period for data release by choosing Initialize Package under Mass Actions for the specified entities. With that, a PRR is generated and the Period Status for the selected entities changes from To Be Initialized to Initial. After initialization, subsidiaries can start preparing and releasing their financial data for consolidation. For more information or this follow-on process on the local accountant side, see the section Consolidation Data Release Cockpit.  Note The functions of currency translation, validation, and release are basically the same between Consolidation Data Release Cockpit and Consolidation Data Release Monitor apps, except they are available in the latter with mass action mode, that is, you can perform the actions for multiple entities.   Currency Translation Reported financial data in the local and transaction currencies needs to be translated into corresponding amounts in the group currency for consolidation purposes. To do that, choose Currency Translation under Mass Actions. If the Detail Log checkbox is selected when running currency translation, a detail log is recorded and is available for auditing or other tracking purposes. The log can be accessed from Log  Currency Translation Log. It displays the group account number, translation key, exchange rate, source currency, source amount, target currency, and translated amount for each entity. For information on the currency translation method, see the section Currency Translation Method.  Validation Before releasing data for group consolidation, translated financial data needs to be validated against the defined rules. To do that, choose Validate under Mass Actions. If validation fails, you can view its details by choosing the arrow icon () of each entity record to navigate to the app Consolidation Data Release Cockpit. Under Validation, you can check which validation rule the data fails to meet. For more information, see the section Consolidation Data Release Cockpit.   Release Data Following a successful currency translation and validation, you can proceed to releasing the data. To do that, choose Release under Mass Actions.  Approve As a group accountant, you have the option to approve or reject the released data.  Note When you choose any option under Mass Actions, the system triggers the possible preceding tasks sequentially for the selected entities. On the other hand, separate action buttons on the top right of the table, such as Approve, Reject, and Defer, only apply to the data released by local accountants from the Consolidation Data Release Cockpit app.   Lock/Unlock Locking an entity prevents further data release or any data processing, for example, currency translation, validation, and defer. You can choose to lock or unlock selected entities, the Lock Status of which changes to Locked or Unlocked accordingly.  Defer Generally, the defer action copies the newly-posted adjustment data for prior periods to the current period, or copies the adjustment for current period to the next period, where "adjustment" means the delta changes made since the last approval/defer time till now. The copy operation posts documents into the consolidation journal (ACDOCC table), divided by combinations of entity, period, and currency code. The document type is 04 (Defer from Prior Periods) with the posting level 03. Note that a posting level less than or equal to 09 refers to local data, which needs to be released in Consolidation Data Release Cockpit by local accountants. Note If the currency translation mode of your consolidation model is set to 1 (Currency Translation in Accounting), then in addition to local currency, it also posts documents in the relevant group currencies.  If the adjustments are made to a prior period (by reopening it, for example), a New Posting notification appears for the corresponding period in both Consolidation Data Release Cockpit and Consolidation Data Release Monitor apps. By choosing Defer under Mass Actions, you can defer the new postings into the next period that is not initialized or processed yet. When you initialize the next available period in Consolidation Data Release Monitor, the following dialog pops up, asking whether you want to defer the variations of prior periods to current period.    If you choose OK, all these new postings of prior periods are copied into current period. Apart from the data copy operation, it also creates an ARR for each prior period that has variations. The deferred ARR has Deferred status and is recorded in the corresponding deferral document. When checking data through the BPC virtual InfoProvider, you will not see the new postings in their original periods, but in the deferral target period. This is achieved by using only the timestamp of latest approved DRR as the filter for the prior periods. Therefore, the deferred/rejected DRRs are not counted in. In this way, the data is consistent among periods from the consolidation point of view. There are some constraints for the deferral action, though: You can only defer changes to a target period that is either not initialized or not processed, meaning no currency translation or validation is executed yet. When you choose the deferral action, the system automatically helps you find the next available period for deferring to.  You can only defer changes for a period that is not the last period based on your fiscal year variant (FYV). For example, if your model has the FSV K4 (Calendar Year, 4 Special Periods), you cannot defer the changes for the period 16.  You cannot defer the full-period data, that is, you cannot defer PRRs. It is required for each period to get its PRR approved. After its approval, all the subsequent data releases are recorded in ARRs, which are deferrable. If you deferred any ARRs in the current period, but when a later change comes in and you approve it, the system cancels all the previous deferred ARRs and marks the posted deferral documents as deleted. Note The main reason that the year-to-date (YTD) model is superior to the period model is that the YTD model automatically counts the adjustments of prior periods into current period during data collection. As the Real-Time Consolidation solution is based on accounting (FI) data, which is period model-based, the Deferral concept is introduced to cope with the adjustments for the prior periods. With the ARRs organized in chronological order, deferral is more convenient than submitting YTD data. You can easily trace back to know when the changes take place. For external entities that don't have their accounting in SAP S/4HANA and first need to upload the data into ACDOCC table by periods, they can upload the data again for the changed periods. The Consolidation Data Release Cockpit then displays the New Posting notification for the changed period. You can defer them just like for internal entities.  Note This app replaces the following transaction codes that are available in SAP S/4HANA 1610 and become obsolete from SAP S/4HANA 1709 onwards:  RTCDSRB: Data Submit Requests in Batch   RTCMPL: Mass Period Lock   RTCRL: Data Submit Request List   RTCPL: Pull Request - Period Lock/Unlock  Refer to SAP Note 2569477  to disable the transaction codes in the back-end systems.
Business roles: Consolidation Specialist
Consolidation Specialist : 
Is responsible for the Consolidation setting, processing for the FI or other business data from subsidiaries. Generates the legal & management consolidated reports.