The purpose of this page is to clarify how EWM handles the statuses in Delivery Processing.
The following scenarios may be encountered opening the delivery in /SCWM/PRDO or /SCWM/MON transactions:
For Inbound Delivery (PDI), at header level you see:
- The Goods Receipt has status completed, but there is still open quantity to receive;
- The Unloading has status completed, but there is still open quantity to unload;
- The Putaway has status completed, but there is still open quantity to be putaway'ed;
For Outbound Delivery Order (PDO), at header level you see:
- The Picking has status completed, but there is still open quantity to be picked;
- The Packing has status completed, but there is still open quantity to be packed;
- The Loading has status completed, but there is still open quantity to be loaded;
- The Goods Issue has status completed, but there is still open quantity to be GI'ed;
In EWM, the status handling is different compared to the ERP side deliveries. Loading, picking, goods issue statuses are calculated based on a single item – for the item.
The statuses can be different in source, nature and behavior.
How statuses are calculated in EWM
The statuses can be calculated based on:
- Document flow on item level
- Processes and statuses stored on DB level
- Projected statuses
- Aggregated statuses
Document flow on item level
For example, Picking status is calculated purely from Document Flow links.
Any quantity in pick relevant DF links will be added and compared against (usually) IM ALTER quantity from table /SCDL/BO_STM_QO.
a. If they match, the picking is completed.
b. If the picking is 0, it is not started.
c. If IM ALTER is zero, it is not relevant.
d. If IM ALTER is higher than the pick quantity, it is in process.
e. If IM ALTER is lower, it is overpicked.
Note: there might be hidden document flow links that can alter this behavior (typically cancel pick related entries).
Processes and statuses stored on DB level
For example, DCO status is calculated from several other statuses, see table /SCDL/STM_DETER. For example for the profile /SCDL/OUT_PRD_DLV the DCO is calculated from DBC, DBD, DBP, DDC, etc statuses. Here the calculation is quite simple: take every relevant status and compare their resulting status values based on the mentioned table. If all statuses are the same, this will be the status. If the statuses are not the same, it will take the default value for the ambiguous value – from /SCDL/STM_TYPES- STATUS_VALUE_DET.
There are also some statuses which are set from outside. For example, the inbound delivery related delay status DWM. When the putaway is completed for the item, a job might be scheduled to set the DWM status. As long the report is not run, the DWM status is set to 1 and once the job is finished OK, it is set to 9 and the DCO status is updated.
Other statuses might come from the header level. For example, status DAC – For archiving. Once the archiving flag is set for the delivery, it is set for all of its items as well.
Another example would be status DBC – blocked inconsistency – if the delivery is blocked for any inconsistency, all items should be blocked.
A projected status on document item level offers the option to control activities and the field control on item level using a status at header level. This attribute has a purely technical meaning.
An aggregated status at document header level provides summarized information on the status of all items.
The goods receipt status can be displayed at the delivery header level. Rather than being set by activities, the status values are specified by the set of status values for the goods receipt status of all document items. The aggregated result is always valid and cannot be ambiguous. The rule for the aggregation is:
- if everything is 0 (Not relevant) -> header status is 0
- if everything is 1 (Not started) -> header status is 1
- if everything is 2 (Partially Completed) -> header status is 2
- if everything is 9 (Completed) -> header status is 9
- in case of mixed values the 0s have no effect and there are 3 cases:
- all other values are 1 -> header status is 1
- all other values are 9 -> header status is 9
- otherwise -> header status is 2
In case you create split items, the main item will never be posted goods issue, for example. For this reason, these main items where the status will not be relevant gets their respective statuses set to ‘not relevant’. On the other hand, for these main items, the distribution status (DSP) gets an important role: it shows if there is still any quantity on the main item waiting for split. Later on, these statuses are aggregated to the header level.
So in case you want to check if picking is completed or not, you should check picking and distribution status together.
In case the picking is not completed, you still have some picking to do. In case distribution is not completed, you will find open quantity on some main item.
To make such checks easier, we have introduced several new statuses with “… and distribution” description. These statuses combine the base status and the distribution status, so it is enough to check a single status.
For example, the DED (plan picking and distribution) status on header level will tell you if you still need to create pick WTs or not. Similarly, the DLD (loading and distribution) status will tell you if loading is done or not yet completed.
If you have 3 items (item 10, 20 and 30):
- item 10, 20 and 30 have the same values, e.g. 2 -> header status is 2
- item 10 is 0, other 2 items have the same values, e.g. 1 -> header status is 1
- item 20 is 0, other 2 items have different values, e.g. item 10 is 1, item 20 is 9 -> header status is 2
If a status "... and distribution" (e.g. DGD) shows an empty value or value "not relevant" it may be that the status is set to "inactive" in the corresponding status profiles. The status are often optional and are inactive. So ensure that for all delivery header and item status profiles you are using that these status are active. It is important that you activate them in the header as well as in the item profiles.
Also note that when you activated the status in the profile, the status for the deliveries will in most cases only show correct values for deliveries/warehouse requests that have been created after the activation of the status. This is due to the fact that several status are persisted on the database and the activation in the profile will not cause that the database entries get created for existing deliveries/warehouse requests.
SAP KBA 2518328: EWM delivery status handling