SAP customer project guide

In customer projects, the actual costs are settled, but accrued amounts (such as costs of sales or
inventory from which revenue can be generated) are not. You carry out this settlement at billing
element level.
For customer projects which you settle in full to Profitability Analysis, it is a good idea to generate
the settlement rule using a strategy defined in the IMG. The standard system includes a strategy
for
automatically generated settlement rules for customer projects.
The system uses this strategy to generate the following:
For all billing elements:
- Results analysis key
- Settlement to profitability segment
- A settlement profile providing for settlement in full
For all other WBS elements:
- No results analysis key
- A settlement profile providing for no settlement
If account assignment elements within a billing structure do not contribute to the cost of sales,
you can change the settlement rule manually.
If you maintain the settlement rule manually,
- Use a project profile with a settlement profile that forbids settlement. This initially prevents
settlement for all the WBS elements in the project.
- Change the settlement profile in the billing elements manually. Define a settlement profile
that permits settlement
- If you want to settle account assignment elements (in whole or in part), you must change the
settlement profile for account assignment elements manually.
Experience has shown that manual settlement rule maintenance for very complex project
hierarchy structures is very time-consuming and brings with it the risk of inconsistent
characteristics in settlement of customer projects to the profitability segment. The system uses
automatic generation to create the settlement rule and parameters, in accordance with the
strategy defined in the IMG. The type of planning decides which strategy applies to which object:
- Planning element
- Account assignment element
- Billing element
- WBS element with change of organization re the superior WBS element
To generate settlement rules automatically, choose Logistics or Accounting -> Project
System -> Financials -> Period-End Closing -> Individual Functions -> Settlement Rule.
2. The system selects the objects according to the selection criteria in the database.
3. Using the project profile, the system determines which strategy to use for automatic rule
generation. In line with the strategy, the system generates:
- The settlement profile for the WBS element
 SAP customer project guide

This determines, for example, which receivers are allowed for settlement
- The results analysis key in the WBS element control data
This stipulates how valuation and results analysis take place.
- The settlement rule for the WBS element
In the settlement rule, you stipulate the apportionment rules and settlement
parameters. The system generates the actual settlement rule.
- Characteristic derivation for settlement to profitability segments
As a rule, the system generates a periodic settlement of 100% to the receiver entered in
the strategy. You can stipulate the following account assignment categories in the
strategy.
Hence , RA is not at all mandatory !
 SAP customer project guide

Resource-related billing (RRB)

Skip to end of metadata
 Created by Gerald Vilimovsky, last modified by Former Member on Dec 19, 2016
Go to start of metadata

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)

 SAP customer project guide

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

 SAP customer project guide

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

 SAP customer project guide

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***

 SAP customer project guide

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

 SAP customer project guide

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
 SAP customer project guide

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
 SAP customer project guide

 Sources view
 SAP customer project guide

 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

 SAP customer project guide

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

 SAP customer project guide

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).
 SAP customer project guide

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.
 SAP customer project guide

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.
 SAP customer project guide

E.g. you can see, which selection criteria is used in material determination.
 SAP customer project guide

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

 SAP customer project guide

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
 SAP customer project guide

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:
 SAP customer project guide

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.
 SAP customer project guide

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
 SAP customer project guide

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.
 SAP customer project guide

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’
 SAP customer project guide

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.
 SAP customer project guide

3.2 Sales price view

 SAP customer project guide

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

 SAP customer project guide

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.
 SAP customer project guide

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.
 SAP customer project guide

Within this subroutine the system tries to get already existing dynamic items. As they were read before, they can be
found:
 SAP customer project guide

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:
 SAP customer project guide

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.
 SAP customer project guide

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:
 SAP customer project guide

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.
 SAP customer project guide

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.

 SAP customer project guide

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.
 SAP customer project guide

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.