Understanding Service Operations and Processes

​AI-Assisted In-House Service Initiation enables you to create in-house repairs and repair objects from documents using AI technology. This makes it easier to initiate the in-house repair process for repair objects from service quotations or service order or in the Manage In-House Repairs app without typing data manually in your system.

​AI-Assisted In-House Service Initiation is available in the following apps when you click the Create from Document button:

• Manage In-House Repairs: Create in-house repairs and repair objects
• Manage Service Quotations in the Repairs Objects (In-House Repair) assignment block: Create repair objects
• Manage Service Orders in the Repairs Objects (In-House Repair) assignment block: Create repair objects

After uploading the document into your system, the content is imported into the in-house repair process using the Document Information Extraction service on the SAP Business Technology Platform. Generative AI technology supports the extraction of the data required for the creation of the in-house repair and the repair objects. Based on the extracted data, the system then searches for and identifies the relevant master data for the equipment, product, or business partner in In-House Repair, for example, the sold-to party or the equipment. The result of this data extraction and data enrichment is then displayed in the corresponding fields in the apps and can be reviewed there. Having reviewed the result, you can create the in-house repair and/or the repair objects.

After completing this learning module, you will be able to understand:

• How to create in-house repairs and repair objects based on a scanned paper document
• How to create repair objects for existing service orders and service quotations, based on a scanned paper document

Repair shops process a lot of information on paper. There is a high manual effort when converting the information from paper to an SAP document in the system. In addition, the potential error rates and the loss of information caused by the manual process and time pressure are high.

Enable repair centers to record information about the repair objects of paper using the Document Information Extraction service.

• The paper document (for example, a purchase order) is scanned or photographed in the repair center
• The Service Management solution can automatically create a list of repair objects for the in-house repair/service order/service quotation.
• The result is checked at the repair center, which then further processes and releases the service order/in-house repair.

• Time-to-value: Automates the process of extracting form data and creating repair objects in SAP S/4HANA Cloud Private Edition.

• Accuracy: Reduces human errors, improves overall process efficiency, reduces process execution time, and generates immediate savings.

• Improve operation: Automatically identifies equipment that exists in the system. Avoids manual and repetitive tasks.

As a prerequisite for this process, the paper document that contains the data relevant for in-house repairs and repair objects must be available as a digital scan or digital copy.

To initiate the process, click the Create from Document button in the Manage In-House Repairs app.

In the dialog box, click the Select and Upload button to select the digital paper file from the computer. This automatically initiates the upload to the Document Information Extraction service.

While the information extraction and data enrichment are performed in the background, the running process is marked with the busy indicator. If required, you can already start filling header data such as sold-to party and organizational information manually. In this case, the input is considered a manual input and is not overwritten by extracted information.

After the information extraction and data enrichment has been performed, the data is filled in the corresponding fields. Fields for which no data could be extracted remain empty. In case of errors or warnings, the corresponding fields are highlighted. The tooltip of each field indicates whether the data was populated with the value identified by the Document Information Extraction service or whether the value is a derived value based on the data enrichment algorithm.

For details on the origin of the values of the individual fields, see the message log.

Once you have checked the values in the dialog box and corrected it if necessary, you can create the in-house repair including the related repair objects. To do this, click the Create button.

As a result, the in-house repair including the repair objects is created. Now, you can proceed as usual, for example, by adding additional repair objects, confirming the in-house repair, and creating follow-up transactions, such as service quotations or service orders.

The document from which the data was extracted is automatically attached to the in-house repair.

Alternatively, you can add repair objects to an existing service order in the Repair Objects (In-House Repair) assignment block. To initiate the process, click the Create from Document button.

In the dialog box, click the Browse button to select the digital paper document to be used to extract the data.

To initiate the upload to the Document Information Extraction service, click the Upload button. While the information extraction and data enrichment are performed in the background, the running process is marked with the busy indicator.

After the information extraction and data enrichment has been performed, the data is filled in the corresponding fields. Fields for which no data could be extracted remain empty. In case of errors or warnings, the corresponding fields are highlighted. The tooltip of each field indicates whether the data was populated with the value identified by the Document Information Extraction service or whether the value is a derived value based on the data enrichment algorithm.

For details on the origin of the values of the individual fields, see the message log.

Once you have checked the values in the dialog box and corrected it if necessary, you can add the corresponding repair objects into the 'Repair Objects' assignment block of the service order. To do this, click the Confirm button.

