In S/4HANA Cloud for Service, there is currently no integration between service orders and the core logistical process that one might know from the Sales Line-of-Business such as outbound deliveries, picking or packing. You can simply reserve stock parts in a particular storage location, and directly consume the parts from this storage location – there is no standard process to create deliveries, pick the parts or post goods movements between the main storage location and the technician van stock. In this blog, I would like to detail a workaround as to how such an integration of service orders with the logistical processes can be achieved.

This is not an official process in the LoB Service, rather this approach is simply a consultant’s solution of using the system’s different capabilities to put together a solution that fits the customer’s need.

Let’s look at the high-level overview of the fundamental requirement as well as the process in the system to achieve this:

Requirement: to visualize the customer’s requirement in the form of a user-story, it would look something like this:

As a (field service) customer service manager, I need to be able to:

1. Reserve and deliver service spare parts to the customer’s location so that my service technicians can perform the required services
2. Track real time, if any reserved spare parts are still in the company’s storage location or have already been picked up by a service technician
3. Generate delivery papers from the system to deliver the spare parts via a freight carrier or to handover to the service technician (in case of pick-from-stock)
4. Generate a pro-forma invoice in case of deliveries to an international country such as Switzerland.

These requirements from the service business of a customer can be fulfilled using the approach shown in this blog. Let’s look at the assumptions and the process in the system for this to be achieved.

Assumptions:

• The service providing company has the following org. units:
  • Company code 1010
  • Plant 1010 with a central warehouse managed storage location 105W and a technician van storage location 101S (inventory managed):
  • 2 MRP Areas: Plant MRP area 1010 and a storage location MRP area ‘SRV_VAN’, which is a separate MRP area for the technician van. The planning type of this MRP area will be ‘ND’, so as to not trigger any MRP runs for demands created directly against the technician van storage location.
  • Sales Area: Sales Org 1010, Dist. Channel 10, Division 00
  • Example Product used: SRV_05
  • Assignment of all service technicians to storage location 101S (SSCUI 102883)
  • Configuration activity “Activate Stock Transfer Between Storage Locations” (SSCUI 103197) is activated.

The overall approach to facilitate the integration of the logistics processes for service orders can be summarized as follows. The reservations of stock parts will be created against the technician van stock 101S. These will however be “empty” demands, as the reservations are separated off by the MRP area ‘SRV_VAN’, which will prevent MRP runs and creations of purchase requisitions. The reason for this is the usage of the stock transport orders (STO) in the next step, which will serve as the primary document responsible for ATP checks, stock spare part reservations, and the transfer of stock from the warehouse to the van storage location. With this being the overarching thought process, let’s look at the entire process flow in the system:

1. Service Order: Create and release a service order with the item SRV_05 and quantity of 1 piece. A reservation will be created against 101S, which will do nothing, as explained above.
2. Stock transport order: In the next step, create a purchase order (App “Create Purchase Order – Advanced”) of document type ‘UD’. Maintain the following header values:
   1. 
   2. In the item overview, copy all inventory managed items from the service order in step 1. *Service items or expense items do not need to be copied over into the STO.
   3. On the item overview, enter the material, quantity, plant and receiving storage location:
   4. 
   5. On the item overview line, make sure to scroll to the right and also maintain the value for the issuing storage location (105W)
   6. 
   7. Once this is done, in the item detail section below, you will see the confirmed schedule line for the material. *If required, you can additionally adjust the delivery address for the item to reflect the end customer’s ship-to address, as this is what will be printed on the delivery note afterwards:
   8. 
   9. Save the STO and make note of the ID.
   10. 
3. SD Outbound Delivery: Now that the STO is saved, the next process step is to create an outbound delivery so that the goods can be picked and issued out of the warehouse 105W and into the van storage location 101S.
   1. Use the app “Schedule Delivery Creation” to create the OD for the STO in step 2.
   2. In productive usage, you can optionally setup a job that will regularly run through pending STOs and create the OD documents. For testing purposes however, you can use the following scheduling options and parameters:
   3. 
   4. 
   5. Once the job finishes, you will see the following log:
   6. 
   7. Make note of the delivery number.
4. Next, in the app “Change Outbound Delivery”, enter the delivery number from above. This is a crucial step, as one of two things could now happen. If the sending storage location were to have been an IM managed storage location (without warehouse capabilities), you could directly go into the OD, complete picking, packing and post goods issue. In our case however, since the sending storage location is a warehouse, the OD created is read-only, as the OD has been distributed to the Warehouse, where certain warehouse tasks now have to be executed:
   1. 
5. Warehouse Tasks: The next step is to execute the pending warehouse tasks after the OD has now been distributed to the Warehouse. Use the app “Run outbound process – Deliveries” for this step. Set the appropriate filters for the Warehouse No. and delivery date. You should see your OD from Step 4
   1. 
   2. Navigate into the item. In the Items tab, click on Missing Tasks, select the item and click on “Create Tasks”. * In case the storage bin is not maintained in the product master data, you will have to click “Create Tasks Manually” and enter the correct storage bin
   3. 
   4. Next, switch to Open Tasks, and click “Confirm Tasks”
   5. 
   6. Finally, switch to Picked and post the “Goods Issue”. *If needed, packing can be done before the goods issue.
   7. 
   8. Once this step is completed, the quantity of 1PC for SRV_05 will have been booked out of 105W
6. Post Goods Receipt: in this step, you will now have to post the GR of the stock which is in transit into the receiving storage location 101S. Use the app “Post Goods Receipt for Purchasing Document” for this and enter the STO ID from step 2 as the reference. *This is generally an optional step, as you can activate the so-called 1-step procedure (SSCUI 103426) with which you don’t necessarily need to post the goods receipt into 101S. This will then be done automatically after the Goods Issue in step 5.
7. Print delivery papers: now that the goods issue is posted, the SD OD delivery from step 4 will have reached the Goods Movement Status “completed”. This means that you can now print out the delivery note required to handover to the freight carrier/service technician.
   1. Go back to the SD OD and navigate to Output Control
   2. 
   3. There, you can print out the delivery note output item.
   4. 
8. Create Service Confirmation: Now, from the process flow point of view, the required stock parts have been delivered and the technician has completed his work at the customer’s site. The final step is now to create the service confirmation with the actual consumed quantities. After completing the service confirmation, the goods issue for the consumed parts will be posted out of 101S (due to the storage location assignments in customizing)
   1. 

That concludes the end-to-end process flow in the system of how to achieve an integration between field service and the logistical processes in S/4HANA Cloud. Feel free to like/comment if this helped you out.

*Credit for the overall approach goes to Julius Englert for conceptualizing this idea*