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 today‟s 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 it„s the first time that SAP provides a functionality, which doesn„t 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 haven„t 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



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


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 recognition logic was implemented. It prevents certain billing documents to be interpreted as revenue postings. For details, please refer to SAP-note 1002577.

Display type

a) Messages: Document Level

If you set this flag, the system does execute all checks selected, but the log is output on the basis of the sales document level. The system issues error messages only once per document although the errors may occur more often.

b) Only Docs with Error Messages

Sales documents that do not have any errors are indicated with a green checkmark in the log. If you set this flag, the system no longer displays these correct sales document numbers in the log, but only the incorrect ones with their corresponding error messages.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Change Type

The report is able to make updates to the database. The scope of these corrections is defined by the following options. If you want to carry out a correction update, you have to select at least one of these options. In addition, you must deselect the 'Test Run without Update' flag.

a) Change control lines

If you set this flag, the system overwrites the control lines that can be corrected. This means that the control lines (VBREVK) were re determined via the revenue lines (VBREVE) and the reference lines (VBREVR).

Also for Currency change SD/FI: If you set this flag, the system overwrites the control lines although there are different currencies in the control lines and existing revenue documents.

b) Delete control lines

If you set this flag, the system deletes those control lines from the database that have neither revenue lines nor reference lines.

c) Create reference lines

If you set this flag, the report attempts to regenerate missing reference lines (VBREVR). The basis for this is either the respective billing document or the financial accounting document generated from the billing document.

d) Create revenue lines

If you set this flag, the report generates revenue lines (VBREVE) if it detects balances on both clearing accounts (E16). In this case, the report always generates two revenue lines. Both lines have the same revenue value (VBREVE-WRBTR) with one value being positive and the other one being negative. The first line gets status (VBREVE-RRSTA) 'A' (to be recognized), the second gets status 'C' (recognized).

Posting period: Generally, the system determines a posting period for the new revenue lines to be created. This posting period is always the first posting period (descending sort order) of a sales document that no longer contains revenues to be recognized, that is, all revenue lines of this sales document that concern the determined posting period have status 'C' (VBREVE-RRSTA ='C'). However, if you want to create revenue lines for a certain posting period, you can specify a period here. This must be done in the 'YYYYPPP' format where 'Y' represents the year and 'P' the period.

Our recommendation regarding the flag „Test Run Without Update‟:

This flag has to be set. The errors are shown in the result list BUT there is not an update on the revenue recognition data.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

4.4.3 VF47 Error categories

When transaction VF47 is executed a result is shown in two parts. The first part lists the single sales documents for which an error is detected and the second part gives a summary of the proceeded sales documents.

In case errors are detected these errors are shown in error categories. In the following you can view the existing error categories in detail. A complete explanation can be found in the SAP-note 399777 and 542161.

Account determination errors

Error Description

E01 Missing Account for 'Restricted Revenues' in Control Lines: SAKRR.

E02 Missing Account for 'Non-Billed Requests' in Control Lines: SAKRRK

E03 No Accounts Available in Control Lines

E05 Missing Revenue Account in Revenue Lines: SAKRV

E06 Missing Account for 'Restricted Revenues' in Revenue Lines: SAKDR

E07 Missing Account for 'Non-Billed Requests' in Revenue Lines: SAKUR

E08 Missing Account for 'Restricted Revenues' in Reference Lines: SAKRR

E09 Missing Account for 'Non-Billed Requests' in Reference Lines: SAKRRK

Inconsistencies between VBREVK / VBREVE/ VBREVR

Error Description

E04 No Control Lines Found

E14 No Detail Lines Available, although Time-Related Revenue Recognition

E17 Reference Lines Available for Billing Document in Table VBREVR

Incorrect values / balances

Error Description

E10 Differences in Total Accrual/Deferral Amount:

E11 Differences in Balance: WRBTR

E12 Differences in Recognised Revenues: RVAMT

E15 Control Lines with Balance for 'Restricted Revenues' and for 'Non-Billed Requests'

