2 Step Stock Transfer in EWM Kanban

 It is always true that, when observed, the overall solution and the concepts used in all Warehouses will be the same. But there are always variations in which the process executed on the Warehouse floor. It is one such variation that I would like to share in this blog.

Through this blog, one will be able to understand the below:

1. 2 Steps Stock Transfer in EWM Kanban– Configuration Steps and Execution
2. The need for a New Document Type and New WPT
3. Partial Pick during Kanban

This blog is with the assumption that you have setup the Warehouse to function already. Steps below will be concentrated only towards Kanban process related setup.

Note – In my process, both the Source and Destination Slocs are EWM managed.

Process Flow that will be explained in this blog:

Overall Process

Step – 1: I have configured the 2 step Kanban Process using the “Delivery Option”. There is a new method that SAP has introduced, not long back, using Warehouse Task. The use of this method, technically called as the Control Type, is defined in the below configuration node.

Control Type Menu Path

Control Type Config

As noticed in the screenshot above, the Control Type – 7 is used. Type – 8 can be used for Warehouse Task Option (I haven’t tried that option though, yet). Movement Type is 313, which is triggered during the Step – 1 of the 2-Step Kanban Cycle. Now comes the question on the 2^nd Step and defining that in our configuration.

Step – 2: The system is now informed of the Movement Types and the ERP Document Type to be used for Outbound and Inbound Deliveries.

Delivery Type Determination

Delivery Type Determination Config

Step – 3: This is where the little deviation that I had to do in specific for my client. I had to auto create the WT at both Inbound and Outbound automatically including the auto post of GR and GI. This is in conflict to the other configuration in place for the regular Vendor GR and Customer GI, which will use the same Document Type in ERP and EWM.

This made it difficult for me to play around with PPF to automate WT/ GR and GI creations only for Kanban and to leave out other GR and GI processes for manual execution by the Warehouse Operator.

This left me with no option but to use a different Document Type in both ERP and in EWM. I had an unused Document Type that I havent used in any of my processes – HID and HOD.

Also, in the EWM side, I had 2 Standard Document Types that I haven’t used for any of my other processes, which is IPS and OUTS.

Respective configurations for HID/ HOD and its link with EWM Document Types are as below:

SCM Extended Warehouse Management –> Interfaces –> ERP Integration –> Delivery Processing –> Map Document Types from ERP System to EWM

Doc Type Mapping

SCM EWM –> Interfaces –> ERP Integration –> Delivery Processing –> Map Item Types from ERP System to EWM

Item Type Mapping

Standard EWM Document Types used are shown below. I havent changed anything other than its description and hence I don’t see a need to show the details inside the Document Types.

SCM Extended Warehouse Management –> Goods Receipt Process –> Inbound Delivery –> Define Document Types for Inbound Delivery Process

Defining Doc Types for IBD

SCM Extended Warehouse Management –> Goods Issue Process –> Outbound Delivery –> Define Document Types for Outbound Delivery Process

Defining Doc Types for OBD

Step – 4: All the configuration that is done till now will manage the IBD and OBD creation separately but the trigger of IBD once the GI is done is for OBD is not managed yet. For this we will have to activate a Workflow in the system. Below are the details.

T-Code: SWE2

IBD Creation WF

Above are the configurations needed to be in place for Kanban to work. When the Kanban Control Cycle is setup, one will have to maintain the Container Qty that needs refilling by the WH Operator.

When the Container is marked as Empty, WT is generated for the Container Qty as in the Control Cycle.

In an ideal world, it will work when the stock is present in the source bin, but this is not always the case in the real world. If the stock is less than the Container Qty in the source Storage Bin, the WT will be created for the Qty that is available. When this is the case, GI cannot be posted as the pick Qty is less than the OBD Qty.

Hence, we will have to use the concept called “Pick Denial”. When the WT creation Qty is less than the Available Qty, the Pick Denial which was set during WT creation is triggered. This will reduce the OBD Qty in EWM and in ERP to the WT Qty. This will now allow auto GI in hence the 2^nd Step of Kanban is continued.

When the above is configured, it will allow the WH Operator to continue with his pick Qty and the Production will not have to stop their process due to stock non availability.

Step – 5: Below are the steps to configure Pick Denial

SCM Extended Warehouse Management –> Goods Issue Process –> Pick Denial –> Activate Pick Denial at Warehouse Number Level

Pick Denial Activation at WH Level

SCM Extended Warehouse Management –> Goods Issue Process –> Pick Denial –> Specify Pick Denial at Warehouse Process Type Level

Activate this for the WPT that you are planning to use for Kanban Goods Issue.

Pick Denial Activation at WPT Level

SCM Extended Warehouse Management –> Goods Issue Process –> Pick Denial à Assign Internal Exception Codes to Exception Codes

Assigning Internal Exception Codes

Cross verify the configurations of Exception Code PD01 assignment to your Warehouse along with the below values (though should be present by default).

Exception Code Check 1

Exception Code Check 2

Exception Code Check 3

