Using Additional Functionality Related to Standard Service Processes


After completing this lesson, you will be able to:

  • Use additional standard functions of service order management

The Accounting Indicator

In the app Manage Your Solution, after choosing Configure Your Solution, you can search for application area Service and then under General Settings you can find the option Accounting Indicators For Service. Here, you can check what accounting indicators have already been defined in the system and you can add new indicators if required.


Initially, there was a default account indicator available using key S1. To provide more flexibility in accounting indicator usage, the existing accounting indicator with key S1 was replaced by SAP in release 2208 with a new accounting indicator with key S2. As of SAP S/4HANA Cloud 2302, the accounting indicator with key S1 is not available anymore.

You can then create new pricing condition records for condition type DAI2 (Accounting Indicator (%)) using the (new) accounting indicators as key fields.


You can activate this feature with technical ID CRMS4_SRVC_ACCOUNTING_IND in the app called Activate New Features. Once you activate the feature toggle, the accounting indicator with key S1 is not listed in the value help anymore, and therefore, you cannot select it for new service transactions. You can still complete processing of all service transactions that have been created using the accounting indicator with key S1.

All existing pricing condition records that use the accounting indicator with key S1 need to be replicated in order to use the new accounting indicator with key S2.

The accounting indicators can now be used in the service order items and based on the defined condition records, they influence the pricing of the service order items. You can see this by navigating to the pricing details for a service order item and checking if condition type DAI2 is visible with the correct value assigned.

The accounting indicators used for the service order items are later on also copied into the service confirmations for these items.

Output Management for Service Orders

Process Steps

On release of a service order, the output Items for that service order are generated and are visible in a header area in the Output Control tab.

The user can preview the output of the form for the service order in PDF format.

The form contains details about the ship-to address, requested service dates, customer contacts, item details and pricing, and has a placeholder for reference remarks. It is possible to configure the form as per business requirements.


Service contract IDs can be printed on output forms of service orders at both header and item level. This saves time when searching for the service contract IDs, which are used to handle customer calls and emails.

The gateway service FDP_CRMS4_SRV_OUTPUT_SRV, which contains the entities ServiceContractNode and ServiceContractItemNode, is used to fetch data of service contract IDs for the output forms.

Changes to a service order can require an update of the form. You can do this by clicking the Determine Items option in the service order. Only Released and Completed items are considered in the form. Rejecting a service order does not trigger a redetermination of items on the form.

Sending an e-mail can be triggered by choosing Send Output. The e-mail contains the service order details in a PDF file that is added as an attachment. E-mail addresses are determination based on the master data. Two default roles are supported: Contact Person and Sold-To Party.

The figure, Send Output, shows an example of an e-mail that is sent to the customer contact person with the e-mail template selected (based on the e-mail configuration).

The following templates are provided by SAP:

  • CRMS4_SERVICE_ORDER_SUMMARY (Service Order Summary)
  • CRMS4_SERVICE_ORDER_EMAIL_TMPL (E-Mail Template for Service Orders)

Flexible Configuration of Output Relevance

As stated before in the unit explaining service contracts, in SAP S/4HANA Cloud Public Edition, service, a flexible way is available of defining whether a service contract, a service quotation and/or a service order is relevant for output. Rules can be defined for each type of document individually. The slide shows rules set up for a service order. This can be done in a similar way for a service contract and/or a service quotation.

The fields Error Status, Cancellation Status, Release Status and Open are available as columns in the decision table used to set up the output relevance for a service order. For a service contract, the field Error Status is available to do this. For a service quotation, the field Release Status can be used.

Since this topic is also relevant for both service contracts and service quotations, it is also discussed in the respective units of this course discussing these documents.

More Functionality of a Standard Service Process

Integration of the Sales Text from a Service or Expense Product

In the material master record of a service product or an expense product, a sales text can be maintained. This sales text is then copied from the material master record to the service order item where this product is used.

In the service order item, the sales text can be updated. The updated version will then be copied from the service order item into the corresponding service confirmation (when it is being created).

From the service confirmation, the sales text is copied into a subsequent billing document request (BDR) and from there into the corresponding invoice.