E16 Detail Lines have Determined Balance for 'Restricted Revenues' and for 'Non-billed Requests'

E18 Total Amount Difference for Control Lines and Sales Document Item:

E24 Total amount difference for control lines and billing item:



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Status problem

Error Description

E13 Different Status found: RRSTA

Currency problem

Error Description

E19 Currency Differs in Control Lines and Revenue Lines.

E20 Currency Differs in Control Lines and Reference Lines.

E22 Currency Differs in Accounting Document and Control Lines.

Lock problem

Error Description

E21 Document in Processing

E23 System Error: Document Could Not Be Blocked.

Assignment problem

Error Description

E25 Error during determination of posted values on account: Revenues not posted!

E26 No FI documents found. Revenues not posted!

4.5 SD Monitoring with VF48

4.5.1 VF48 Overview

Transaction VF48 is a report that compares the FI and SD values on the accrual accounts. This means that transaction VF48 determines the balance on the accrual accounts from FI side (all postings to the accrual account) and from SD side (postings that corresponds to the SD data represented by the VBREV* tables).

Transaction VF48 cannot be used for revenue accounts.

The main aim of VF48 is to trace balances on accrual accounts and not to trace possible inconsistencies between SD and FI. In order to find out inconsistencies that may occur during the processing of sales document items transaction VF47 should be used (see section 4.4 of this document).

Transaction VF48 can be executed for a single accrual account in a single company code and it is recommended to use it also only for one posting period.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Here is a short description on how transaction VF48 works:

Firstly the account balance in FI for the selected period(s) is determined from the account transactions.

Secondly the account balance is determined by the SD data (tables entries in VBREVE and VBREVR) for the selected period(s).

Only if there is a difference, the system reads the FI postings of the concerning account, that are not caused by billing processes or revenue realization postings.




The following fields are mandatory in VF48: the field „company code‟, the field „G/L account) and the field „Posting Period/Year‟.

At least one posting period has to be entered. There is the option to use only the field „TO‟ and to leave the field „FROM‟. With this selection also the revenue recognition postings done without a posting date in the revenue line (VBREVE-BUDAT is not filled) are considered.

The selection field „Only Uncleared Documents‟ can be flagged. If the flag is set, only revenue recognition processes that are not completed are taken into consideration. These processes may cause the balance on the accrual account between FI and SD.

4.5.3 VF48 Result

When transaction VF47 is executed the result is shown in two parts where detailed information can be viewed.

The first part provides the balances that are determined for the selected accrual account and the second part provides a worklist with the sales document (items) that used the selected accrual account when the billing or revenue postings were done.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

Furthermore there are additional functions available to get more details. Here the buttons on the top can be used.

In the following you can view the two parts the VF48 result separately in detail as well as the additional functions.

Upper part of the VF48 result - Balances

The different balances are displayed per currency, for each currency in form of a calculation.



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

The calculation consists of the following lines:

Balance from Revenue Recognitions: This balance is determined from the revenue realization process. The value shown is the total of the revenue that is recognized in the selected posting period and to the selected accrual account. Data is retrieved using the revenue line table (VBREVE).

Balance from Billing Documents: This balance is determined from the billing process. The value shown is the total of the billing value that is accrued in the selected posting period and to the selected accrual account. Data is retrieved using the reference line table (VBREVR).

