RR Best Practices V16 Part2

SAP ERP SD REVENUE RECOGNITION -

BEST PRACTICES PART 2

Knowledge Document

Version 1.6

SAP AG Page: 2 Of: 58

S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

SAP ER P SD REVE NU E REC OGNIT ION -

BEST PR ACTICE S

K N O W L E D G E D O C U M E N T (based on ERP Release ECC 6.0)

Release:

Version 1.6, August 2009

Issued by: SAP AG 69190 Walldorf Germany

Revenue Recognition - Best Practices Part 2 Table of Contents

Knowledge Document


S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

1 HANDLING OF REVENUE RECOGNITION DATA ................................................. 5

1.1 Revenue realization processes ................................................................................................................. 5

1.2 Revenue recognition view ........................................................................................................................ 9

1.3 Update of revenue recognition data ...................................................................................................... 11

1.4 Changes in a sales document ................................................................................................................. 13

1.5 Changes in customizing ......................................................................................................................... 14

2 ADDITIONAL FUNCTIONS ................................................................................... 16

2.1 Summarization ....................................................................................................................................... 16 General Information ...................................................................................................................................... 16 Activation of summarization ........................................................................................................................ 16 Additional Remarks ...................................................................................................................................... 17 Relevant Notes .............................................................................................................................................. 18 Example of Summarization .......................................................................................................................... 18

2.2 FASB 52 Solution ................................................................................................................................... 19 FI customizing transactions .......................................................................................................................... 20 Restrictions ................................................................................................................................................... 20 Example (independent from the revenue recognition category) ................................................................... 21

2.3 Completion of contracts ......................................................................................................................... 22

2.4 Proof of Delivery (POD) ........................................................................................................................ 25 2.4.1 Standard - Proof of Delivery ............................................................................................................... 25

General Information ...................................................................................................................................... 25 Process details ............................................................................................................................................... 26 Additional remarks ....................................................................................................................................... 27

2.4.2 Incoming Invoice (Third-party business process) ............................................................................... 28 General Information ...................................................................................................................................... 28 Process details ............................................................................................................................................... 28 Additional remarks ....................................................................................................................................... 29

2.4.3 Customer Acceptance Date ................................................................................................................. 30 General Information ...................................................................................................................................... 30 Process details ............................................................................................................................................... 30 Additional remarks ....................................................................................................................................... 31

2.4.4 Customer-Specific Event ..................................................................................................................... 31 General Information ...................................................................................................................................... 31 Process details ............................................................................................................................................... 32 Additional remarks ....................................................................................................................................... 32

2.5 Handling of costs .................................................................................................................................... 33

2.6 Archiving of revenue recognition data ................................................................................................. 34

2.7 Customer enhancements (User-exit solution/BTE implementation) ................................................ 36

3 RESTRICTIONS ..................................................................................................... 39

3.1 Revenue recognition vs. non revenue recognition postings ................................................................ 39

3.2 Translation of foreign currencies ......................................................................................................... 39

Revenue Recognition - Best Practices Part 2 Table of Contents

Knowledge Document


S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

4 MONITORING OF THE REVENUE RECOGNITION DATA ................................... 40

4.1 Importance of Monitoring ..................................................................................................................... 40

4.2 FI-Monitoring ......................................................................................................................................... 41 4.2.1 Check Account Balances and Line Items ............................................................................................ 41 4.2.2 Reconcile FI and SD Values ............................................................................................................... 42 4.2.3 Automatic Clearing of Accruals Accounts .......................................................................................... 43

4.3 SD-Monitoring with VF45 ..................................................................................................................... 44 4.3.1 VF45 Overview ................................................................................................................................... 44 4.3.2 VF45 Selection criteria........................................................................................................................ 45 4.3.3 VF45 Results ....................................................................................................................................... 45

4.4 SD-Monitoring with VF47 ..................................................................................................................... 47 4.4.1 VF47 Overview ................................................................................................................................... 47 4.4.2 VF47 Selection criteria........................................................................................................................ 47 4.4.3 VF47 Error categories ......................................................................................................................... 52

4.5 SD Monitoring with VF48 ..................................................................................................................... 53 4.5.1 VF48 Overview ................................................................................................................................... 53 4.5.2 VF48 Selection criteria........................................................................................................................ 54 4.5.3 VF48 Result ........................................................................................................................................ 54

Upper part of the VF48 result - Balances ..................................................................................................... 55 Lower part of the VF48 result SD data (VBREV* tables) ......................................................................... 56 Additional functions of the VF48 result ....................................................................................................... 57

5 CONCLUSION ....................................................................................................... 58

Revenue Recognition - Best Practices - Part 2 Knowledge Document


S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

1 Handling of revenue recognition data

1.1 Revenue realization processes

Revenues can be realized after the process is initialized (depending on the revenue recognition method) with the revenue recognition run (transaction VF44). With transaction VF44 the revenues are posted and financial accounting documents are created.

The posted revenues can be cancelled by using transaction VF46, e.g. if revenues have been realized in error. The revenue recognition cancellation is not a real cancellation in the sense of a reverse posting. The balances on the accounts at the creation date of the cancellation are used as a basis.

When transaction VF46 is called there are two possibilities as selection criteria:

an individual sales document (item) or

collective run done with VF44.

With transaction VF46 the revenue lines are changed:

When executing VF46 the original revenue lines and the created cancelled line that is transferred to accounting will be fixed.

The original revenue line is updated with REVFIX A. The cancellation line is updated with REVFIX B. Both revenue lines get the revenue recognition status RRSTA = C.

A new revenue recognition line is created with REVFIX blank and RRSTA = A. This new revenue recognition line should be processed with VF44.

Both transactions VF44 and VF46 can be executed in the dialog mode or in the background. For scheduling the relevant reports as a batch job, use report SDRRAV01 for transaction VF44 and report SDRRAV05 for transaction VF46.

With release 6.00: Block indicator (posting block)

The block indicator/posting block is designed to avoid that revenues can be posted with transaction VF44. Until a service has been performed / an event has been confirmed. This means that while the posting block is set, revenues cannot be posted. The block can also be seen in the revenue lines VBREVE, field REVPOBLCK is filled with X. The block can be set and removed either manually or automatically depending on the process used.

In time-based revenue recognition you can use the posting block manually when executing transaction VF44. There is not an automatic block allocation in one of the time-based processes.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

In service-related revenue recognition it depends on the functions you are using.

If you are not using the function proof of delivery (service has to be confirmed more details see section 2.4 of this document) you can use the posting block manually when executing transaction VF44. There is not an automatic block allocation in one of the time-based processes.