As a result, the extracted repair objects are added to the service order. From here, you can continue as you are used to, for example, by adding additional repair objects or entering other data into the service order. As soon as the service order is saved, the in-house repair and the repair objects will be created and linked to this service order automatically.

You should now be able to:

• Create in-house repairs and repair objects based on a scanned paper document.
• Create repair objects for existing service orders and service quotations, based on a scanned paper document.

For more information, see the product assistance for In-House Repair on SAP Help Portal at In-House Repair.

• SOAP API for Service Orders
  • Suppress Service Contract Assignment
  • Net Value, Gross Value, Tax Amount
• ODATA API for Service Orders
  • Business Completed / Reopen
  • Posting Date, Created by, Created at, Changed by, Changed at
  • Qualification Requirements Fields

The following new features are now supported:

• Suppress Service Contract Assignment

  The field can be used to indicate that no service contract should be assigned to a service order item.

• Net Value (Header and Item)

  The net value of the header and items of the transaction.

• Gross Value (Header and Item)

  The gross value of the header and items of a transaction.

• Tax Amount

  The tax amount of the header and items of a transaction.

If no service contract ID is given in the payload for the ServiceContractID field of a given item, the Assign Service Contract dialog opens in the UI when a user edits the transaction. In this case, a service contract can be assigned, or you can decide to assign no service contract.

When the Suppress Service Contract Assignment field is set to true, you indicate that no service contract shall be assigned to the item.

In this case, the Assign Service Contract dialog does not open in the Edit mode.

Net value, gross value, and tax amount on header and item level are basic pricing information.

The information is available in the outbound and notification service.

The OData API for Service Orders now supports the following new features:

• Business Completed / Business Reopen

• The following fields provide information about all direct predecessor and successor transactions:

  • Posting Date

    Posting date of the transaction.

  • Created By

    User who created the transaction.

• Created At

  Timestamp when the transaction was created.

• Changed By

  User who changed the transaction the last time.

• Changed At

  Timestamp when the transaction was changed the last time.

With OP2023 FPS1, the Business Completed and Reopen Business statuses of service orders were introduced. Business Completed indicates that the transaction is finished from a financial perspective (no financial postings allowed) and transactional perspective (only display mode) with processing and ready for archiving.

Reopen Business can be used if some unexpected activity needs to take place on the business side that requires financial postings again, like a customer complaint, resulting in a credit memo request.

Now, the settings of both statuses are supported for ODATA APIs for Service Orders as well.

The posting date of a transaction defines on which date the document was entered into the system. Normally, this is the creation date.

You can change the posting date to the past or future if you want to indicate that the document should have been entered into the system earlier or later.

With SAP S/4HANA Cloud Private Edition release 2023, feature package 3, it is now possible to read or specify the posting date via the OData API for service orders.

Created By, Created At, Changed By, and Changed At are basic creation and change information of a service order transaction that was requested by several customers and are also important for internal integration use cases.

The OData API for Service Orders now supports the Qualification Requirement fields:

• Business Trans. Category
• Transaction ID
• Object ID for Qualification Requirement
• Item Number in Document
• Qualification Requirement Valid From
• Qualification Requirement Valid To
• Is Requirement Mandatory
• Optimum Qualification Requirement
• Weighting

The qualification requirements feature is enabled for the Service Order OData API.

​You should now be able to understand:

• SOAP API for Service Orders
  • Suppress Service Contract Assignment
  • Net Value, Gross Value, Tax Amount
• ODATA API for Service Orders
  • Business Completed / Reopen
  • Posting Date, Created by, Created at, Changed by, Changed at
  • Qualification Requirements Fields

Billing is very crucial, hence several enhancements were made.

The Release for Billing app provides the new search parameter Related to Service Order ID. With this, a search for billable service order items will also include a search for billable service confirmations items that are created as a follow-up from this service order.

During the creation of billing document requests (BDRs), the entered product on the service transaction item that is substituted through product substitution will be also passed on to billing. With this, not only is the substituted product available on the billing documents but also the entered product.

If BDRs are created for an ad hoc billing plan on service order items, these BDRs can be checked on the ad hoc billing plan. Now, these BDRs are also available in the Transaction History on the service order header and item.

Partial billing for service confirmation items can be used to release billable service confirmation items for billing when predecessor service order items are Completed, but not the whole service order. In delivery customizing new service confirmation item categories are now available that can be used out-of-the-box.