Balance from Other Postings: There is a balance determined if not only the revenue recognition process (postings done by transaction (VF44 / VF46 / VF01 / VF02 / VFX3) but also other FI transactions such as FB01 posted to the selected accrual account. The value shown here is not known in SD (VBREV* tables). Important information: The value shown here is not an inconsistency between SD and FI.

Total Balance: This balance is determined from all FI postings. The value shown is the total of the FI postings that are done in the selected posting period and to the selected accrual account.

With these different balances you can find out if there is are inconsistencies that may occur during the processing of sales document items relevant for revenue recognition.

Please do the following check:

Take the Balance from Revenue Recognitions, minus the Balance from Billing Documents and the Balance from Other Postings.

Compare the result of the first three balances with the Total Balance.

If there is a difference, further actions are necessary to find out the reason for this difference. Here the other monitoring transactions such as transaction VF45 and VF47 are helpful.

Lower part of the VF48 result – SD data (VBREV* tables)

This worklist shows exact information about the sales document (items) that are relevant for revenue recognition and that use the selected accrual account. The values shown here are SD data (VBREV* tables).



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

The worklist displays the following values in columns:

Billed Revenues: For the single sales document item, the value shown is the billing value that is accrued in the selected posting period and to the selected accrual account (VBREVR entries). Data is retrieved using the reference line table (VBREVR).

Recognized Revenues: For the single sales document item, the value shown is the revenue that is recognized in the selected posting period and to the selected accrual account. Data is retrieved using the revenue line table (VBREVE).

Total Accrual Value: For the single sales document item, the value shown is the revenue amount to be recognized and billed at accruals account level. Data is retrieved using the control line table (VBREVK).

Balance: For the single sales document item, the value shown is the difference between the billed revenues and the recognized revenues.

At the end of the worklist the values in the different columns are summed up and a total line is created.

Here, an important check has to be considered:

Take the total value of the column „Balance‟ in the lower part of the VF48 result

Compare this total value with Total Balance of the upper part of VF48 result.

If there is a difference, further actions are necessary to find out the reason for this difference. Here the other monitoring transactions such as transaction VF45 and VF47 are helpful.

Additional functions of the VF48 result

To get some more details of a single sales document (item) the buttons on the top of the VF48 result or the functional keys can be used. At first a single line in the lower part of the VF48 result has to be selected.

Available additional functions are:

Billing Documents (F5) : Here the billing document items that were created related to the selected sales document item are displayed. In the new screen there is a link to the billing document.

Other FI Documents (F6) : Here the financial accounting documents are displayed if there are postings from other transactions as from the revenue recognition process. In the new screen there is a link to these financial accounting documents.

Overview (F7) : With the button „Overview‟, the revenue recognition data of the selected document item is displayed (this function is similar to transaction VF45 – see section 4.3 of this document).



S

AP

AG

03

/20

13

. A

ll rig

hts

re

serv

ed.

5 Conclusion

SAP provides revenue recognition functionality in the Sales and Distribution component (SD) of an ERP system. This functionality complies with the latest bookkeeping principles and current regulations in accounting world. This document contains some general recommendations and best practices for customers using SAP ERP SD revenue recognition.

Some important points discussed in this document are:

In order to implement of SAP ERP SD Revenue Recognition functionality, customers have to request a pre go-live assessment (free of charge) of their system landscape from SAP to avoid a negative impact on the financial statement.

The functionality should be implemented by SAP-certified SD- and FI-Consultants. The consultants have to setup the accounts and other settings in the customizing as outlined in this document.

It is important to understand the business scenarios that are supported by SAP for revenue recognition. This document explains pure core business scenarios which start and end in the ERP system. There can be ERP core business scenarios within your landscape which are not included in this document. In this cases please ask for an assessment as mentioned in SAP-note 820417 when you are planning to implement the SAP ERP SD Revenue Recognition functionality.

It is necessary to continuously monitor the data created by revenue recognition functionality. The programs and reports for monitoring are introduced in detail in this document.

The SAP ERP SD Revenue Recognition functionality has been designed to feed and interact with a classic SAP ERP financial accounting module. External or third-party accounting backend is not covered and supported by the functionality.

The integration of revenue recognition with other solutions of SAPs business suites (e.g. SAP CRM) as well as the integration with SAPs industry solutions (e.g. IS-OIL, IS-ADEC-BOQ) is not validated and released. In case you plan to combine SAP ERP SD Revenue Recognition with another solution please address this need via the SAP User Groups or the responsible SAP Solution Manager. In case you don‟t know who to contact you can create a service ticket on component SD-BIL-RR. SAP Support will then forward your request to the responsible person.

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