You are on page 1of 24

Resource-related billing (RRB)

1 RRB process
1.1 Scenario:
We sell a product/service to a customer. In background we have a project, which is created to produce the material sold to the customer and
the installation of this material on the customer site.

We want to make resource related billing. On the bill, there should be three different types of items shown:

1. item for the material sold


2. item for the work costs which have been accumulated installing the material
3. item for other (additional) costs

To achieve this, we need different service materials which will be used by the system to reflect these items on the billing document. These
service materials are determined according to the settings in DIP profile.

1.2 Transactions
1.2.1 Customizing
ODP1 Definition DIP profile

ODP2 Consistency check for DIP profile

ODP2A Consistency check for DIP profile

ODP3 Definition of apportionment reasons

ODP4 Cost condition for sales document type

GS01 Definition of sets

GS02 Change Sets

1.2.2 Operative
DP90 Billing request; process individually (SD and CS orders)

DP91 Resource related Billing document (SD orders only)

DP95 Billing request; process collectively (SD and CS orders)

DP96 Billing request; process collectively (SD orders only); uses logical database from SD

DP97 Billing request; process collectively; uses logical database from PM

DP98 Resource item for billing request/credit memo request; from 470 onwards, Reporting transaction

DP99A Document flow for resource related billing document

DP99B Document flow for resource related billing document (enhanced selection screen); uses logical database from SD
DP99C Document flow for resource related billing document (Service order)

1.3 The service materials


The service materials are copied into the created SD document (billing request) and represent the items (cost, activity type) billed to the
customer. You need to define a material master for these materials to allow the system to use them in a sales document. Item category group
should be LEIS. SD relevant views in material master have to be maintained.

With resource related billing it is not possible to define a general sales price for service materials, which represent these items in the billing
request. Even more so, the price is a result of the incurred costs alone.

You have to decide between cost based billing and quantity based billing. The relevant customizing has to be done for the material
determination.

Therefore, you cannot flag conditions for these types of prices (for example, PR00) as obligatory in the pricing procedure you use in pricing for
the billing request.

To get the price for the service materials into the resulting SD document, you have to define a costing condition which is transferred from DP9*
to the sales document (billing request). The relevant customizing is done in transaction ODP4.

1.4 DIP profile

The information about the DIP profile used within an SD-order is stored in table VBKD.

1.4.1 Using sets


As will be shown in chapter 1.4.3 the selection of the relevant information from the database can be influenced by using sets. Within sets you
can define, what selection criteria (range) is to be used to select the relevant information.

Sets can be defined within customizing using either the customizing transactions for the DIP profile, or by using TA GS01/GS02. Set with initial
value
Using this kind of set will select only data, where field LSTAR is not filled.
An initial line is created by choosing menu Edit -> Insert initial value.

Set with value

Using this kind of set will select all entries from the database, where the value for field LSTAR is within the given selection range.

Set with ***All values***

This kind of set can be created by using menu Edit Insert all values. This kind of set does not lead to any selection limitation. Each value is
allowed.

Empty set
This kind of set will prevent any selection. Using this kind of set within material determination will lead to errors within material determination.
This kind of error in material determination is not detected by TA ODP2.

You should never use this kind of set!

1.4.2 Material determination

The indicator Individual means, that for each dynamic item leading to one of the service materials, one line is shown within the billing request.

The last line with the flag Material direct allows the system to transfer the material directly to the billing document. Criteria material number has
to be marked as relevant. If this is not the case, flag Material direct will not be available.

Indicator Conversion Quantity can be used in case you want to use the sales unit (or the base UoM if the sales unit is not maintained in the
material master) in the created debit memo request. Otherwise the system will use the UoM found in the selected cost lines.

1.4.3 Selection of the service materials


The selection of the service materials is done by using sets
This combination of sets means, that for each entry where LSTAR is filled and MATNR is initial, the service material ZGVILEISTUNG is found.

Considering this, we have to flag LSTAR and MATNR as relevant within the DIP profile.

