Sei sulla pagina 1di 23
Migration Guide for SD Revenue Recognition to SAP Revenue Accounting and Reporting

Migration Guide for SD Revenue Recognition to SAP Revenue Accounting and Reporting

Migration Guide for SD Revenue Recognition to SAP Revenue Accounting and Reporting

TABLE OF CONTENTS

1

INTRODUCTION

4

1.1

Overview

4

1.2

Timeline / End-to-End Process

5

2

RESTRICTIONS

6

2.1

Migration Prior to S/4HANA

6

2.2

Out-of-Scope

6

3

PREREQUISITE ACTIVITIES

7

3.1

Consistency Check of SD Revenue Recognition Data

7

3.2

Update Sales documents with VF42

8

3.3

Recognize Open Revenues with VF44

8

3.4

Setup of SAP Revenue Accounting & Reporting

9

3.4.1

Customizing

9

3.4.2

Migration Packages

9

3.4.3

Transfer Date

10

3.4.4

Special SD Processes

10

3.4.5

Activation of Inflight Checks

10

4

MIGRATION TOOLS

11

4.1

Operational Load

11

4.1.1

General Functionality

11

4.1.2

Prerequisites

11

4.1.3

Selection

11

4.1.4

Processing Parameters

11

4.1.5

Expert Mode

12

4.2

Revenue Correction Report

13

4.2.1

Correction of Revenues

13

4.2.2

Correction of Billing Documents

14

4.3

Checks

14

4.3.1

Revenue Accounting Contracts Consistency Check

14

4.3.2

Two-Step Reconciliation

14

4.3.2.1

Comparison SD data with Revenue Accounting Items

15

4.3.2.2

Comparison Revenue Accounting Items with RAR Contract Data

15

5

MIGRATION OF THE REVENUE RECOGNITION PROCESSES

16

5.1

Sales Order or Contracts with Category A

16

5.2

Sales Order with Category B

16

5.3

Contract + Call-off Orders with Category B

16

5.4

Sales order or Contract with Category D

16

5.5

Credit/Debit Memo Request with Category A or B

17

5.6

Credit/Debit Memo Request with Category D

17

5.7

Credit/Debit Memo Request with Category F

17

5.8

Credit/Debit Memo w/o request with Category A or B

17

5.9

Return Order with Reference to a Sales Order with Category B

18

5.10

Return Order with Reference to a Contract/Call-off Order with Category B

18

6

SPECIAL PROCESSES

19

6.1

Invoice Cancellation (VF11)

19

6.2

Sales Document Items with Rejection Code

19

6.3

Revenue Recognition Cancellation (VF46)

19

6.4

Foreign Currency Handling

20

6.4.1

Fixed Exchange Rate Method (FX1)

20

6.4.2

Actual Exchange Rate Method (FX2)

20

6.5

Price Change in SD

21

7

VALUABLE OSS NOTES

22

1

INTRODUCTION

1.1

Overview

The SD Revenue Recognition (SD RR) functionality has been available in SAP ECC since 2005.It was developed to cover the requirements to defer revenues and recognize them as either event or time-based. This was driven mainly by US GAAP regulations and since 2005 has become a proven and stable component that is used by thousands of SAP customers.

As soon as the new regulations from IFRS15 were visible, discussions began on whether SD RR could be used beyond its original scope to cover the new requirements. As SD RR does not offer sufficient functionality, the decision was made to develop SAP Revenue Accounting and Reporting (SAP RAR) as a new solution. The aim for SAP RAR was 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 (minimum prerequisite is release 6.0 with enhancement package 5) or SAP S/4HANA. For integration with Sales and Distribution, you will also require software component SAP Sales Integration with SAP Revenue Accounting and Reporting 1.0 (SAP SALES INTEGR SAP RAR 1.0).

For more information on supported software stacks please refer to the Release Strategy Note: 2386978 - Release strategy for the ABAP add-on REVREC 130.

As of SAP S/4HANA 1809, the former SAP Revenue Accounting and Reporting add-on has become an integral part of SAP S/4HANA. This relates to product version SAP REVENUE ACCOUNTING and includes software component version REVREC. The software component SAP Sales Integration with SAP Revenue Accounting and Reporting 1.0 (SAP SALES INTEGR SAP RAR 1.0) has also been added to the SAP S/4HANA 1809 stack.

For more information on S/4HANA 1809 please refer to the following Note: 2675360 - Revenue Accounting and Reporting with SAP S/4HANA 1809: Release Information Note.

When SAP S/4HANA was developed, the decision was made to only proceed with one solution to defer and recognize revenues in the on-premise stack. 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/implementation.

