Explaining the Process Steps and Business Roles for Solution Orders

The figure shows an example of a solution order with multiple items that, once saved, each generate their own required follow-up document, such as a service order or a service contract. The solution order itself could be created based on a quotation issued to the customer including all these items (for example, selling a laptop to a customer, the installation service for the laptop, and a one-year support contract for the laptop). It could even include additional subscriptions the customer requires (in an integration scenario with the component SAP Subscription Billing) or project-based service items.

Depending on the specific follow-up documents created, further documents are created during the process. For example, selling a laptop requires an outbound delivery document to be created to trigger picking and packing. After issuing the laptop to the customer, an invoice (a billing document) can be sent to the customer for the laptop. On this same invoice, an item could be included for the support contract. For the support contract, a billing document request (BDR) is created which leads to an item being added to the billing document for the customer.

When a service order is created automatically out of a solution order, the system also updates the solution order number as part of the service order. So from within the service order, it is possible to see to what solution order that specific service order belongs. Navigation from the service order to the solution order is also provided.

The figure above shows a complete process flow for a customer engagement using a solution order. We look at this process in more detail by zooming in to some parts of the flow and describing the individual steps required.

The figure above shows the tasks that must be executed by the Solution Order Specialist, a user responsible for creating and maintaining solution orders in SAP S/4HANA Cloud Public Edition (business role: SAP_BR_SOLN_ORDER_SPCLST).

The Solution Order Specialist creates a new solution order. The SAP Fiori app Manage Solution Orders can be used for this. An alternative is to create a solution order using an OData Application Programming Interface (API).

All sales, service, expense, and service contract items sold to the customer (the whole solution) are now included in the solution order.

It is also possible to add external service items, non-stock service part items and (both as used in service orders) and service contract items with price adaptation to a solution order.

Besides service items, service contract items, and sales items (as shown in the figures), it is also possible to add subscription items and/or project-based service items to a solution order. Project-based service items have been integrated into the test script for Solution Order (4GT).

As an example, let's consider adding a sales item to a solution order:

• Prior to releasing the sales item, the solution order provides a check sales items action to retrieve availability data for the sold products and additional pricing-relevant attributes. The check sales items option triggers a sales order simulation without storing the sales order in the database.
• When releasing the sales item in the solution order, the sales order is created. The solution order item is then updated with the sales order id/item number.
• Standard stock items can be included in a solution order. Non-stock sales items (In the solution order, item category SOS5 is used) and configurable sales items (In the solution order, item category SOS6 is used) are also supported.
• A sales item representing a service can also be added to the solution order. This represents a service that is being sold to a customer using a sales order. In the sales order, this item uses item category TAD. In the solution order, item category SOS4 is used.
• Order type and item type/category determination for the sales order happens in the solution order.

It is also possible to maintain relationships between items in a solution order. There are two types of relationships that can be used:

• depends on
• has dependency

An example of such a relationship would be selling hardware to a customer, combined with the installation service of this hardware. Relationships are also visualized in a solution order as part of the solution order progress.

In the figure above, you can see that, in addition to Solution Order Specialist, other roles are also involved in the process concerning solution orders:

• The Customer Service Manager is responsible for the service orders and service contract.
• The Internal Sales Rep is responsible for dealing with the sales orders.
• The Billing Clerk is responsible for creating the billing document for the end customer.

A solution order can contain a service contract item. This service contract (to which the item refers), can be a service contract containing a recurring service (see solution process Recurring Services (4X5) for more details concerning these recurring services).

The invoiced amount of the service orders for this recurring service is zero, because the billing plan of the service contract already includes the prices for the recurring service.

In the process flow in the figure called Other Roles (see before), all items from the solution order can be invoiced to the end customer using one invoice.

Solution orders are not relevant for billing. However, you can set a billing block in a solution order, blocking the billing of follow-up transactions, such as service contracts and sales orders. Follow-up transactions of solution orders, such as sales orders, follow their own individual billing process.

By default, the Solution Order ID is not a split criterion for a billing document. This could lead to billing documents containing billable items originating from multiple solution orders. Depending on your use case, this may be an undesirable outcome. You may prefer one billing document per solution order rather than mixing items from different solution orders in one billing document.

Assuming that no other split criteria apply (this means that the split-relevant fields of the billed SD documents and service transactions referencing the solution order are identical), you can achieve one invoice per solution order by splitting invoices according to the referenced solution order ID of each billed item. SAP Note 2927115 explains how to do this.

SAP Knowledge Base Article 2927115 explains the context required for achieving this one invoice per solution order. Using the extensibility framework, a custom field is created at the billing document header level and is filled with the solution order ID. The solution order ID is then used as a split criterion by SAP S/4HANA Cloud Public Edition when creating billing documents. Refer to SAP Knowledge Base Article 2927115 for more details and an example.

If you want to create an interface to SAP S/4HANA Cloud Public Edition concerning the integration of solution orders, you need to create a communication arrangement. This arrangement contains all relevant information for the interface, the communication system and the relevant inbound and outbound authentication. When creating your communication arrangement for integration of solution orders, you can use communication scenario SAP_COM_0706 (Business Solution Order Integration). If necessary, refer to the SAP Help Portal for more information.

Solution order items have different statuses throughout their life cycle. The same statuses apply to, and can also be found in, the solution order at the header level. A user cannot change the header status because the system automatically updates it according to the item statuses.

Only some fields are editable for released and completed items: for example, a delivery blocking reason for a sales item or a billing blocking reason for a service contract item. New changes are forwarded to the follow-up transactions, although this is dependent on the availability of features in the follow-up transactions.

A predefined pricing procedure (for instance A17024 for the United States) is available for solution orders. You could use it as a reference to define your own pricing procedure.

Multiple condition types are available in this predefined pricing procedure. You can use these condition types in the price details to set up:

• One-time pricing
• Recurring pricing

During the processing of a solution order, price details determined by the pricing procedure are automatically copied from the solution order to the follow-up service transactions and/or sales documents.

The actual pricing conditions in a solution order are copied to the follow-up documents, for example, to a sales order. In addition to those pricing conditions, the solution order pricing procedure itself is passed on and used throughout the whole document chain.

This means that the solution order pricing procedure is used in the sales order, the service order, the service contract, the billing document requests, and the billing documents themselves. In this way, consistent pricing and account determination is achieved.

The table above provides an overview of all the standard business roles that are used in scope item Solution Order (4GT).

These roles can be used as a template to create your own business roles for your business users working with scope item Solution Order (4GT).

The SAP Fiori app, Manage Solution Orders, used to manage and create solution orders (available under the Solution Order Management header) is available if a user has been assigned role SAP_BR_SOLN_ORDER_SPCLST.

The other roles listed in the figure, Standard Business Roles, are required if a user wants to test the complete process flow that is available with scope item Solution Order (4GT). The role that is exactly needed depends on the type of items added to a specific solution order. For example:

• Managing service orders and service contracts requires role SAP_BR_CUSTOMER_SRVC_MGR to be assigned to a user testing scope item 4GT (based on the test script that is available for the scope item).
• Creating and displaying billing documents requires role SAP_BR_BILLING_CLERK to be assigned to the user.
• The roles, SAP_BR_PROJ_BILLG_SPCLST and SAP_BR_PROJ_MANAGE_COMM are required when integrating project-based service items into a solution order.