If you are using the function proof of delivery the revenue lines are automatically allocated a posting block. The posting block is allocated upon goods issue or when the service order is saved. According to the functionality the posting block is automatically deleted when the confirmation is done. Then the posting block is automatically deleted and the revenues can be posted. You can delete the posting block in advance manually when executing transaction VF44.

Here are the selection criteria for transaction VF44:

In the selection screen the following items have to be considered:

The last block with the selection fields Revenues to be Recognized and Blocked Revenues that can be flagged are provided with ERP release ECC 6.00. These flags are related to the block indicator.

There is just one mandatory field in VF44, the field posting period. At least a start posting period has to be entered otherwise there are not revenues selected.

The posting date is set as default to todays date but it can be changed.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

As result, a worklist is shown and exact information is provided about which revenues are to be posted according to the selection criteria:

Here is additional information that is good to know:

It is possible to create subtotals and to hide revenue lines manually.

The two pushbuttons Set Blocking ID and Delete Blocking ID are provided with ERP release ECC 6.00. Here a block indicator can be set or deleted. If a block indicator is set manually for an individual revenue line by using the button Set Blocking ID the revenues are not posted for this line. The block indicator is especially relevant for the proof of delivery function.

If one revenue line is selected it is possible to display the control line:

By pushing on the sales document number of the provided control line the sales document is displayed.

If one or more revenue lines are selected and button Collective processing is used the revenue recognition run is executed:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

In the result list the following issues are important to know:

If the revenue recognition documents are created meaning that the revenue posting is done for the revenue line a green light is shown as processing status. The values shown in the list are updated.

If an error occurs during the revenue recognition run the revenue line gets a red light and the error log can be viewed.

If one revenue line with a green light is selected again the control line is displayed with the new values:

By using the button Accounting the financial accounting documents that are created by the revenue recognition run are displayed:

From this screen it is possible to view the single financial accounting documents by pushing on the single document number:

Here is further information regarding the revenue realization process:

Revenue recognition (VF44 or VF46) and invoicing (VF01 or VF04 or VF06) can be run in parallel.

Transaction VF44 and VF46 check before posting revenues, if there are sales documents indicated to be updated. In case of a missing update by VF42, the VF44 / VF46 updates the revenue recognition data.

A complete ROLLBACK WORK does not occur in case there is an error for a single sales document during the posting of the revenues.

Revenue posting with and without summarization is possible. The posting without summarization is delivered as the active default version. For more details please see section 2.1 of this document.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

1.2 Revenue recognition view

To gather an overview of all revenue recognition documents and revenue recognition data that exists for a selected revenue recognition process, the revenue recognition view can be used.

The revenue recognition view is especially needed if the document summarization is active because the retracing to the accounting document is not possible (only compressed posting lines exist in the accounting document).

For getting the revenue recognition view of the revenue postings, three options are available:

From the SD document flow by displaying the revenue recognition document.

From the accounting document (transaction FB03) by going to Environment > Document Environment > Original document.

By using transaction VF43 (report SDRRAV50).

Here are the selection criteria for transaction VF43:

As you can see, the view can be used for a single sales document (item), a collective run number OR for a single accounting document.

As result, a worklist is shown and exact information is provided about the revenue recognition postings according to the selection criteria:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

By pushing on Sales Doc. of the revenue posting line, the sales document is displayed. By pushing on DocumentNo. of the revenue posting line, the revenue recognition document is displayed. With the button Revenue Overview, the revenue recognition data of the selected sales document is displayed (this function is similar to transaction VF45 see section 4.3 of this document):

The block Revenues and Billing Docs is displayed when a control line was selected and the button Display Revenues and Bill.Docs was used in the block Control Lines.

Also there is a link to the financial accounting documents created by the revenue realization process (VF44 / VF46).

Here is additional information regarding the choosing of selection criteria: If you enter in the selection screen a collective run number, the revenue lines of the sales documents which were posted with this collective run number are shown.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

To get all revenue postings of the entered collective run number button All Revenue Positing has to be used.

1.3 Update of revenue recognition data

In certain cases - for example, when you change condition values - revenue lines of the related sales document have to be updated.

Therefore following events initiate an update:

Goods issue posting in case of a delivery relevant processes

Change of the call-off order in case of a contract / call-off order process with order-related-billing

Releasing of an invoice to accounting except in case of revenue recognition category D

Revenue recognition posting (VF44 and VF46) in case of missing information to set revenue recognition status correctly, for example if the relevant item includes a 100 percent discount.

To perform the update there are two available options:

Directly updating of the revenue lines when creating billing document and posting a goods issue. With this option the system is loaded with the order update during billing and goods issue, and so this option is recommended for systems that have a low production rate only.

Indicating the documents to be updated by creating internal worklist entries (VBREVC). The updating of the documents is done at a later time by calling transaction VF42 or automatically during the VF44 run.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

It is possible to switch between these two options by changing the system message category of message V4 313 in view V_160MVA via transaction SM31:

o Message category E Option 1 = Direct update

o Message category W and all other cases Option 2 = Indicate the documents

The second option is delivered as the active default version. It is recommended for main systems. The mentioned events create an internal VBREVC entry for the sales document. The VBREVC entries are the workload for transaction VF42 (report SDRRAV54). Report SDRRAV54 can be called in dialog mode or can be scheduled in the background.

Here is the selection screen for transaction VF42:

In the selection screen, the following items have to be considered:

If the flag According to Automatic Worklist is set, only the revenue recognition data of the sales document for which a VBREVC entry exists are updated.

With transaction VF42 also the revenue recognition data of sales documents without a VBREVC entry can be updated but then the flag According to Automatic Worklist have not to be set.

Here is our recommendation regarding the update functionality:

Use the second option with indication of the documents.

Schedule this report with flag According to Automatic Worklist switched on as a batch job regularly to process documents that have been indicated for additional update via option 2.

Make sure that SDRRAV54 is scheduled before revenues will be posted via VF44 because otherwise VF44 does the update and this means a high system load.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

1.4 Changes in a sales document

There are different changes possible, which will affect revenue recognition data:

time changes such as:

o change in the contract data

o change in the billing plan data:

o end date (FPLA-ENDAT)

o dates from (FPLA-LODAT)

o dates to (FPLA-TNDAT).

o add a settlement period manually

o delete a settlement period manually

price changes such as

o change of a condition value in the sales document

o change of a condition value in the billing document

o add a condition in the sales document

o add a condition in the billing document

setting of a reason for rejection

setting of a billing block