1.4.4 TA ODP2

Characteristics view
Sources view

Material determination view

On the material determination view you can simulate the material determination by giving certain values for the characteristics.

If the status of the DIP profile is not ok, this might lead to errors within the RRB process. You should check the used profile before investing too
much time in the detailed investigation of the problem.

Via doubleclick onto the SetID you can show the set in detail.

The old version of the consistency check can be made available. This would be TA ODP2.

1.4.5 Dynamic item w/out material


If this indicator is set, the system will take over all source records, for which a service material can be found. All others will be ignored.

But this flag will also lead to the suppression of all errors within material determination.

This flag should only be used if you use a user exit to determine the service materials.

This flag should never be used just to suppress material determination errors! Material determination errors need to be addressed by fixing the
DIP profile settings.

1.5 Example - The Project

In this example there are different WBS-elements and activities which will get posted with costs of different characteristics

1.6 Example - The sales order


The sales has the DIP profile assigned to it.

And it is assigned to the Project (in this case directly to the billing WBS-element).

1.7 DP90/DP91
DP90 (DP91) shows the collected costs summed up into the various dynamic items as customized in the DIP profile.

1.8 Simulation of the Sales document

Via Menu Goto -> Simulate sales and distribution docs the resulting SD document can be simulated.

2. Program flow
Development class AD01

AD15 Read Objects, Read Sources, Determine Dynamic Items

AD1C DIP-Profile processing

DIP17 Read document flow

2.1 Check item from order


This is done in function modules VPKI_CHECK_SD_ORDER_FOR_DIP (for sales orders) or VPKI_CHECK_CS_ORDERS_FOR_DIP (for CS
orders).
Here the system decides whether the item is allowed for RRB. There is also a BAdI existing here for customer specific checks. The BAdI is
called DIP_CHECK_INPUT_OBJECT.

2.2 DIP profile determination


Function AD1C_PROF_READ

Here the information about the source, the characteristics and the material determination is read. Including the selection information from the
sets.

E.g. you can see, which selection criteria is used in material determination.
Or you can see which characteristics are used.

If necessary, you can check the existing customizing settings here.

2.3 Object selection


Function module AD15_OBJECTS_DETERMINE.

Here the objects are read, for which billing has to be done. The selected objects get returned via structure ET_OBJECTS.
Here an EXIT_SAPLAD15_001 is processed, to influence the selection of the objects.

Call stack (using DP90):

SAPLAD15 FUNCTION AD15_OBJECTS_DETERMINE

SAPLVPKDPP FORM GET_DI_FOR_SALES_DOCUMENT

SAPLVPKDPP FUNCTION VPKDPP_GET_DI_WITH_VALUES

SAPLVPKO FUNCTION VPKO_INIT_BY_VBELN

SAPLVPKI FUNCTION VPKI_RRB_SD_INIT

SAPLVPKI FUNCTION VPKI_RRB_SM_INIT

SAPLVPK_GUI_INTRO MODULE (PAI) HANDLE_SM_BI

2.4 Reading the source tables


Function module AD15_DLIS_FOR_OBJECTS_READ

Depending on the source setting within the DIP profile, the system reads the relevant source table to determine the costs to be billed.
For which objects (WBS elements, Networks,) this is to be done is in structure IT_OBJECTS. If an object is not within this structure, no costs
for this object will be read.

E.g. reading line items actuals (database view COVP).

IT_OBJECTS Objects, for which costs are to be read.

IT_SELR Additional selection criteria.

I_DATE_TO Date given on the selection screen up to which costs should be selected
After selecting the source data a subroutine FILTER_... (in this case FILTER_COVP) is processed, where the selection criteria for the source is
executed (if any sets) and revenues are excluded.

2.5 Forming the dynamic items


After this is done and duplicate entries are excluded, the dynamic entries are formed:
At first, the system tries to find already existing dynamic items which fit the characteristics of the selected cost lines. If none exists, a new
dynamic item will be created.

Within structure L_ATTRI you will find the attributes, which the system uses to look up already created dynamic items.

