Customer Service

SAP DI processor: Effort-based billing in maintenance and customer service

The prices for customer-specific services are not always specified as fixed prices in a contract or determined using standard pricing. This is particularly the case when there is insufficient empirical data available for certain services and therefore no reliable calculation can be made before the contract is concluded. Typical examples of this are:

• Services and consulting
• Maintenance or repair of a product or plant
• Customized production, e.g., in the form of creating a customer-specific product or equipment

These orders are invoiced on a time and material basis. The customer is provided with evidence of individual materials, internal services, and costs in the invoice.

SAP provides a solution for this in the form of the DPP (Dynamic Items Processor) in both ECC and S4/HANA. Although extremely powerful, it is rarely used to its full extent. This is unfortunate, as it means that the possibilities for automating business processes with activity-based billing are not being fully exploited.

Dynamic items and the SAP solution

Dynamic items are data that are summarized according to defined criteria from a project, a sales order, or a service order. They are used in quotation creation and sales price calculation as well as in invoicing. The data is summarized from defined sources, such as line items or planned cost summary records, using the dynamic item processor (DI processor). This process is controlled by the settings in the dynamic item processor profile.

In short, the DI processor calculates planned or actual costs as individual or total records from various sources, such as CS (customer service) orders or freely defined, customer-specific sources. On this basis, materials and quantities are determined, which are then billed via a customer order—referred to as a billing request in the DI processor context.

With all this in mind, it is important to remember how complex effort-based invoicing can be in practice. The SAP standard in the form of the DI processor—and this refers to customizing and SAP extension options in the form of BAdIs and enhancements—covers these requirements in an impressive manner. SAP has thought very far ahead and comprehensively here: Cost-based billing, and the DI processor in particular, are closely integrated with the SD, PM/CS, and PS modules. the DI processor can therefore also be used profitably in areas that are not immediately obvious or that were not initially considered.

Benefits for your company

Even if you are not currently planning to introduce a cost-based DI processor solution, it is worth taking a closer look at the possibilities. This will broaden your fundamental view of process automation with SAP.

Below you will find selected highlights relating to the DI processor and cost-based invoicing that we have successfully implemented in our customer projects:

• Generation of SD documents (quotations/invoice requests) via OData service. This required encapsulation of the DI processor in function modules.
• Creation of quotations via DI processor based on planned costs “without” CS orders.
• Simultaneous settlement of more than one CS order and creation of a separate hierarchy that is reflected in the SD items.
• Multiple billing of “one” CS order depending on the customer relationship with “multiple” customers.
• Complex cross-system and cross-client source identification.
• Billing of a CS order based on expenditure, fixed price, or flat rate.
• Down payment processing via DI processor

Implementations and expertise of clavis

We have extensive expertise in implementing DI processor solutions, particularly for energy suppliers, and have successfully implemented these in numerous customer projects. Energy suppliers in particular have particularly high and complex requirements due to the specific nature of their business processes and regulatory requirements.

All this was possible because the solution architecture provided by SAP offers this flexibility. At this point, we would like to express our sincere respect to the SAP architects and developers who developed this solution. There are not many examples in the SAP world where the standard can be expanded so extensively and effectively with relatively little intervention.