Reveal SAP EWM
Inbound staging bin determination
This blog reveals the logic for staging bin determination step as part of an inbound unloading storage process step. 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. In this context we will also cover the staging bin determination for delivery items in general. So even if you are not using the POSC, this article provides everything you need to know about this topic.
The blog is separated into the following sections:
- Rules-based vs. non-rules-based staging bin determination
- Deep-dive into the logic
- Option for enhancements
Let us start with looking into the differentiation between a rules-based and a non-rules-based determination, while using the process-oriented storage control.
The standard help text is very – let’s say ‘lean’ here:
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). Minimal information in the SAP Press Books about EWM and nothing in the OSS.
In general, the ‘Rule-based’ flags are used to trigger logic which is used to determine the destination which is needed to complete the previous step (so e.g. a record with OB02 will set the destination for step OB01). It replaces the rather fixed, pre-given destination (storage types, storage sections and storage bins) that you can maintain in each external step.
The inbound staging bin determination logic in the context of the POSC is only relevant for unloading steps though. This also means, that the rules-based flag helps us here to find the destination bin for the actual (the unloading) step (this is kind of unique – as mentioned above, for most of the other steps we are actually determining the destination data for the previous step).
Note that I highlighted the ‘unloading step’ here. This is important to understand. If we want to determine the staging bin via the POSC, we need to do this via an unloading step (not via a ‘staging’ step like one could think in the first place – the latter is only used during the outbound process)!
Within this blog post, we will first look into the non-rules-based logic, before we close with the non-rules-based one.
Non-rules-based is pretty straightforward –
EWM simply reads the destination bin from the customizing of the POSC step itself. That’s it. No determination logic. No determination table:
So let us focus on the rules-based option, which is much more interesting!
What the bin determination for all POSC steps has in common, 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. For the inbound unloading / staging process, it reads the staging data, which should have been set already ahead of the POSC actually being executed (so ahead of unloading the HUs). The staging data is read via FM /SCWM/GET_STAGING_AREA_INT, which will then return the destination bin for the unloading step:
The FM reads the staging area for items of the given handling unit. It first (1) tries to get it from the delivery items where the HU items are referring to:
Pretty easy, but how did EWM actually fill those fields on delivery item level?
As this is not happening within the POSC coding itself, we are now leaving the POSC for a quick excurse. The logic that I explain now is independent from whether you are later using the POSC for the inbound process or not. This is purely about the staging data determination for the delivery item. We will come back to the POSC context later again.
The trigger for the staging data determination for the delivery item is sitting here:
/SCWM/CL_AF_SR_CONFIG-/SCWM/IF_AF_SR_CONFIG~DETERMINE_STAGING_AREA_INB
But the whole logic is sitting inside of method /SCWM/CL_AF_SR_CONFIG-DETERMINE_STAREA_INB, which is called from the one mentioned before.
Let us go through that one step-by-step:
First this method makes use of method SELECT_STAREA_DET to read the application data:
- Read all records from the staging area determination table for the given warehouse number (filled via transaction /SCWM/STADET_IN)
Read all records from the staging area access sequence for the given warehouse number (filled via transaction /SCWM/STADET_ASS)
This selected data is returned to method DETERMINE_STAREA_INB in order to evaluate the determination table records based on the access sequence and then return the result / match.
Important notes (~ some – incl. myself – call it ‘party knowledge’ (I understand if you now imagine a very nerdy party 😉 )):
- The access sequence table is used for inbound as well as outbound processes and not all fields of the table are relevant for the staging bin determination in the context of the inbound process (green vs. red)
- The Door field is the only one which is not mandatory (~ does not have to be filled in the delivery item) even if you set the door flag for all records of the access sequence (at the end, EWM will always try to find a record without considering the door value > no door access after the ELSE statement in the screenshot below)
That’s it. Pretty simple. No surprises! We know now where the data is coming from. Finished our short excurse about the staging data determination for the inbound delivery items.
Back to the POSC and back to the FM that started the determination process (/SCWM/GET_STAGING_AREA_INT) and which original task was to handover the staging data to the POSC determination logic. In case is not possible for this FM to get the data from the warehouse request (~ the fields in the delivery item are empty), it tries to get it from the transportation unit (2):
So let us try to explore where and how EWM determines the data from the transportation unit.
Method /SCWM/CL_SR_MY_SERVICE-GET_DLV_DOOR_BY_TU first tries to determine the relevant TU based on the HU item data (remember we are analyzing the task creation in the context of the process-oriented storage control here > thus, we are always trying to create a task for a HU, during runtime of the code that you see here).
Once it has determined the assigned TU, it reads the door assignments to this TU, which are matching the planned times for the start/end of the unloading process (ignoring all door assignments where the time window either stops before the planned unloading start or where the time window starts only after the planned unloading end):
If EWM finds exactly one door within the allowed time window for unloading, it proceeds with the staging bin determination via method /SCWM/CL_SR_CONFIG-STAGE_AREA_DET_IN:
From within this method we call method /SCWM/CL_SR_CONFIG-GET_STADET_IN, which is doing the exact same thing as method /SCWM/CL_AF_SR_CONFIG-DETERMINE_STAREA_INB did for the inbound delivery item before. It reads the determination table and the access sequence records and then compares those with the data collected from the transportation unit (also considering the door that was determined for the planned unloading time window (described above)):
The result of this method is than carried back to function module /SCWM/GET_STAGING_AREA_INT, which then returns the data back to our well-known POSC FM /SCWM/STORAGE_CONTROL_P_GET which kicked-off the determination initially, in order to get the destination for the unloading step of our storage process.
That’s it. You do know have (or have not) staging data which has been determined in a rules-based approach, either based on the delivery item or based on the transportation unit.
It is important to understand that it is not foreseen to skip the unloading step entirely (like e.g. steps for quality inspection or deconsolidation during the inbound process). So in case you decided for the rules-based logic and the staging bin determination described above does not return a valid bin, EWM will give you an error message instead of skipping the step!
As usual, I will close this post listing some options for you the enhance the EWM standard logic here.
Options for enhancements
Badi for staging bin determination of delivery items: /SCWM/EX_SR_STADET
This Badi is called at the end of method /SCWM/CL_AF_SR_CONFIG-/SCWM/IF_AF_SR_CONFIG~DETERMINE_STAGING_AREA_INB (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_IN (so after the standard bin determination based on the TU has been processed):
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 this Badi, which can be used to implement your very own rules-based determination of the destination data for the given POSC step (this one is independent of the step type itself)
Based on this article you should have a good understanding of the staging data determination for delivery items. On top of this, you know now how this data is being evaluated in the context of the process-oriented storage control and which additional options you have here, while using the POSC (non-rules-based with fixed data in the POSC step or rules-based considering the delivery item & TU data).
Please feel free to subscribe to my blog updates or my youtube channel in case you want to be notified about new posts!