CL_BADI_SD_REV_REC_PODEV - Example for RevRec/PODEV - User Status

CPI1466 during Backup   ABAP Short Reference  
This documentation is copyright by SAP AG.

Functionality

A sample implementation is delivered with the BAdI. The implementation is based on the following process:

An order item is relevant for service-related revenue recognition (category 'B'). However, the userstatus is configured such that the order item is initially blocked for billing after it has been created.As well as the revenue recognition category, revenue event type 'X' is also set for this item (customer-specificevent). In the example, this means that revenues cannot be recognized until the user status is set to 'free'. The status can be changed on the 'Status' item tab in the order.

The user status is checked in the BAdI. If the status is set to 'blocked', the revenue lines are updatedas blocked. As soon as the user status is set to 'free', the relevant revenue lines in the revenue table (VBREVE) are also unblocked. Revenue recognition can now take place using transaction VF44.

A status profile must be maintained in the item category of the order item for the above process. This status profile is managed or created as follows, using transaction BS02 in Customizing:

Status profile: ZZ000001

Status text...: Billing document initially blocked

Object type...: Sales order item

User status:

OrdNo. Status ShText LText Initial Low High Item Prio.

--------- -------- ------------ ------- ------- --------- ------- ----- ------

10 blck blocked X 10 20 1 1

20 free open 10 20 1 1

Status profile: ZZ000001 Status: blck (blocked)

Bus.Transaction Allowed Forbidden No Action Set

-------------------------- ---------- ------------ ----------------- ---------

Unblock X X

Create Billing Doc. X

Block X X

Status profile: ZZ000001 Status: free (open)

Bus.Transaction Allowed Forbidden No Action Set

-------------------------- ---------- ------------ ----------------- ---------

Unblock X X

Block X X

The Customizing involved is minimal. There are a number of other possible business processes. See SAP Note 910554 for additional support.

As of EHP3, the status profile 'CB000001' is also available as standard. This profile contains the above statuses and can be used for the sample implementation.

Relationships

Example

Notes

Further information

In the sample implementation described above, an action within the order triggers the revenue recognition event. In other words, the order is always updated.

In many cases, however, there is a revenue recognition event without the order being updated. Paymentof the billing document could be an event that releases the revenues for recognition. The same appliesfor an order confirmation from the customer or a repair completion confirmation from the fitter. Incotermsgenerally also represent the point of the risk transfer. A specific transaction, linked to the Incoterms, could also lead to revenue recognition.

An order must definitely be updated after this type of event so that the relevant revenue lines areupdated or changed and released for recognition. This can be done using the function module SD_REV_REC_COLLECT,which if implemented appropriately, ensures that the relevant orders are updated immediately or at a later point in time. See SAP Notes 780993 and 781192.

The BAdI BADI_SD_REV_REC_PODEV is processed as part of the update. The relevant event data must nowbe read in the corresponding implementation, and the internal table CT_RRPODEVCUST must be filled. Theevent data that has already been updated for the transaction is made available in the BAdI by means of internal table IT_RRPODEVINFO.

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
This documentation is copyright by SAP AG.


Length: 4267 Date: 20120526 Time: 085733     triton ( 186 ms )