The partial billing feature is enhanced with a new setting so that such billable service confirmation items can be released for billing if predecessor service order items have the status Completed or Released. With this, completed service confirmations can be billed and further service confirmations can be created.

After completing this learning module, you will be able to understand:

• The new search parameter in the Release for Billing app
• Substituted products in billing integration
• Display billing document requests (BDRs) for an ad hoc billing plan in the Transaction History
• New item categories for partial billing feature on service confirmation items
• Enhanced partial billing feature for service confirmation items

​The Release for Billing app provides the new search parameter Related to Service Order ID.

If a service order ID is entered for the new search parameter Related to Service Order ID, the search will determine not only its billable service order items but also billable service confirmations items that are created as a follow-up from this service order. The already available column Predecessor ID can be added to the search result list for checking which service confirmation belongs to which service order.

An entered product on the service order item shall be replaced with another product through product substitution.

A substituted product is chosen for the service order item. This service order item is confirmed and completed. During release for billing, the substituted product on the service order item is passed on to the billing document request item. Now, the entered product is also passed on to billing.

The billing document request item displays the substituted product in the Material field, and the product entered originally in the Material Entered field.

The invoice that is created for this billing document request item displays the substituted product in the Material field, and the original entered product in the Material Entered field.

The billing document request (BDR) that is created for a billing request line of an ad hoc billing plan on a service order item can be displayed in a column that can be added through personalization.

Now, billing document requests (BDRs) of such billing request lines are also displayed on the Transaction History tab of the service order item and also of the service order header.

The service order item categories for expenses SRVE and for service products SRVP are copied accordingly to service confirmation item categories SVCE and SVCP.

The billing relevance of these service confirmation item categories is set to Billing On Completion. The completed service confirmation can be released for billing, if the related whole service order is completed.

New service confirmation item categories for expense and service product SPCE and SPCS are introduced.

The billing relevance of these service confirmation item categories is set to Partial Billing. The completed service confirmation can be released for billing. If the related service order items are completed, the whole service order could still, for instance, be released.

The new service confirmation item categories can be chosen in the Item Category dropdown list.

The billing relevance for an item category of service confirmation items is set to Partial Billing. Now, a new checkbox is displayed: Even If Predecessor Order Items Are Only Released.

If this checkbox is selected, the completed service confirmation items can be released for billing when their predecessor service order items have the status Completed or Released.

With this new feature, completed service confirmations can be released for billing in case the predecessor service order items are not completed yet.

​You should now be able to

• Explain the search with new search parameter in the Release for Billing app
• Describe the billing integration of substituted products
• Display billing document requests (BDRs) for an ad hoc billing plan in Transaction History
• Explain the new item categories for partial billing feature on service confirmation items
• How partial billing feature for service confirmation items was enhanced

Searching for service confirmations is made easier with the new search parameter Predecessor Service Order ID.

​With this new search parameter, you can easily find all service confirmations that are created as follow-up from this certain service order.

The new column Predecessor Order ID can be added to the search result list via personalization.

​After completing this learning module, you will be able to understand:

The new capabilities in the Service Confirmation Search app

The Search for Service Confirmation app supports the new search parameter Predecessor Service Order ID. ​With this new search parameter, you can easily find all service confirmations that are created as follow-up from a certain service order. ​​

The new column Predecessor Order ID can be added to the search result list via personalization. With this, you can easily check the relations.

You should now be able to:

Describe the new capabilities in the Service Confirmation Search app

After completing this learning module, you will be able to understand:

• Planning of manual GI in service order with the support of Recipient Location in the service order
• Transaction history with Outbound Delivery update
• Transaction history with Inbound Delivery update

During the service order planning, until the service part item is Released, the service manager will be able to define if the service part shall use the manual GI SRVG item category. Depending on this decision, in the service confirmation you can indicate the Recipient Location.

Outbound Delivery creation from MIGO/MB26 will update the service order transaction history.

Inbound Delivery creation within the Return Process will update the Service Order transaction history.

You should now be able to understand:

• Planning of manual GI in service order with the support of Recipient Location in the service order
• Transaction history with Outbound Delivery update
• Transaction history with Inbound Delivery update

• Unplanned item - automatic completion of service order item
• Enhancement to Financial Hierarchy

Unplanned items can be added to the service confirmation if additional items, which haven’t been planned before, are needed during service execution. To improve user experience, the logic has been enhanced.