It is not possible to migrate SD RR to SAP RAR after the Go-live with S/4HANA.

As a migration cannot be fully automated and you need to setup SAP RAR before you start the migration, this should be considered as a separate project and should not be combined with the S/4HANA implementation. The project must be planned carefully with sufficient time and resources so that the migration is finished before the S/4HANA project starts.

The purpose of this migration guide is to provide guidance on all processes and steps that must be executed during migration.

1.2

Timeline / End-to-End Process

The following graph outlines a common project setup:

1.2 Timeline / End-to-End Process The following graph outlines a common project setup: 5

2

RESTRICTIONS

2.1 Migration Prior to S/4HANA

As the SD RR functionality is no longer available in S/4HANA, migration from SD RR to SAP RAR is necessary prior to the implementation of S/4HANA. In the unlikely scenario where a customer might use SD RR in a system with a release lower than 6.05, the system first must be upgraded to a release higher than or equal to 6.05. RAR can then be implemented, and migration from SD RR be performed. Finally, conversion to S/4HANA is made possible.

2.2 Out-of-Scope

All SD RR processes (categories) can be migrated to SAP RAR. There is only one exception; if customer- specific events were implemented in SD RR, the related sales documents cannot be migrated adequately. Industry solutions that influence the standard Sales & Distribution processes (e.g. IS-OIL, IS-ADEC-BCQ) were not validated or released. Therefore, these solutions are also not supported in the integration component respectively in the migration process.

Depending on the support stack of SAP RAR 1.3 that is used, other restrictions may apply. Please carefully read OSS Note 2591055.

3

PREREQUISITE ACTIVITIES

3.1 Consistency Check of SD Revenue Recognition Data

As with other data migration scenarios, it is recommended that you ensure all source data is correct and consistent prior to being transformed into the new environment by the migration process.

Transaction VF47 in SD RR (Revenue Recognition: Inconsistency Check in Revenue Tables) can be used for checking source data. VF47 is a very powerful tool that enables you to identify many different inconsistency types in the SD RR data.

More information about VF47 and the potential error codes can be found in OSS Note 399777.

potential error codes can be found in OSS Note 399777 . A second check is performed

A second check is performed using the Read Revenue Lines in FI flag instead of Read Revenue Lines in SD.

Lines in FI flag instead of Read Revenue Lines in SD . Note: The Read Revenue

Note: The Read Revenue Lines in FI option does not provide reliable results if FI summarization is active for postings from SD RR (IMG: Financial Accounting resp. Financial Accounting (New) Periodic Processing Integration Sales and Distribution Perform Document Summarization for Sales and Distribution).

The same restriction applies if the relevant FI documents from SD RR have been already archived.

3.2

Update Sales documents with VF42

Before you proceed with the migration process, you should ensure that all revenue lines in the table VBREVE (Revenue Recognition: Revenue Recognition Lines) have the most actual values.

This can be achieved by running the transaction VF42 (Revenue Recognition: Update SD Documents). This transaction checks if there are remaining entries in the table VBREVC (Revenue Recognition: Worklist of Changed Sales Documents) and executes an update of the sales documents.

Documents) and executes an update of the sales documents. You do not need to run the

You do not need to run the transaction VF42, if the sales documents are updated in real-time in SD RR (IMG: Sales and Distribution Basic Functions Account Assignment/Costing Activate SD Functions). In this case, there must be no entries in the table VBREVC.

All sales documents, for which entries in VBREVC exist, are not picked up by the operational load.

3.3 Recognize Open Revenues with VF44

If the end date of the SD RR relevant sales document is in the past, all open revenue lines must be recognized before migration starts. Otherwise, all follow-up processes in SAP RAR (such as re-scheduling) may not work correctly.

Use transaction VF44 (Revenue Recognition: Post Revenue) to recognize all open revenue lines. Please consider even revenue lines that are blocked manually. You can recognize blocked revenues by setting the relevant flag on the VF 44 selection screen.

by setting the relevant flag on the VF 44 selection screen. In all other cases, it

In all other cases, it is recommended that you recognize all revenues up to the transfer date, even from a business perspective.

3.4

Setup of SAP Revenue Accounting & Reporting

3.4.1 Customizing

To prepare for the migration itself, the future revenue accounting and reporting processes must all be set up first. The majority of the customizing settings can be found here: IMG: Financial Accounting resp. Financial Accounting (New) Revenue Accounting. Alternatively, the transaction FARR_IMG can be used to reach the revenue accounting customizing. The main processes include:

Activation of the required Revenue Accounting Item classes and generation of the interfaces

