Why does EWM call /SCWM/GMHU_SELECT during /SCWM/TO_CONFRIM

[former_member349127]

During WT Confirmation of a product WT onto a HU EWM collects GM data for all ODO related goods-issues that HU was involved in:

1. Using the HUIDENT of the pick-to pallet EWM collects all /SCWM/GMHUHDR entries e.g. if a HU has been goods issued multiple times there will be multiple entries in this table for this HU, here 10.
2. For all all entries found in 1. collect all goods issues from /SCWM/ORDIM_C using the TANUM from the /SCWM/GMHUHDR entry
3. For all goods issues found under 2. go find the associated /SCWM/GMHUHDR records. In the below example 135 /SCWM/GMHUHDR entries are found. In this project one goods issue typically contains 48! HUs.
4. For all /SCWM/GMHUDR entries collect data from

1. /SCWM/GMHDURTW
2. /SCWM/GMHUREF
3. /SCWM/GMHUIDENT
4. /SCWM/GMHUSTOBJ
5. /SCWM/GMHUSTAT
6. /SCWM/GMHUITEM
7. /SCWM/GMHUITMSN

I would very much like to know why this (historic) goods movement data is of interest during the confirmation of a pick-WT.

The reason for the question is that we have a warehouse with returnable pallets that have a fixed HUIDENT printed on them, once a HU has been trough the warehouse 20, 30, 40 times we see the time required for product WT confirmations on those HUs increase to unacceptable levels ( > 3 seconds, up to 10 - 15 seconds). The customer retains about one years worth of /SCWM/ORDIMC_C. Despite the large data volumes the queries themselves are fast enough, it is the number of queries that is executed for HUs that have been goods issued many times that ultimately compound to a significant delay in the execution of the WT confirmation.

Any insights will be much appreciated!

[Daniil · Accepted solution]

Hi Helios,

it seems like Transit Warehouse functionality. It depends on some flags in the HU. If you are not using Transit Warehouse functionality for Pick HUs you maybe should remove these flags from HU. If you not use Transit Warehouse functionality at all, it could be that HU is created not in a proper way.

ls_huhdr-TWHUTYPE

BR,

Daniil

[former_member349127 · Accepted solution]

Hi Daniil

Thanks for your reply. I've run a test to double check, TWHUTYPE is initial i.e. not "TR".

The comment in /SCWM/CL_SR_TW_PACKING=>SETUP_PSHU_BY_HU (number 14 in the call stack in my initial post) seems to, sort of, suggest the observed behavior is desired/expected? In any case the reason for loading all past GI Goods Movements for my pick-to HU (and all other HUs goods-issued with the same TANUM) remains elusive...

Best regards

Helios.

[Daniil · Accepted solution]

Hi Helios,

do you create pick HU during WT confirmation? or is it created in advance? I would expect here return statement for normal Process.

if you do not have it, see OSS Note https://launchpad.support.sap.com/#/notes/2510013

/SCWM/CL_SR_TW_PACKING=>GET_PLANNED_HUS_BY_HU (number 15 in your stack) begins with:

  CALL FUNCTION '/SCWM/HU_READ'
           EXPORTING
                iv_appl = 'WME'
                iv_db_select = space
                iv_top = abap_true
                iv_guid_hu = iv_guid_hu
           IMPORTING
                es_huhdr = ls_huhdr
           EXCEPTIONS
                OTHERS = 99.
  IF sy-subrc IS INITIAL.
    IF ls_huhdr-twhutype IS INITIAL AND ls_huhdr-flgtwext IS INITIAL. 
      RETURN. "<<<<<<<<<<<<<<<<<<<<<<<<<<
    ENDIF.
  ENDIF.

[former_member349127 · Accepted solution]

Hello Daniil

Thank you very much! That is it, I don't have this coding in our system. Will apply note and test.

(Yes, the pick HU is created in advance)

Thanks again,

Helios.