The mentioned changes affect the revenue recognition data in different ways. In some cases, the total accrual value changes and/or the system adjusts the existing revenue lines or the system forecasts new accrual periods. The already recognized revenues remain unchanged.

In the following we provide some more details about the corrections caused by the changes:

If a condition is added manually in the sales document and a time change is done, e.g. a new settlement period is added, the value of the new condition is populated into the accrual periods for the entire validity time and not only for the new settlement period.

o If the new condition has its own G/L account, separate revenue lines are created.

o If for the new condition the same G/L account is determined as for the already existing conditions, the existing revenue lines are updated and, in case of already recognized revenues, adjustment lines are created.

o This is standard functionality due to the fact that pricing occurs at item level and not at the level of the settlement periods.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

If the net value to be recognized in the item relevant for revenue recognition will be changed and if revenues have already been posted, the system must enable a correction posting for the difference amount. This means that the system considers the new situation in whole and checks which correction is necessary by comparing the old and the new amounts for each accrual period. The system checks if the FI posting period is open. Depending on this check the adjustment is carried out in the affected posting period. Otherwise the value is added to the current period (see SAP-note 1096005). For the open accrual periods, the amount which has to be recognized according to the new net value will be set. The revenue distribution customizing is considered when using time based revenue recognition (RRREL = A). Please consider SAP-note 837805.

If a reason for rejection marked as invoice relevant is set in the document item the total accrual value changes. Regarding the revenue lines the following items have to be considered:

o If the item is not invoiced and the revenues are not posted, the system deletes the existing revenue lines.

o If the item is invoiced but revenues are not posted, the system forecasts new accrual periods for the billed value.

o If the item is not invoiced but revenues are already posted, the system forecasts new accrual periods for the recognized value as correction lines. Revenue lines that are not realized before are deleted.

If a billing block is set in the document header or item the total accrual value does not change. The unrecognized revenue lines are blocked and cannot be realized as long as the billing block is set. A different system behavior can be achieved by a BTE solution mentioned with SAP-note 556394.

1.5 Changes in customizing

There are different changes in the customizing possible, which will affect revenue recognition data:

SD item category in the sales document

Accounts changes:

o Revenue account

o Accrual account

The mentioned changes affect the revenue recognition data differently.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

In the following we provide some more details about the corrections/adjustments caused by the changes:

If the sales document item is not invoiced and the revenues are not posted, the item category can be changed in the document. The new item category can be customized with the same or with another revenue recognition type. The revenue recognition data are created according to the new revenue recognition type. In case the new item category is not relevant for revenue recognition, the system deletes the revenue recognition data.

If the sales document is changed, the account determination is executed. If a new revenue account is determined for the sales document after a customizing change is done, this new account is considered for the current process. If revenues are already posted, the system forecasts new accrual periods with the old revenue account as correction lines. Revenue lines with the old revenue account that are not realized are deleted. New accrual periods are created with the new revenue account for the total accrual value.

If the sales document is changed the account determination is executed. If a new accrual account is determined for the sales document after the customizing change is done this new account is only considered for the current process if the sales document is not invoiced and revenues are not posted.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

2 Additional functions

2.1 Summarization

General Information

Summarization is a function that allows for multiple revenue lines from SD documents to be posted to a single financial accounting document while the revenue realization process is carried out (transaction VF44 and VF46). This is helpful when there are many revenue lines with the same accrual accounts and the same G/L accounts but belonging to different SD documents.

Since these revenue lines are posted to different accounting documents, this could result in a large volume of accounting documents making it hard to manage. The summarization function solves this problem by helping have fewer financial accounting documents with higher number of posting lines.

Please consider that summarization is the same as compression in the revenue recognition functionality.

Activation of summarization

The system can only total items in the financial accounting document if they have the same account assignments and only differ in the value fields. It is therefore not possible to carry out the totalling across different G/L accounts.

The summarization can be achieved by deleting the contents of field ZUONR (assignment number) in all items. As a consequence, this field will not contain data in the financial accounting document which will prevent the split of posting lines into several financial accounting documents. Section 4.2.3 of this document explains how the field ZUONR is filled in the financial accounting document items.

Implementation of summarization for revenue recognition involves some steps that are spread over both SD and FI:

The main step in setting up summarization is adding field BSEG-ZUONR to table TTYPV. This indicates that the field ZUONR is cleared in FI. A report attached with SAP-note 940789 (report name: ZZ_TTYPV_VBRR) should be used to add this entry in the database.

In transactions VF44 and VF46, the default value for maximum sales documents to be processed is 300 and maximum number of posted lines in a financial accounting document is 996. This limitation could be modified by implementing and activating business transaction event (BTE) BTE OUTBOUND_CALL_00503116_E. A description of how to activate and use a BTE is available in section 2.4 of this document. Please consider that this step is not mandatory.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Additional Remarks

The Posting Level field in selection screen of VF44 and VF46 is important in the context of summarization. With this field you can define the granularity of summarization at the time of revenue recognition run. You can only summarize the revenue postings under the following posting levels:

o Posting level '1' - Collective processing level

o Posting level '4' - Collective Processing Level (With New Coll.Processing No.s)

The reference key in the header of financial accounting documents no longer contains the sales or billing document number after revenue realization is done. Instead, it contains the relevant collective processing number (SAMMG):

Because of this effect, it may not possible to use customer-specific reconciliation reports and analysis programs. There are two alternative solutions to this problem defined in SAP-note 1131589.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

It is important to note that this change of reference key value to contain value of collective processing number is done every time revenue realization is performed, and is not limited to the use of summarization function.

Relevant Notes

SAP-note 940784 - Document summarization in the revenue recognition

SAP-note 940789 - Implementation details

SAP-note 36353 - Summarization from FI point of view

SAP-note 1131589 - Using reconciliation reports after implementing summarization

Example of Summarization

Three contracts are to be processed with VF44. Since they all contain revenues to be posted to same G/L accounts, it is possible to make only one, summarized, financial accounting document for all three contracts. In the selection screen, enter value for Posting Level, besides other necessary fields.

When executed, the system gives a worklist of revenue lines to be recognized:

Select all lines and use the button Collective Processing.

At this step the revenue lines are posted and one financial accounting document is created. The collective run number is assigned under the Group column as shown below:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

A summary of the processed revenue lines could be viewed in transaction VF43.

Here it is possible to see all the FI and SD documents for the given collective processing number:

Note here that for different sales documents, only a unique financial accounting document is created with all revenue postings compressed into it.

2.2 FASB 52 Solution

General Information