Setup the accounting principles and maintain the company code related settings

Creation of contract categories and POB (Performance Obligation) types, including the related number ranges

Maintenance of the BRF+ application for the SAP RAR processes (access also possible using transaction BRF+)

Create the accounts and setup account determination for RAR-specific P&L and balance sheet accounts

3.4.2

Migration Packages

The creation and use of migration packages is not mandatory for the SD RR migration. Migration packages are only required if the migration should be performed in multiple waves. This means that after the migration of the first wave, revenue accounting is already productive. In this case, the migration package is required for the next wave to start again as the next migration package has status set to Migration. Example:

Two different SD RR processes should be migrated in company code 1000; one is represented by item category ZRRA and the other by ZRRB. In the first wave, all sales document items with ZRRA should be migrated.

Setup of IMG: Sales and Distribution Revenue Accounting and Reporting Maintain Revenue Accounting Item Settings: The appropriate revenue accounting type is assigned to the combination sales organization, order type, and item category ZRRA, but has no package ID assigned.

Setup of IMG: Financial Accounting resp. Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Assign Company Codes to Accounting Principles: One line is maintained per combination company code 1000/accounting principle, and the status is set to Migration. No further lines are required on the second level of this customizing view.

When you start the operational load, the Migration Package ID field should be empty. After the first migration wave is finished, the status is set to Productive. One month later, the second wave should follow for sales document items with item category ZRRB.

Setup of IMG: Sales and Distribution Revenue Accounting and Reporting Maintain Revenue Accounting Item Settings: The appropriate revenue accounting type assigned to the combination sales organization, order type, and item category ZRRB. Now you need to assign a package ID (M001 for example), which also needs to have been created before.

Setup of IMG: Financial Accounting resp. Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Assign Company Codes to Accounting Principles: Create an additional line with Package ID M001 on the second level related to the existing line for company code 1000 and set the status to Migration.

When you now start the operational load, the migration Package ID M001 has to be entered on the selection screen.

3.4.3

Transfer Date

On the first level in the customizing transaction IMG: Financial Accounting resp. Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts: Assign Company Codes to Accounting Principles

and if required, maintain a transfer date on the second level. The transfer date must be always the last day of

a period and cannot be a future date.

Usually, this date identifies the point-in-time on which SD RR stops for a corresponding set of SD Documents and SAP RAR continues with the migrated documents. It means that for SD RR migration, the operational load only selects the posted revenue lines that are assigned to periods lower or equal to the period of the transfer date. Legacy data for SAP RAR is also created.

3.4.4 Special SD Processes

If in SD RR, special event types such as proof of delivery (PoD) or incoming invoice are used, the

corresponding entries must be maintained in IMG: Sales and Distribution Revenue Accounting and Reporting Activate Functions to Integrate with Revenue Accounting.

3.4.5 Activation of Inflight Checks

Inflight checks were introduced with SAP RAR Release 1.3. These checks are executed when you process the RAIs to create or change RAR contracts and POBs. The aim is to detect inconsistencies as early as possible, before any contracts or POBs are stored in the database. Please ensure that the checks provided by BAdI FARR_EXTENDED_CHECK are not de-activated or manipulated. More information about the BAdI can be found in OSS Note 2476987, and more information about inflight checks can be found in OSS Note 2567106.

4

MIGRATION TOOLS

4.1

Operational Load

4.1.1

General Functionality

Then main tool that is used to migrate SD RR data to SAP RAR is the operational load program. Transaction FARRIC_OL or customizing menu IMG: Sales and Distribution Revenue Accounting and Reporting Execute Operational Load is used to start the migration process.

This program creates fulfillment RAIs and invoice RAIs based on the selected sales documents order RAIs. 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). That means that nothing can be processed by referring to the migrated documents using VF44/VF46 after the operational load has been executed.

Additionally, all table entries from SD RR remain available for reporting or audit purposes.

4.1.2 Prerequisites

The operational load only works as expected if:

the SD item categories that initially are assigned to a SD RR revenue recognition category are set up in the SD Integration Component as relevant for SAR RAR (IMG: Sales and Distribution Revenue Accounting and Reporting Maintain Revenue Accounting Item Settings)

the Integration Component for Revenue Accounting is activated (IMG: Sales and Distribution Revenue Accounting and Reporting Integrate with Revenue Accounting and Reporting)

the affected company code is customized for initial load, meaning that status Migration must be assigned to the relevant company codes (IMG: Financial Accounting New Revenue Accounting Revenue Accounting Contracts Assign Company Codes to Accounting Principles).

4.1.3

Selection