If an unplanned item in the service confirmation is completed, the automatically created unplanned item in the service order is completed as well. This simplifies the process in the service order, especially when you are using the Field Service Management (FSM) Integration.

With SAP S/4HANA Cloud Private Edition release 2023 feature package 2, the new financial scenario Financial Hierarchy in a Service Contract was introduced. In this scenario, the revenue is billed from the service contract and the cost comes from the follow-up service order with advanced execution order items and follow-up maintenance orders.

For the supported advance execution order items, only the billing relevance Not Relevant for Billing was supported.

Now, it is also possible to choose the billing relevance Billing on Completion.

You should now be able to understand:

• Unplanned item - automatic completion of service order item
• Enhancement to Financial Hierarchy

• When item-based accounting is active, each service order item creates its own account assignment object. ​As of OP2023 FPS03, this behavior is enhanced with the function Service Hierarchy with Collective Accounting. With this new function, you can customize the inheritance of the account assignment object of a main item in an item hierarchy.

• New item category Service Item with Collective Accounting: You assign this item category to an item and designate it as the main item in Service Hierarchy with Collective Accounting.
• New value Inherit to Subitems in Customizing: When this value is selected, the service item with collective accounting creates its own account assignment object and all the subitems of this item inherit this account assignment object.
• With the new Customizing value and the new item category, you can use the function Service Hierarchy with Collective Accounting.

After completing this learning module, you will be able to understand:

Service Hierarchy with Collective Accounting

When item-based accounting is active, each service order item creates its own account assignment object. For a price item, the inheritance of the account assignment object from its higher-level item was introduced via the customizing flag Inherit from Higher-Level Item (‘X’) in 2023OP FPS1.

With 2023OP FPS3, this behavior is enhanced with a new value in Customizing for item categories. With the new value Inherit to Subitems (‘C’), the service order item creates its own account assignment object and all the subitems of this item inherit this account assignment object. All the costs and revenues that are triggered by the subitems are posted only to this single account assignment object.

This item is called Service Item with Collective Accounting.

​Example: Time & Material (T&M) Main Item with Collective Accounting

• Item 10 has an account assignment object.
• All subitems don’t have their own account assignment objects.
• All items are relevant for service confirmations and will be billed via service confirmation.

For main item 10, an account assignment object is created.

No account assignment objects are created for any subitems, for example, subitem 40.

You can create service confirmation items for the main item and each subitem.

The invoice is created and posted to Financial Accounting.

The costs and the revenues are posted to the account assignment object of the main item.

​Example: Fixed Price (FP) Main Item with Collective Accounting

• An account assignment object is created for item 10, but the item is only relevant for billing and not for confirmation.
• No account assignment objects are created for any subitems. The subitems are relevant for confirmation, but they won’t be billed via the service confirmation.

For main item 10, an account assignment object is created.

No account assignment objects are created for any subitems, for example, subitem 40.

Service confirmation items can be created for the subitems.

The invoice is created and posted to Financial Accounting.

The costs and also the revenues are posted to the account assignment object of the main item.

The Planned Cost and Revenue assignment block is visible on the main item and sums up all the cost and revenue of all subitems and the main item itself.

Be aware that there can be a difference in the planned cost after the Update Baseline button is used if an execution order item is a subitem of the service item with collective accounting. This is because the maintenance order triggers its own planned cost separately from the service order.

​Service contract assignment can only be done on the main item as the service contract is an attribution for the account assignment object. Price agreements from service contracts are inherited to all of its subitems. ​

In the Assign Service Contract Assignment popup, the service contracts are filtered for equipment maintained on the main item as it is done for standard items.

You can add an unplanned item to a service hierarchy. As usual, a service item must be selected as reference item. Any service item in the service hierarchy including the main item itself can be used as a reference item. The unplanned item is then added as a subitem to the reference item. This unplanned item will have the status Released in the service order and the status Open in the follow-up service confirmation. As usual, the unplanned item in the service confirmation can be deleted as long as it is not set to Completed.

The service hierarchy supports event-based revenue recognition. To enable this, a revenue recognition key must be assigned to the item category of the item with an account assignment object: the main item. ​

The revenue is recognized depending on the chosen method. If the TECO status is set, the full cost and revenue are recognized. Independent of the method, the full cost and revenue are recognized (EBRR accounts cleared). The main item and all the subitems must fulfill the prerequisites for setting the TECO status. For example, completed follow-up processes, billing processes, and cost postings.