Now, in the WF above, SAP has provided it to work as a Dialog Step. So once the WT is created with less Qty, this WF will be triggered in the backend but will NOT get completed unless there is some manual intervention, which will NOT happen. Hence the WF needs to be updated as below.

WF Automation

Once all the above configurations are done, you will be able to complete the 2 Step Kanban Pick Cycle with Pick Denial.

Process Steps:

As mentioned above on the assumption that the Warehouse is already setup to work, I will NOT be showing the Master Data used other than that is in specific for Kanban.

Kanban Control Cycle:

Kanban Control Cycle

Once the Control Cycle is setup and the Kanban Board is updated with status as WAIT for the Container. Based on Status configuration, the status sequence may vary. Am going with the standard flow here, where the status will change from WAIT –> EMPTY –> IN TRANSIT –> FULL. If it’s a 1 step Kanban, IN TRANSIT status will be skipped.

Kanban Board

Let’s work with Container 32.

Step – 1:

Mark the Bin as Empty either using the App – Set Kanban Container Status (Can be used in any supported HHD) or using the Transaction PK13N, if executed using desktop or tab. As an alternative, if your Warehouse uses RFUI application, you can try mapping the standard program provided by SAP for Container Status Change – TCODE: PKRFBC.

The behaviour is however the same way whichever way you choose to perform the action.

The Kanban Container once marked Empty, an OBD is generated automatically to pick the items. Since I have used a different OBD Doc Type along with a WPT that is specifically configured for this, I have maintained PPF condition to generate WT at once it gets distributed.

Kanban Container Info

As noticed above, OBD is now created for the 2 Qty as mentioned in the Control Cycle. However, I currently hold only 1 Qty as stock in the Warehouse. Since I have also configured Pick Denial, WT would have been created for 1 Qty and the OBD in EWM and ERP is should also be reduced to 1 Qty. Can be noticed in the screenshots below:

EWM OBD:

EWM OBD

ERP OBD:

ERP OBD

WF triggered:

Pick Denial WF Trigger

PPFs triggered:

PPFs Triggered

Once the Pick is confirmed and the GI posted (via PPF trigger as the WH Operator cannot come to the PC to do a PGI for this OBD, all should happen either on the WH Floor or automatically), the Container status will now turn to IN TRANSIT and an IBD is created automatically to place the item in the PSA.

In Transit Status

IBD Doc Number in Container Info

WT Info

Once the above WT is confirmed, the stock is placed in the PSA and the status of the Container is changed to FULL automatically.

FULL Status

References:

https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/49d0972a760b4646918ce9fddb034d64/bfd0f863bb1c4598a262a4fa10b46765.html?version=2021.002

https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/49d0972a760b4646918ce9fddb034d64/e75ebd534f22b44ce10000000a174cb4.html?locale=en-US

https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/2d95c3180a974e0aad07556ee4d28e94/a6a50a0b6aa54e338ba886f06d68b00b.html?locale=en-US

Appreciate feedback and happy to correct.

Thanks,

Prasan

Source: https://blogs.sap.com/2023/08/24/2-step-stock-transfer-in-ewm-kanban/

EWM – ARM Advanced Returns Management integration with EWM

 

Introduction

You can use the Advanced Returns Management component in SAP ERP with SAP Extended Warehouse Management (SAP EWM) to manage returns items on storage bin level. The inspection of returns items is fully supported by the Quality Management (QM) component of SAP EWM. This integration improves the efficiency and transparency of the returns process.

In this blog I would like to compare 2 scenarios of ARM integration with EWM in comparing with Customer Returns process without ARM as listed below.

• Customer Returns Process without ARM
• ARM integration with EWM Process – Inspection occurs in ERP
• ARM integration with EWM Process – Inspection occurs in EWM

The testing version is S/4 HANA 2020 – EWM Decentralized.

 

Process Flow

Explain ERP Storage Location maps with EWM Warehouse Avail.Grp

Before we get into detail of each process, let’s have a look of current mapping between SAP ERP Storage Location and Warehouse Availability Grp & Stock Type as below.

We manage returns stock in ERP Sloc RETR firstly after receiving, upon inspection decision we will transfer stock to normal Sloc GRCV or Scrapping Sloc SCRP. And in EWM we have mapping Stock type for each Sloc. Try to keep the process simple so we only have 1 Stock type (F4/F9) per Avail.Grp for Returns & Scrapping.

Customer Returns Process without ARM

In this scenario, we assume that Inspection will be manage outside SAP and decision to change stock type after Inspection have to be done manually.

ARM integration with EWM – Inspection occurs in ERP

In this scenario, Inspection happens in ERP and inspection result is sent from ERP to EWM.

ARM integration with EWM – Inspection occurs in EWM

In this scenario, Inspection happens in EWM and inspection result is sent from EWM to ERP.

Testing

Because the limitation of my current EWM system setting, I can only describe the testing for scenario ARM – Inspection occurs in EWM with 2 Cases: Inspection Decision Accepted & Inspection Decision Rejected/Scrapping.