Based on the entered selection parameters; company code, sales organization, distribution channel, sales document type, sales document, creation date and migration package ID; for all selected documents, the root documents are selected.

The root document is the document that is found on the highest level of the document flow. Afterwards, for each root document, all follow-up documents down to the lowest level are determined (including sales documents, delivery documents, and billing documents).

For SD RR-relevant sales documents, the item status in table VBUP is checked. The document is skipped if the revenue determination status (VBUP-RRSTA) is C.

Another important selection criterion is the document date of the sales document. Only if the document date is older than or equal to the migration transfer date, the documents are selected by the operational load.

4.1.4 Processing Parameters

External Run ID For every execution of the operational load, there is a unique ID to identify the run. This ID is generated automatically. If required, an explicit unique external key can be entered. This can be useful as the content of this field is displayed in the application log (Transaction SLG1) and can be used to identify different runs.

Processing Type Apart of the type Load which creates the RAIs and the legacy data, the program can also be executed using the Reset type. If an operational load (or any further processing in Revenue Accounting) was not successful and the operational load should be performed again, the previously loaded documents must be reset first.

Otherwise, the operational load cannot select them again. Reset means that the Revenue Accounting relevance is removed from the corresponding item and the revenue lines in the table VBREVE are activated again. Therefore, the program recovers the state in SD that existed before the last operational load, but only

if the same selection criteria is applied.

Note: RAIs created by the operational load are not deleted by using the Reset option. If this is required, the transaction FARR_IL_CLEANUP (Initial Load: Cleanup Report) must be applied.

Synchronous Online Processing By default, when you execute the program, the system creates jobs automatically in the background. Normally one job works on one package (see below) and the next one is created automatically once the first job is finished. To get automatic parallelization, there is an additional option to maintain the number of jobs that should be started automatically in parallel.

4.1.5 Expert Mode

If the selected options of the transaction FARRIC_OL are not sufficient, the extended version can be used

with transaction FARRIC_OL_EXPERT. This provides some additional flags that can be used to control the behavior of the operational load in more detail. However, these flags are provided to cover all different migration scenarios. For some flags, it does not make sense to change the default setup for migration from SD RR to SAP RAR.

The following section describes the purpose of the additional options:

Process Fulfillment Documents

If this checkbox is selected, the fulfillment documents of the selected sales orders are processed too. In most cases, this flag must not be deleted. Only if custom specific event types were implemented in SD RR it should be part of a bespoke solution.

Process Billing Documents

If this checkbox is selected, the billing documents in the document flow of the selected sales documents are processed too. It should never be deselected for SD RR migration.

Create Legacy Data

If this checkbox is selected, legacy data creation is performed. The realized revenue is obtained from SD RR (from the posted revenue lines in table VBREVE) if a sales document item is relevant for SD RR (meaning that VBKD-RRREL is not blank) and the integration component for SAP RAR is active (IMG: Sales and Distribution Revenue Accounting and Reporting Integrate with Revenue Accounting and Reporting). For SD RR migration to SAP RAR, this flag should not be deselected.

Search for Root Documents

If this checkbox is selected, the selection of the involved documents is performed as described in chapter

4.1.3. Only if it is requested that the selection of the documents should start with the numbers entered on the selection screen, then successor documents should only be determined downwards from there (to the lowest level of the document flow) should this flag be selected.

Read from Archive

If this checkbox is selected, SD billing documents and FI documents that are archived, are read from the

archive if they are required as a basis for the migration RAIs and legacy data. If this option is deselected and

a document is archived, an error message is raised.

Skip completed Sales Documents

If this checkbox is selected, the set documents that are determined by the entered selection is reduced by

already completed documents. The completion is identified in table VBUK. Only documents without status C are considered for the overall processing status of document (VBUK-GBSTK) or documents that have status

C in VBUK-GBSTK and the revenue determination status (VBUK-RRSTA) is A or B.

Transfer Revenue Schedule Without selecting this checkbox (default setting), SAP RAR would distribute the migrated transaction price per POB to the periods according to the rules maintained in BRF+ and then save the result into the revenue schedule. Only if a special distribution was implemented in SD RR (BTE event 00503105) and this distribution should be transferred to SAP RAR, this flag must be selected. This flag is only relevant for SD documents with revenue recognition category A or D. Even if the flag is selected and there are open revenue lines before the transfer date, the open amount is accumulated into the first period after the transfer date.

Incl Rev status cmpl items By default, the operational load would not consider sales document items that are already completed from an SD RR perspective, meaning those that have a revenue determination status of C in table VBUP. If it is required that such document items are considered by the operational load, this flag must be selected.

Create FX Dif. Conditions

