Reveal SAP EWM
Calculation of the Latest Starting Date (LSD)
By reading this blog post, you will learn everything you need to know about how EWM calculates the Latest Starting Date for warehouse orders. Once again, I took a deep dive because I was not satisfied with the explanations I found in the SAP help texts. Here, I share the results of my analysis and, as usual, I promise to reveal some of EWM’s secrets. 🙂
What is it and what can it be used for?
Let us start with defining what the LSD actually is. In the 2nd part of this post, I will try a deep-dive into the calculation of the LSD. As you know it from my articles/videos, I promise to reveal some details and information that you will not fine in the SAP help or any of the SAP books! The latest starting date (LSD) is the latest point in time by which execution of a warehouse order (WO) should commence, so that it is completed by the due date & time. It is calculated on warehouse task level but saved for the warehouse order.
SAP help: The system calculates the LSD of a WO by: Calculating the LSD of each WT as described above Taking the worst-case scenario LSD (that is, the earliest LSD)
It is calculated in the context of resource management. Technically that means that it is only calculated in case the given WT found a queue with operating environment 2, 3 or 5:
Later during processing of the warehouse orders, the LSD is mainly used for sorting the WOs in the queues (this is true for the RF environment as well as for the MFS). Note that some other factors also have an impact here. We will not tackle the queue sorting further here but it is on my list for the upcoming months!
Examples for sorting in the RF and the MFS queues (standard MFS warehouse order selection for resources (e.g. high-bay cranes) is also sorting the WOs in the queues based on the LSD):
How to calculate and set the LSD?
Based on the SAP help text, the LSD is calculated as follows:
LSD = WO due date – (planned execution duration + planned movements duration)
Simply imagine the ‘due date’ being one point in time in the future and interpret the minus (-) components as those time periods in which we need to move backwards from this point in the future in order to find our starting point.
This is the most important formula which will accompany us until the end of the article/video. In the following chapters we will try to break that down and analyse the different components.
Before we start our deep-dive, it is important to understand that the LSD is calculated for each possible resource type due to the fact, that the velocity of the resource type has an impact on the movement duration and therefore also directly on the LSD calculation. The final LSD for the WO is then the LSD for the slowest possible resource type. During WO creation we do not know which resource will later process the WO so we better assume the worst case and write the corresponding LSD into the WO.
FM /SCWM/RSRC_WHO_CREATE is the one to collect all resource types which are allowed to process the given queue (considering allowed HU type groups and allowed bin access types from customizing) and hands them over (along with the WO and its WTs) to our most important player: FM /SCWM/RSRC_LSD_CALC:
FM /SCWM/RSRC_LSD_CALC starts to collect the data to fill the variables for our formula shown above:
*Party-Knowledge*
If the pick completion timestamp is not set in the wave template option, EWM determines the storage process step that happens after the picking step (PACK in our example but it can also be staging or loading). From there it takes the planned duration and calculates backwards against the planned completion timestamp (from the wave template) of the corresponding step.
Example:
- Pick completion is not maintained
- Packing step is taking 10min (600sec) based on the POSC customizing
- Pick completion = Pack completion – 600sec
(pls ignore the 1h time-shift between warehouse time and DB time in my system!)
If either
- waves are not used at all
- the pick completion timestamp is not maintained and you are not using storage processes / POSC
- the pick completion timestamp is not maintained but also the completion timestamps for packing, staging and wave completion (loading) are initial
The due date is the planned departure from yard from the warehouse request header (which might be set by the ‘planned departure’ timestamp from the transportation unit in case you are using TUs).
Important note (again, a secret that is not mentioned anywhere in any of the SAP user manuals that I know) –
If maintained in customizing, EWM substracts from this planned departure also the duration of all POSC process steps that happen after the picking step. This makes a lot of sense as picking should not be completed when the goods leave the warehouse but rather at an earlier point in time to have some buffer left to pack, stage and load the goods:
For the sake of completeness –
The logic to set the due date for physical inventory warehouse orders is based on the planned count date, which can be provided during PI document creation (set in method /SCWM/CL_PI_UI_APPL-WHO_CREATE):
As the next part of our formula, we will look into the calculation of the execution duration.
planned execution duration (~ PP_DUR)
SAP help for the LSD formula (and comment in the code above)
The planned execution duration is taken from the WO
…that does not help much 🙁
EWM offers two main approaches to calculate the planned execution duration
- With Labor Management (the options to calculate the LSD via LM is not in scope of this blog post as it is quite complex and based on my experience most of you will probably not use it anyways)
- Without Labor Management the duration is retrieved in our LSD context in FM /SCWM/RSRC_LSD_CALC via the subroutine get_pick_place_duration (screenshot below)
The subroutine get_pick_place_duration however does not calculate anything. It simply reads the result from the WO data where it had been filled before based on customizing data from different places. Let us have a look at those places/components! To be honest, I cannot ensure that there are some components that I missed (the coding is quite complex here). I am sure I covered the most important ones. In general, you can imagine the calculation to work like this:
Execution Duration = Preparation time of the WO + Execution time of WT #1 + Execution time of WT #2 … + Execution time of WT #n
Preparation time: The preparation time calculation is pretty easy. The value can be derived from the WOCR that was used to create the WO (screenshot):
Both of them describe the time that the picker needs to grab the items from the source bin (and place it on the pick-HU) and to place it (from the pick-HU) to the destination bin.
It’s parameters & values are defined in customizing. For each movement (take from source or place to destination) you can define a constant time (e.g. to open the source box/HU/bin) plus a variable time depending on the quantity to be removed/placed. You can find the customizing path below along with an example setup that I created to simplify the understanding . Note that the F4 help for this customizing node is exceptionally detailed (worth is to read through). In short – you can define the constant as well as the variable part of the execution time depending on the UOM of the task, the product attributes, the bin access type and the WPT category. Quite a flexible framework!
The following screenshot summarizes the result with the objective to make it understandable for everybody.
(1) Preparation time from WO customizing
(2) Extract/Reach time calculation for each WT from ‘Define Extract Time Determination’ customizing
(3) Extract time calculation for each WT (sum for source and destination extract times)
(4) Total time on WO-level (preparation time + extract time of all WTs)
Option 1 (the old ‘Travel Distance Calculation’): The 1st option is the ‘old’ (and default) way of calculating based on the X & Y coordinates of the bins. The logic is sitting in FM /SCWM/BIN_DIST_GET which is called by subroutine get_travel_distance:
Option 2: The ‘new’, more complex approach for Travel Distance Calculation. This one is based on method /scwm/cl_tdc-get_time_for_lsd and needs to be activated in the warehouse number settings.
- Option 2 offers a more sophisticated algorithm for the calculation (which I did not explore in detail and is not in scope of this article). Both will only work in case coordinates are maintained for the storage bins!
- Option 2 offers many different Badis/entry points to change the standard calculation or create a custom logic for the distance calculation. Option 1 does not offer any possibility to include a custom logic
- Option 2 calculates the travel time right away (considering the velocity of the slowest resource type) whereas option 1 calculates only the distance
Note that the customizing for Define Planned Duration of Movements in Warehouse does not have any impact on the LSD calculation, based on my research. Did not explore any other usages but seems SAP is only using this as a simplified option to calculate the planned completion timestamps for WTs in case you are neither using warehouse requests, nor waves. So not really interesting for us here.
The subroutine modify_lsd first calculates the travel time in case we used option 1 (mentioned above) for the travel distance calculation. It does this based on the distance calculated via FM /SCWM/BIN_DIST_GET (remember option 1 mentioned above) and the velocity of the different resource types. As mentioned, this is only required in case the travel time calculation has not yet happened via method /scwm/cl_tdc-get_time_for_lsd and handed over to our subroutine (remember option 2 for travel time calculation mentioned above).
The result is added to the execution duration (pv_plandura_sec in the screenshot below), that we got above from subroutine get_pick_place_duration above. The sum results in the total duration (movement duration + execution duration):
Note that if labor management is active, the travel duration is already part of the planned duration coming from LM and not calculated again here.
Once the total duration is calculated, FM /SCWM/RSRC_TIMESTAMP_SUBTRACT finally executes our main formula. It uses the total duration to calculate backwards based on the due date. This finally delivers the LSD:
This LSD is then saved for all allowed resource types in table /SCWM/WO_RSRC_TY and once for the WO in table /SCWM/WHO:
This summary marks the end of this post. As usual, I hope I could add some value for some or the other.
To finally wrap it up –
The LSD that we calculated above for a given WO, can easily be changed via the warehouse monitor manually:
This is easy but what can you do in case you want to calculate it right away based on a custom logic. Stay tuned for my next video. Smash the subscribe button and sign in for my newsletter so you cannot miss it!