This is my first blog on SAP RAR (Revenue Accounting and Reporting). In this blog I will try to cover my experience on migration of SD Revenue Recognition functionality to SAP RAR.
In S/4HANA, the traditional SD Revenue Recognition functionality is no longer available and instead SAP RAR functionality will be only solution going further to perform the revenue recognition. Hence when any SAP customer plan to convert their existing ECC system to S/4HANA On-Premise version and also uses SD Rev Recog functionality in source ECC system then it becomes mandatory to perform migration to SAP RAR before start conversion.
Please note it is mandatory to perform migration of SD Rev Recog to SAP RAR before to start the S/4HANA Conversion.
SD Rev Recog to SAP RAR migration cannot be fully automated and require to setup SAP RAR before to start the migration and hence this migration process should be considered as a separate project and should not be combined with the S/4HANA implementation. The migration project must be planned carefully with sufficient time and resources so that migration is finished before the S/4HANA conversion project starts. In case of parallel project approach, then RAR should gone live before Quality box conversion starts.
In preparation for the S/4HANA conversion, the SIC Framework (Simplification Item Check) can be used to identify those simplification items that are relevant for the customer and to determine the steps to be performed in the system to start and maintain consistent conversion. There is an option for the SIC check to skip the below described checks in order not to block the S/4HANA conversion.
Consistency check follows :-
1.Checks if entries in table VBREVK exist. If no entries exist, conversion can proceed.
2.If yes, checks if entries in table VBREVE with VBREVE-REVFIX = ‘M’ exist, meaning that the sales documents are already migrated. If no entries exist, it is assumed that there are SD RR relevant sales documents to be migrated and therefore the S/4HANA conversion is blocked.
3.If entries exist, it means that migration has been already (maybe partially) performed. In this case, a check occurs to determine whether there are remaining open sales documents that are still SD RR relevant.
Following prerequisite activities needs to be performed carefully
1.Consistency check of SD Revenue Recognition data which ensure all source data is correct and consistent prior to being transferred to the new environment by the migration process.
Execute Tcode VF47 to check inconsistency in Revenue Tables
Execute Tcode VF44 to update the Sales Documents with final values of Revenue Items in table VBREVE
Execute Tcode VF42 to recognize the all-open revenue lines.
2.Before RAR migration, the future require RAR set up must all be set up first.
3.Set up “Migration Package” in RAR setup, which is require at the time of performing migration tasks.
4.Set up “Transfer Date” in RAR setup, must be only last date of month which is acceptable for migration and status should be “Migration”.
5.Set up “Special SD Processes” in RAR setup, If in SD RR, special event types such as proof of delivery (PoD) or incoming invoice are used, the corresponding entries must be maintained.
6.Activation of “Inflight Checks” which is applicable from RAR 1.3 release and checks aim to detect inconsistencies as early as possible, before any contracts or POBs are stored in the database.
Operational Load :
Operation load program is the main tool that is used to migrate SD RR data to SAP RAR. This program creates fulfillment RAIs and invoice RAIs based on the selected sales documents order Items. In addition, it refers to the already recognized revenues (entries in table VBREVE with status C up to the transfer date) legacy data that was created. Both, RAIs and legacy data are then processed by the RAI monitor (Transaction FARR_RAI_MON).
As soon as the SD data is transformed into RAIs and legacy data, the revenue recognition category is removed from the sales document item and all revenue lines (both those already posted and those that are open) are set to Inactive (field VBREVE-REVFIX is set to M). This means that nothing can be processed by referring to the migrated documents using VF44/VF46 after the operational load has been executed.
Figure
Once Loaded, the document will be displayed in FARR_RAI_MON transaction. These documents we can process through Initial Load which will create the Contract and POB’s.
Reconciliation Key
Execute highlighted RAR period end activities with transaction NWBC and relevant RAR role will update effect on FARR_D_RECON_KEY with various status as soon as step progresses. In order to reverse the migration document, execute FARR_IL_CLEANUP program and reset through FARRIC_OL or FARRIC_OL_EXPERT so once reset completed SD documents again enable for RAI processing.
Data Validation
To ensure quality and consistency for SAP RAR contracts and POBs created by the migration process, the transactions FARR_CONTR_CHECK can be used.
Comparison of SD Data with RAI
For SD RR migration, it must be ensured that the created RAIs based on the SD documents are correct. Transaction FARR_CHECK_CONS is executed to ensure that the source data has been transferred correctly to the inbound layer of SAP RAR.
Consistency Check error Comparison
Once migration completed then re-execute the SIC check program and evaluate the SI impact from earlier status it should changed to not ERROR/RED. Then update the status from “Migration to “Productive” (Note: Once status changed to Productive, it can not be reset to back).
Some relevant SAP notes
SAP recommends, that customer always should be on the latest support package/feature package level in order not to miss out on the most important OSS notes respectively and to avoid additional effort during implementation of the OSS notes. Some of the most important Notes are outlined below:
In S/4HANA, the traditional SD Revenue Recognition functionality is no longer available and instead SAP RAR functionality will be only solution going further to perform the revenue recognition. Hence when any SAP customer plan to convert their existing ECC system to S/4HANA On-Premise version and also uses SD Rev Recog functionality in source ECC system then it becomes mandatory to perform migration to SAP RAR before start conversion.
Please note it is mandatory to perform migration of SD Rev Recog to SAP RAR before to start the S/4HANA Conversion.
SD Rev Recog to SAP RAR migration cannot be fully automated and require to setup SAP RAR before to start the migration and hence this migration process should be considered as a separate project and should not be combined with the S/4HANA implementation. The migration project must be planned carefully with sufficient time and resources so that migration is finished before the S/4HANA conversion project starts. In case of parallel project approach, then RAR should gone live before Quality box conversion starts.
In preparation for the S/4HANA conversion, the SIC Framework (Simplification Item Check) can be used to identify those simplification items that are relevant for the customer and to determine the steps to be performed in the system to start and maintain consistent conversion. There is an option for the SIC check to skip the below described checks in order not to block the S/4HANA conversion.
Consistency check follows :-
1.Checks if entries in table VBREVK exist. If no entries exist, conversion can proceed.
2.If yes, checks if entries in table VBREVE with VBREVE-REVFIX = ‘M’ exist, meaning that the sales documents are already migrated. If no entries exist, it is assumed that there are SD RR relevant sales documents to be migrated and therefore the S/4HANA conversion is blocked.
3.If entries exist, it means that migration has been already (maybe partially) performed. In this case, a check occurs to determine whether there are remaining open sales documents that are still SD RR relevant.
Following prerequisite activities needs to be performed carefully
1.Consistency check of SD Revenue Recognition data which ensure all source data is correct and consistent prior to being transferred to the new environment by the migration process.
Execute Tcode VF47 to check inconsistency in Revenue Tables
Execute Tcode VF44 to update the Sales Documents with final values of Revenue Items in table VBREVE
Execute Tcode VF42 to recognize the all-open revenue lines.
2.Before RAR migration, the future require RAR set up must all be set up first.
3.Set up “Migration Package” in RAR setup, which is require at the time of performing migration tasks.
4.Set up “Transfer Date” in RAR setup, must be only last date of month which is acceptable for migration and status should be “Migration”.
5.Set up “Special SD Processes” in RAR setup, If in SD RR, special event types such as proof of delivery (PoD) or incoming invoice are used, the corresponding entries must be maintained.
6.Activation of “Inflight Checks” which is applicable from RAR 1.3 release and checks aim to detect inconsistencies as early as possible, before any contracts or POBs are stored in the database.
Operational Load :
Operation load program is the main tool that is used to migrate SD RR data to SAP RAR. This program creates fulfillment RAIs and invoice RAIs based on the selected sales documents order Items. In addition, it refers to the already recognized revenues (entries in table VBREVE with status C up to the transfer date) legacy data that was created. Both, RAIs and legacy data are then processed by the RAI monitor (Transaction FARR_RAI_MON).
As soon as the SD data is transformed into RAIs and legacy data, the revenue recognition category is removed from the sales document item and all revenue lines (both those already posted and those that are open) are set to Inactive (field VBREVE-REVFIX is set to M). This means that nothing can be processed by referring to the migrated documents using VF44/VF46 after the operational load has been executed.
Figure
Once Loaded, the document will be displayed in FARR_RAI_MON transaction. These documents we can process through Initial Load which will create the Contract and POB’s.
Reconciliation Key
Execute highlighted RAR period end activities with transaction NWBC and relevant RAR role will update effect on FARR_D_RECON_KEY with various status as soon as step progresses. In order to reverse the migration document, execute FARR_IL_CLEANUP program and reset through FARRIC_OL or FARRIC_OL_EXPERT so once reset completed SD documents again enable for RAI processing.
Data Validation
To ensure quality and consistency for SAP RAR contracts and POBs created by the migration process, the transactions FARR_CONTR_CHECK can be used.
Comparison of SD Data with RAI
For SD RR migration, it must be ensured that the created RAIs based on the SD documents are correct. Transaction FARR_CHECK_CONS is executed to ensure that the source data has been transferred correctly to the inbound layer of SAP RAR.
Consistency Check error Comparison
Once migration completed then re-execute the SIC check program and evaluate the SI impact from earlier status it should changed to not ERROR/RED. Then update the status from “Migration to “Productive” (Note: Once status changed to Productive, it can not be reset to back).
Some relevant SAP notes
SAP recommends, that customer always should be on the latest support package/feature package level in order not to miss out on the most important OSS notes respectively and to avoid additional effort during implementation of the OSS notes. Some of the most important Notes are outlined below:
| SAP Note No. | SAP Note Description |
| 2777486 | S4/HANA Simplification Item Check (SIC) for SD-Revenue Recognition |
| 2733866 | Migration Guide for SD Revenue Recognition to Revenue Accounting and Reporting |
| 2569950 | FAQ: Migration & Operational Load in the SD Integration Component |
| 2580924 | RAR GoLive preparation - additional checks |
| 2591055 | Functional limitations in the SD Integration Component |
| 2567106 | Documentation of data validation checks in revenue accounting and reporting |
| 2766906 | Operational load: SD RR migration check for completed revenue lines without FI documents |
- SAP Managed Tags:
2 Comments
