Reveal SAP EWM
Work center determination for a deconsolidation process
This blog reveals the logic for destination bin / work center determination in a deconsolidation step as part of an inbound storage process. Having said that, it should be obvious that we are looking into inbound processes using the process-oriented storage control in order to model the physical flow & steps.
Note that I will not share a detailed explanation here about the deconsolidation process as such, but rather focus on the work center and/or bin determination for this step. I am recommending this this blog here from Nitin Solan for those who want to make themselves familiar with the general functionality here upfront.
Before we look at the Agenda for this post, I would like to highlight one funny thing, that I noticed while reading the code. Some EWM standard constants and programming objects are referring to ‘spreading’ instead of ‘deconsolidating’ in the context we are talking about here. You might notice that in some of the screenshots below. Never heard that term before – seems they dropped it at some point and replaced it by ‘deconsolidation’. Maybe just ‘party knowledge’ but I think it kind of helps to understand the logic as we are actually ‘deconsolidating’ in case the goods will later be ‘spread’ into different areas of the warehouse. This is why I thought it would be worth sharing it here:
Enough for the introduction – let us look at the structure of this article.
Agenda
– Rules-based vs. non-rules-based determination
– Deep-dive into the logic
– Option for enhancements
Rules-based vs. non-rules-based determination
In general, we can separate the options for the bin determination as part of the process-oriented storage control into rules-based and non-rules-based ones.
As for the deconsolidation, the rules-based flags will be used to determine the destination which is needed to complete the previous step (so e.g. a record with IB02 will set the destination for step IB01).
Alternatively, you can use the rather fixed, pre-given destination (storage type, section and bins) that you can maintain in each external step.
Based on this we know now that a rules-based determination of the destination data can be used for our deconsolidation step. Honestly – that help text here does not help at all. At least not when you are just starting your EWM journey.
Thus – the perfect feature for my blog series ‘Reveal SAP EWM’. Within the following paragraphs I give you an in-depth technical review for the usage of this flag for internal process steps of the type ‘deconsolidate’.
Deep-dive into the determination logic
The non-rules based option is the easy one of course. As mentioned above, you only need to maintain the destination data in the POSC customizing for the given step and it will be fixed for all HUs which fulfill the key-criteria:
The rules-based option is the more interesting one –
Function module /SCWM/STORAGE_CONTROL_P_GET is the most important player for all kind of rules-based bin determination (no matter whether we are talking about deconsolidation or any other step type).
In case the rules-based flag is set for a deconsolidation (~spreading) step, EWM first (1) collects all product warehouse tasks having the given source HU. With this step EWM is preparing the relevance-check. Note that EWM will also consider tasks for all sub-HUs here. The logic is sitting in FM /SCWM/TO_GET_ROUTE_MAT_TO:
– the FM reads all sub-HUs for the given top-HU
– reads all open product WTs with one of those HUs as source HU
– determines the destination activity area for each of those tasks based on the destination bin and the activity type from the WPT
– returns the result
In the second step (2) – in case it could find product-WT(s) for the given HU(s) – it evaluates the deconsolidation rules via FM /SCWM/SPREADING_RULES_EVALUATE, in order to return a destination type, section and bin. So in this step EWM is actually executing the relevance-check:
FM /SCWM/SPREADING_RULES_EVALUATE executes the following logic –
At first it checks whether deconsolidation is necessary at all, based on the enriched list of WTs returned from the first FM mentioned above (product WTs for our HU & sub-HU(s)). This is done via subroutine spreading_check:
– Do we have tasks/products with different quality inspection types (e.g. one product is relevant for sampling and one is not)? If yes, deconsolidation is relevant
– Do the WTs point towards different activity areas? If yes, deconsolidation is relevant
– Do the WTs point towards storage bins with different deconsolidation groups? If yes, deconsolidation is relevant
– Do we have more than one WT and is one of the WTs moving preallocated stock? If yes, deconsolidation is relevant
– In case none of the above is true, EWM makes one last check, comparing the number of WTs for the given source HU against the maximum per HU for the given activity area (threshold can be set via deconsolidation customizing)? If equal or bigger, deconsolidation is relevant
In case deconsolidation turns out not to be relevant, we return from here and skip the step of the given storage process (e.g. provide the final putaway destination of the HU right after the unloading process step).
In case deconsolidation turns out to be relevant, EWM tries to determine a work center as a destination to execute the deconsolidation step. This is done via subroutine spreading_station_determine:
– It first determines the HU type group for the given HU as well as the source storage type (e.g. the staging bin or one from the door bin in case the HU is moved from a TU directly)
– Then it uses this data to read the deconsolidation work center determination table:
1. first time fully qualified
2. second time without the destination activity area
3. third time without storage type
4. fourth time without storage type & activity area:
Note that in case the rules-based flag is not set, the deconsolidation step is always relevant. In this case, EWM will try to read the destination data for the previous step from the customizing of the POSC deconsolidation step and throw an error in case it could not find any.
Options for enhancements
In case what I described above is not sufficient to cover your requirements, you can use Badi /SCWM/EX_WRKC_DECON_DET to potentially add a custom logic for the work center determination. With this Badi you could overrule the error flag mentioned before and provide a destination based on your own rules:
Closure
…nothing left to say. Hope you learned something new. At least the fact that ‘deconsolidation’ has once been ‘spreading’… 😉
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!