Describing Dependent Items

This lesson explains what a dependent item is and how it can be used in different use cases.

A dependent item is a billable item or a consumption item that gets created dependent on another billable item to which it is linked. Dependent Items, also called DITs, get created automatically based on different rules defined in customizing. Dependent on those rules a part of the billable item amount gets processed differently. Each billable item in the system can have one or multiple dependent items. In this context, the billable item that is relevant to the end customer invoice is referred to as a primary billable item. The DIT can therefore also be referred to as secondary billable item. Dependent Items can be billed either separately or together with other dependent or billable items.

The most common use cases for dependent items are partner settlement scenarios where a part of the billable item amount is due to a third party, for example a portion of the item amount for a music download is to be paid to the musician as royalties. Another example for the use of dependent items could be the calculation of a discount or a charge for some specific primary item.

In general this means dependent items offer a flexible solution for any scenario where a portion of a billable item amount is to be handled differently to the rest, either it needs to be paid to a third party or a charge/discount or something similar for the customer gets calculated.

The creation process for dependent items contains the following steps:

1. A raw primary billable item gets created in the system. This primary item has a dependent item type which makes sure that when it gets transferred to the status billable that a dependent item gets created.
2. When the raw item gets transferred to status billable the dependent billable and/or consumption items get created automatically based on customizing.
3. Those DITs have a dependent item reason so that you will always know why they got created. The primary billable items are linked to the corresponding dependent or secondary items – to make sure that it is always visible which items belong together. This link is called Primary/Secondary Relationship.
4. Further downstream processing like billing and invoicing can be carried out.

As dependent items are basically just another version of billable or consumption items they do also need a billable or consumption item class. In order to be able to use the functionality of dependent items there are different interface components needed.

DIT_PRIMARY (Primary Item for Dependent Items Basic Data)

• Used for the original billable item class
• Adds dependent Item Type to the structure
• Provides fields for the primary items required for deriving dependent items
• Activates the interface component for Primary Items
• Activate this interface component only if the billable item class is intended for the storage and processing of primary items

PRIMARY_IT (Primary Items)

• Used for the original billable item class
• Contains fields for linking primary and secondary items

DIT_SECONDARY (General Data for Created Dependent Items)

• Used for the created dependent billable item
• Adds dependent Item Reason to the structure
• Activates the interface component for secondary items
• Activate this interface component only if the billable item class is intended for the storage and processing of dependent items

SECONDARY_IT (Secondary Items)

• Used for the created dependent billable item
• Contains fields for linking dependent items and primary items

DIT_PARTNER (Dependent Item Data for Partner Settlement)

• Used for dependent items with a "Partner Settlement" relation to the primary item
• Activates related interface components of the "old" partner settlement solution to allow the re-use of further FI-CA functionalities such as reversal
• Activate this interface component only if your billable item class is intended for the storage and processing of dependent items of type partner settlement

You can find the customizing for dependent items under FICAIMG:Convergent Invoicing → Enhanced Functions → Dependent Items.

The functionality of the dependent items lets you create automatically one or more dependent items for a billable primary end customer item based on the Customizing settings of the functionality of the dependent items. During transfer of a primary raw item (BIT status 0), dependent items are generated for a billable item (BIT status 2). In order to be able to use this functionality a couple of different settings have to be done in the system:

1. Create a billable or consumption item class for the dependent items and activate the according interface components.

   As mentioned before the following interfaces have to be used.

   1. interface component DIT_PRIMARY for a class of billable items for which dependent items are to be created. This interface automatically activates the interface Primary Items as well. 
   2. interface component DIT_SECONDRY for a class of consumption items or billable items to be used for dependent items. The interface Secondary Items will be activated automatically by the system.
   3. If you create dependent items using the "Partner Settlement" creation procedure, also activate the interface component DIT_PARTNER for the class intended for dependent items
2. Maintain Dependent Item Types

   The dependent item type is assigned either by the sending system or by function module to the billable primary item and is the starting point for determining the reasons assigned and creating a dependent item based on the Customizing settings. For each type, you can define the rules by which dependent items are to be created. The dependent items are linked with the primary billable items through a primary/secondary relationship.

   
3. Maintain Amount Calculation Key

   The amount calculation key is used to calculate the amount of the dependent items based on the amount of the primary item. The amount of the primary item is called base amount. With the amount calculation key you decide if the dependent item should be a charge or a discount. More complex calculations can be done with a function module.

   In the customizing of the key you can choose if the charge/discount should be a block charge/discount, if you do not select the block charge/discount it will be treated as a scaled one.

   You can simulate the result of the amount calculation key in the detail screen. The calculation Rules can be setup per currency and have a validity. The rule setup is flexible in a way that you can decide from which base amount the charge/discount should be calculated as well as if there should be a fixed portion or not. You can specify the rounding unit and rule as well as the percentage with which the charge/discount should be calculated. There is also the option to set amount limits.

   Each amount calculation key is assigned to a dependent item reason.

   
4. Define Dependent Item Reasons

   The dependent item reason is assigned to the dependent item and is there to  describe the business significance of the dependent item. The settings for the dependent item reasons decide the following:

   • Whether a dependent item is generated as a consumption item or as a billable item ( Creation Procedure )
   • Whether a dependent item is of the partner settlement type or is a general dependent item ( Dependent Item Category)
   • Which amount calculation key is used
5. Assign Dependent Item Reasons to Item Types

   In this configuration step, you additionally define the respective underlying settings (for example, class and item type) for the dependent consumption or billable items. You also have to specify the source transaction type for each entry. For dependent billable items the Subprocess has to be defined in addition. In Customizing, one or more dependent item reasons are assigned to every dependent item type. A dependent item is generated for each assigned reason.

   
6. Master Data Determination

   The following steps have to be done in order to customize the Master Data Determination for dependent items

   1. Create a number range interval for the number range object for master data IDs (FKK_MD_ID).
   2. Create a master data ID that contains all master data required for creating a dependent item.
   3. To determine at runtime the master data ID that contains the respective master data for a dependent item, assign your master data IDs to the corresponding attributes .Besides the two mandatory attributes dependent item type and -reason, further optional key components are available.

   In case the dependent items should be created for the same master data as the primary items a specific customer enhancement can be used.

7. Partner Settlement 

   If the dependent items should be used for a partner settlement scenario customize also the settings for it. Partner settlement is explained in more detail in unit Partner Settlement and Revenue Share. Using dependent items to model the partner settlement process is therefore only one of the options.

Similar to the billable items events there are different customer enhancements which can be used to adapt the system behavior according to your needs. As the list shows you have the option at any time to adjust the dependent items created by the system based on customizing settings. To do this, for the dependent item reasons, the listed events for customer implementations are available.

For example, in Event 15 (Master Data Determination) you can implement logic to always use the business partner and contract account of the primary item instead of using the determination by master data ID. This is often used in case dependent items are solution for discounts or charges.

In Event 35 you can add data to the dependent billable item, for example you can take over the values of custom fields of the primary item into the secondary item for further processing.

Dependent items are items which are linked to primary billable items via the primary/secondary relationship. The Billable Item Monitor is used to display billable items of all types therefore it can also be used to display DITs. The Billable Item Monitor will display the Dependent Item Type for the primary item as well as the Dependent Item Reason for the secondary item. With that you can get all the information needed to evaluate billable items and there dependent items.

It is also possible to directly navigate from a primary billable item to its according dependent items via the Primary/Secondary Relationship Icon.