Within the revenue recognition function the statutory requirement FASB 52 (Financial Accounting Standards Board Statement 52) is included. The FASB 52 Statement requires a fixed exchange rate for the entire accrual period. After the sales document is fully invoiced and all revenues are realized there must not be a balance on the 'Deferred Revenues', 'Unbilled Receivables' and revenue account in local currency.

In the revenue recognition functionality the revenues are kept in document (transaction) currency in SD.

With the activation of the FASB 52 solution the system calculates and posts currency differences in local and group currency.

To activate the function the variable message V4 314 (view: V_160MVA) must be defined.

Options: 1. category E - if you want to use the function 2. category W - if you not want to use the function.

Detailed information about the activation can be found in SAP-note 786266.

Functionality historical translation date

To have a fixed exchange rate for the complete revenue recognition process the function determines a date which will be used to determine the related exchange rate. The exchange rate is relevant for all following accrual postings.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

According to the process the first invoice or the first revenue recognition posting fixes the date. This date is called historical translation date. The historical translation date will be saved in the revenue recognition control lines.

FASB 52 solution (valid on august 2009) takes the fixed date for postings to the accrual account(s) and the actual posting date for the revenue account. This is valid for revenue recognition postings and invoice postings.

Because of the exchange rate difference between the historical rate and the actual posting rate FI carries out a currency differences posting to a related G/L account. The currency differences are posted into the same accounting document as the accrued revenues.

The accounts for the currency difference posting have to be setup with transaction OB09.

To influence the historical translation date the business transaction event (BTE) BTE OUTBOUND_CALL_00503115_E can be used as long as the transaction date is not fixed by the first posting. A description of how to activate and use a BTE is available in section 2.4 of this document.

FI customizing transactions

Transaction OB09 to maintain the account information for the exchange rate differences in dependency of the chart of accounts and the revenue account. Two accounts have to be given (gain and loss account).

Transaction OB22 to maintain additional local currencies for company code.

Restrictions

The FASB 52 solution (valid on august 2009) is provided for monetary liabilities, it does not support non-monetary liabilities.

It is not possible to post currency differences in group currency if the transaction currency is equal to the local currency.

Already existing business processes created before the FASB 52 is activated are not processed with this solution.

Exchange rates must not be changed in customizing after a posting is carried out with a historical translation date.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Example (independent from the revenue recognition category)

Net value from the sales document 300

Transaction currency EUR

Local currency of the company code USD

Historical translation date 11/01/2008

Fixed exchange rate 1: 2

Business process:

3. revenue recognition posting (12/01/2008) 100 EUR exchange rate 1 : 1,5 4. revenue recognition posting (01/01/2009) 100 EUR exchange rate 1 : 1,2 5. invoice creation/posting (01/20/2009) 300 EUR exchange rate 1 : 1,6 6. revenue recognition posting (02/01/2009) 100 EUR exchange rate 1 : 1,8



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

2.3 Completion of contracts

Sales processes with contract and items relevant for revenue recognition should be completed when the sales process is finished. To complete sales documents manually, transaction V_MACO can be used.

In case the sales process was completed but should be reopened again, also transaction V_MACO can be executed to reset the completion. SAP-note 801065 provides further details.

To find out if a contract item was completed manually by transaction V_MACO, the field MANEK has to be checked in table VBUP / VBUK. In case a manual completion was done, the field was filled with C.

When transaction V_MACO is used for a contract with items relevant for revenue recognition the related revenue recognition data are influenced. So transaction V_MACO checks the revenue recognition data and updates these data if needed. In detail:

If the sales document is not invoiced and the revenues are not posted, the system deletes the existing revenue lines.

If the sales document is invoiced but revenues are not posted, the system forecasts new accrual periods for the billed value.

If the sales document is not invoiced but revenues are already posted, the system forecasts new accrual periods for the recognized value as correction lines. Revenue lines that are not realized before are deleted.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Here are the selection criteria for transaction V_MACO:

As result a worklist is shown with detailed information:

If one or more line is selected and button Set Status is used the sales document is completed or reopened.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

In the result list the following issues are important to know:

If the sales document was completed or reopened meaning that the status was changed, a green light is shown as processing status.

If an error occurs during transaction V_MACO, the line gets a red light and the error log can be viewed.

By pushing on Sales Doc. of the provided line the sales document is displayed.

With the button document flow, a link is provided to the whole document flow of the selected line.

With the button Revenue Recognition, the revenue recognition data of the selected document is displayed (this function is similar to transaction VF45 see section 4.3 of this document):

When the button Display Revenues and Bill.Docs was used in the block Control Lines, the block Revenues and Billing Docs is displayed.

Also there is a link to the financial accounting documents created by the revenue realization process (VF44 / VF46).



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

2.4 Proof of Delivery (POD)

In service-related revenue recognition (revenue recognition category = B), revenues cannot be recognized until the service has been performed.

When using revenue recognition in combination with POD various confirmation events trigger the revenue realization process. This means that revenue realization depends on the confirmation event. So revenue recognition can be carried out straight after the confirmation event, regardless of when invoicing takes place.

You can use the following events for revenue recognition after performance of service:

Standard - Proof of delivery

Incoming invoice (Third-party business process)

Customer acceptance date

Customer-specific event

The revenue event (except the Standard - POD) is assigned to the item category of the sales document item and can be viewed in the sales document item on tab billing document (in the screen there is no customizing done):

The POD function is based on the business processes that are described in section 4.3 and 4.4 of this document. Credit/debit memo processing as well as return processing is not in scope of the POD function.

In case the process contract with call-off order is used the revenue event has to be assigned to both item categories (contract item and call-off order item).

2.4.1 Standard - Proof of Delivery

General Information

Using service-related revenue recognition in combination with Standard - POD you can carry out recognition based on the quantities which are confirmed in the POD functionality, that means when the customer confirmed the quantity of post goods issue delivery.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

To use this functionality the following settings have to be maintained:

The customer has to be relevant for POD. This has to be maintained on the shipping tab in the customer sales area data (transaction XD03):

In customizing the POD relevance has to be assigned to the delivery item category:

Alternatively it is possible to set the POD relevance on the shipping tab of the sales order item.

When you activate the Standard - POD process for a sales document item and you are using delivery-relevant billing, it is not possible to create the invoice before the complete quantity has been confirmed in transaction VLPOD.

Process details

The POD process has to be used in combination with revenue recognition category B and the sales document item must be delivery relevant.