Supported revenue recognition methods are Completed Contract and Cost Based Percentage of Completion.

​When item-based accounting is active, the TECO report analyzes the items. If prerequisites are met, the report sets the status of the corresponding account assignment object to the status TECO.

The report displays a log that informs users of whether the TECO status has been set or not and the reasons why the status TECO is not set.

The account assignment object for a service hierarchy is always on the main item. But potential log messages can come as well from the subitems of the hierarchy. To know which item offers which log information the log text has been enhanced to include the item number into the message text.

A service hierarchy can have a sales item as a subitem. The new Controlling scenario Service is supported not only for standard items but also for service hierarchy and can be customized in the IMG activity Define Item Categories.

​In this case, a sales item in a hierarchy will use the main item’s account assignment object as well and transfer it to the follow-up sales order. As a reminder, in the Sales scenario, the sales item is just a placeholder and the sales order creates its own account assignment object.

The sales item is now integrated with planned cost and revenues and event-based revenue recognition.

​The account assignment object of the service hierarchy main item is then displayed in the sales order.

​You can use service hierarchies with collective accounting in service quotations. According to your Customizing configuration, you can:

• Add main items with collective accounting to your service quotation.
• Add subitems to these main items that inherit the service contracts from the main items.
• Create a follow-up service order and copy the service hierarchies to this order.
• Create a requote.
• With acceptance of the requote, copy the newly accepted items to the existing service order.

1. Prerequisite to do requoting is an initial quotation that has no quotation and no order as a predecessor assigned.
2. With the acceptance of the initial quotation a new service order is created as a follow-up transaction. All accepted items in their relation to a higher-level item are copied to this service order.
3. A requote can be created from the latest service quotation that is related to the service order.
4. When the requote is accepted the accepted items which were newly added to the requote are copied to the existing service order. This includes the relation to the higher-level item if this also exists in the service order.

Example: Initial quotation containing a Time & Material (T&M) Main Item with Collective Accounting

• Service contract determination and assignment takes place for item 10.
• Subitems don’t have their own contract assignment but inherit the one from item 10.

If you choose Accept in the initial quotation:

• A follow-up service order is created.
• All accepted items are copied to this service order.
• The copied items include relations to the higher-level items.

If you choose Create Follow-Up:

• A follow-up service order is created.
• You can choose the items to be copied from the quotation to the order.
• The copied items include relations to higher level items if those were also copied to the service order.

​To create a requote, choose Requote in the latest service quotation that is related to the service order.

You can add new items to the requote and send it to the customer. It's possible to add a new item under an existing main item that has been accepted in a predecessor quotation.

If you choose Accept, the item 50 with its relation to the higher-level item 10 is copied to the existing service order.

• Execution order item can be included as a subitem in the Service hierarchy.
• Execution order item cannot be main item in a Service hierarchy.
• This is enabled in both Service order quotation and Service order.
• No account assignment objects are created for the execution order item.

• All the planned and actual costs which are collected on the corresponding billable maintenance order are attributed to the account assignment object of the main item. ​
• Revenues are anyway posted directly to the account assignment object of the main item.
• Itemized Billing and Summarized Billing are not supported in the context of a Service hierarchy. The execution order item can have a billing relevance of Not Relevant for Billing, Billing on Completion or Billing via Billing Plan After Release depending on the business scenario.
• All other features of service with advanced execution is supported including resource-related quotation and distributed execution. ​

• Warranty determination is independent at item level
• Accounting indicator is copied from master warranty of main reference object of the items
• Warranty ID and accounting indicator can be different at main item and subitem

• Service order / service quotation items are copied from the service order template assigned to the maintenance plan item
• If the service order template contains a service hierarchy (main and sub items), they will be copied to the call objects (order / quotation)

• Service order item is copied from the service contract: Only the item that is referred in the maintenance plan item is considered to copy from service contract to service order

You should now be able to understand:

Service Hierarchy with Collective Accounting

After completing this learning module, you will be able to understand:

• How to activate qualification requirements for service transactions – service orders, service order quotations, and service order templates
• Qualification catalog and master data assignment
• Manual assignment of qualification requirements at transaction header or items
• Automatic determination of qualification requirements at transaction header or items
• Copy of qualification requirements from source to target transaction

