Decentralize warehouse management
This is the question related to warehouse management system.
My requirement is that we are going to set decentralize management. Presently we are having CWM in our present system. At another place there is local ERP , we want to replace it and need to go for decentralise WM there.
Then this decentralised WMS and my present WM willl communicate with each other.
Could you please let me know what will be it process ? Transaction cycles ? and its configuration?
Dear All ,
I got some information I am sharing with you and closing this ticket.
1) Process :
rocesses Between the SAP System as ERP System and as WM System
Purpose The variant for the SAP System as an enterprise resource planning (ERP) system and as a Warehouse Management (WM) system describes the link-up of an external warehouse management system to an SAP System. The stand-alone system that executes all warehouse management functions is an SAP System. Prerequisites Two systems are involved in this scenario. The first system is an ERP system that performs inventory management, purchasing and sales tasks and distributes existing master data and movement data to the Warehouse Management system (WMS). The second system is a WMS that performs warehouse management tasks such as putaway/picking and goods receipt/goods issue and is responsible for carrying out the physical material transfers. Process and Data Flow General inventory postings: If the decentralized scenario is used, inventory postings are not directly processed in Inventory Management (IM). If a goods movement is created in IM, the system generates inbound or outbound deliveries and distributes them to the WMS. In the WMS, the goods are put away or picked based on the existing delivery. As a result of the goods movement posting in the WMS delivery, the system sends the completion verification to the ERP system and then uses the delivery to post the actual goods receipt or goods issue in inventory management. Deliveries with a purchase order or a sales order as a source document are handled in the same way. Goods receipts based on purchase orders: You use the ERP system to create purchase orders and send them to the vendors. To give notification of the delivery that is due, the vendor returns a shipping notification that is recorded in the ERP system as an inbound delivery. The inbound delivery is distributed to the WMS using a Business Application Programming Interface (BAPI). In the WM system, the inbound delivery is a request to put away or pick goods. When the vendor physically delivers the goods, a transfer order is generated in the WMS which is used to place the goods into stock. After the transfer order is confirmed, goods receipt is posted for the inbound delivery. This clears the interim storage bin. As a result, the completion confirmation is sent to the ERP system and the goods receipt is processed in inventory management. An inbound delivery based on a purchase order can be created in different ways, depending on the confirmation control key in purchasing. If the vendor usually sends a shipping notification, the inbound delivery is created when the shipping notification is recorded in the system. In all other cases, you have the option of creating inbound deliveries automatically using collective processing. Process for goods receipts based on a purchase order: Creating the purchase order in the ERP system Generating the inbound delivery (automatically/manually) Distributing the inbound delivery from the ERP system to the WM system using BAPI method "InboundDelivery.SaveReplica" (this process is automatically executed in the background) Physically receiving the goods into the warehouse (WMS) Creating the transfer order Putting the goods away Confirming the transfer order Posting goods receipt for the inbound delivery (as a result, a completion verification is sent to the ERP system using BAPI method "InboundDelivery.ConfirmDecentral") Goods receipt for the inbound delivery is automatically posted in the ERP system (in inventory management) when the verification is recorded. Quality management in decentralized WMS using handling units (HUs) Quality management is also available in the goods receipt process in the decentralized warehouse. In this scenario, the quality management function is in the central system. If there are handling units in the inbound delivery for which an inspection lot has been created, the inspection lot number is copied into the decentralized WMS and stored in the quants there. The inspection lot does not exist in the decentralized system. You make the usage decision for the inspection lot in the central system, which triggers the system to create a posting change delivery and distribute it to the decentralized system. Then, the stock that belongs to this inspection lot is found in the warehouse and the corresponding posting change is made. From this point on, the procedure is the same as that of a posting change (see below). Other goods receipts: All other goods receipts are recorded in the ERP system. When the document is saved, the system creates an inbound delivery and sends it to the WM system using a BAPI. The inbound delivery is then processed in the WM system as described above. When the verification for the inbound delivery is sent to the ERP system, the goods receipt posting is automatically initiated in inventory management. Stock transfers: A stock transfer usually involves two storage locations (plants): the issuing storage location for picking and the receiving storage location for putaway. If the stock transfer is recorded in the ERP system as a two-step procedure and if one of the storage locations involved is a WMS-relevant storage location, the system creates a delivery for this posting and sends it to the WMS. Both storage locations involved are copied into the delivery to allow the actual posting to be executed after the verification is received from the WMS. One-step stock transfers using a WMS-relevant storage location are only possible if a storage location that is not WM-relevant is involved in the posting change. Process for stock transfers: Entering the goods movement in the system Automatically creating the delivery Distributing the delivery from the ERP system to the WM system using BAPI method "InboundDelivery.SaveReplica" (this process is automatically executed in the background) Physically receiving the goods into the warehouse or removing the goods from the warehouse (WMS). Creating the transfer order Putting away or picking the goods Confirming the transfer order Posting goods receipt for the inbound delivery (as a result, a completion verification is sent to the ERP system using BAPI method "InboundDelivery.ConfirmDecentral") or posting goods issue for the outbound delivery (as a result, a completion verification is sent to the ERP system using BAPI method "OutboundDelivery.ConfirmDecentral"). Goods receipt for the inbound delivery or goods issue for the outbound delivery is automatically posted in the ERP system (in inventory management) when the verification is recorded. When the goods receipt or goods issue is posted in the ERP system, the stock transfer is simultaneously posted in inventory management. Goods issues based on sales orders: The system uses sales orders to generate deliveries in the ERP system. The deliveries are then sent to the WMS. You use the WMS to create the transfer order, pick the goods and confirm the transfer order. When goods issue is posted, the picking quantities are passed on to the delivery of the ERP system. Process for goods issues based on deliveries: Creating the sales order Creating the outbound delivery Distributing the delivery to the WMS Creating the transfer order for outbound delivery Physically picking the goods in the warehouse Confirming the transfer order Printing the shipping documents, if appropriate Posting goods issue for the outbound delivery (as a result, a completion verification is sent to the ERP system using BAPI method "OutboundDelivery.ConfirmDecentral") Goods issue for the outbound delivery is automatically posted in the ERP system (in inventory management) when the completion confirmation is recorded. Posting changes You can also initiate transfer postings in the central system, in which case the stock change will be compared with the stock in the decentralized system and adjusted, if necessary. If you use inventory management to make posting changes in the central system, the system first generates a delivery. This delivery is technically a request for the decentralized system to make a transfer posting for the stock involved. The central system does not create material documents or make any changes in stock at this point. The delivery is transmitted to the decentralized system and, as of this point, can only be changed there. You can make settings in the decentralized system so that the system automatically creates a transfer order that corresponds to this delivery that does not require confirmation. You can also set the system to make the appropriate transfer posting in the WM stock automatically at the end of the process. The transfer posting in the decentralized system simultaneously verifies the appropriate quantities to the central system. When the central system receives this verification, it automatically makes the stock change and creates a material document. You can display the material document in the delivery’s document flow. Production supply If the decentralized warehouse is also responsible for production supply, the following two methods of material staging are available in the system: Production staging by switching storage locations Production stock is managed in a storage location that is located somewhere other than in the decentralized warehouse. In this case, the production storage location is not managed in the decentralized warehouse. If you switch the storage location in the central system, the system generates a delivery, for which you can then pick and post goods issue in the decentralized system. At this point, the stock that has been staged using this method can be used in a manufacturing order in the central system. Goods issue posting for a manufacturing order In this scenario, the raw materials are taken directly from the decentralized warehouse’s storage location and used in the manufacturing order. If goods issue is posted for the manufacturing order in the central system, the system creates a delivery that is sent to the decentralized system. The rest of the process is the same as regular goods issue processing. Note the following distinctions with regard to reservations: Delivery does not trigger request generation If the goods issue posting that generates the delivery refers to a reservation, the reservation number is copied into the delivery. In this case, the delivery does not check for availability and no requirements are generated, since that was already done in the manufacturing order. The reservation is canceled when the actual goods issue posting is made. Changes disappear after the delivery is distributed Keep in mind that if the reservation is changed in the meantime (if the production quantity has changed, for example), this change will not affect the delivery. Similarly, a change in the delivery will not result in a change in the reservation. The WM/PP interface, which you can use for production supply in an integrated system, is not supported for decentralized warehouse processing. This function is not available decentrally because the WM/PP interface is based on the assumption that WM and PP are running in the same system, which is not the case in a decentralized system. Goods receipt for a manufacturing order You can process goods receipts from manufacturing orders in the decentralized WM system. For goods receipt postings, the central system first creates an inbound delivery for the manufacturing order and distributes it to the decentralized system. In the decentralized system, the inbound delivery serves as a basis for putaway in WM. You can correct quantity differences here. Once you have confirmed the putaway transfer orders, goods receipt is posted in the decentralized system. The decentralized system then reports the quantity that was posted back to the central system. This verification automatically makes the actual goods receipt posting for the manufacturing order, along with the material document, in the central system.
2) Config we will get from Google also we will get standard idocs for ib and out bound.