SAP Logistics

Below is the solution approach to be followed in case of the error message Error "/SAPAPO/LOC040" during mass maintenance in /SCWM/MON : Entries for that Party Entitled to dispose (PED) should be present in tables /SAPAPO/LOC, /SAPAPO/LOCMAP,/SCMB/TOENTITYMP and /SCMB/TOENTITY.  If relevant entry for PED (Party Entitled to Dispose) is missing from any of above tables then system will through error "/SAPAPO/LOC040" during mass maintenance in /SCWM/MON To correct this, please execute below steps Go to SE38 tcode, Execute report /SCMB/CHECK_SCU  Give the affected SCU & Business Attribute. example "PLOC", "ZONE" Mark the check box "Make Corrections"& execute Report /SCMB/CHECK_SCU correct the inconsistencies and process ended with message "Program /SCMB/CHECK_SCU ended" (/SCMB/SCU206)

 At technical level, fixed bin will be determined based on the below logic : system will first check for the fixed bin field at the storage type level , if this is checked (  /scwm/t331 - fixbin = 'X' then system will call FM ' /SCWM/BINMAT_READ_MULTI' which will read the data maintained through the bins maintained in the /SCMW/BINMAT transaction at the front end level to fetch the bin data.

At times, we will struggle with stock being not picked from the source bin, in this situation to investigate from technical level for issue related to the source bin determination, try to keep breakpoint on the FM ' /SCWM/REM_BIN_DET_INT' which will give you some hint related to the root cause of the issue

In general, if business do not want source HU to be populated during the picking process then settings 'S ource L evel of Available Quantity of the Source Storage Type is on Bin Level' and  source storage type needs to be setup as a final storage type (Setting: Storage Control complete).

As per standard SAP functionality capacity check for /SCWM/ISU is deactivated. This transaction should be used for initial data transfer from old system to EWM (example). That means the stocks must be physical stocks already stored within the warehouse at storage bins. The same would happen if physical inventory will be performed and the user count more then allowed capacity. The system will post the differences without capacity check.  At /SCWM/ISU, and also in physical inventory counting (PI), not all checks against storage type, bin type customizing are performed, compared to 'normal' putaway. The reason for this: Both in initial stock upload, and PI counting, it must be possible to enter stock on a bin the way it physically exists there. Even if it is against the put away rules. 

Below is the determination of Departure from Yard ( OUTYARD ) in the outbound delivery order : If there are several EGOODSISSUE dates (both on header and item level) on the delivery items, it takes the latest date from all the EGOODSISSUE dates. If there is no EGOODSISSUE date on the delivery items, it takes the value of the TDELIVERY date field. This date will be given highest priority during the wave creation for automatic process. If this value is blank, then system leverages planned goods issue date for wave creation

  Issue   When using DRFOUT and select replication mode "Changes", none of the changed BPs are sent to target system Solution Approach When Changes are selected in DRFOUT transaction, this requires Change pointers to be present in table MDGD_CP. For Change pointers to be present in this table, Business System that is associated to Replication Model selected & Outbound Implementation 986_3 should have Pooled Output. If DRFIMG is not Pooled output for the target system. Hence there are no change pointers saved. Change output mode to "P Pooled Output" in customizing below: T-code DRFIMG -> Define Custom Settings for Data Replication -> Define Technical Settings -> Define Technical Settings for Business Systems -> Define Bus. Systems,  BO