When the post goods issue is performed the system creates revenue lines in table VBREVE which are blocked for the revenue recognition postings (block indicator is set). Transaction VF44 cannot be executed. These revenue lines (VBREVE) can be identified based on the subsequent document category R for goods movement and the event type P for proof of delivery (POD) as shown here:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Using the POD functionality by executing transaction VLPOD it is possible to confirm the quantity which has been delivered and goods issue posted to the customer. It is also possible to confirm a quantity that is higher/lower than the delivered/good issue posted quantity.

Here is the screen for transaction VLPOD:

With the confirmation of quantities the system removes the posting blocks from the related revenue lines and the revenues can be recognized by using transaction VF44. Additionally the delivery number will be filled in the reference document field of the revenue line.

In case the confirmed quantity differs from the delivered/good issue posted quantity the system updates the revenue lines (VBREVE) accordingly, meaning that the accrual values are changed while the confirmed data is relevant:

Additional remarks

It is also possible to change the confirmed quantity in transaction VLPOD even when the related revenues have already been recognized with transaction VF44. In this scenario the system creates adjustment lines in the VBREVE to reverse the so far posted revenues and to post the new accrual value based on the new confirmed quantity.

Executing transaction VLPOD by changing the quantity:

As result the VBREVE is updated:

In case the goods issue posting is cancelled the system deletes the revenue line in table VBREVE as long as the revenues are not posted with transaction VF44. When revenues are already posted the system creates a cancellation line to reverse the posted value.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

In case then there is a price change done in the sales order item and revenues are already posted the system changes the accrual value in the control lines but does not create an adjustment line in revenue table VBREVE before the invoice is created.

2.4.2 Incoming Invoice (Third-party business process)

General Information

Using service-related revenue recognition in a third-party business process in combination with confirmation event the revenue recognition is based on the quantities of the incoming invoice. This means the delivery is made by a vendor, the customer confirmed the quantity of goods issue posting to the delivering company and then the invoice receipt is created by the delivering company. You can carry out revenue recognition once you have received the incoming invoice from your vendor.

To use this functionality the following setting has to be maintained:

Revenue event in the customizing of the revenue recognition category (transaction OVEP) for the item category of the sales document has to be set to incoming invoice (revenue event A):

According to Note 370443, the category of the system message V4 300 in view V_160MVA via transaction SM31 has to be set from "W" to "E".

Process details

The third-party business process has to be used in combination with revenue recognition category B and the sales order item must be specified with revenue event type A but has not to be delivery-relevant. The goods are delivery by a vendor after you created a purchase order for your sales order item. The invoicing to the customer (order-related invoicing) can be done independent to the delivering process and the revenue recognition process.

The system creates revenue lines in table VBREVE when a sales order is saved based on the schedule lines of the sales order item. These revenue lines can be identified based on the event type A and they are blocked for the revenue recognition postings (block indicator is set). These revenue lines are only for forecast. The accrual values are determined from the quantity in the schedule lines and the condition values of the item.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Based on the schedule lines of the sales order item the delivery process is initialized. The delivery process is not set up in the system (your vendor receives a purchase order and delivers directly to the customer. The customer confirms the delivery of goods or the performance of a service. Afterwards the vendor sends an incoming invoice).

The delivery process is finished. The invoice receipt has to be created. This is done by using transaction MIRO. With the creation of the incoming invoice the performance of the service is maintained in the system. It is possible that the quantity is the one which has been purchased. It is also possible that the incoming invoice includes a quantity that differs to the one which is purchased because the customer has confirmed another quantity.

Here is the screen for transaction MIRO by entering the purchase order number and changing the quantity:

With the receipt of the incoming invoice the system triggers the revenue recognition process. The existing revenue lines, created based on the schedule lines of the sales order item, and not posted, will be deleted. New revenue lines without a posting block are created based on the quantity of the invoice receipt. Additionally the invoice receipt number will be filled into the revenue line. The revenues can be recognized by using transaction VF44.

Additional remarks

With category "E" of the system message V4 300, you change the previous behavior of the standard system. Now you receive an error message if the sales document is blocked. Otherwise you could get the following issue: if the sales order is edited in SD at the same time, the customer does not receive an invoice and VBREVE lines are not updated. However, the invoice receipt is updated correctly.

In case the related revenues had been recognized with transaction VF44 (posting block was deleted manually) before the invoice receipt is created the system creates



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

a cancellation line to reverse the posted value and new revenue lines are created based on the quantity of the invoice receipt.

In case the sum of the confirmed quantity (invoice receipt) differs from the sum of invoiced quantity (customer invoice) and the sales order item is completed the system updates the revenue lines. In this scenario the system creates adjustment lines in the VBREVE to reverse the so far posted revenues and to post the new accrual value based on the invoiced quantity.

The posting block can be set or removed manually as in Standard - POD.

2.4.3 Customer Acceptance Date

General Information

Using service-related revenue recognition in combination with event customer acceptance date you can carry out recognition based on manual confirmation. After the customer has confirmed the receipt of the service, the confirmation is executed by entering the customer acceptance date in the order item.


The Revenue event in the customizing of the revenue recognition category (transaction OVEP) for the item category of the sales document has to be set to acceptance date (revenue event B):

The order type (transaction VOV8) has to have contract data allowed:

Process details

The event customer acceptance date has to be used in combination with revenue recognition category B and the sales order item must be specified with the revenue event B. The sales order creates revenue lines that are automatically allocated a posting block at this stage.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

These revenue lines can be identified based on the event type B for customer acceptance date and they are blocked for the revenue recognition postings (block indicator is set). These revenue lines are only for forecast. The accrual values are determined from the quantity in the schedule lines and the condition values of the item.

The customer confirms the delivery of goods or the performance of a service (e.g. by phone or EDI). The customer acceptance date is entered in the order on header or item level.

The block indicator is automatically removed and this triggers the revenue recognition process. Realizing the revenues with transaction VF44 is now possible.

Additional remarks

The customer acceptance date entered in contracts is not relevant. The customer acceptance date has to be maintained in the order, since the order creates/updates the revenue lines.

The invoice can be done independent from the performance of the service.

Delivery processing is independent from the revenue recognition process. Any delivery relevance of the sales order item is ignored for the creation of the revenue lines. The revenue lines are based on the sales order as described above.

The posting block can be set or removed manually as in standard POD.

2.4.4 Customer-Specific Event

General Information

Using service-related revenue recognition in combination with customer-specific event you can carry out recognition until the customer has confirmed the performed service, e.g. the releasing of a sales document item for billing. Other events can be the payment of the invoice, an order confirmation, a repair



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

