Revenue Accounting and Reporting

Pre history 

Customers that use SD Revenue Recognition and plan to convert to S/4HANA, need to migrate to Revenue Accounting and Reporting before they convert to S/4HANA.

The aim for SAP RAR is to handle the new IFRS15 regulations announced on May 28, 2014 with an effective date of January 1, 2018 in countries that adhere to both US GAAP and IFRS.

SAP RAR is available as an add-on and can be implemented in SAP ECC. For integration with Sales and Distribution, you will also require software component SAP Sales Integration with SAP Revenue Accounting and Reporting 1.0 From S/4HANA 1809 onwards, the former SAP Revenue Accounting and Reporting add-on became an integral part of SAP S/4HANA. This relates to product version SAP REVENUE ACCOUNTING and includes software component version REVREC.

This solution is SAP RAR. Therefore, it is clearly stated in all versions of the Simplification List for SAP S/4HANA that the SD RR functionality will no longer be available in S/4HANA. SAP RAR must be used instead.

That means that all customers using SD RR and planning to convert to S/4HANA (brown field approach) or implementing S/4HANA in a new system (greenfield approach), must migrate all SD RR relevant sales orders and contracts to SAP RAR prior to the S/4HANA conversion or implementation.

Additionally e-learning courses are available for this functionality. These e-learning courses are available at www.sap.com/education:

• SCM653: Sales and Distribution Revenue Recognition
• SCM654: Advanced Revenue Recognition

Additional information

2624932 - Consulting: Handling of the bill of material scenarios in the SD integration component

You are working with revenue accounting relevant sales documents that contain subordinate items for example through bill of material (BOM) explosion. The handling of internal costs does not work as you expect, or you receive errors during RAI processing in the revenue accounting engine.

There are various bill of material scenarios available in the Sales standard, however not all these process variations are supported by SAP RAR.

Example sales document structure:

Item 1

└─Item 11

└─Item 12

     └─Item 121

     └─Item 122

Only one order item on a path from lowest level to root can be billing relevant

• Example 1: If Item 1 is relevant for billing, no other item can be billing relevant
• Example 2: If Item 12 is relevant for billing, Item 1, Item 121 and Item 122 cannot be billing relevant, however Item 11 can be billing relevant

Periodic billing plans are NOT supported on lower level items

Restrictions depending on delivery relevance:

If the BOM header is billing and delivery relevant the subordinate order items do not create performance obligations even if they are marked as relevant for RAR

Example 1: If Item 12 is billing and delivery relevant performance obligations are NOT created for Item 121 and Item 122

If the BOM is distinct the fulfillment needs to be on lower level

Example 1: A distinct BOM fulfillment of Item 1 is NOT supported

Restrictions for conditions:

Cost conditions (internal price "G") are NOT passed for BOM headers, even if the order item is delivery relevant and has a cost condition assigned

Cost conditions (internal price "G") are NOT meant to be added for BOM headers via BADI FARRIC_BADI_ORDER method INCLUDE_CONDITIONS. The corresponding RAIs will be generated but will not be processable (unless the BOM hierarchy is dissolved, see last chapter of the Note)

Cumulated cost (internal price "G") on BOM header are NOT supported

Example 1: If Item 1 is not delivery relevant but has a cost condition for the cumulated cost of Item 11 and Item 12 this cost condition is not passed to RAR (see previous point)

Example 2: It is expected that Item 11 and Item 12 are relevant for RAR, have a cost condition and statistical item category. For a statistical item the cost conditions will be inactive but will be passed to RAR regardless (only for BOM lower level items)

Example 3: If there is more than one inactive cost condition the BADI FARRIC_BADI_ORDER method EXCLUDE_CONDITIONS must be used to ensure only one cost condition is passed to RAR

Inactive standalone selling price conditions (SSP) are not passed automatically

Example 1: Typically in this scenario Item 11 and Item 12 have a statistical item category and the standalone selling price will be inactive. BADI FARRIC_BADI_ORDER method INCLUDE_CONDITIONS can be used to pass the standalone selling price condition

Work around for BOM´s not relevant for RAR:

If a BOM is not relevant for RAR and the BOM header is not needed in RAR, it can be marked as "not relevant for RAR" and the BOM structure is automatically removed

If the BOM header is needed in RAR the BOM structure can be removed in BADI FARR_BADI_RAI0 method ENRICH. In this case the VPRS condition can be included for the item in BADI FARRIC_BADI_ORDER method INCLUDE_CONDITIONS because it is technically no longer a BOM header, so the restriction does not apply either (SAP Note 2696156 is required for this workaround)

The following fields need to be cleared to remove the hierarchy: HIERARCHY_ROOT, HILDOC_COMP, HILDOC_LOGSYS, HILDOC_TYPE, HILDOC_ID

If the BOM is "only" used to bundle items sold together and has billing on multiple levels the hierarchy must be removed in the BADI because RAR cannot handle billing on multiple levels

2675360 - Revenue Accounting and Reporting with SAP S/4HANA 1809: Release Information Note

2767088 - Consulting: Incompleteness in the RAR SD Integration Component

How does the incompleteness of sales documents influence the productive RAI processing?

In case a sales document item is incomplete or it is part of a bill of material or any hierarchy of sales document items where at least one item is incomplete the integration component does not create any SDOI or SDPI RAI.

How does the incompleteness of sales documents influence the operational load?

In case a sales document item is incomplete or it is part of a bill of material or any hierarchy of sales document items where at least one item is incomplete the integration component skips the migration of the given item. Existing follow-on documents like deliveries or billing documents which reference the skipped item are also skipped.

What is considered incomplete?

The standard SD incompleteness check is more strict than the incompleteness check in the SD integration component. In the SD integration component the SDOI/SDPI RAIs (and the migration) are only suppressed if an item´s delivery data is incomplete (VBUP-UVVLK=A) and either the invoice data (VBUP-UVFAK=A) or the pricing data (VBUP-UVPRS=A) is incomplete as well. (This controlled by the customizing settings of status group assigned to the missing field)

The purpose of this is to only suppress the RAI creation if it is not possible to create follow-on deliveries and billing documents. Otherwise such follow-on documents could create invoice items (SDII) or fulfillment items (SDFI) which have no reference performance obligation (SDOI). These RAIs would immediately end up in error messages in the RAI monitor.

Why does one incomplete item of  a bill of material (BOM) suppress the RAIs of the entire item hierarchy?

The items of a BOM are sent to RAR containing their hierarchy information, which is used to create a compound performance obligation in the RAR Engine. In case a BOM item is incomplete and therefore skipped from processing the compound performance obligation can be created with incorrect allocations and the other items´ follow-on documents may lead to unexpected / incorrect postings in FI-GL.

Are there known problematic scenarios caused by this incompleteness logic?

An incomplete BOM item which is not relevant for revenue accounting suppresses the RAIs of the RAR-relevant items (in review)

An incomplete BOM item which is eventually dissolved in revenue accounting suppresses the RAIs of the other BOM items (limitation)

During migration LOAD and RESET document items may become incomplete due to profitability segment determination / deletion. To resolve this a dummy update must be performed in the impacted sales document using transaction VA02 before the migraiton is repeated.