The testing for scenario ARM integration with EWM – Inspection occurs in ERP – You can reference to another blog that I attach the link in the Reference part.

Prerequisites

You have made the following settings in Customizing for Extended Warehouse Management:

• You have separated the posting of a decision and follow-up action and canceled an inspection under Cross-Process Settings -> Quality Management  Basics -> Warehouse-Dependent Activation for Inspection Object Types.

• You have made the basic settings for inspection rule (master data) creation under Cross-Process Settings -> Quality Management -> Settings for Inspection Rules.

• You have defined a code group MSRDEC with assignment of allowed decision and follow-up codes (this has to be synchronized with SAP ERP) under Cross-Process Settings -> Result.

• You have set up QM for the sending and receiving locations under Cross-Process Settings -> Quality Management.

• You have maintain QM Inspection Rule under Q-Inspection Returns Tcode /SCWM/QRSETUP

ARM – Inspection occurs in EWM Process Flow Testing

Step 1: ERP Create Returns Sales Order

Tcode: VA01

Returns Sales Order is created with Follow-Up Action is “Receive into Plant” and Refund Control “Standard by credit memo request”.

Step 2: ERP Outbound Delivery is created.

Tcode: VL10A

Outbound Delivery is created reference to Returns Sales Order, and receiving Sloc is RETR – Returns.

ERP – Check Customer Returns Overview – Tcode MSR_TRC_C

At this stage when Return Delivery is created, you can see Delivery number is updated in the Returns Steps and marked as Green – Completed, next step is GR marked blue as not yet process.

Step 3: EWM Inbound Delivery is replicated, Post GR

Tcode: /SCWM/PRDI

EWM Inbound Delivery is replicated and stock supposed to be posted in F4 – Returns stock type and keep in QI-ZONE.

Post GR and GR status is completed.

ERP – Check Returns Overview

After GR posted in EWM, it sends update to ERP and Goods receipt movement is created and marked as Green – Completed, next step is Inspection.

Display GR Document, it’s posted with Mvt653 and to Sloc RETR.

Step 4: EWM Inspection

Tcode: /SCWM/QINSP

There are 2 Items in Delivery, I will set Item 10 – Material A as Inspection pass and Item 20 – Material B as Inspection fail, then we can compare the difference.

Item 10 – Perform Inspection Decision: Accept – Quality check passed.

First step to create new HU because current HU is the dummy one. Then choose the Decision as 0001 – OK, Accepted; and assign Dest. HU as new created HU.

Note the Inspection Type before making Decision is A.

Save the inspection decision and you can see Inspection Type changed to C now. You can mark Completed Process Step for HU if storage processes related.

EWM – Stock Overview: Material A is updated as F1 – Goods in Putaway.

ERP – Check Returns Overview

Inspection result is sent from EWM to ERP and updated in Returns Steps. Here Inspection result and Transfer Posting are marked Green – Completed. Next step in ERP is to create Credit Memo.

Display ERP Inspection, Follow up Activity is “Transfer to Free Available Stock”.

Display Transfer Posting, it transfers from Sloc RETR to GRCV.

Item 20 – Perform Inspection Decision: Reject/ Scrapping – Quality check failed.

First step to create new HU, then choose the Decision as 0003 – Scrapping and assign Dest. HU as new created HU. Note that Inspection Type change from A to C after Save Inspection result.

EWM Stock Overview, stock type is changed F4 -> F9.

ERP – Check Returns Overview

Inspection result is sent from EWM to ERP and updated in Returns Steps. Here Inspection result and Transfer Posting are marked Green – Completed.

Display ERP Inspection, Follow up Activity is “Transfer to Specified Stock”.

Display Transfer Posting, it transfers from Sloc RETR to SCRP.

Step 5: EWM Create Warehouse Task for Putaway & Confirm WT

This step is managed in EWM to finish EWM putaway step and has no impact to further Credit Memo step in Returns process in ERP, means Credit Memo step can happen in parallel.

Create WT as Follow-On Function in Inbound Delivery and confirm WT as normal.

EWM – Stock Overview: After Putaway Material A to Normal Rack, Stock type change F1 -> F2; Putaway Material B to Clearing Zone for scrapping, Stock type has no chance.

Step 6: ERP Process Credit Memo & Payment

Those steps belong to Accounting department which I don’t get in detail. Statuses are updated in Returns Overview as well.

— END —

Thanks for reading, I would like to receive any feedback or comment from you.

Best Regards,

Van Bao Dang

 

Reference

SAP Help –  ARM with EWM https://help.sap.com/docs/SAP_EXTENDED_WAREHOUSE_MANAGEMENT/3d97bec9bf1649099384bb8167df3cf2/570d7a28ff3e465d9780b3afcf1cab78.html

ARM with inspection occurs in ERP Blog – https://blogs.sap.com/2021/07/08/advanced-return-management-integration-to-sap-s-4-hana-embedded-ewm-2020/

Source: https://blogs.sap.com/2023/10/06/ewm-arm-advanced-returns-management-integration-with-ewm/