In the last 2 blog posts I have described SAP S/4HANA for manufacturing logistics in an overview and the newly created master data in more details. In this blog post I will describe in more details how some of these new master data are used in the production supply process using route trains.
A route train is a vehicle which can move racks and stock through the EWM-managed warehouse to production supply areas (PSA). By its nature, it is a repetitive process (as it circles around the production and comes back to the warehouse where new racks are loaded on the route train) and a time-critical process as the products shall reach the PSA before they are needed but not too early, so that the available limited spaces is well utilized.
SAP S/4HANA for Manufacturing Logistics is running on a completely configured EWM system and uses and enhances the Distribution equipment from EWM standard. This means that you must configure the distribution equipment process before you can start using SAP S/4HANA for Manufacturing Logistics. You can find more information on how to set up the distribution equipment process in the blog post from Jörg Michaelis and in note 2963920.
We assume that you have set up the distribution equipment scenario and the configuration guide for the route train process: you cannot run the route train process without a fully configured distribution equipment process.
Route train processes can be configured very simple, but they can also be configured in a very complex processes chain. The main component of the route train process is a tour.
The tour is the most important transactional data of SAP S/4 HANA for Manufacturing Logistics and it contains all information about the planning and execution of the delivery using route trains.
Tours are related to the master data of routes: a tour is created with reference to a route version and thus defines the PSAs which might be part of the delivery of racks.
Not all PSAs of a route need to be served by a tour: in case there is no demand to deliver for a specific PSA of the route version, then the PSA will also not be part of the corresponding tour.
Tours have information of planned or actual racks and handling units, the stops of the tour and they support the status management. Apart from this, they also contain the information of the planned loading start time and the planned departure date and time from the train station (which is modelled as a storage type).
A tour can be created in 4 different scenarios (depending on the tour creation strategy maintained on the route) :
In this blog post I will describe the line supply process for a very simple scenario, where route trains are driving on different routes to different PSAs in a bus-like manner: there is a time table (similar to a bus or a train schedule) created upfront and the system needs to determine which delivery item shall be processed with which tour (in real life: which bus shall I take?).
This brings us to the general requirements, which must be fulfilled so that a delivery item can be processed via route train process:
In a nutshell: the delivery item needs to know, when it needs to be where and how it shall get there.
SAP S/4HANA for Manufacturing Logistics evaluates based on the supply date and time and the determined route with the planned round trip time from the route master data, when the delivery must start: this identifies the planned departure date and time. We assume that all items on the tour have a supply date and time, which is later than the planned departure date and time of the tour, but we do not consider if a delivery item is to be unloaded at the beginning of the tour or at the end (which would require a later supply date and time).
In this example the warehouse request is created at 10:15 with a demand time of 15:00 at the same day. The timing function determines, once the route has been determined – based on planned loading duration and cycle time of the route - when the loading should start. The loading start defines also the end of the picking phase. The picking start time can then be used as a planned wave release date and time when you create the corresponding picking waves using the add-on specific wave creation.
You can configure a planned picking start time so that this time is added to the planned loading start time. This time can then be used to determine the corresponding wave options in case your process uses waves (and the complex processes do use waves, so we leave it out of this post for now).
In this example we configured that in general the picking time is one hour unless it is configured differently for the different storage types.
Before we start to plan the goods distribution, the tours are created upfront using report /ILO/TOUR_CREATION for a given route; we must ensure that appropriate condition records exist so that the route can be determined automatically when the e.g. WMR is created in EWM.
When the report is executed, then the master data of the route (here: R_DEMO) is evaluated and corresponding tours are provided to the user.
These tours can now be consumed by incoming warehouse requests
The demo process picks, loads and delivers 6 different JIT calls to 5 different PSAs on one route train tour.
While the picking process is near standard (with some special checks on route and tour) we will focus on the loading and unloading (=delivery) process.
We depart from storage type 5T01 and stop at the first PSA-100. The unloading takes place to the right in driving direction and is posted to the handover point 6P50-100-H. The next PSA-200 is served also via handover point (here 6P50-200) and unloading is done to the left. For PSA-300 and PSA-400 the unloading is also taking place to the left without using a handover point. The last PSA-500 is served via right unloading direction before the route train is back to the arrival storage type 5T02 where empty racks can be posted.
Now 4 JIT calls are created to PSA-100 to PSA-400, while there are 2 JIT calls to PSA-500 which are created a bit later. Therefore, the standard app Request Replenishment for Control Cycles (F4038) is used.
The system determines during the creation of the delivery item in EWM the route and the tour. This determination is part of a complex algorithm called "Logistical Revaluation" which tries to determine the corresponding planning data when a delivery item is changed.
Now the warehouse tasks for picking are created: 1 WO for the first 4 items and another one for the remaining 2 items.
These 2 WO are now processed in RF into racks via the route train specific logical transaction for Picking (PICIWO).
As a result, both racks are ready for loading: there is a separate WO for loading for each rack.
The loading warehouse orders are confirmed in RF with the add-on specific logical transaction CILH00 for route train loading.
As the tour has already been created upfront and HUs have been assigned to the tour, the system can propose the next HUs for loading.
The loader confirms the second HU as being loaded, then completes the loading step and confirms the tour to the start bin of the route.
After loading completion, the system creates in the background the unloading warehouse tasks for whole racks (if they are to be unloaded on one PSA) or for each single loaded HU in the rack in case the rack has to be unloaded on multiple PSAs.
In this scenario the system created one WO for unloading which contains one WT for unloading for the rack and 4 WTs for unloading for HUs in the second rack. This unloading WO is linked to the tour and cannot be processed with the standard RF transaction for WO confirmation but with the add-on specific unloading transaction.
The EWM warehouse monitor has been enhanced with an own node for tour management. In this node you can select tours by e.g. route, driver, status, JIT call etc.
As a result you get the well-known two layered structure with object identification and object details as drilldowns.
There are different drill-downs available:
and to unpacked warehouse request items.
Of course there is also a Fiori app Manage Tours (F4600) available which can be used for tour management and monitoring:
The unloading process can be triggered via add-on specific logical transaction CIULHU for unloading. The EWM warehouse monitor also contains an unloading function for HUs but in this scenario I will focus on the more common RF scenario.
The driver has to identify the tour in this manual scenario by scanning one of the top HUs of the tour (= racks)
Afterwards a towing vehicle needs to be assigned to the tour, if this is configured on route level. The usage of a towing vehicle is mandatory if you want to monitor the tour execution process as a driver with the My Tours app (F4553).
The My Tours app is a read-only app which shows the list of stops and the representation of the racks to the user. It shows which HU or which rack has to be unloaded at a given stopID. Therefore the user can click on stops and then the HUs for unloading are highlighted in dark blue, already unloaded HUs are highlighted in light blue. The driver can also click into the racks to get more information on the loaded HUs and their position.
The app is a read-only app: the user cannot execute the unloading process with this app; this is done using RF.
On the top right corner the user can see the unloading progress and the number of unloading warehouse tasks. In general: changes in the backend like e.g. confirm an unloading warehouse task triggers the update of the app automatically.
The driver confirms the unloading on the first PSA-100 via RF:
According to the confirmation method maintained on the route stop the HU and the unloading bin needs to be scanned. However as the PSA cannot be reached directly but unloading is done via handover point the system does not request the stop storage bin.
After confirmation at the handover point of PSA-100 the next PSA is proposed and the My Tours app is refreshed automatically.
The user confirms the unloading at every PSA for each HU. At PSA-400 the whole rack 620525 can be unloaded so the user does not have to confirm the unloading of the two HUs which are put into this rack during the picking process.
After confirmation of the last HU the driver continues the ride and brings the route train back to the arrival station and confirms the arrival at 5T02-06. The empty rack (this is the rack where the HUs have been unloaded to different PSAs) is also posted to the end point of the route
As a result 4 of the 6 WMRs are completed, while 2 of them are not yet transferred to the PSA: they have been moved to the handover points.
Conformation of these 2 warehouse orders also completes the corresponding WMRs.
The tour node shows now that the tour is in status completed and that the execution of this tour took 11,3 minutes.
All HUs are confirmed to the PSAs and there are no open warehouse tasks anymore for these WMRs.
It is important to know that the tour and the unloading warehouse order are combined in a way, that you cannot complete the WO in e.g. RF in the WO transactions as these transactions do not update the assigned tour: you must process this unloading warehouse order with the functions of the addon; otherwise you will create data inconsistencies (open tours with no open unloading warehouse order).
This post showed a simple, although quite lengthy tour scenario with tours which are created upfront. We have shown the tour creation, the picking process and the main route train processes loading and unloading. We also showed two Fiori apps for tour management.
In the next post I will go into more details on the more complicated scenarios for wave assignment and route and tour determination.
A route train is a vehicle which can move racks and stock through the EWM-managed warehouse to production supply areas (PSA). By its nature, it is a repetitive process (as it circles around the production and comes back to the warehouse where new racks are loaded on the route train) and a time-critical process as the products shall reach the PSA before they are needed but not too early, so that the available limited spaces is well utilized.
SAP S/4HANA for Manufacturing Logistics is running on a completely configured EWM system and uses and enhances the Distribution equipment from EWM standard. This means that you must configure the distribution equipment process before you can start using SAP S/4HANA for Manufacturing Logistics. You can find more information on how to set up the distribution equipment process in the blog post from Jörg Michaelis and in note 2963920.
We assume that you have set up the distribution equipment scenario and the configuration guide for the route train process: you cannot run the route train process without a fully configured distribution equipment process.
Route train processes can be configured very simple, but they can also be configured in a very complex processes chain. The main component of the route train process is a tour.
But what is a tour?
The tour is the most important transactional data of SAP S/4 HANA for Manufacturing Logistics and it contains all information about the planning and execution of the delivery using route trains.
Tours are related to the master data of routes: a tour is created with reference to a route version and thus defines the PSAs which might be part of the delivery of racks.
Not all PSAs of a route need to be served by a tour: in case there is no demand to deliver for a specific PSA of the route version, then the PSA will also not be part of the corresponding tour.
Tours have information of planned or actual racks and handling units, the stops of the tour and they support the status management. Apart from this, they also contain the information of the planned loading start time and the planned departure date and time from the train station (which is modelled as a storage type).
A tour can be created in 4 different scenarios (depending on the tour creation strategy maintained on the route) :
- 01: For scheduled tours by report /ILO/TOUR_CREATION
- 02: Manual in RF or in the EWM warehouse monitor
- 03: External/third Party via an internal API
- 04: Utilization oriented late in the line supply process
In this blog post I will describe the line supply process for a very simple scenario, where route trains are driving on different routes to different PSAs in a bus-like manner: there is a time table (similar to a bus or a train schedule) created upfront and the system needs to determine which delivery item shall be processed with which tour (in real life: which bus shall I take?).
The prerequisites
This brings us to the general requirements, which must be fulfilled so that a delivery item can be processed via route train process:
- the delivery item must be a delivery item which can be processed via distribution equipment. As described in the blog post from Jörg and in the How-To_guide for distribution equipment, the distribution equipment process requires that the delivery item has a specific warehouse process type and specific process (in standard: DEP1 or DEP2). This warehouse process type will decide if the picking warehouse order is relevant for the route train or not. In addition, it controls with the POSC that the rack follows the steps OB01 (Picking), DE01 (staging, optional step)), DE02 (loading) and DE03 (unloading).
- the delivery item must have determined an intralogistics route (please do not mix up with the route SCMB route) during delivery creation or update. SAP S/4 HANA for Manufacturing logistics supports condition technique to find the route based on delivery item information.
- the delivery item needs a time information, when it shall arrive at the PSA. This information is derived from a time segment of the delivery item. You can configure which time type shall be used to identify the correct supply date and time (based on the item type of the delivery item).
In a nutshell: the delivery item needs to know, when it needs to be where and how it shall get there.
The time model
SAP S/4HANA for Manufacturing Logistics evaluates based on the supply date and time and the determined route with the planned round trip time from the route master data, when the delivery must start: this identifies the planned departure date and time. We assume that all items on the tour have a supply date and time, which is later than the planned departure date and time of the tour, but we do not consider if a delivery item is to be unloaded at the beginning of the tour or at the end (which would require a later supply date and time).
Time model with backwards calculation from Demand time
In this example the warehouse request is created at 10:15 with a demand time of 15:00 at the same day. The timing function determines, once the route has been determined – based on planned loading duration and cycle time of the route - when the loading should start. The loading start defines also the end of the picking phase. The picking start time can then be used as a planned wave release date and time when you create the corresponding picking waves using the add-on specific wave creation.
You can configure a planned picking start time so that this time is added to the planned loading start time. This time can then be used to determine the corresponding wave options in case your process uses waves (and the complex processes do use waves, so we leave it out of this post for now).
Picking times for different source storage types for picking
In this example we configured that in general the picking time is one hour unless it is configured differently for the different storage types.
The Tour Creation
Before we start to plan the goods distribution, the tours are created upfront using report /ILO/TOUR_CREATION for a given route; we must ensure that appropriate condition records exist so that the route can be determined automatically when the e.g. WMR is created in EWM.
Tour Creation: Selection screen
When the report is executed, then the master data of the route (here: R_DEMO) is evaluated and corresponding tours are provided to the user.
Tour Creation: Result screen
These tours can now be consumed by incoming warehouse requests
The process
The demo process picks, loads and delivers 6 different JIT calls to 5 different PSAs on one route train tour.
Route Train Process: Execution steps based on Distribution equipment with add-on checks
While the picking process is near standard (with some special checks on route and tour) we will focus on the loading and unloading (=delivery) process.
Route Train Process: Unloading beyond the distribution equipment
We depart from storage type 5T01 and stop at the first PSA-100. The unloading takes place to the right in driving direction and is posted to the handover point 6P50-100-H. The next PSA-200 is served also via handover point (here 6P50-200) and unloading is done to the left. For PSA-300 and PSA-400 the unloading is also taking place to the left without using a handover point. The last PSA-500 is served via right unloading direction before the route train is back to the arrival storage type 5T02 where empty racks can be posted.
The JIT Call creation
Now 4 JIT calls are created to PSA-100 to PSA-400, while there are 2 JIT calls to PSA-500 which are created a bit later. Therefore, the standard app Request Replenishment for Control Cycles (F4038) is used.
The system determines during the creation of the delivery item in EWM the route and the tour. This determination is part of a complex algorithm called "Logistical Revaluation" which tries to determine the corresponding planning data when a delivery item is changed.
Tour assignment to delivery items
EWM warehouse monitor node: Tours with assigned warehouse request items
Now the warehouse tasks for picking are created: 1 WO for the first 4 items and another one for the remaining 2 items.
Picking Warehouse orders with route and TourID
The picking step
These 2 WO are now processed in RF into racks via the route train specific logical transaction for Picking (PICIWO).
Picking Process in RF
As a result, both racks are ready for loading: there is a separate WO for loading for each rack.
Open loading warehouse orders
The loading step
The loading warehouse orders are confirmed in RF with the add-on specific logical transaction CILH00 for route train loading.
RF loading for 2 racks, loading completion and parking of the tour at the start point
As the tour has already been created upfront and HUs have been assigned to the tour, the system can propose the next HUs for loading.
The loader confirms the second HU as being loaded, then completes the loading step and confirms the tour to the start bin of the route.
After loading completion, the system creates in the background the unloading warehouse tasks for whole racks (if they are to be unloaded on one PSA) or for each single loaded HU in the rack in case the rack has to be unloaded on multiple PSAs.
In this scenario the system created one WO for unloading which contains one WT for unloading for the rack and 4 WTs for unloading for HUs in the second rack. This unloading WO is linked to the tour and cannot be processed with the standard RF transaction for WO confirmation but with the add-on specific unloading transaction.
Unloading warehouse order for rack and HU in racks
Tour Monitoring
The EWM warehouse monitor has been enhanced with an own node for tour management. In this node you can select tours by e.g. route, driver, status, JIT call etc.
As a result you get the well-known two layered structure with object identification and object details as drilldowns.
There are different drill-downs available:
- To Handling units:
EWM Warehouse monitor: Tour node and drilldown to HUs
- To tour stops:
EWM Warehouse monitor: Tour node and drilldown to stops
- To status values
- To unloading warehouse tasks
EWM Warehouse monitor: Tour node with unloading warehouse tasks.
and to unpacked warehouse request items.
Of course there is also a Fiori app Manage Tours (F4600) available which can be used for tour management and monitoring:
Manage Tours app (F4600)
The Unloading step
The unloading process can be triggered via add-on specific logical transaction CIULHU for unloading. The EWM warehouse monitor also contains an unloading function for HUs but in this scenario I will focus on the more common RF scenario.
The driver has to identify the tour in this manual scenario by scanning one of the top HUs of the tour (= racks)
RF unloading: tour identification and towing vehicle assignment
Afterwards a towing vehicle needs to be assigned to the tour, if this is configured on route level. The usage of a towing vehicle is mandatory if you want to monitor the tour execution process as a driver with the My Tours app (F4553).
The My Tours app is a read-only app which shows the list of stops and the representation of the racks to the user. It shows which HU or which rack has to be unloaded at a given stopID. Therefore the user can click on stops and then the HUs for unloading are highlighted in dark blue, already unloaded HUs are highlighted in light blue. The driver can also click into the racks to get more information on the loaded HUs and their position.
The app is a read-only app: the user cannot execute the unloading process with this app; this is done using RF.
My Tours app: main screen
On the top right corner the user can see the unloading progress and the number of unloading warehouse tasks. In general: changes in the backend like e.g. confirm an unloading warehouse task triggers the update of the app automatically.
The driver confirms the unloading on the first PSA-100 via RF:
Unloading confirmation of a subHU to a handover point of a PSA
According to the confirmation method maintained on the route stop the HU and the unloading bin needs to be scanned. However as the PSA cannot be reached directly but unloading is done via handover point the system does not request the stop storage bin.
After confirmation at the handover point of PSA-100 the next PSA is proposed and the My Tours app is refreshed automatically.
The user confirms the unloading at every PSA for each HU. At PSA-400 the whole rack 620525 can be unloaded so the user does not have to confirm the unloading of the two HUs which are put into this rack during the picking process.
My Tours and RF unloading for a whole rack
After confirmation of the last HU the driver continues the ride and brings the route train back to the arrival station and confirms the arrival at 5T02-06. The empty rack (this is the rack where the HUs have been unloaded to different PSAs) is also posted to the end point of the route
The result
As a result 4 of the 6 WMRs are completed, while 2 of them are not yet transferred to the PSA: they have been moved to the handover points.
Confirmation of open warehouse task from handover point to PSA completes the WMR
Conformation of these 2 warehouse orders also completes the corresponding WMRs.
The tour node shows now that the tour is in status completed and that the execution of this tour took 11,3 minutes.
Completion of tour: HU arrived at the bins on the PSAs
All HUs are confirmed to the PSAs and there are no open warehouse tasks anymore for these WMRs.
It is important to know that the tour and the unloading warehouse order are combined in a way, that you cannot complete the WO in e.g. RF in the WO transactions as these transactions do not update the assigned tour: you must process this unloading warehouse order with the functions of the addon; otherwise you will create data inconsistencies (open tours with no open unloading warehouse order).
Conclusion & Outlook
This post showed a simple, although quite lengthy tour scenario with tours which are created upfront. We have shown the tour creation, the picking process and the main route train processes loading and unloading. We also showed two Fiori apps for tour management.
In the next post I will go into more details on the more complicated scenarios for wave assignment and route and tour determination.
- SAP Managed Tags:
| User | Count |
|---|---|
| 7 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