If the FASB52 functionality was activated in SD RR (see also chapter 0) and in SAP RAR, the actual

exchange rate method is used, additional lines are added to the legacy data with the operational load that represent the cumulated value of legacy exchange rate gains or losses caused by the SD RR postings. To enable this functionality this flag must be selected.

If FASB52 was not in use in SD RR, it is strongly recommended to deselect this flag in order to improve the performance of the operational load.

4.2 Revenue Correction Report

This report is necessary if in SD RR, between transfer the date and the date of the operational load, VF44 postings and/or SD RR relevant billing documents were created. You can use either the transaction FARRIC_RR_CORR or for the expert mode, transaction FARRIC_RR_CORR_EXP (report FARRIC_SD_REV_CORRECT). The expert mode allows you to deactivate the correction functionality for billing documents, which is not possible in the basic mode.

Corrections can only be done if the report is performed while the corresponding combination of company code/migration package has the Migration status.

The latest updates for this correction report are provided with OSS Note 2715378. If this note is implemented, the table FARRIC_MIGRATED can be checked with transaction SE16 to see which SD documents require revenue correction. For all SD documents that display values X, I, or R in the field INV_CORR, the correction program must be performed.

4.2.1 Correction of Revenues

To explain this functionality, the following example is used:

A SD document item with SD RR category A exists with start date 01.01.2018, end date 31.12.2018, and a

net value of 1.200 EUR. Lines in table VBREVE were created and are already recognized with transaction VF44 for the periods January to April (in total 400 EUR). The corresponding billing document was posted too in period 1/2018. For migration, the transfer date is set to 31.03.2018. The operational load in April would create an order RAI (which creates one POB with the transaction price of 1.200 EUR), an invoice RAI with the same amount (both with initial load flag), and legacy data with an accumulated amount of 300 EUR. Although 400 EUR are already recognized in SD RR, the legacy amount is 300 EUR as revenues are only considered if they were posted prior to the transfer date. Within the revenue schedule of the created SAP RAR contract, 100 EUR is assigned to each period; even to period 4, which is the first period after the transfer date. If the posting is executed in SAP RAR, revenues would be created for period 4 again. In this case, the revenues in period 4 would be doubled (100 EUR realized by VF44 and 100 realized by the SAP RAR posting run).

The transaction FARRIC_RR_CORR can now be used to reverse the revenues already posted in SD RR. The reversal works exactly as known from transaction VF46. An additional revenue line in VBREVE for period 4 with reversed signs is created and immediately posted. A second line is created for period 4 again with status A and fixed revenue line indicator M.

4.2.2

Correction of Billing Documents

To explain this functionality, the following example is used:

A SD document item with SD RR category A exists with start date 01.01.2018, end date 31.12.2018, and a

net value of 1,200 EUR.

Lines in table VBREVE were created and already recognized with transaction VF44 for the periods January

to March (in total 300 EUR).

The billing document is created in period 4/2018. For migration, the transfer date is set to 31.03.2018. The operational load in April would create an order RAI with an initial load flag (this creates one POB with the

transaction price of 1.200 EUR), and an invoice RAI with the same amount without an initial load flag, and legacy data with an accumulated amount of 300 EUR. After Go-live, the processing of the invoice RAI would create invoice correction lines in the SAP RAR sub- ledger because SAP RAR assumes that revenues caused by a billing document must be reversed. However, the billing document in SD RR have not been posted to revenues, but to a balance sheet account instead. Therefore, reposting is now necessary from the balance sheet account to revenues. This re-posting document is created by the transaction FARRIC_RR_CORR. Changes in the SD RR tables are not necessary.

4.3

Checks

4.3.1

Revenue Accounting Contracts Consistency Check

To ensure quality and consistency for SAP RAR contracts and POBs created by the migration process, the transactions FARR_CONTR_CHECK and FARR_CONTR_MON can be used.

Note: the standard version of this check helps determine technical inconsistencies within the SAP RAR contract management database. It does not reconcile the RAR contract data against the corresponding documents in the sender component.

To enhance the program functionality so that also the basic SD values are compared with the transaction price of the resulting POBs, the BAdI FARR_BADI_CONS_REPORT can be implemented. SAP provides sample coding that can be inserted into the BAdI Implementation. More information on this process is provided in OSS Note 2714781.

How to use both transactions and how the error codes can be interpreted is explained in the document SAP Revenue Accounting Data Validation.pdf which is attached to OSS Note 2567106.

4.3.2 Two-Step Reconciliation

The following two transactions were developed to focus separately on the two steps SD RAI and RAI