completion confirmation a specific process related to the Inco terms etc. This function cannot be used with contracts.


Revenue event in the customizing of the revenue recognition category (transaction OVEP) for the item category of the sales document has to be set to customer-specific event (revenue event X or Y or Z):

BADI implementation:

o BADI_SD_REV_REC_PODEV is needed to map the customer-specific event. In this BADI the table CT_PPPODEVCUST has to be filled with the relevant event data.

o BADI_SD_REV_REC_PODEV_DISP is needed to display the revenue event document.

Please see SAP-note 1125456 that provides more details especially about the BADI implementation.

Process details

The customer-specific event has to be used in combination with revenue recognition category B and with a sales order. The system created revenue lines in table VBREVE when a sales order is saved. The revenue lines are blocked for the revenue recognition postings (block indicator is set).

When the customer-specific event occurs, the revenue recognition process is triggered, meaning that the system removes the block indicator from the revenue lines in table VBREVE. Afterwards the revenue posting can be done (transaction VF44 can be executed).

It is important to know that the creation/ update of the revenue lines have to be triggered individually.

Additional remarks

Delivery processing is independent from the revenue recognition process. Any delivery relevance of the sales order item is ignored for the creation of the revenue lines. The revenue lines are based on the sales order as described above.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

The invoice can be done independent from the performance of the service.

2.5 Handling of costs

In sales processes with items relevant for revenue recognition, costs and revenues should be handled.

The general precondition for involving costs into the sales process are:

In the customizing of the CO-PA operating concern, the costing based profitability analysis has to be active (see transaction KE4I).

A cost condition has to be determined in the sales document. The cost condition has to be customized as statistical with condition type G. In the SAP standard the cost condition is called VPRS.

If in the CO document the value of each condition has to be listed, there must be different accounts for each condition type.

If the preconditions are met the followings items are important to know:

Costs will be passed to CO-PA during the revenue realization process (VF44 / VF46), if there is not an account assignment object assigned to the sales document item. Relevant account assignment objects are: AUFNR, VBELV / POSNV, PS_PST_PNR. For the cost condition a revenue line is created without the creation of a corresponding control line. This means that posting of the cost condition for items relevant for revenue recognition depends on the non-existence of an account assignment object.

If the item has an account assignment object, the cost condition will be ignored during the revenue realization process and the costs are posted with releasing of the invoice. In this case revenues and costs are posted at different times.

If the cost condition is set as accrual-relevant cost condition (XKOMV-KRUEK = X), the costs are posted directly as an accrual in the financial accounting. An accrual of the costs in the revenue recognition does not occur, that is, neither during the billing nor during the actual revenue recognition the cost is considered.

A single statistical cost condition without a revenue condition cannot be processed. To post a cost condition by the revenue recognition and not by billing, the system requires a relevant pricing condition.

The calculation of the cost value depends on the revenue recognition category:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

o When using time based revenue recognition the cost amount per period is calculated from the total cost amount in the same way, the revenue per period is calculated. With a periodic billing plan involved the value of the VPRS condition is considered in each period while when using a partial billing plan the value of the cost condition is split.

o When using performance based revenue recognition the total cost amount for the event is posted in the period the event occurs. Exceptions: - If the goods issue posting is non-valuated the costs are determined from the sales order item. - If the valuation is done at item level in a batch material the costs are determined from the sales order item.

2.6 Archiving of revenue recognition data

Archiving of revenue recognition data consists of archiving of business document data like sales orders, invoices and the revenue recognition data itself.

Archiving of the business documents is executed using the standard functionality for archiving objects SD_VBAK and SD_VBRK. For revenue recognition related documents some specific prerequisites need to be considered.

Prerequisites for archiving of revenue recognition relevant documents:

Archiving object SD_VBAK (sales documents):

The sales document can only be archived if the document status of the revenue determination is "Completely Processed" or "Not Relevant".

There must not be any unprocessed changes for the sales document. Table VBREVC ("Revenue Realization: Worklist of Changed Sales Documents") must not contain entries for the document to be archived.

The whole revenue recognition process needs to be finished. Table VBREVK ("Revenue recognition: Control Lines") must contain only entries with status C (completed) for the document.

Archiving object SD_VBRK (billing documents):

The whole revenue recognition process needs to be finished. Table VBREVK ("Revenue recognition: Control Lines") must contain only entries with status C (completed) for the document.

Further information can be found in SAP-note 790817.

For archiving of revenue recognition data the archiving object SD_VBREV is available with SAP-note 790817 or a corresponding support package. This archiving object allows archiving the content of revenue recognition tables VBREVK, VBREVE, VBREVR.

For the archiving object SD_VBREV the following reports are available:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

S3VBREVPTS This program should be executed before the actual write program to be able to assess the quality of the revenue recognition table entries to be archived

S3VBREVWRS This program is used to write the revenue results table entries from the database to archive files.

S3VBREVDLS This program deletes revenue results table entries from the database after they have been written to the archive file by the write program.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

The sequence of archiving deviates from the standard SD archiving logic.

For revenue recognition relevant documents the following sequence needs to be used for archiving:

1st step: Archiving of the sales document, object SD_VBAK

2nd

step: Archiving of revenue recognition data , object SV_VBREV

3rd

step: Archiving of billing data, object SD_VBRK

For more details please see SAP-note 962426.

For customer or Add-On specific implementation the following BADIs are available:

ARC_SD_VBREV_CHECK The Business Add-In (BADI) ARC_SD_VBREV_CHECK is used to check archivability criteria.

ARC_SD_VBREV_WRITE The Business Add-In (BADI) ARC_SD_VBREV_WRITE is used for writing and deleting additional data.

Further information can be found in SAP-note 673030.

To reduce runtime of the archiving reports please create an index on table VBREVR as described in SAP-note 962713.

2.7 Customer enhancements (User-exit solution/BTE implementation)

There can be functions required that are not included in the ERP standard revenue recognition functionality. SAP provides different options with predefined interfaces where additional functions can be included by the customers itself. For the revenue recognition functionality the option for customer enhancements is the use of Business Transaction Events (BTEs).



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Here is a short description on how to use the user exit solution defined via BTE implementation: 1. You can use transaction SPRO. Then go to Sales and Distribution -> System modifications -> Use business transaction events. Alternatively you can use transaction FIBF directly. 2. Select Environment: Info System (P/S) Enter into the selection Attrib. field SD-ER and execute. You will get a list of all BTEs predefined for the revenue recognition functionality.