Here the first summarization step is done. Different line items are summed up to one dynamic item, as the system can find an already created
dynamic item with the same attributes.

Also already created dynamic entries of former billing runs are selected from the database here. These are stored in table AD01DLI.

This is the reason, that the system cant detect already posted dynamic items, if the DIP profile was changed in the meantime (the attributes will
not be the same).

This read/creation process is run for each line found in the source table.

When the system is back in function module AD15_DLIS_FOR_OBJECTS_READ, the created dynamic item data is stored in internal tables

LT_DLIA Characteristics data

LT_DLIV1 Cost data, quantity


LT_DLIM Metadata

2.6 Material determination


Function module AD15_MATERIAL_DETERMINATION.

The system determines the customizing for the material determination (all selection criteria/sets given in ODP1).

Then the system loops over this information and checks, if the set is fitting the current dynamic item.

I_ATTR Current attributes

LT_MATA Selection criteria from customizing

LT_MAT Service materials

All selections containing the attribute fields are found and the fitting one is selected. The service material is selected from LT_MAT and passed
back.

Consequently LT_DLIM (see above) is updated with the service material number (field INV_MAT).

2.7 Interface to prizing


The interface between RRB and SD prizing is function module SD_SALES_DOCUMENT_FROM_SM.

The function module PRICING_COMPLETE is called to determine the price/conditions within the SD document (billing request).

Call stack:

FUNCTION PRICING_COMPLETE

FORM PREISFINDUNG_GESAMT

FORM FCODE_KONB

FUNCTION SD_SALES_DOCUMENT_PERFORM

FORM PREISE_ERMITTELN

FUNCTION SD_SALES_DOCUMENT_FROM_SM

3 Handling DP90
Within DP90/DP91 there are two views onto the cost to be billed. The Expenses view and the Sales price view. With these two views you can
see the compression which is done in two steps.
E.g. in the DIP profile characteristic Document number is relevant (not marked for no summarization) and material determination customizing
does not show flag Individual.
Two cost lines posted with different document numbers but otherwise identical characteristics will not be compressed in the first step (creation
of dynamic item), but as the only characteristic where these cost lines differ is not flagged for no summarization in the second compression
step these dynamic items will be summed up into one item in the debit memo request.
Within the expenses view you can see the actual cost from the assigned project. Here you can decide whether to change the amounts or to
reject them.

Within the Sales price view the system shows the material numbers used to compress the dynamic items into various sales order items in the
billing request. Pricing is done and you can analyze/change the conditions here

3.1 Expenses view


Within this view you can see the costs to be billed structured by the relevant characteristics within the DIP profile.

You can select different entry proposals controlling the columns that are open for input/change.

In the upper part of the expenses view you can also show a tree which can be used to apply structuring to the dynamic items displayed in the
list to increase overview.
E.g. structuring using sets for characteristic cost element
Also you can change the View using different tabs. You can view the situation from amount side, the quantity side and you can get a
percentage view on the situation. This may help, if you do postpone or reject certain parts.

3.2 Sales price view


As already mentioned, this view shows the what will be in the debit memo request document to be created. You can influence the pricing here.
3.3 Process open items only
This flag on the entry screen does lead to the effect, that only items, which were not yet processed are shown in DP90/DP91.

There is a user parameter existing, which determines, that rejected amounts are treated like open again. See SAP note no. 387659.

3.4 Posting Date to


This is important when the DP90/DP91 is rerun.
If you select a posting date for the second run, which is before the posting date of the costs already billed in the first run, the system will show
(at least a part of ) the already billed amounts to be cancelled.

4. Specific questions
4.1 How is the program flow at a repeated DP90/DP91 run?
Assume there was already some billing done for a sales order. When this was done some of the costs were postponed from billing, others were
rejected completely.
Table AD01DLIEF (individual flow for dynamic items) shows what amounts were posted in what debit (credit) memo request.

When a billing request is saved, AD01DLI, AD01DLIEF and AD01DLISF is filled.