With this feature, it is now possible to define qualification (skill) requirements in service transactions (service orders, service order quotations, and service order templates) to be able to match qualified technicians or service personnel to the right tasks.

The qualification requirements are created under a qualification catalog and can be manually assigned in the service transaction header or service items.

In addition, the qualification requirements can also be assigned to below master data and automatically determined in the service transactions:

• Sold-To Party
• Ship-To Party
• Equipment
• Reference Product of Equipment
• Functional Location
• Reference Object Product
• Service Products

Qualification requirements can be activated for a transaction type by selecting the parameter ACTIVE under Define Parameters for Qualification Requirements in Transaction.

Qualification requirements can also be activated at item category level for the service items by selecting the parameter ACTIVE under Define Parameters for Qualification Requirements for Item Category.

Additionally, the INHERIT parameter, if selected at both transaction type and item category, allows you to automatically inherit qualification requirements from header to items as well as from main item to sub-items.

Qualification group and qualification requirements can be created under Edit Qualification Catalog (Tx: OOQA).

Qualification group and qualifications use a proficiency scale that can be defined under Maintain Scales.

The qualification requirements can be assigned to the below service-relevant master data under transaction PPPM :

• Business Partner: (sold to party, ship to party)
• Material: (service material, equipment reference product, reference object product)
• Equipment
• Functional location

Along with the qualification requirement, corresponding proficiency, mandatory flag, and validity dates can be maintained.

Qualification requirements can be manually added in the service order, service order quotations, or service order templates under the assignment block Qualification Requirements at both header and service item levels.

Along with the qualification requirement, a mandatory flag and proficiency level can be maintained.

Qualification search is possible under the Qualification ID field to select the qualification from the qualification catalog.

Qualification requirements can be automatically determined in a service transaction by specifying the determination parameters under Define Parameters for Qualification Requirements in Transaction. Determination is supported from Sold to Party, Ship to Party, Equipment Reference Product, Equipment, Functional Location, and Reference Object Product.

Additionally, qualification requirements can also be automatically determined at service item level by specifying the determination parameters under Define Parameters for Qualification Requirements for Item Category. Here, determination is additionally also supported from the Service product.

Optionally, a BADI can also be implemented by customers to define a custom logic for identifying qualification requirements at header service items under BADI: Qualification Determination in Transactions. The parameter USE_BADI must be selected for this under parameters for qualification requirements in transaction or item category.

Qualification requirements can be automatically determined from Sold-To and Ship-To Party in the service transaction (service orders, service order quotations, or service templates) at header or service item level.

In case the same qualification is determined from multiple sources, the qualification value is kept with the highest demand (considering proficiency level and mandatory flag).

Qualification requirements can also be automatically determined from Functional Location and Reference Object Product ID at service transaction header or service item level.

In case the same qualification is determined from multiple sources, the qualification value is kept with the highest demand (considering proficiency level and mandatory flag).

Qualification requirements can also be automatically determined from Equipment as well as the Reference Product of the Equipment.

In case the same qualification is determined from multiple sources, the qualification value is kept with the highest demand (considering proficiency level and mandatory flag).

Qualification requirements can also be automatically determined at the service item level from the Service Product.

In case the same qualification is determined from multiple sources, the qualification value is kept with the highest demand (considering proficiency level and mandatory flag).

If a service transaction is created as a follow up from another service transaction, the qualification requirements are copied from the source transaction header and service items, for example, from service quote to another service quote, or from service quote to service order, or from service order template to service orders.

The customer can influence this copy behavior with the BAdI CRM_COPY_BADI that now has qualification-specific methods.

You should now be able to understand:

• How to activate qualification requirements for service transactions – service orders, service order quotations, and service order templates
• Qualification catalog and master data assignment
• Manual assignment of qualification requirements at transaction header or items
• Automatic determination of qualification requirements at transaction header or items
• Copy of qualification requirements from source to target transaction

Service order sales item with CO assignment service (item-based accounting)

• Overview
• Planned cost and revenue
• Follow-up sales process
• TECO status and event-based revenue recognition

In SAP S/4HANA Cloud Private Edition release 2023 with item-based accounting, only the CO assignment Sales (Selling of a sales product with a service) was supported. This means that the follow-up sales order creates its own account assignment object, so the sales item is considered as a ‘placeholder’ for a sales order.

Now, the CO assignment service is supported as well. Here, the account assignment object is created in the service order sales item and handed over to the sales order and all follow-up documents. From a financial controlling perspective, the sales order is then part of the service accounting and is then part of the service order margin analysis.