3. For implementing a BTE please proceed as follow: Select the needed BTE e.g. 0503110 Revenue realization: Change accounting data and then go to details. You will get the Sample Function Module e.g. SAMPLE_INTERFACE_00503110 4. You have to use this sample function for creating you own function module. Use transaction VF37 and copy the sample function into your own function. Please use ZZ* for your own function module e.g. ZZ_INTERFACE_00503110 and enter your own coding there. 5. After you have implemented the coding into your own function module, please go back to the initial screen of transaction FIBF. Select Settings: P/ S Modules: ... of a customer. Make a new entry there for the selected event e.g. Event 00503110 and assign the name of your own function (ZZ_INTERFACE_00503110) 6. After the assignment is done please go back to the initial screen of transaction FIBF again. Select Settings: Products: ... of a customer.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Define a product and set the 'Active' flag.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

3 Restrictions

3.1 Revenue recognition vs. non revenue recognition postings

Please keep in mind, that revenue recognition relevant invoice items always post to either the D/R or the U/R account, but never to a P&L account.

Non-revenue recognition relevant invoice items in the same invoice always post to a P&L account, but never to the D/R or the U/R account.

Revenue recognition postings can be distinguished from non-revenue recognition relevant postings in revenues accounts in FI. The revenue recognition lines have value VBRR in field BKPF-AWTYP.

For D/R and U/R accounts only revenue recognition relevant postings are allowed. This means that only postings from invoices (with revenue recognition-relevance) and postings from the revenue recognition transactions VF44 and VF46 are requested. Otherwise, reconciliation between FI and SD becomes difficult or impossible. For manually posted accruals or other adjustments, separate accounts should be used.

3.2 Translation of foreign currencies

A solution, compliant with the requirement FASB 52 (Financial Accounting Standards Board Statement 52, which requires a fixed exchange rate for the entire accrual period), is provided in support packages. For more information please view SAP-notes 891585 and 786266.

If this FASB 52 solution is not implemented and used, the following issues have to be considered:

The translation of foreign currencies cannot be accomplished in logistics.

The translation of foreign currencies is possible on line item or on balances. To translate on a line item level, the account has to be set as open item management otherwise the balances can only be updated in foreign currency.

According to IAS, balance sheet accounts are generally translated using the current closing exchange rate. Non-monetary items should be reported using the historical exchange rate (the exchange rate at the date the transaction was recognized). According to this unbilled- and deferred-accounts are not revaluated.

The P&L accounts are to be translated using the rates at the dates the transactions were recognized. Because this is maybe impractical, appropriately weighted average exchange rates can be used. These rules apply in case the local currency is the functional currency of the respective subsidiary (which is usually the case).

These rules for translation of foreign currency statements are similar to US-GAAP rules.

When the open items on the D/R or the U/R account are cleared at the end of the process (i.e. all invoices are created and all revenues are recognized), currency differences should be posted to a currency differences account (P&L account) affecting net income.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

4 Monitoring of the revenue recognition data

4.1 Importance of Monitoring

Monitoring of the revenue recognition process has to be performed on both sides:

FI monitoring

SD monitoring

An accurate monitoring is very important, because its the first time that SAP provides a functionality, which doesnt post the revenues directly with the billing document, but distributes the realization of revenues across a certain range of periods. This means that there is a decoupling of the billing document and the revenue posting in FI concerning both, the time dimension as well as a possible split of the revenue amounts.

The whole monitoring tasks have to ensure, that despite the mentioned decoupling finally those revenues are realized, which are billed to the customer.

In order to get an overview of what happened in total with a single sales document, the following options are available beside the monitoring tools described in this section of the document:

SD document flow by using transactions VA02/VA42 or VA03/VA43.

The revenue recognition view by using transaction VF43 (report SDRRAV50) as mentioned in section 1.2 of this document.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

4.2 FI-Monitoring

4.2.1 Check Account Balances and Line Items

In order to monitor the revenue recognition process from FI you can check whether there are balances on the accrual accounts or not. To display balances on accounts use transaction FS10N.

Here is the selection screen for transaction FS10N:

As a result, the balances per period are shown, separated by credit and debit:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

By double-click on a single figure, e.g. on the total balance, detailed information are shown.

Alternatively the line items of an accrual account can be shown directly by using transaction FBL3N.

Here is the selection screen for transaction FS10N:

Please notice that if the selected accrual account is customized with Open Item Management only the line items respectively the sales documents can be displayed which cause the balance on the account.

4.2.2 Reconcile FI and SD Values

If balances on accrual accounts are determined, they can be reconciled with the revenue recognition data in SD on an aggregated level.

Especially use transaction VF48 to compare the FI and SD values created by the billing process, as well as by the revenue realization process. The reconciliation can be done for a certain range of periods. For detailed information see section 4.5 of this document.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

4.2.3 Automatic Clearing of Accruals Accounts

In order to monitor the accrual accounts effectively, it is recommended to use the automatic clearing process in FI with transaction F.13 for the concerning accrual accounts.

The prerequisites for enabling automatic clearing are:

The accrual account is customized with Open Item. Please notice that if you havent yet activated open item management, create new accounts and do not change the open item management flag for an existing account which is already in use.

The field Assignment (ZUONR) has to be maintained in the customizing transaction Prepare Automatic Clearing:

Please notice that the standard revenue recognition logic fills the assignment field in the financial accounting document item depending on the revenue recognition category:

o If a sales order is relevant for time based revenue recognition (RRREL =A) or performance revenue recognition (RRREL=B) the field BSEG-ZUONR is filled with sales document number and item number.

o If a sales order is relevant for time based and billing related revenue recognition (RRREL=D) the field BSEG-ZUONR is filled with billing document number and item number.

In the billing run the field Assignment(ZUONR) has to be filled exactly in the same manner than in the revenue realization process. Therefore a SD user exit has to be implemented (SAP enhancement SDVFX004).



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

4.3 SD-Monitoring with VF45

4.3.1 VF45 Overview

Transaction VF45 shows deferred revenues, unbilled receivables, billed and realized amounts on the level of a sales document item.

Transaction VF45 is used within the following revenue recognition functions:

In the revenue recognition view called by transaction VF43 with the button Revenue Overview in the result list. For more information see section 1.2 of this document.

In the completion of contracts called by transaction V_MACO with the button Revenue Recognition in the result list. For more information see section 2.1 of this document.

Transaction VF45 is in comparison to the transaction VF47 a more value-oriented view from the sales perspective.

The worklist shown as result contains detailed information on SD document item level. The whole revenue recognition data of the selected documents are displayed:

Accrual accounts

Realized revenues

Invoiced values

Balances on unbilled/deferred account