RAR Contract/POB unlike the consistency check described above. The reports are useful in the test phase of the migration project, where single test cases must be checked. It

is not proven that a high volume of documents/RAIs can be analyzed without performance issues.

4.3.2.1

Comparison SD data with Revenue Accounting Items

Since the value flow from the source component to SAP RAR may cross system boundaries, the transaction FARR_CHECK_CONS was developed to ensure that the source data has been transferred correctly to the inbound layer of SAP RAR.

For SD RR migration, it is useful to ensure the RAIs that were created based on the SD documents are correct.

In general, the report expects processed RAIs. Therefore, an error message is created if processable RAIs are selected. That would mean in the case of SD RR migration, that a large volume of error messages would be raised if the check is performed right after the creation of the processable RAIs by the operational load.

To avoid this, the messages can be deactivated by using a special customizing setting (IMG: Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Change message control). Insert a new line for message number 507 and disable the message for online and/or batch mode.

4.3.2.2 Comparison Revenue Accounting Items with RAR Contract Data

Use transaction FARR_RAI_RECON to reconcile the amounts and quantities from the processed revenue accounting items with the resulting POB values.

5

MIGRATION OF THE REVENUE RECOGNITION PROCESSES

Every process type of SD RR is explained in this chapter in terms of how it should be processed to get it into the new SAP RAR environment.

Each section starts with an overview of the main settings in the source (SD RR) and the target (SAP RAR) environment.

As already mentioned in chapter 0, the settings for SAP RAR must be maintained before migration starts. The column Revenue Accounting Type refers to the customizing setting where the revenue accounting type is assigned to sales organization, order type, and item category (IMG: Sales and Distribution Revenue Accounting and Reporting Maintain Revenue Accounting Item Settings).

5.1 Sales Order or Contracts with Category A

Revenue Recognition Category A = Time-related revenue recognition

SD Revenue Recognition

 

SAP Revenue Accounting and Reporting

SD Document

Revenue

Revenue

Revenue

Fulfillment

Event

Start

Recognition

Event

Accounting

Type

Type

Date

Category

Type

Type

Type

Sales Order/Contract

A

N/A

X

T

N/A

1

5.2 Sales Order with Category B

Revenue Recognition Category B = Service-related revenue recognition

SD Revenue Recognition

 

SAP Revenue Accounting and Reporting

SD Document

Revenue

Revenue

Revenue

Fulfillment

Event

Start

Recognition

Event

Accounting

Type

Type

Date

Category

Type

Type

Type

Sales Order

B

 

X

E

GI

N/A

Sales Order with PoD

B

 

X

E

PD

N/A

Sales Order with PoD

B

N

X

E

GI

N/A

Sales Order

B

A

X

E

PI

N/A

Sales Order

B

B*

X

E

???

N/A

* Solution evaluated, but not yet available

5.3 Contract + Call-off Orders with Category B

Revenue Recognition Category B = Service-related revenue recognition

SD Revenue Recognition

 

SAP Revenue Accounting and Reporting

SD Document

Revenue

Revenue

Revenue

Fulfillment

Event

Start

Recognition

Event

Accounting

Type

Type

Date

Category

Type

Type

Type

Contract

B

 

X

E

RO

N/A

Sales Order (call-off)

B

 

C

E

GI

N/A

5.4 Sales order or Contract with Category D

Revenue Recognition Category D = Billing-related, time-related revenue recognition

SD Revenue Recognition

 

SAP Revenue Accounting and Reporting

SD Document

Revenue

Revenue

Revenue

Fulfillment

Event

Start

Recognition

Event

Accounting

Type

Type

Date

Category

Type

Type

Type

Sales Order/Contract

D

N/A

G

T

N/A

1

5.5

Credit/Debit Memo Request with Category A or B

SD Revenue Recognition

 

SAP Revenue Accounting and Reporting

SD Document

Revenue

Revenue

Revenue

Fulfillment

Event

Start

Recognition

Event

Accounting

Type

Type

Date

Category

Type

Type

Type

Stand-alone Credit/ Debit Memo Request

A

N/A

X

T

N/A

1

Stand-alone Credit/ Debit Memo Request

B*

 

X

E

???

N/A

* Solution evaluated, but not yet available

5.6 Credit/Debit Memo Request with Category D

SD Revenue Recognition

 

SAP Revenue Accounting and Reporting

SD Document

Revenue

Revenue

Revenue

Fulfillment

Event

Start

Recognition

Event

Accounting

Type

Type

Date

Category

Type

Type

Type

Credit/Debit Memo Request

D

N/A

G

T

N/A

1

5.7 Credit/Debit Memo Request with Category F

