API Enhancements for Service Orders: Introduction
Release 2025 FPS contains various enhancements for both the SOAP API and the ODATA V4 API for service orders.
Enhancements for the SOAP API:
- Enable SOAP updates of service orders without an external service order reference number
- Intercompany reference item number
- Posting date, open status (header/item), error status, reference service quotation, and reference service quotation item
- CNS order reference
Enhancements for the ODATA V4 API:
- Warranty information
- Qualifications at the item level
- CNS order reference
- Intercompany reference item number
Enhancements for the SOAP API for Service Orders
Enable SOAP updates of service orders without an external service order reference number:
In previous releases, only service orders created via the SOAP API for service orders could be updated via this (same) API. The reason for this was that an external service order reference number was used during the creation of a service order (via the SOAP API), and only this reference number allowed updates to this (externally created) service order. This restriction has been removed with release 2025 FPS1. Since this release, it is possible to update service orders that were created via an OData service or the WebClient UI. Additionally, the reference number is no longer needed in the HTTPS request when creating a service order. This enables customers to easily create service orders, and freely use the SOAP API to change service orders, regardless of the service order’s creation history.
An inbound HTTPS request without the reference number creates a new item.
If no reference number is provided in the inbound HTTPS request, the service order GUID is set as the reference number. In the bottom part of the figure, you can see information about the newly created item in the outbound request.
The following features are supported for SOAP APIs for service orders (since release 2025 FPS1):
PostingDate:
Defines the date on which the service order is received.
ServiceOrderIsNew:
Indicates that the status of the service order item is new (lifecycle status: Open).
ServiceOrderItemIsNew:
Indicates that the status of the service order item is new (lifecycle status: Open).
ServiceOrderHasError:
A flag indicating whether there are any errors at the header level.
ServiceOrderItemHasError:
A flag indicating whether there are any errors at the item level.
ReferenceServiceQtan:
ID of the service quotation for which the service order was created as a follow-up.
ReferenceServiceQtanItem:
Contains a reference to the related service quotation item.
SrvcDocInterCoReferenceItem:
Displays the service order intercompany reference item number.
SrvcCloudVersion2ServiceOrder:
Displays the SAP Service Cloud Version 2 Service Order ID.
SrvcCloudVers2ServiceOrderItem:
Displays the SAP Service Cloud Version 2 Service Order item number.
Status Open, Error, and Posting Date:
Open is the initial life-cycle status, indicating that a transaction or item has been newly created.
The status Error indicates that there is an issue: this means at item level that the item contains an error with an existing error message. This means at header level that at least one item has an error or the header itself contains an error message.
The posting date of a transaction defines the date on which the document was entered into the system. Normally, this is the creation date. You can however change the posting date to a date in the past, if you received the document earlier.
The Predecessor Service Quotation ID at header level and the Predecessor Service Quotation Item Number at item level (shown on the left in the figure) provide information about the service quotation transaction and its item, from which the service order and its item originate (after the service quotation was accepted).
The intercompany reference item number (shown on the right in the figure) is required during the intercompany process for an intercompany dual order when an additional item is added. Because there can be multiple intercompany items in a single intercompany dual order, this number identifies which intercompany item the added item belongs to. It also determines where accounts payable for the added item are going to be posted when the item is billed.
Since release 2025 FPS1, the CNS order reference is available in the transaction history of the service order, and is planned to be populated when the Service Cloud integration is used. The SOAP API for service orders allows reading of the CNS order reference at both header and item level. Currently, the create and change cases are supported only in the OData API, not in the SOAP API.
Enhancements for the ODATA V4 API for Service Orders
The OData V4 API for service orders supports the following fields since release 2025 FPS1:
Warranty information:
Service document warranty status:
Indicates the cumulative warranty status of all items in a service transaction.
Service document item is under warranty:
Indicates the warranty status of a service transaction item.
Master warranty ID:
The ID of the master warranty assigned to a reference object, such as a piece of equipment.
Warranty end date:
Indicates the end date of a warranty period for a service transaction item.
Qualifications at item level containing the fields:
Service order ID:
ID of the service order item
Service order item number:
This entity allows qualifications to be added at item level.
Service document qualification:
Object ID of the qualification requirement
Start time of the qualification requirement:
Indicates when the validity of the qualification requirement starts.
End time of the qualification requirement:
Indicates when the validity of the qualification requirement ends.
Qualification is mandatory:
Indicates whether the qualification requirement is mandatory or not.
Optimum qualification requirement proficiency level:
Optimum proficiency level for the qualification requirement
Weighting of the qualification requirement:
Indicates the weighting of the qualification requirement.
CNS order reference:
Service Cloud version 2 service order:
Displays the SAP Service Cloud Version 2 ID.
Service Cloud version 2 service order item number:
Displays the SAP Service Cloud Version 2 ID item number.
Intercompany reference item number:
Displays the service order intercompany reference item number.
The warranty information consists of four fields: one on header level and three on item level. The Under Warranty field can be set to false to indicate that the warranty is invalidated. This can be done, for example, if the customer intentionally damages the piece of equipment.
Qualifications can be added via this entity to an item to indicate what the service technician must be able to do to execute the job. For example: If a specific level of English proficiency is required for a job, the qualification Language can be created with options such as Beginner, Intermediate, or Advanced.
Note
Starting with SAP S/4HANA Cloud Private Edition 2025 FPS1, a reference to the CNS order (Service Cloud Version 2) can be assigned in the transaction history of the service order via the OData API.
The reference is filled automatically by the Service Cloud V2 application. Once a reference is assigned, the assignment cannot be changed anymore.
The reference at header level is the ID of the related CNS order based on which the service order was created. Only one specific CNS order reference can be assigned at header level to a service order. The reference at item level is the CNS order item ID based on which the service order item was created. The same CNS order reference can be used in multiple service orders, but in one particular service order only for one item in that order.
In the figure, you can see an example of an OData request that adds the CNS Order reference at both header and item level in a service order. You can also see the fields displayed at header and item level.
Additional items can be added to an intercompany order. If the intercompany order includes several distributed intercompany items, an intercompany reference item number must be maintained to indicate to which distributed intercompany item the additional item belongs. This ensures that costs from accounts payable are posted to the correct account assignment object of the intercompany order item in the customer-facing service order. Since release 2025 FPS1, the field can be read and set via the OData V4 API.
ODATA V4 API: Rejection Reasons
This ODATA V4 API provides information about rejection reasons used in service transactions, such as service orders, service quotations, and service contracts. It determines rejection reasons based on a combination of the service transaction type and the sales organization.
The available fields are:
Service document type:
The transaction type of the service transaction
Sales organization:
The sales organization of the service transaction
Rejection reason:
The customized rejection reason
Rejection reason name:
The name of the rejection reason
The relevant customization can be accessed via transaction SPRO and menu path: SAP Reference IMG→Service→Transactions→Settings for Service Transactions→Settings for Rejection Reasons for Service Transactions→Define Rejection Reasons/Assign Rejection Reasons to Rejection Profiles.
The logic builds on the Transaction Type Specific Rejection Reasons feature, which was delivered with SAP S/4HANA Cloud Private Edition 2025.
Note
The motivation behind this API is a (planned) Joule skill that will allow users to reject service transactions in a future release of SAP S/4HANA Cloud Private Edition.
You can find detailed information on this V4 API via:
- The SAP Help portal: https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e94543741b6142e198a86f908c698978/5fb2b4aa2fe1441fbd15685382ebe112.html?version=2025.001
- The Business Accelerator Hub: https://s4chbstagingi5rzc0vs3c-yxucacoeq3.int.sap.eu2.hana.ondemand.com/api/sap-s4-OP_SRVCDOCITEMREJECTIONREASON_0001-v1
Payment Cards in the ODATA V4 API for Service Orders
Digital payment cards (in short: payment cards) are supported in the ODATA V4 API for service order since release 2025 FPS1. You can create, read, and delete payment cards for a service order from an external system. The entity Service Order Payment Plan (technical name ServiceOrderPaymentPlan) is used for this.
In the figure, you can see an example for creating a service order with a payment card.
For more information, see: https://help.sap.com/viewer/p/DIGITALPAYMENTS.
