Goods Issue automation in EWM
This is a blog item to illustrate a possible methodology to automate the ‘goods issue’ functionality within EWM for outbound deliveries using a batch job.
I posted a query in the EWM community hoping a nicer, better tip would come up. But while waiting for tips, I figured out the following method which is off course just one of many possible options depending on the business processes involved in your Warehouse.
My client runs a medium sized Warehouse using SAP EWM 7.0 SP6. Business processes are not so complex and custom code is fairly limited to RF functionality other than few reports. He doesn’t use the Shipping and Receiving function in EWM, nor he performs loading or transportation activities within EWM. These considerations count towards the solution proposal shown below:
Having stabilized the operations after Go Live, the client was interested in spreading the Goods Issue load during the day Vs current manual job of having to go to the transaction /scwm/prdo, select confirmed ODOs and press the ‘goods issue’ button. One issue with this operation is slowing down of RF devices the moment a big bunch of deliveries were goods issued.
Method proposed considering the functionality being used in this Warehouse:
It is evident that the goods issue is processed by a PPF action in EWM. So, I worked backwards in steps to figure out how to automate the steps.
I did not find any job to mimic the action of clicking on the goods issue button in /scwm/prdo, hence I focussed on getting it done by PPF itself.
Goods issue button in /scwm/prdo:
SAP provides the report RSPPFPROCESS (transaction: SPPFP) to manually select and process PPF actions. Based on this, I decided to first to change the setting on “Send message to ERP” PPF action to non-automatic.
PPF action for sending the Goods Issue from EWM to ERP:
I made the ‘Processing Time’ from ‘Processing when saving…” to ‘Processing using selection report’.
Effect: when user clicks on the goods issue button, a message (PPF action) is created but not processed in EWM automatically.
As you have already noted, I used the report RSPPFPROCESS to create a batch job and schedule it according to the customer needs/frequency.
My next goal is to ‘mimic the goods issue action’ itself within EWM. In order to do so, I found that after the Warehouse Task confirmation, I need to achieve the task of Goods Issue without the user intervention. Warehouse pickers use RF devices to complete picking and confirm the warehouse tasks. However, the goods issue action was not automatic. I noticed the PPF action for the goods issue function:
I set the processing time on this PPF action to ‘Processing when saving document’.
Handling the statuses:
To my surprise, though I had made the goods issue PPF action automatic, deliveries were not getting goods issued. This led me to check what is preventing the goods issue. I noted that when I complete the “LOADING” activity, the delivery was now ready to be goods issued. The standard SAP steps leading up to the goods issue were: Pick-Pack(optional)-Load(optional)-Goods issue.
I did not want to retain the loading the get the loading PPF action completed automatically, nor I had the flexibility or the incentive to spend more time researching the options. Since the customer was not using the loading functionality and not earmarked to use it in the distant future, I thought I could perhaps switch off the loading indicator leading up to the goods issue.
I recognize that this kind of decisions are subjective and perhaps best to decide with the customer input and SAP centre of excellence input (if there is one).
I set the “Loading” status as ‘inactive’ for the outbound delivery document:
In order to do so, I created my own Z*status profile and preserved the standard SAP status profile. I attached the Z*profile to my ODO.
Effect: Now as soon as the Warehouse task of a Warehouse order is confirmed, system completes the goods issue and creates a message to send out to ERP. For performance control, I kept the goods issue action non-automatic and used batch job to send the message in a defined frequency to ERP. Stock status will not be synchronized with ERP until the goods issue message is sent out to ERP. This was not a major concern in our business process.
We have two options. (1) Keep the goods issue PPF action processing manual and create a batch job for this step or 2) Keep the goods issue processing automatic upon WT confirmation as described above.
If you go with the option-1, you may set up 2 batch jobs as shown below:
Batch Job-1 Z_PPF_POSTGOODSISSUE_STEP1
Batch Job-2 Z_PPF_POSTGOODSISSUE_STEP2
Both jobs use the same report program ‘RSPPFPROCESS’ (transaction: SPPFP).
Batch Job-1 processes the ‘create goods issue in EWM’ PPF action
Batch Job-2 processes the ‘send goods issueto ERP’ PPF action
I also noted a side effect which was positive for the customer’s business process. Earlier, when the warehouse clerk manually goods issued many deliveries together, all those deliveries got combined into one EWM material document based on system’s own grouping decisions. Though efficient, the problem with this is when you want to reverse the goods issue, you will end up reversing goods issue for all those related deliveries together.
With the batch job processing, we noticed that goods issue was done with separate material document per delivery.
We are currently assessing the full impact and performance issues if any. Personally, I intend to look at the business process at a higher perspective and try to find bottlenecks with this approach with future enhancements. I will keep an eye at EWM community as well looking for tips and better approaches. Meanwhile I hope this documentation helps other like me who have just stepped into the EWM area and looking for knowledge tips.
Note: Due to the 1mb size limit, I could not attach 2 more testresults. Interesting to not that SCN does not allow PDF or WORD attachments.
Excellent blog, thank you Raj for contributing such valuable info
Thanks for sharing, nice one!
Hello Yathi ,
Excellent document with Excellent Business Explanation . Thanks for sharing .!
Thanks and Regards
Pavan G Kulkarni
Thank you Pavan...
I do have a similar requirement ,as soon as I load the HU's I want to auto trigger PGI .
However there are two scenarios:
case 1: Not all the HU's for the delivery which is assigned to TU are loaded
and Case 2:All the HU's of a delivery are loaded.
Can you please share some of your thoughts on this
I have similar situation as indicated above...
our goal is to trigger the Auto GI after WT confirmation via RF but auto GI doesnt happen.
We do not have LOAD process. We use standard RF screens for Pick by WO. I did the steps above. I did not create a custom status profile but instead I set the Loading to "Inactive" for /SCDL/OUT_PRD_STANDARD status profile but still PPF for delivery is not triggered.
Is there something I missed in the configuration?
Thanks for sharing.
Thanks for sharing this.
However, i have a concern here. In my stock destruction process setup, a delivery is sent from ECC to EWM where the warehouse task is created manually in EWM which is assigned to a resource for picking. Now, i was able to automate GI with the help of PPF actions but the problem was that as soon as i confirm the task for picking, the PGI gets posted. But physically, the stock lies with the resource only and it is yet to putaway to a scrap zone. So, even if the stock is actualy not putaway in scrap zone, the system posts the GI. Hence, can you please let me know how can we actually achieve the PGI after knowing that the stock has been putaway physically. Not sure, if we can achieve it by creating an incompleteness profile maybe...
Thanks for nice document and appreciate your willingness to share knowledge to others.
However I have question concerning stock synch, with delay in 10 mins every job run then what about the stock status in ECC,do we have any report for stock sych like in APO(/sapapo/ccr)
Even we are following same method for Goods Receipt. 🙂
I'm having the issue that the GI posting message is sent too early in the process. It is already sent when confirmining the picking WT but before being able to confirm the destination bin. The pick-HU is therefore stuck on my resource and the GI posting ends up in the SMQ2 with the message that GI cannot be performed as the HU is still on the resource.
Any help on this?