Revenue Recognition Category F = Credit/Debit Memos with reference to predecessor

SD Revenue Recognition

 

SAP Revenue Accounting and Reporting

SD Document

Revenue

Revenue

Revenue

Fulfillment

Event

Start

Recognition

Event

Accounting

Type

Type

Date

Category

Type

Type

Type

Credit/Debit Memo Request

F

N/A

M

     

In this case, in SAP RAR there are no necessary separate settings for the fulfillment type, event type, and start date type because the SD credit/debit memo request does not create order RAIs. It only triggers the creation of invoice RAIs based on the credit/debit memo that belongs to the credit/debit memo request with revenue recognition category F.

5.8 Credit/Debit Memo w/o request with Category A or B

If credit/debit memos that were created with reference to a revenue recognition relevant billing document should be migrated, no separate settings in SAP RAR are necessary. Only invoice RAIs are generated with a reference to the number of the basic SD RR-relevant sales document. The settings for the correct migration of the initial sales document must be done according to the sections described above.

5.9

Return Order with Reference to a Sales Order with Category B

SD Revenue Recognition

 

SAP Revenue Accounting and Reporting

SD Document

Revenue

Revenue

Revenue

Fulfillment

Event

Start

Recognition

Event

Accounting

Type

Type

Date

Category

Type

Type

Type

Return Order

B

 

X

E

GI

N/A

5.10 Return Order with Reference to a Contract/Call-off Order with Category B

SD Revenue Recognition

 

SAP Revenue Accounting and Reporting

SD Document

Revenue

Revenue

Revenue

Fulfillment

Event

Start

Recognition

Event

Accounting

Type

Type

Date

Category

Type

Type

Type

Return Call-off Order*

B

 

C

E

GI

N/A

* Solution evaluated, but not yet available

6

SPECIAL PROCESSES

6.1 Invoice Cancellation (VF11)

If in SD for a SD RR relevant sales document, a billing document and a cancellation of the billing document

was created (both with posting dates prior to the transfer date), nothing in addition must be considered from

a migration perspective. These billing documents are skipped by the operational load as they completely offset each other; their documents even remain in SD RR in table VBRP (Billing document items).

If these types of documents are treated with the operation load, the resulting RAIs appear as if there was no billing document posted at all, meaning that no invoice RAIs are created.

If the posting date of the billing cancellation is after the transfer date, then the operational load considers

both the original billing document (RAI with initial load flag) and the billing cancellation (without the initial load

flag). Nevertheless, the correction program described in chapter 4.2.2 should be applied.

A special behavior was designed for sales documents with revenue recognition category D. These billing

document items are only excluded from the operational load if both, the cancelled document and its cancellation, are fully realized in transaction VF44. If either of these processes still has open revenue lines, then the two documents do not cancel each other out completely. Their exact legacy amounts must be accumulated and transferred into two separate RAR contracts so that the open revenue is scheduled accordingly in SAP RAR.

6.2 Sales Document Items with Rejection Code

SD document items with a rejection code assigned are treated by the operational load in the same way as normal document items. For example, in the operational process, the rejection code in SD triggers the population of the field Finalization Date in the order RAI. This tells the RAR contract respectively, that the performance obligation has to be completed.

For migration, the operational load fills the last change date from the table VBAK (header data of a sales document) into the finalization date of the created order RAI.

6.3 Revenue Recognition Cancellation (VF46)

If within the periods that should be migrated, revenues were reversed in SD RR with transaction VF46,

nothing extra must be considered for the SD RR migration. The cancelled lines are correctly handled when the legacy data is calculated; the legacy amount is reduced by the revenue amount of the period that was reversed.

Note: The reversal line and the reversed line do not get M in field VBREVE-REVFIX (like all other posted VBREVE lines), but keep A (reversed line) and B (reversal line) instead. These lines are completely skipped when the cumulated revenue amount is calculated for the legacy data transfer.

6.4

Foreign Currency Handling

In SD RR, a feature is available to avoid remaining balances in a local currency on the accrual accounts if the transaction currency of the basic sales document is not equal to the local currency of the corresponding company code. It can be found under the key word FASB52. This can be activated within the view

V_160MVA with the variable message V4 314 (see also OSS Note 786266) or within IMG: Sales and

Distribution Revenue Accounting and Reporting Activate Functions to Integrate with Revenue Accounting. The first posting related to a sales document item, fixes the used exchange rate (date of the exchange rate) and all follow-up postings use the fixed rate to calculate the values in the local currency. In addition, the differences are posted to an exchange rate difference account.

