Using a Device as a Service

Service Providers take a typical hardware device (such as a laptop, desktop, tablet, printer, or mobile phone), bundle it with a variety of services and software, and offer it to a customer for a monthly subscription fee. It gives customers one contract and just one provider to hold accountable.

Examples of these are as follows:

• A company that offers laptop devices, IT support, and software (including third-party software) bundled into a subscription on a fixed recurring price per device.
• A company that sells exercise equipment outright, but offers related training classes on a subscription basis.

The flow of information is as follows:

1. A subscription order is created with a subscription bundle, which contains a sales-relevant item. When the order is submitted, a subscription contract is created with all subscription items. In addition, a sales order is created with the sales-relevant item.
2. A delivery is created as a follow-up of the sales order. The delivery has the picking quantity and a serial number assigned to it. The serial number is for a piece of equipment.
3. When the delivery is saved, the equipment is assigned to the object list of the subscription contract main item. The equipment number is also copied to a technical resource of type equipment.
4. When the delivery is posted goods issue, the status of the equipment is changed to At Customer.
5. The new status of the equipment triggers the ODI steps of the subscription contract to distribute and activate the contract. The billing start date is set to the date when the equipment is at the customer site.

When serial numbers are assigned in a delivery and the document is saved, the CREATED/CHANGED event for the LIKP object is raised.

If equipment is created and activated when serial numbers for a product are created, then during delivery, it's possible to identify the relevant equipment IDs.

By tracking back from the delivery, it should be possible to identify the relevant sales item in the subscription order or solution quotation.

If the products are structured in such a way that the sales item is a sub-item of a subscription item or the opposite, then that subscription item is the one on which maintenance of equipment is required.

By registering an event receiver, and leveraging the still open for change subscription order or the new Maintain Equipment IDs change process, equipment IDs can be maintained on the relevant subscription contract.

When equipment status is changed, the CHANGED event for the EQUI object is raised.

If this equipment, which is changed, is maintained in the object list of a subscription contract, then potentially depending on the status, different processes can be triggered on the subscription contract.

In this example, the At Customer status is being checked for, and if it's set, an attempt is made to trigger the ODI step of the relevant subscription contract to start the distribution and activation process.

To support models where the subscription is for the hardware or the subscriptions are dependent on the hardware, the feature of integration between the equipment master and the subscription contract is provided. The ability to bundle different kinds of products (hardware, service, and subscription) already existed and hardware products resulted in the creation of SD Sales Orders from which downstream processes such as Delivery, Goods Issue, and so on, could be performed. This has been taken further now, where if the hardware resulted in the creation of an Equipment item, then such an Equipment item can be linked back to the related Subscription Contract.

With this integration, dependent processes such as the following can be realized:

• Activation of a subscription and start of billing only after the hardware is delivered to the customer and installed
• Cancellation of a subscription if the related hardware is deactivated

Equipment IDs for a subscription item in a subscription order or a solution quotation can be maintained under the Object List. Additionally, you can search for equipment based on the Equipment ID, Serial Number, Reference Product ID, and so on. The maintained Equipment IDs are copied to the Subscription Contract. If the equipment IDs are unknown during the creation of the subscription order or the solution quotation, the subscription contract is created without the equipment IDs, while the contract remains inactive. Equipment IDs that are determined after downstream processes, such as delivery of the hardware, must be maintained on the related Subscription Contract. The Maintain Equipment IDs change process is available to support the maintenance of equipment IDs later in the process.

The ID associated with the hardware (serial number or equipment ID) may be relevant in the calculation of usage-based charges in CC. To facilitate this, equipment IDs maintained in the object list are copied to technical resources and distributed to the CC contract. The prerequisite for such a copy is that the Technical Resource Type should be defined with the category Equipment. The standard implementation copies equipment IDs, as they are, to technical resources.

In scenarios where the serial number is set up to be different from equipment IDs and the serial number is to be used as a technical resource, or if the technical resource is to be derived based on the equipment ID, then this can be done by implementing the CRMS4_SOM_BADI_EQUI_INTEG BADI. In scenarios where the equipment IDs are not available at the time of subscription order or solution quotation creation, then the technical resource should be set up in such a way that the time of allocation check should be set to BA-Before Activation to suppress the check during order capture.

