Search
  • Samiullah Sheik

SAP EWM PPF for Auto Post Goods Issue(PGI)

Updated: Oct 16, 2020

This blog post explains how to deal with Auto PGI being triggered too early in cases of batch splits during picking.


Once picking is complete, Auto PGI PPF of the ODO is triggered every single time a picking quantity is confirmed. This is due to the fact that the system checks the status of DPI ( eq 9), which is set to 9 every time a batch split happens. As a result there are unnecessary failed multiple PPFs for Auto PGI in the inbound queue(SMQ2)

The following solution approaches can be considered


Approach 1: Use start condition /SCWM/DLV_CONF_ST by applying SAP standard notes


1461585 - Usage of dlv status values in schedule and start conditions

1460370 - PPF action executes too many times despite of the condition


These notes provide the ability to add start conditions and limit the execution of PPF after the status values are updated in the data base. The following excerpt from note 1461585 explains the difference between schedule condition and start condition



“From technical point of view, there is a big difference between the schedule and start condition. On the one hand, schedule conditions use data from memory and are evaluated before the main process updates the database from the memory. On the other hand, start conditions are evaluated when the database is already updated and they use data from there. The solution to the issue is to let the PPF action triggered but stop its execution by a start condition.”


Since start conditions use data from the database, the evaluated condition records cannot be based on the same condition tables that are used by schedule conditions. In these condition tables, the status-related field catalogs (like DPP_GM_STATUS - Goods Movement Status Changes) represent a status change, which is calculated from the status in the database and the status in the memory. Therefore, note 1460370 added five new header field catalogs to your system.


· DPP_MV_C_STATUS Pick/Putaway Current Status

· DPP_GM_C_STATUS Goods Movement Current Status

· DPP_LD_C_STATUS Load/Unload Current Status

· DPP_PK_C_STATUS Packing Current Status

· DPP_WA_C_STATUS Warehouse Activity Current Status


DPP_MV_C_STATUS is the relevant field for this scenario as we are looking to the get overall picking status. But unfortunately, the system picks the DPI status of the delivery.





Approach 2: Adding a new field to set the real DPD status


Add a new Z field Z_DPP_DPD_STATUS”( Real DPD status) in the condition table used for managing the condition records for Auto PGI PPF


Use BADI /SCWM/EX_DLV_PPF_CONF to include the new field “Z_DPP_DPD_STATUS”


Load the current status of all the items in the delivery and check DPD status of all items. If all the items have 0 or 9 then it is set to X, otherwise it will be left as blank.


Condition records should be maintained by including real DPD status = X. Only when this condition is fulfilled Auto PGI PPF will be triggered


The following is a comparison of advantages and disadvantages of both these approaches


Approach 1: Use start condition /SCWM/DLV_CONF_ST by applying SAP standard notes


Advantage

  1. Standard functionality

Disadvantage

  1. Doesn’t serve the purpose as it uses DPI instead DPD. DPI is set to 9 at header level in case of batch split for any of the delivery items which means PGI will be triggered for every batch split. This behaviour might not be acceptable for all clients

  2. DPP_PD_C_STATUS is not available in the field catalog for the condition tables

  3. Evaluation of start condition along with evaluation of schedule condition doubles the execution time

  4. If the recommended process is “immediate processing” of Auto PGI once the picking is complete, then it would conflict SAP recommendation of “Do not use start condition /SCWM/DLV_CONF_ST for PPF actions, which have processing time 'Immediate', because it might decrease the performance of your system”


Approach 2: Adding a new field to set the real DPD status


Advantage

  1. Serves the purpose as it uses DPD instead DPI

  2. Faster execution as decision is made in the schedule condition evaluation instead of start condition

  3. Follows the SAP recommendation of not using SCWM/DLV_CONF_ST for PPF actions, which have processing time 'Immediate'

  4. Using development switch framework, it is possible to populate new field for only certain warehouses. This helps in faster execution time for other warehouses that donot need Auto PGI functionality as the BADI will not load all delivery items for other Warehouses.

Disadvantage

  1. Bespoke functionality as a new field is added to the condition record and BADI is implemented to fill the value in the field


Disclaimer: This blog post is for information purposes only. No liability is accepted by the author in cases where this solution is used for productive purposes.




5,134 views0 comments

Recent Posts

See All