current period, it considers the figures from the migration period, such as revenue, that has already been posted
through a legacy revenue recognition system. These values can therefore never be changed in Revenue
Accounting. For this reason, the migration period has to be closed in the operational application before the
operational load starts. The period in Revenue Accounting must also be closed before revenue accounting items
from operational load are processed.
Note
Please make sure that you have closed the migration period in General Ledger before the operational load
starts. Also you need to make sure that you have set the migration period in Revenue Accounting to status
Closed or In-Closing before revenue accounting items (RAIs) from operational load are processed. However, in
the case of Result Analysis migration, the migration period in Revenue Accounting should only be set to status
In-Closing.
Closing a period usually takes some time in order to allow data for new contracts, contract changes, fulfillment
events and invoices to be created in the operational applications between the transfer date and execution date of
the operational load. Any changes to operational items between the transfer date and execution of the operational
load will be taken into account as if they had already occurred before the transfer date.
Revenue Accounting assigns fulfillments and invoices with an event or posting date to the respective period
defined for this event or posting date after the transfer date. So they will be handled as if Revenue Accounting
were active when they were posted.
The complete migration, consisting of operational load and initial load, usually takes some time. Revenue
Accounting integration has to be activated as soon as the operational load starts. Revenue Accounting does not
require a downtime.
Information created by the operational load, such as orders, fulfillments, and invoices, that does not belong to the
migration period, such as a date after the transfer date, will first be suspended and processed later on when the
company code or migration package is set to Production.
As long as the company code or migration package is not yet set to Production, all new documents and any
changes made to existing documents belonging to this company code or migration package will also not be
processed. This means that they will remain, but are suspended, in Revenue Accounting.
You therefore have to reconcile the cumulated values that have been transferred during the migration period with
the balances in the general ledger from postings that have been created from the operational application and the
legacy revenue accounting system up until the transfer date.
The transfer date is usually defined according to the level of company code so that all documents belonging to the
same company code can be loaded in one single step. This means that the complete company code starts its
revenue accounting with Revenue Accounting for the period that follows the transfer date.
This approach is not always feasible. If, for example, a company code has a large data volume or different complex
sales scenarios, it will be too time-consuming to execute and reconcile the complete migration in between two
closings. So the concept of a packaged migration has been introduced. This enables you to perform migration for
one (or several) company codes in several steps. You can do this if operational data, such as contracts, can be
split into several disjoint classes, for example, different businesses, which can then be migrated separately.
16.1.1.1 Migration by Package
You can either perform migration for a complete company code, or you can load revenue accounting items (RAIs)
to Revenue Accounting with finer granularity than an entire company code. This means that you can already start
292
P U B LI C
SAP Revenue Accounting and Reporting
Migration