Reveal SAP EWM
Synchronization of Warehouse Order completion
Note: This blog shows an EWM standard logic which is rarely mentioned in any of the EWM books and documentations but tackles a process / scenario which is relevant for almost every SAP EWM warehouse / operation that I’ve seen. Let’s jump into the technicals!
Description of the problem
Process
o You pick SAP EWM warehouse orders for the same warehouse request / consolidation group within different activity areas of the warehouse (e.g. one warehouse order in manually operated racking area, another warehouse order in an automated high-bay area with pick points)
o Once the picking process is completed you want to consolidate everything into one shipping HU at a pack station (e.g. a big carton box or a pallet)
Constraints
1. The pack stations have a limited number of buffer bins in the inbound area of the pack station. You cannot stage an unlimited number of pick HUs which means that you cannot proceed picking any more once all buffer bins at the packing station are occupied)
2. The pack stations have a limited number of pack bin in the main area of the pack station (you can only pack a limited number ship-HUs in parallel at a time)
3. As you want to consolidate all items for one CG into one shared ship-HU, you cannot complete packing (~ move the ship-HU for the given consolidation group to the outbound area of the pack station) before picking is completed
Based on the process and its constraints, the objectives are obviously to
– Always ensure that there are empty buffer bins which can be used by the pickers as destinations for the pick HUs
– Minimize the time that a pick-HU is waiting at the packing buffer (~ inbound area of the pack station) in order to be packed (the packing buffer is our bottleneck > storage space is very costly here)
– Always ensure that there is not idle time for the packer (there should always be pick-HUs which can be packed ~ pick HUs that belong to a warehouse request / consolidation group which is completely picked)
So in summary we want to make sure that the pickers as well as the packers are able to constantly execute their tasks (no waiting times for completely picked HUs at the one hand and no waiting times for buffer bins to become empty on the other hand) and ensure that we are not running into a deadlock (‘deadlock’ here means that the packer cannot start packing because all pick-HUs which are waiting in the buffer belong to warehouse requests / consolidation groups which are only partially picked and the pickers cannot pick any more because there are no empty bins left at the packing buffer / inbound area.
How to solve this problem/challenge?
We will reach all the objectives mentioned above once we are able to synchronize the completion of different warehouse orders for the same consolidation group which are being processed in different activity areas.
Having said that we already see that this is a dynamic process. In heterogenous environments – like most of the warehouses we are operating – it is not possible to sync processes upfront which take place in different areas over a period which is longer than a couple of hours. We can do a rough planning upfront (EWM has a couple of options via standard customizing which I do not want to describe in detail) but at the end you will never know exactly which WT/WO in which area starts/completes at which point in time.
Badi /SCWM/EX_CORE_CO_POST
This Badi is being called upon confirmation of a WT and SAP delivers an example implementation (class /SCWM/CL_EI_CORE_POST_CONS_WHO) to cover the consolidation/synchronization scenario described above:
In the first step (1) the example implementation checks whether the SAP EWM warehouse order which is being confirmed is relevant for the consolidation logic:
Following checks on the WT/WO are executed in the method check_relevance:
– Does the WT has a delivery reference?
– Is it assigned to a RF queue?
– Is the activity of the WPT of type PICK?
– Does the WO have a LSD and a planned duration?
Only if all checks are true, we proceed and set the local system date and time into the variable lv_lsd_new. If the system date/time is more than 1h earlier than the LSD of the current WO (which means the WO for which the WT is being confirmed right now has a LSD in the future), we call the method adjust_lsd_4_who and handover the new LSD (~ current timestamp) as well as the duration (planned execution time) and the planned completion time (end time stamp) of the current WO:
Note: As mentioned above, we won’t explain in detail how you can make use of the standard customizing to calculate the planned duration/completion times.
Important note for the LSD update via method adjust_lsd_4_who (queue it due to RF performance!!):
Within the method for the LSD adjustment we execute the following steps:
1. Select all other WOs for all deliveries which have a reference in any of the other WTs of the current WO
2. Calculate and write the updated/new LSDs into internal table lt_who_data
3. Call standard FM /SCWM/WHO_UPDATE to write the new LSDs for the WOs into the DB
One detailed look into point (2) reveals how the example implementation finally calculates the new LSD for the other WOs. Within a loop over those WOs the following logic is being applied:
1. If the duration of the other WO is bigger/longer than the duration of the current WO (the one for which the WT is being confirmed), the LSD is updated to the current system date/time (~ which basically means “start right away with the other WO!”)
2. If the duration of the other WO is smaller than the duration of the current WO, set the LSD to the planned completion of the current WO minus the planned duration of the other WO (~ which basically means “do not have to start right away but ensure that both WOs are completed at same time”):
Summary
I showed you an example logic about how SAP thinks the scenario that I described could be solved (that is at least my interpretation). I do not want to give any statement here about the meaningfulness of the logic above. It will probably not cover your requirements out of the box but this is why it is called ‘example implementation’. For sure, it is food for thoughts and for sure it is a good basement and starting point for your custom solution. You will probably be able to re-use at least 50% of the given logic in case you want to cover a similar process. Simply copy the class and redefine/adjust wherever you have slightly different requirements.
Having said that, I hope I could help anybody out there. This is a topic which is not mentioned in many of the books that I’ve read but synchronizing picking activities from different areas is surely something which is relevant also in some of your projects!
I hope this blog post provides value to you and you could learn something. Please feel free to subscribe to my blog updates or my youtube channel in case you want to be notified about new posts!