SAP Logistics

 At times, there will be a situation where sample warehouse task is not created.  The first step, we will check the configuration of the QM note of EWM  Define and Activate warehouse IOT settings. If the sample size config is maintained there. Then check if the inbound delivery document flow is determined with doc category 'Q01', this will give you the sample size. System still unable to determine warehouse tasks then in that situation, from technical standpoint during debugging, keep a breakpoint at the below class and Methods to troubleshoot the issue. This is the place where inspection rules will be called.  CLASS -  /SCWM/CL_QGR_CONTROL METHOD - /SCWM/CL_QGR_CONTROL~SAMPLE_SPLIT_CHECK CLASS - /SCWM/CL_GOODS_MOVEMENT METHOD - /SCWM/CL_GOODS_MOVEMENT~CHECK_QGR_CONTROL METHOD - PREPARE_DLV_DATA~CHECK_QGR_CONTROL BADI : GGR_CONTROL ~ SET_GGR_CNTRL_BY_IRULE can be leveraged in case of if business have a requirement that deviates from the standard functionality...

 Error Message Creating a return to vendor delivery on VL60 raises error: 'Unknown error has occurred in target system (Message No. /SCWM/DELIVERY_UI056)'. Root Cause RFC user is not configured as a dialog user. When creating a return delivery from EWM, the system attempts to call the RFC function /SPE/INB_CALL_TRX_VL60 using an RFC destination. This process involves executing the dialog transaction VL60, and the RFC destination relies on the RFC user for the call. Solution Approach Solution 1: Master data. Ensure that the RFC User master data is adapted to 'dialog'. Solution 2: BAdI implementation. Maintain a separate RFC destination for Return to Vendor scenario. Maintain a separate dialog user with restricted authorizations (e.g. only VL60). Assign the dialog user to the RFC destination. Change the RFC destination for calling the VL60 transaction from EWM, with BAdI '/SCWM/EX_DLV_ERP_CALL_CTRL->CALL_CTRL'. BAdI documentation extract: "Sample coding an...

The customizing flag for storage type "No GI" blocks only the posting goods issue for delivery documents, but in ad-hoc goods movement scrapping process (/SCWM/RGI_SCRAP), it is not evaluated.  On the selection screen of /SCWM/ADGI, if flag "Select Scrap Stock only" is set, the system will filter for stock with stock type S5 Scrapping from Putaway and/or S6 Scrapping from Warehouse.  In case it is needed additional checks on ADGI, customer-specific checks during unplanned goods issue can be implemented via BAdI /SCWM/EX_CORE_GM_STOCK.

If there is a requirement where system has to determine warehouse process type based on the storage location then in that situation we have to leverage exit /SCWM/EX_DLV_DET_PROCTYPE~CHANGE_PROCTYPE to accomplish the requirement. Logic should be written such that /SCWM/WHR_QUERY is used to fetch the delivery document details from EWM. REFDOC field in the IT_HEADER-REFDOC will contain the S4 delivery number.  This is passed into LIPS and fetch storage location and determine process type based on TVARVC or custom table

Issue : Although SAP does not recommend it, it may happen that you want to change the serial number profile of an existing material. If stock has ever existed for this material in the warehouse, the serial number profile is stored in table /SCWM/SERH, and it is no longer changeable despite any changes in the material master in ERP or in EWM . Solution Approach  As first step you have to remove all stock (including planned stock, which means rejection of all not yet goods receipted stock on existing inbound deliveries) for the material from the warehouse. Set the appropriate serial number profile for the material in ERP. Delete the entry from table /SCWM/SERH for the material. Then you can start using the material with the new serial number profile, when the new stock comes for the material the entry in /SCWM/SERH will be automatically recreated with the relevant data. Deletion of the entry from the table can be done through debug mode or through the implementing the code proposed b...

Rejection of the outbound delivery order can be done from /'SCWM/MON or /SCWM/PRDO. This post will show you the rejecting the delivery through /SCWM/PRDO Below is the process steps to reject the outbound delivery in SAP EWM : Launch transaction /SCWM/PRDO and enter the delivery number, execute Click on Process codes --> Adjust delivery Quantity     Select O001 and click on ok , Save Delivery will be rejected and EWM. If the delivery type is enabled with create OD automatically at cancel, then business need not click on 'Outbound delivery' button. If not, business has to click on this button to cancel the delivery in SAP S4. Thank you.

 At times, business will contact us to perform put away reversal due to various reasons like received wrong quantity or PO was wrongly entered. As per standard SAP, EWM will not allow you to perform GRN reversal after stock is received in the warehouse ( Putaway is done ) . For say, if the business has done goods received but not initiated the putaway process then system will allow business to perform GRN reversal if no HU movements are done. But however, if the warehouse tasks are confirmed then system will not allow business to reverse the goods receipt.

 SAP Note  1913028   recommends the below steps to be followed in case of this error : Option A Cancel all additional material documents with MVT 107,  except the first one . Use transaction MIGO with "A03 Cancellation" and "R02 Material Document". Remember the quantity posted. Post a subsequent delivery for the first material document number with MVT 107 for the quantity used in step 1. Use transaction MIGO with "A06 Subsequent Delivery" and "R02 Material Document". Release Goods Receipt for Inbound Delivery by movement ' 109 ' in transaction  VL32N . Now the error M7329 should be gone. Option B Please run the reports ZCORR_EKBE_ETENS from note  655427  and ZCORREKESGRRTV from note  536190  to fix/synchronize the fiels EKBE-ETENS and EKES-ETENS.

