Reveal SAP EWM
Options for the destination of loading tasks
This blog focuses on the outbound loading process which is used for the last movement of a given handling unit, before it leaves the warehouse (physically & logically).
I will explain three different options provided by the standard in order to determine the destination of the EWM loading warehouse task. EWM always offers more than you expect so I assume that also in this context, there are some additional options that I am not aware of :-).
Note that I have not considered any additional options that might evolve out of a TM integration or the new features being delivered based on ASR. I assume most of you are dealing with the loading process in EWM without being integrated into TM.
…a rough agenda, before we start with the details:
– Simple vs. Complex loading
– Preconditions for complex loading
– Creation of loading tasks
– Options for the destination determination
– Interesting findings/discoveries
– Options for enhancements
When we are talking about loading warehouse tasks, we are always talking about a ‘complex loading’ process. In contrast do this, with a ‘simple loading’ process we do only set the status/timestamps on the TU/delivery without creating & confirming specific warehouse tasks for the loading process.
For the purpose of this blog, we will look at the ‘complex loading’ process only. Pre-condition to make use of this is the usage of the process-oriented storage control (POSC). Without an external process step with the internal step of type ‘LOAD’, you will not be able to create loading warehouse tasks at all:
All of those options will not be explored in detail within this blog as we do not want to focus on the creation itself but rather on the determination of the destination for the given tasks.
This external storage process step of the storage process is the starting point for our 3 options for the determination of the loading task destination.
Rules-based vs. non rules-based
First of all we need to differentiate between rules-based and non rules-based determination of the destination.
Based on this we know now that a rule-based determination work of the destination data can be used for some of the process steps. Honestly – that help text here does not help at all. At least not when you are just starting your EWM journey. The web-help (help.sap.com) does also not offer anything helpful here (at least not at the time of writing this blog post). Thus, we have to take it into our own hands again.
One important point upfront, before we look into the details –
For the outbound loading step, EWM uses the rules-based flag in order to determine the destination of the actual step. Only for the unloading and for the loading steps we are determining the destination for the actual step with the data from the given external step. For all other step types we are actually determining the destination data for the previous external step (e.g. packing work center for the destination of the picking step). This is important to understand from my point of view!
What all types of POSC steps types have in common though, is the spot in the code where the respective logic is being called. Function module /SCWM/STORAGE_CONTROL_P_GET is the most important player here. Before we take a deep dive here, let us quickly look at the non rules-based approach.
The non rules-based option
As one could expect – this is the easy one.
Option #1 for the determination of the destination for the loading task:
The destination data from the external process step.
With this approach you simply unflag the rules-based option and provide the destination as part of the POSC step data:
Theoretically that also works with the storage type only (along with the customizing for the generic putaway WTs (‘2’) for the storage type), but the standard RF loading dialog does only support the confirmation of loading WTs with generic destination via CHBD exception. The latter does only work in case you have multiple possible doors for loading / docking the TU. If this is not the case, you will receive an error message:
The rules-based options
In case the rule-based flag is active, the destination data given in POSC-step customizing will be ignored. Instead – as mentioned before – function module /SCWM/STORAGE_CONTROL_P_GET jumps in to apply some more complex logic. This will bring us option #2 and option #3 for the determination of the destination for the loading task.
We start here by calling function module /SCWM/GET_DOOR_TU_INT in order to determine the door bin or TU as a destination for the loading tasks:
This FM executes the following steps in order to determine the destination:
It first tries to read the TU based on the document reference from the given HU
- 1. In case the HU, delivery or delivery item does have a reference to a TU, the FM returns this TU itself as the destination for the loading step
- 2. In case the delivery or delivery item does not have a reference to a TU, it tries to get the door data from the referenced delivery item via method /scwm/cl_sr_config-read_door_single
- If it could find a door, it determines and returns the door bin as the destination for the loading step
Excursus
The door itself can be determined for the delivery item based on the application data which can be maintained via transaction /SCWM/STADET_OUT (access sequence via /SCWM/STADET_ASS):
Storage bins can be assigned to doors via transaction /SCWM/DOOR_SCU (loading WT creation will fail in case EWM determined a door as the destination but this door does not have a door bin assigned to it):
Interesting notes
#1
The standard RF dialog will always display the bin of the active door as the destination. Even in case EWM could determine a TU for the HU and the WT is created with the TU as the destination. It is not possible to load to a TU in case the HU is not arrived/assigned to an active door (S&R Door Activity).
#2
If a WT is confirmed at a door where a TU is positioned, the system automatically changes the destination storage bin in the WT to TU.
Before confirmation of the loading WT:
Closure
As mentioned above already, if the FM mentioned above could neither find a TU, nor a door, it throws an error and does not create a loading task at all. Thus, the step is not supposed to be skipped, in case the rules-based destination determination could not determine a destination (like it is e.g. done with other process step types)).
Options for enhancements
Badi to determine destination bin for storage process step: /SCWM/EX_CORE_PSC_PROCESS
- At the end of the FM /SCWM/STORAGE_CONTROL_P_GET EWM calls Badi /SCWM/EX_CORE_PSC_PROCESS which can be used to implement your very own rules-based determination of the destination data for the given POSC step
Badi for staging bin determination of delivery items: /SCWM/EX_SR_STADET
- This Badi is called at the end of method /SCWM/IF_AF_SR_CONFIG~DETERMINE_STAGING_AREA_OUTB (so after the standard bin determination for the delivery item has been processed) and also at the end of method /SCWM/CL_SR_CONFIG-STAGE_AREA_DET_OUT (so after the standard bin determination based on the TU has been processed):
Summary
- POSC is mandatory in case you want to execute the loading process with warehouse tasks
- Three options that I am aware of
- Fixed destination based on the external POSC step (non rules-based)
- Rules-based
- TU as a destination (in case you are working with Tus and a TU is assigned to the given delivery item at the point in time when the loading task is created
- Door bin as a destination (in case no TU is assigned but a door with a door bin was determined for the delivery item before)
- No option to skip > error message in case rules-based without a result
Based on this article you should have a good understanding of options for the destination determination for loading warehouse tasks. On top of this, you know now how loading tasks are created and how the tasks behave during confirmation.
Please feel free to subscribe to my blog updates or my youtube channel in case you want to be notified about new posts!