Finally, the sales text is available for output on the printable version of the invoice.

Service Documents in the Customer 360° View

This feature has the following properties:

  • It leads to an improved overview of customer-related processes, including sales and services. This is achieved via a single access point for all customer processes across sales and services.
  • The content in the Customer - 360° View app was enhanced to include tabs for service quotations and service orders.
  • Navigation to the Customer 360 View app was provided from within the app Manage Service Orders by selecting Sold-to-party.

Service Teams

A service team is an organizational unit to which service employees are assigned for performing service tasks. It facilitates the assignment of service employees in service transactions, related analytics, and the search for service transactions.


It is not possible to create a hierarchy in a team's structure. This means that it is not possible to group people (team members) into sub-teams based on their responsibilities (member functions).

Service teams can be implemented by using the team function in Responsibility Management. Using the SAP Fiori app Manage Teams and Responsibilities, it is possible to create master data or maintain pre-delivered master data for service teams by specifying team types of team category Service. The master data of a service team includes country, postal code, plant, and storage location.

The country and postal code specify the location for which a service team is responsible. The system uses these two fields to determine appropriate service teams for customers in different countries and regions.

The plant and storage location specify the default location where a service team member (executing service employee) obtains service parts to perform a service task. After creating the master data for a service teams, configuration steps must be executed to enable the use of service teams in specific service transactions.

The system can determine service teams based on the country and postal code of the ship-to party or sold-to party. Service teams are automatically determined on the header of a service order or a service confirmation. These determined service teams are inherited by the items of the service order or service confirmation. It is possible to use the Propose Service Team function to manually trigger the service team determination for the items of a service order or a service confirmation.


If multiple service teams are determined for the header or items of a service order or a service confirmation, the user is prompted to select a service team. Also, the determined service teams can be changed. After the service teams are changed in the header of a service order or a service confirmation, the changed service teams are inherited by the items of the service order or service confirmation. However, if the origin of the existing service teams is Manually Entered/Selected or Corrected Based on Executing Service Employee in the items of a service order or service confirmation, the service team is not inherited.

A function classification EXEC_SRVC_EMPLOYEE is defined by SAP for a team with category Service.

Users can map their own defined team functions to this function classification. Then, these user-defined functions are classified as Exe. Service Employee (EXEC_SRVC_EMPLOYEE).

A team member who is not classified as Exe. Service Employee (EXEC_SRVC_EMPLOYEE) is not part of a search result (in for example, a service order) by default.

An assigned Exe. Service Employee (EXEC_SRVC_EMPLOYEE) needs to originate from the service team assigned in the same service order item, or an error message is displayed (2002CE). If a person assigned as Exe. Service Employee (EXEC_SRVC_EMPLOYEE) does not have the function which has been assigned as Service Employee based on the classification, a warning message is displayed.

SEPA Mandates

In the Single Euro Payment Area (SEPA), a payer can authorize a company sending a billing document to this payer to collect payments as direct debits. To consent debits from a payer’s account, the payer has to sign a SEPA mandate.

The scenario discussed here is the following: You want to collect the payments for a payer as direct debit from your customer’s account according to an existing SEPA mandate for the billing documents created for your service orders/service confirmations. Analyzing/creating SEPA mandates is done using the app called Manage SEPA Mandates.

For a certain customer (i.e. payer) one or more SEPA mandates can be created. To be able to use a SEPA mandate, it needs to have status that is set to Active and that is still valid.

You create a service order for a payer with an active SEPA mandate. The terms of payment in the service order need to chosen so that a SEPA relevant payment method is selected (like Direct Debit).

The SEPA mandate field (Mandate Reference) is changeable later on if needed A SEPA mandate maintained on header level in a service order is inherited in all items of that service order.

Once a service order with a SEPA mandate is released, a service confirmation can be created that also receives the SEPA mandate that is present in the service order. The service confirmation is then completed and released for billing.

The billing document (created based on a billing document request) again contains the same SEPA mandate as the one that the service order and the service confirmation contain.

Log in to track your progress & complete quizzes