This feature can be useful if you want to report the sales item as part of the service, for example, to distinguish between new business and replacement parts business.

The feature is only available for item-based accounting.

When the service order sales item is created and error-free, the ongoing data of planned cost and revenue is displayed.

After the item is released, the baseline data is calculated as well.

​When the service order sales item is released, the sales order is created.

On the Account Assignment tab in the sales order item, the transferred account assignment object for the item is displayed. ​Select More → Goto → Item → Account Assignment.

​After the outbound delivery is created from the sales order, the account assignment object is displayed in the Financial Processing tab. ​Select Menu → Goto → Item → Financial Processing.

When the goods issue is posted, the account assignment object is displayed in the Account Assignment tab of the item when the More button is selected.

The cost of the goods issue is also displayed in the accounting and controlling document.

When the invoice is created out of the sales order or outbound delivery, the account assignment object is displayed on the accounting document.

​In case a customer return is created, the account assignment object is displayed in the Account Assignment tab of the item.

One advantage is that when the sales item uses item-based accounting, event-based revenue recognition is supported. ​Both sales order scenarios Sales Order related and Delivery related Billing are supported. ​The report CRMS4_SET_FIN_TECO analyzes if the account assignment object of the object can be set to the TECO status. ​

If the status TECO is set, the event-based revenue recognition accounts are cleared and the original cost and revenue become effective.

​The financial postings of the service order with the sales item are now easily displayed in the Service Actuals app that is used for item-based accounting. ​ ​ ​ ​

You should now be able to understand:

Service order sales item with CO assignment service (item-based accounting)

• Overview
• Planned cost and revenue
• Follow-up sales process
• TECO status and event-based revenue recognition

SOAP APIs for Service Order and for Service Confirmation are enhanced to support the payment card integration with SAP Digital Payments Add-On.

​SOAP APIs for Service Order and for Service Confirmation are enhanced to support Work Breakdown Structure (WBS) elements as controlling objects or as attributes of an internal order (IO) when item-based accounting is not active.

After completing this learning module, you will be able to understand:

• Which new fields were enabled in SOAP APIs for Service Order and for Service Confirmation to support the payment card integration with SAP Digital Payments Add-On
• Enablement of Work Breakdown Structure (WBS) elements in SOAP APIs for Service Order and for Service Confirmation, when item-based accounting is not active

The inbound services of SOAP APIs for Service Order and for Service Confirmation have a new node on the header level called PaymentPlanItem. Under this, the new field EPaytByDigitalPaymentSrvc is added.

This new field reflects the token that is provided by the SAP S/4HANA Financials Cloud for Digital Payments Service as a substitute for the real payment card number.

For more information, refer to Integration with SAP Digital Payments Add-On.

Also, the outbound services of SOAP APIs for Service Order and for Service Confirmation have a new node on header level called PaymentPlanItem. Under this, the new field EPaytByDigitalPaymentSrvc is added.

Furthermore, details of payment cards are delivered in the new fields PaymentCardType, PaymentCardMaskedNumber, PaymentCardHolderName, and PaymentCardValidityEndDate.

The details of the authorized item amount can be identified and checked in the new fields AuthorizedAmountInAuthznCrcy with CurrencyCode, AuthorizationByDigitalPaytSrvc, and PaymentCardAuthznRelationID.

The existing field WBSElementExternalID that is already available in inbound and outbound services of SOAP APIs for Service Order and for Service Confirmation can now be used as controlling object or as attribute of an internal order (IO), when item-based accounting is not active.

You should now be able to:

• Describe which new fields were enabled in SOAP APIs for Service Order and for Service Confirmation to support the payment card integration with SAP Digital Payments Add-On
• Explain the enablement of Work Breakdown Structure (WBS) elements in SOAP APIs for Service Order and for Service Confirmation, when item-based accounting is not active

After completing this learning module, you will be able to understand:

The transition to item-based accounting for productive customers

• Use Case
• Solution
• Features
• Setup
• Restrictions

With SAP S/4HANA Cloud Private Edition release 2023, the integration of Service with item-based accounting was introduced for customers who start with a new system (a greenfield project). However, some customers have been using Service productively already with the old financial integration (account assignment manager with internal order, WBS element, or profitability analysis) and they cannot just switch on the new financial integration (Item-based accounting) because of the following reasons:

1. Existing documents could technically not be completed.
2. Service transaction with new financial integration would be created, but in the old financial integration, all cost and revenue from follow-up service orders are posted to an internal order or WBS element of the assigned service contract; with the service order using item-based accounting, this would break the financial reporting of the service contract using internal order or WBS element.
3. The old existing transaction would use the new financial logic which would lead to severe inconsistencies.

As item-based accounting is the future financial solution, Service supports the following features:

• Planned Cost and Revenue displayed in the service transactions
• Event-based Revenue Recognition and TECO status
• No additional financial transaction (Internal Order) needed
• Financial Hierarchy on the Service Contract
• Service Hierarchy (Collective Accounting)
• Business Completion
• Intercompany Order
• Unplanned Items

Already productive customers need a way to transition from the old financial integration to the new one.

When productive customers activate item-based accounting, their systems already contain service contracts using the old financial integration. Unlike service orders, service contracts normally have a very long lifecycle and can be active for several years. The system also contains rather short-lived unfinished standalone or follow-up service orders, They might have their follow-up transactions in different phases of the process as well. Last but not least there could be a standalone service confirmation using the old financial integration with the account assignment manager.

In the old financial integration, the service orders used the internal order of the assigned service contracts to post cost and revenue so the service contract has a complete view on profitability.

In summary, new service contracts and service orders must work together with old transactions for the scenarios described as follows:

• An existing service contract using the financial integration with the account assignment manager must be assigned to a new service order using item-based accounting
• An item from a new service contract using new FIN might need to be assigned to an existing service order with old FIN

Both use cases are supported starting with SAP S/4HANA Cloud Private Edition release 2023, feature package 3. The first with an automatic settlement rule, the second only with manual settlement.

Now, SAP provides enhancements that support a transition phase from the old financial integration (account assignment manager) to the new financial integration (item-based accounting).

1. Support to assign service contracts using the old financial integration to service orders items using the new financial integration and vice versa.
2. Ensure that existing service order transactions that already use a financial integration (account assignment manager or item-based accounting) stay with it and their follow-up transactions use the same financial integration as well.
3. Provide an automatic settlement rule to settle service orders using new financial integration to service contracts using old financial integration, which supports a complete financial reporting with profitability analysis (CO-PA) on the service contract.
4. Enable the use for specific features (for example, unplanned items, fixed price service with an intercompany order, service hierarchy) that normally require item-based accounting to work with a productive, old financial service contract.

1. Assign the new service orders to old service contracts.
2. Settle to the existing service contract automatically.
   Note

   In case Event-Based Revenue Recognition is set up for this item category, the determination is skipped as no revenue should be recognized because the revenue is settled anyway to the service contract.
3. To support cost-based CO-PA for the existing service contract in case of I/O or WBS element, the service contract must be settled to profitability segment. This settlement is already in place if cost-based CO-PA is used.

To have a service order related cost and revenue financial reporting and also still support margin analysis in CO-PA for the service contracts using the old financial accounting, cost and revenue of the service orders items using item-based accounting assigned to these contracts must be settled to the Service contract.

This can be done manually but for simpleness and automation, a settlement rule is provided by SAP.

It detects this special case and then settles the actual cost and revenue to the service contract’s accounting object (for example, internal order, WBS element, or profitability segment) automatically.

For this to work, the following must be set up in the Settlement section, newly added in the Service IMG.

1. Define a settlement profile.
2. Create a strategy sequence for automatic generation of the settlement rule.
   1. Maintain the settlement profile in the strategy.
   2. Assign the strategies in the correct priority, include CB1 for this special case.
3. Assign the strategy sequence to the service order.
4. Define a substitution rule for the service orders that assigns the settlement profile upon creation of the item-based accounting object.

When the account assignment object of the service order item is created, the settlement profile is assigned automatically with the correct attributes to settle to the old financial account object of the service contract.

The settlement can then be executed manually by the settlement run Run Settlement – Actuals app or automatically with the usual settlement runs during the usual period end run with the S/4HANA Financial Closing Cockpit app.

The figure shows a manually started run of the automatic settlement rule as an example.

To support cost-based CO-PA for the service contract using financial integration, the service contract’s WBS element or internal order must be settled to the profitability segment.

This is already an existing functionality but to give the complete picture, it is mentioned here as well.

The transition to item-based accounting for productive customers

• Use Case
• Solution
• Features
• Setup
• Restrictions