Reports RSQOWKEX/RSQIWKEX can be scheduled as a periodic background job to reset the status of LUWs registered to outbound(SMQ1)/inbound(SMQ2) queues. RSQOWKEX for outbound queues (SMQS/SMQ1). RSQIWKEX for inbound queues (SMQR/SMQ2). The below parameters are to be maintained : Queue Name as '*' Select 'No Running Queues' Do not select 'No Retry queus' Queues running longer than  < Time in Mins > ideally 20 mins No queues older than < Data > Note that this job will change the status of the failed queue to 'READY' status so that scheduler will process it. But for any queues struck in 'READY' status, th ese need to be processed manually.

  Issue : If the delivery has two items, one of them is reference to the main item of the PO, another one is reference to the subitem whose EKPO-UPTYP is not blank. eg. EKPO-UPTYP = 8, that means the subitem is the 'Interchangeable Items (IBU: A&D)' of the main item. In general, the inbound delivery should only be posted for items which contain the actual material, but in the case of the error PO, inbound delivery was posted for both main item and subitem. This will cause the error when system reads confirmation data during GR posting. Solution Approach given by SAP : Only items refer the actual material in the PO should be created in the delivery. The queue cannot be processed. Reverse GR for the delivery in EWM and cancel the delivery then recreate the delivery. If the GR cannot be reversed due to DCO status is 9, use VL_COMPLETE to complete the ERP delivery then do physical inventory in EWM

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. 

  E WM stock is composed by the physical stocks plus the Difference Analyzer stocks. /SCWM/ERP_STOCKCHECK shows the total physical stock quantity of a given warehouse. The Physical Inventory difference was not yet posted on /SCWM/DIFF_ANALYZER, so the stocks still exist in the warehouse as a "difference" yet to be posted. While /SCWM/MON displays only available and physical stocks, not differences. The correct procedure is to run the /SCWM/DIFF_ANALYZER to clear this stock pending, so it will not be shown on /SCWM/ERP_STOCKCHECK as well. If  /SCWM/ERP_STOCKCHECK  has a different EWM quantity than the total physical stock, the difference can be found on the  Difference Analyzer , since the EWM stock is equal to the physical stock plus the Difference Analyzer stock.

  Issue After zero out EWM delivery, non-EWM relevant items in the ERP delivery are not zeroed out.\ Solution Approach Do not mix EWM relevant items and non-EWM relevant items into one single delivery. But you can add your own logic in method EXIT_SAPLV50I_004 of SMOD_V50B0001 to change the quantity of non-EWM relevant items to zero when the delivery is zeroed out in EWM.

 Issue  Delivery created from a sales order is distributed to the EWM system.  "Partial delivery at item level" is set to 'C' - Only complete delivery allowed Quantity is changed or Goods issue is complete in the EWM system.  Queue fails in the ERP system with error VL062 - "Full delivery is required" Solution Approach Maintain the following entries within your system using transaction OVM1 - if they already exist, adjust them accordingly: Application: 'L' - Shipping processing Call type 'D' - Confirm from external system Call type 'B' - Background processing, multiprocessing with Work phase 'B' Application Area = VL, Message no = 062, Type = I * Call type 'B' with Work phase 'A' is for background delivery creation.

 At times, we might need to overrule the existing capacity check of the bins and create a custom rule to determine capacity of the bin, in this situation we have leverage the below BADI to accomplish the requirement /SCWM/IF_EX_CORE_PTS_CAPACHECK~CUSTOM_CAPA_CHECK  Note : This BADI will be called for all types of transfers to the Bin due to that ensure to be careful while implementing this.

We use the transaction  /SCWM/VALUATION_SET    'Determine and Set Prices from ERP' to replicate the valuation data for products into the EWM system. For the non-valuated ERP products, not any data is created in the data base table /SCWM/T_VALUATE - Valuation Data for Physical Inventory. It is not possible in EWM to distinguish between just missing valuation data for a product( not replicated ), and non-valuated products.