AD01DLI Dynamic items

AD01DLIEF Individual flow


AD01DLISF Total flow

In table AD01DLI there is the meta-data of the dynamic item (the characteristics).

In table AD01DLIEF you will find the information, what was billed so far (per debit/credit memo request).

Table AD01DLISF does additionally show the rejected values (if any; field NO_...).

As the dynamic items are unique combinations of characteristics dependent on the setup of the DIP profile, keeping track of what dynamic
items were used in the debit/credit memo request might be helpful in case of questions. The link what dynamic item was posted into what
debit/credit memo request can be found in table AD01DLIEF (field VBELN).

At a repeated DP9* run, the system looks for existing dynamic items, which fit the characteristics of the picked up costs. This is done in function
module DIP11_DLI_PREREAD.

Here the system looks up all existing dynamic items per object (WBS-element, network activity) relevant in DP90/DP91 and stores them in an
internal table to later determine whether one of these can be used for the new billing run as its characteristics combination fits the costs
collected and summarized to new dynamic items.

The found entries from AD01DLI are stored in table GT_AD01DLI_ATTRI.

When the system reaches subroutine DI_FROM_COVP (see chapter Reading the source tables) to create the new dynamic items.
Within this subroutine the system tries to get already existing dynamic items. As they were read before, they can be found:

Meaning, the system checks whether the characteristics combination (l_attris) of an existing dynamic item fits the chararcteristics combination
of a newly to be created dynamic item. If yes, the existing dynamic item will be used for the further process.

The result is a list of already billed dynamic items, which correspond to the characteristics combination of the now found actual costs:
In our example the costs did not change since the last billing run (where postponement and rejection was done). So, the characteristics
combination of the found costs correspond to the already used (posted) dynamic items. Table CT_DLIV1 shows the dynamic item numbers of
the found and corresponding already used dynamic items.

Field DLINR would start with 9* for newly to be created dynamic items in case costs were picked up which characteristics combination doesnt
fit already existing dynamic items.

Afterwards the flow data for the already existing dynamic items is read into table LT_DLIV2:
Now we have the actual dynamic item data (cost data) in structure LT_DLIV1 and the already existing (stored on the database) data in
LT_DLIV2.
This shows that for dynamic item 447 an amount of 500,00 was already posted (LT_DLIV2). The current amount is 1.000,00 (LT_DLIV1). This
is because 500,00 were postponed the last time DP90/DP91 was run. This postponed amount will be proposed for billing again.

Dynamic item 446 shows a posted amount of 871,04 and a rejected amount of 300,00 (field 'NO_W*') summing up to an amount of 1.171,04.
That is what according to actual costs should be billed for that dynamic item. As 300,00 were rejected which classifies this part to be no longer
relevant in billing, no open amount will be calculated for that dynamic item.

Later in the process the open amount is calculated by subtracting the already billed amount plus the rejected amount from the actual amount
here:

In our example where we did not post any costs since the last run of DP90/DP91 but did only do postponement and rejection, the previously
postponed amount will be shown as to be billed. The rejected amount will not be presented again (rejected amounts will never be billed).

4.2 What happens if the item was rejected in SD?


This is dependent from the customizing setting for the rejection reason in SD. There you can set a flag, which determines, that rejected items
from the SD order do get relevant again for the RRB process.

The reasons for rejection are maintained in TA OVAG.


When a reason for rejection is used, which allows the deleted item to be billed anew, the system stores this in table AD01DLIEF in field DOPEN

This leads to the dynamic item being billed again on a repeated run of DP90/DP91.

In our example item ZGVIBAUGRUPPEDPP1 was already billed 500,00. But as this was rejected in the billing request using a reason for
rejection opening that dynamic item again, a repeated run of DP90/DP91 again proposes that amount to be billed.

ZGVICOSTS also was already billed and rejected in the billing request. But as the reason for rejection used in that item does not open that
dynamic item again, it is considered as billed by a repeated run of DP90/DP91.

You might also like