Resource Related Billing PDF
Resource Related Billing PDF
Resource Related Billing PDF
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:
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
1.2.2 Operative
DP90 Billing request; process individually (SD and CS orders)
DP98 Resource item for billing request/credit memo request; from 470 onwards, Reporting transaction
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)
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.
Sets can be defined within customizing using either the customizing transactions for the DIP profile, or by using TA GS01/GS02.
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’.
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.
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.
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.
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.
In this example there are different WBS-elements and activities which will get posted with costs of different characteristics
1.7 DP90/DP91
DP90 (DP91) shows the collected costs summed up into the various dynamic items as customized in the DIP profile.
2. Program flow
Development class AD01
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.
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.
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.
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.
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.
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_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.
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).
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.
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.
4. Specific questions
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).
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.