Skip to Content
Technical Articles

Different Warehouses in /SCWM/PRDO and /SCWM/PRDI

Introduction

It is hard for me to name this post somehow better and clearer. It goes about SAP relatively new feature (it is not a bug) in the /SCWM/PRDO & /SCWM/PRDI transactions.

Feel free to skip boring part and jump directly to the Hint/Solution.

This feature can be implemented with OSS Note 2651168.

You get no messages when delivery documents cannot be found in the current warehouse. It would be helpful to get a list containing the warehouses for the given deliveries.

So, what does it do? When you search deliveries in these transactions system checks as well if any deliveries matching (partially matching) selection criteria are available. And shows you warning messages (/SCWM/DELIVERY_UI 124)

Delivery document &1 is assigned to warehouse number &2

And why I am writing about this? it is boring and just one of the features.
Here is why:

  1. It has a problem;
  2. It is breaking EWM “Work in one warehouse” concept;

Main part

Let’s start from point 2. Almost all EWM Transactions are warehouse related. Even user Parameter is used to set default warehouse. And usually it is like this in real life. Goods receipt office works in one warehouse, and goods issue office as well. Users have authorization object with warehouse.

Ok, I can imagine some rare cases when user works in two different warehouses and should process deliveries in both.

Features are good, but in this case, it should be somehow controllable, with user parameter, for example. Or at least with customizing.

If I work in a company which has 20 warehouses as member of Goods receipt team in the warehouse #14, and I would like to select not completely processed delivery documents, I am not interested in other warehouses, really not. I do not want to know, that warehouse in Nebraska doesn’t processed deliveries for today, just because of the time difference. Maybe I am wrong, but it could be interested for management team, for head of logistic, who work with different warehouses, but they usually do not work in the PRDO/PRDI transactions.

SAP implemented this feature (not a bug) with service packs, so you kind of cannot switch it off without enhancements/modifications.

And now about point 1.

Selection of ‘other Warehouse’ deliveries can be found in /SCWM/CL_SP=>CHECK_OTHER_WH

All ranges and selection with * pattern are deleted from selection criteria:

  "Delete spec. cases which are performance intensive (like interval, and *)
  DELETE lt_selections WHERE high IS NOT INITIAL.
  DELETE lt_selections WHERE low CA '*'.

And this is bad, that’s why.

If you search deliveries for specific interval + at least one other selection criteria you will get selection in other warehouses for “some other selection criteria”.

Common case: I would like to select deliveries of special type for yesterday. Or for last two hours. Or deliveries with special status and date interval, it is normal to use date interval.

If after deletion of “performance intensive” selection criteria you have something left, you can get following result in transaction:

Select%20by%20document%20type

Select by document type

And%20by%20date

And by dates

Creation date goes away, and you get:

Selection%20result

Selection result

As you can see, this is some kind of strange behaviour, 77 thousand of not relevant documents read from database (and only one relevant).

selection%20took%20more%20than%201%20minute

selection took more than 1 minute

And good news are SAP has fixed this, in original OSS Note side effect is described and fixed with note https://launchpad.support.sap.com/#/notes/2717490

Coding after implementation:

  "No ranges allowed
  DELETE lt_selections WHERE option EQ 'BT'.

  "No regex search allowed
  DELETE lt_selections WHERE option EQ 'CP'.

  "remove every line from selections which are not docnos or erpnos or whs
  DELETE lt_selections WHERE ( fieldname NE 'DOCNO_H'
    AND fieldname NE 'REFDOCNO_ERP_I'
    AND fieldname NE 'LOCATIONID_WH_H' ).

It makes this feature relevant only for the search with ERP Document number. The only case where it theoretically can be required.


Conclusion:

It seems that it makes no sense to write a post about this feature, but my point is really simple:

if you have Support Package from the list:

Component Version Support Package
SAPK-S4CLOUD_1902
S4CORE 103  SAPK-10301INS4CORE
S4CORE 101  SAPK-10106INS4CORE
S4CORE 102  SAPK-10204INS4CORE
SCMEWM 920  SAPK-92012INSCMEWM
SCMEWM 930  SAPK-93010INSCMEWM
SCMEWM 950  SAPK-95004INSCMEWM
SCMEWM 940  SAPK-94010INSCMEWM

and update is not planned in a near future, and you will have more than one warehouse in the system It is better implement OSS Note 2717490. Otherwise users can face performance problem in production system, because system selects a lot of irrelevant documents in /scwm/prdo & /scwm/prdi transactions.



 

P.S. If case somebody from SAP development sees this post:

My suggestion is to check in the beginning of the CHECK_OTHER_WH method:

if NOT line_exists( lt_selections[ fieldname = 'REFDOCNO_ERP_I'] ).
 return.
endif.

Instead execution of often unnecessary selection in the loop

  "remove every line from selections which are not docnos or erpnos or whs
  DELETE lt_selections WHERE ( fieldname NE 'DOCNO_H'
    AND fieldname NE 'REFDOCNO_ERP_I'
    AND fieldname NE 'LOCATIONID_WH_H' ).

  "remove already found docnos and erpnos from the selections it
  LOOP AT it_head_core ASSIGNING <fs_head_core_line>.
      SELECT SINGLE refdocno INTO ls_docid_ero-ero FROM /scdl/db_refdoc
         WHERE docid EQ <fs_head_core_line>-docid AND refdoccat EQ 'ERP'.
      DELETE lt_selections WHERE fieldname EQ 'REFDOCNO_ERP_I'
               AND low EQ ls_docid_ero-ero.
    DELETE lt_selections WHERE fieldname EQ 'DOCNO_H'
               AND low EQ <fs_head_core_line>-docno.
  ENDLOOP.

  "condition: If only warehouse filter remains-> do nothing (performance)
  IF lines( lt_selections ) GT 1.
.....
.....
endif.

 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.