In SAP RAR, there are two different methods for converting contract values in a foreign currency to the local currency(ies): the fixed exchange rate method (FX1) and the actual exchange rate method (FX2). More information on both methods can be found here.

The required method must be assigned to the used accounting principles (IMG: Financial Accounting resp. Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Configure Accounting Principle-specific Settings).

To prepare for exchange rate differences that can be updated in the table FARR_D_POSTING, one special condition type has to be defined and assigned in the following customizing view: IMG: Financial Accounting resp. Financial Accounting (New) Revenue Accounting Revenue Accounting Contracts Condition Types Define Reserved Condition Types.

The system behavior of the migration process differs depending on which conversion method is chosen.

6.4.1 Fixed Exchange Rate Method (FX1)

If the FASB52 functionality was used in SD RR, a fixed exchange rate is transferred by the operational load to the legacy data (table FARR_D_LEGACY), however, the exchange rate differences that were already posted are not handed over to SAP RAR. When the RAIs and the legacy data that were created by the operational load are processed, SAP RAR calculates currency differences ex post based on the transferred fixed exchange rate and saves it directly in the table FARR_D_POSTING with posting category ED.

6.4.2 Actual Exchange Rate Method (FX2)

If the FASB52 functionality was activated in SD RR and in SAP RAR the actual exchange rate method is used, the operational load creates (in addition to the legacy data = already recognized amounts) entries in the table FARR_D_LEGACYC that represent the accumulated value of the already posted exchange rate differences in FI.

Based on these special legacy table entries, an additional table is filled during the processing of the RAIs:

table FARR_D_INV_FX_ED.

Finally, out of this table, program B (FARR_CONTRACT_LIABILITY) creates lines in table FARR_D_POSTING with posting category ED that represent the already posted exchange rate gain/loss postings up to the transfer date.

Note: If the exchange rate differences are already determined by the operational load and handed over to SAP RAR via the legacy data, the report FARR_MIGRATION_ED_CALC must not be started after the processing of the migrated RAIs.

If FASB52 functionality was not used in SD RR, no exchange rate difference data is transferred to SAP RAR at all. Exchange rate differences are calculated in SAP RAR as of the transfer date according to the rules of

FX2.

In some cases, in SD RR it was requested that even with activated FASB52 functionality, revenues in foreign currency should be converted with the fixed exchange rate but should not create exchange rate difference lines. This can be achieved by using BTE 00503115. However, the operational load does not consider this BTE and creates exchange rate differences lines in the legacy data regardless of whether the actual

exchange rate method is used in SAP RAR. To adjust these automatically created exchange rate difference lines in the legacy data table, a bespoke solution is required.

6.5 Price Change in SD

There is one situation in SD RR that cannot be handled adequately by the SAR RAR standard coding. Therefore, additional measures are required to migrate these documents. The issue occurs when the total amount of calculated legacy data per SD sales document item exceeds the current net value of the item.

Example:

Initial SD sales document item with RR category A, net value of 1200 EUR, start date 01.01.2018, and end date 31.12.2018. Revenue Lines are created with 100 EUR per period.

Transfer date should be 31.10.2018 and 1,000 EUR revenues are already recognized until period 10 by VF44. Before =migration starts, the net value of the sales document item is changed to 960 EUR. This generates an adjustment line in table VBREVE for period 11, with a 120 EUR revenue reversal and a regular line in period 12 with 80 EUR.

The operational load creates an order RAI with a contractual price of 960 EUR and legacy data of 1,000 EUR. This would create an inconsistency within the revenue schedule of the RAR contract.

To mitigate this situation, SAP provides the correction report ZFARR_CALC_REV_AMT via OSS Note

7

VALUABLE OSS NOTES

It is recommended that you are always 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:

Note

Description

Number

The redesigned SD Revenue Recognition type "D" migration is now available

Validation for Proof of Delivery

"Proof of Delivery" creates Fulfillment Event

Call-Off Order creates Fulfillment Event

Documentation of data validation checks in revenue accounting and reporting

RAR GoLive preparation - additional checks

Operational load: FASB 52 migration redesign

RA FARR_INITIAL_LOAD_STATUS_API enhancement

Operational load: SD Revenue Recognition correction report redesign

Operational load: Correction revenue line deleted during RESET

Operational load: Open revenue lines are getting lost from the revenue schedule

Operational load: LOAD and RESET of SD Revenue Recognition documents deactivated in S4CORE systems

SD Integration Component: Important core changes not included in Add-On REVRECSD

www.sap.com/contactsap

© 2018 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/copyright for additional trademark information and notices.

trademarks of their respective companies. Se e www.sap.com/copyright for additional trademark information and notices.