The previous figure shows early distribution when equipment activation is delayed.

Typically, early distribution of subscription contract is applicable only when the start date is in the future. With equipment, there's a scenario where the contract start date may be immediate, but the actual activation and distribution should happen only when the related equipment is activated, which can be in the future. With Revenue Accounting and Reporting in the picture, an early view into such a contract may be required even though it's not yet active. To support this, a feature is provided that allows for execution of early distribution even when the start date is immediate, but the actual distribution is to be deferred. This can be configured at the item category level.

An example implementation of how equipment IDs can be automatically maintained on a subscription contract based on serial number assignment in the corresponding delivery is provided. If the equipment master is created and activated when serial numbers for a product are created, then during the delivery, it's possible to identify the relevant equipment IDs. By tracking back from the delivery, it should be possible to identify the relevant sales item in the subscription order or solution quotation.

If the products are structured in such a way that the sales item is a subitem of a subscription item or the opposite, then that subscription item is the one on which maintenance of equipment IDs is required. By leveraging the "still open for change" subscription order or the Maintain Equipment IDs change process, equipment IDs can be maintained on the relevant subscription contract. This system-based auto update is achieved using event type linkages (see transaction SWE2). When serial numbers are assigned in a delivery and the document is saved, the CREATED/CHANGED event for the LIKP object is raised. A SOM_EQUI_DELV event receiver is registered against this event, which facilitates the maintenance of the equipment IDs on the subscription contract.

This is strictly an example only, as each customer may implement these processes in the manner they see fit. Some examples of these are as follows:

• Customer A has implemented the creation of equipment master data when serial numbers are created for a product. In this case, at the time of delivery creation, based on the serial numbers, it's possible to identify the relevant equipment IDs so as to trigger the maintenance of the same on the inactive subscription contract. The example implementation mentioned previously caters for this task.
• Customer B has implemented the creation of equipment master data only when the delivery of the hardware to the end user is complete. In this case, at the time of delivery creation, it's not possible to identify the relevant equipment. A custom implementation can be built to support this task.

Distribution and activation of subscription contract: The subscription contract is not distributed and activated until the equipment IDs are maintained and the relevant status (for example, At Customer, Ready for Use, and so on) is set on the equipment. This is achieved using the ODI framework. A standard example EQUI schema is provided that includes the following steps:

• EQUM (Equipment data maintained?): The status of this step is set to executed only if the equipment IDs are maintained on the subscription contract.
• EQUA (Are all Equipment active?): The status of this step is set to executed only if the linked equipment has a certain status. Standard implementation checks for ECUS(At Customer).
• PCEA (Call FICA Message contract activation): The standard distribution step that triggers the creation of the FICA and CC contracts, which is executed only when the two previous steps are successful.

Trigger subscription contract activation on equipment activation: Similar to the previous scenario, an example implementation of how subscription contract distribution and activation can be triggered based on a status on the equipment is provided. When the status of equipment changes, the CHANGED event for the EQUI object is raised. If the ID of the equipment that is changed is maintained on a subscription contract, then potentially, depending on the status, different processes can be triggered.

In this example shown, when the status of equipment is set to ECUS(At Customer), the distribution and activation process of the subscription contract is triggered. An SOM_EQUI_ACTV event receiver is registered against this event, which facilitates the trigger.

Billing Start Date based on equipment activation: Typically with a subscription contract, the date from which the recurring charges are applicable is the same as the contract start date. When equipment is involved, scenarios are used, where the recurring charges are applicable only when the relevant equipment is activated. Additionally, it can also be "once the equipment is activated" or "X number of days after contract start", whichever is earlier. To support such scenarios, a CONTBILS (Start of Billing) date type is provided. As standard, this date type is set to the date on which the step EQUA is executed successfully, but this can be changed by implementing the CRMS4_SOM_BADI_EQUI_INTEG BADI.

Prerequisite: Item category is marked as relevant for the equipment link.