Status of the process

Also there are links to the related documents:

Single sales document

Financial accounting documents created by the revenue realization process

Follow on documents (invoices)



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

4.3.2 VF45 Selection criteria

Here is the selection screen for transaction VF45:

In the selection screen the following items have to be considered:

The last block with the selection fields Unblocked Revenues and Blocked Revenues that can be flagged are provided with ERP release ECC 6.00. These flags are related to the revenue block.

There is just one mandatory field in VF45, the field sales document. At least one sales document has to be entered.

4.3.3 VF45 Results

As result a worklist is shown and exact information is provided about the selected sales documents:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

If one line is selected in the first block and the button Display Revenues and Bill.Docs is used, details about the created revenue recognition postings and invoiced revenues are available:

If the button Accounting is used, the financial accounting documents created by the revenue realization process (VF44 / VF46) for the selected sales documents are shown:

From this screen it is possible to view the single financial accounting documents by pushing on the single document number:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

4.4 SD-Monitoring with VF47

4.4.1 VF47 Overview

Transaction VF47 is the main tool in the analysis of the revenue recognition data and it provides a technical view on the revenue recognition tables.

If a sales document contains items relevant for revenue recognition, various errors and inconsistencies may occur during the processing of sale document items.

The report of VF47 shows inconsistencies between the revenue recognition tables VBREVK, VBREVE and VBREVR and the appropriate sales documents.

Sales documents, invoices and financial accounting documents can be taken into account to search for inconsistencies beyond the revenue tables (VBREV* tables).

VF47 can be executed in the dialog mode or in the background.

Here is our recommendation regarding the VF47 monitoring:

Schedule VF47 as a regular batch process.

For scheduling use report SDRRAV52.

Depending on the amount of revenue recognition data, run transaction VF47 every week at least once in a month to be sure that there are no inconsistencies in your revenue recognition data.

The report should be executed in test mode (check box Test Run Without Update has to be flagged).

If errors are shown when VF47 is executed please contact SAP support.

Schedule VF47 on a weekly basis and review errors

4.4.2 VF47 Selection criteria

The selection screen for transaction VF47 provides different options and lots of selection criteria. Therefore we provide detailed information separately in the following parts:

General selection data

Performance data

Check type

Display type

Change type



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Selection data

In the first step the documents have to be described which should be analysed. Company code and sales document type can be used, at least one sales document number is mandatory.

Performance data

The parameters in the next step enable the user to improve the runtime of VF47.

a) Pack. Size for Control Lines

To avoid memory problems you can force the system to divide the processing of a huge number of documents into several packages. Enter the number of control lines which should be handled per package. Recommended numbers are 10.000 to 30.000.

b) Database Access on Pack. Level

If the update mode of VF47 is used, all the involved documents are locked. If this flag is set, only the documents of the actually handled package are locked.

c) Maximum No. of Control Lines

If a wide range of documents is selected, you can use this field to restrict the database access to a certain number of control lines (table VBREVK).



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Check types

a) Only Check Current Documents

The systems only checks lines that have not been completed yet. This means that only those control lines are checked that do not have status C (VBREVK-RRSTA).

b) Check Reference LInes

If this flag is set, the system checks whether all items relevant for revenue recognition from the relevant billing documents have an entry in the reference table (VBREVR). Technically, the system reconciles the document flow with the reference table.

Docs. from: It is possible that not all billing documents may be used for a check after a migration. For example, this can occur if current contracts were copied from a preceding system. When you enter a date here, the system ignores all billing documents that were created before this time.

Incl. FI: If this flag is set, the system also attempts to read the financial accounting documents of the billing documents in order to simulate non-existing reference lines (VBREVR) and to include them in the calculation of the control lines. Thus, this analysis program can determine control lines from the detail lines even if reference lines are missing and then compare them with the control lines of the database.

Compr.: If also the financial accounting documents for the billing documents are read, the billing document and the financial accounting document do not have to match completely. This is because the individual posting items can be summarized (compressed) in FI. For this case, this flag must be set. The data required for simulating the missing reference lines is copied from the billing document. However, this only occurs if the billing document was posted to 'deferred revenues' or 'unbilled receivables' only. If both accounts are involved, the reference lines cannot be simulated. This flag is not set by default. The system therefore attempts to link the billing document with the generated financial accounting document. The system assumes that the billing items have generated posting items in chronological order. If this is not the case, the reference lines cannot be simulated here either.

c) Check Control Line Status

This flag is set by default. It ensures that the system also reads the sales document data in order to check whether the status of the control lines is correct. This is necessary because both the reason for rejection on item level and the billing block on header and item level affect the control line status. With this information, the system determines the status on the basis of the detail lines and then compares it with the status of the respective control lines.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

d) Check Total Amount

If you set this flag, the system also reads the sales document types (if it has not done so yet) in order to compare the net item value (VBAP-NETWR) with the total accrued value of the control lines (VBREVK-ACC_VALUE).

e) Read Revenue Lines in SD

If you set this flag, the system is forced to always use the revenue lines from the revenue table (VBREVE) when determining the simulated control lines. Thus, balances and posted revenues of the 'new' control lines are based on the data updated in SD.

f) Read Revenue Lines in FI

If this flag is set, the system attempts in addition to read the financial accounting documents of the billing documents in order to simulate non-existing reference lines (VBREVR) and to include them in the calculation of the control lines. Thus this analysis program can determine control lines from the detail lines even if reference lines are missing and then compares them with the control lines of the database.

Incl. Collective Run No: Generally, the financial accounting documents are generated on sales document level (BKPF-AWKEY) during the revenue recognition (VF44). However, you can carry out the revenue recognition (VF44) on collective processing level as well. In this case, the financial accounting document does not get the sales document number as a reference number, but the collective number. That is, if the financial accounting documents are generated on collective processing level, you must set this flag in order to find these financial accounting documents. This may cause a slight performance loss.

Incl. FI index: This flag has only to be used, if the flag Incl. Collective Run No. is set and documents are involved, which were cancelled once with the old cancellation logic (means: revenue lines in VBREVE were lost). Since the FI data are selected using the collective run number, certain collective run numbers are missing in case of old cancellation, and the FI line items from BSEG have to be selected. In order to limit runtime a Pckt. Size for the line items can be entered as well.

With new reference Trans.: This flag is only needed for documents with revenue recognition category D which were posted before the new revenue

RR Best Practices V16 Part2

Documents

revenue recognition

revenue recognition

revenue realization

example of summarization

knowledge document version

e d g e d o c u

sales document

activation of summarization