Resource-related billing (RRB)
under construction
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 can’t 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 Pricing
The interface between RRB and SD pricing 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 doesn’t 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.