DOC-31471

Generated by Jive on 2015-04-17+02:001

3PL Integration through EDI

Applies to: SAP ECC 6.0, Supply Chain Management and EDI.

SummaryThe objective of this article is to provide a detailed overview of the EDI interfaces required to collaborateeffectively with third party logistics providers. This article also describes the technical approach for typicalbusiness requirements. The reader will gain a better understanding of the EDI processes needed toimplement EDI 940 (Warehouse shipping order) and EDI 945 (Warehouse Shipping Advice) transactionsfor the Advanced Planning, Picking, Packing/Unpacking, Shipment Confirmation/PGI processes. Moreover,this document covers the use of Handling Unit management (HU) as a part of the overall process and theautomated re-processing of failed IDocs. Author(s): Prakash K Bodicherla & Anthony ChesnickCompany: Deloitte Consulting LLPCreated on: 10 September 2012

Prakash Bodicherla is specialist in SAP EDI processing and mapping the IDocs with all set of EDI transactions.Exceptional knowledge in ABAP and Sales & Distribution practice.



Anthony Chesnick - Specialist Leader in Deloittes Retail and Distribution practice specializing inSAP ERP Supply Chain

transformation projects with a focus on Order Fulfillment, Distribution, Warehousing, Transportation andMaterials Management.

OverviewThe objective of this article is to provide a detailed overview of the EDI interfaces required to collaborateeffectively with third party logistics providers. This article also describes the technical approach for typicalbusiness requirements. The reader will gain a better understanding of the EDI processes needed to

implement EDI 940 (Warehouse shipping order) and EDI 945 (Warehouse Shipping Advice) transactionsfor the Advanced Planning, Picking, Packing/Unpacking, Shipment Confirmation/PGI processes. Moreover,this document covers the use of Handling Unit management (HU) as a part of the overall process and theautomated re-processing of failed IDocs.

Third party logistics providers offer outsourced services to support supply chain managementand the delivery of shippers products to customers in an on-demand fashion with real-timeinformation. Standardized electronic data information exchange (EDI) will increase the efficiency for businesspartners. Moreover, it significantly reduces manual intervention, paper work and improves cycle time andbetter supports a high volume transaction environment. It provides direct electronic communication betweenshipper and 3PL computer systems using national and international telecommunication networks and requiresagreements between trading partners. The communication is typically done through a VAN (Value AddedNetwork) using international EDI standards such as the American National Standard Institution (ANSI) or EDIfor Administration, Commerce and Transport (EDIFACT).

BackgroundOur client is a world leader in premium quality cheese manufacturing and the largest U.S.exporter of whey products. The clients mozzarella cheese, cheese blends, and pizza cheese are



made especially for pizzeria and food service operators, frozen food manufacturers and privatelabel cheese packagers. Our premium mozzarella cheese is the uniform source of our high-qualitysweet whey, whey proteins, and lactose products. The client has 10 manufacturing plants in USand the clients whey protein business is 30% of their business. Whey is the by-product from thecheese manufacturing process and is used for nutritional supplements and ingredients. Wheycustomers include baby formula manufacturers, Nestle, Bristol Meyers, and M&M Mars. As a partof the Strategic Systems Initiative project, the client decided to implement SAP ERP using the Deloitte Food& Beverage template solution. EDI plays a key role for the client in transmitting business information to theircustomers and vendors.

Business Requirements

1. 3PL Shipments to customers and Internal plants2. 3PL has to be notified in advance about the warehouse shipping order (EDI 940) to perform the resource

planning. Warehouse shipping order can be generated either from sales order or STO for advancenotification.

3. Any changes in the warehouse shipping order have to be communicated to 3PLs. Changesmay be quantity, date, address or product.

4. If warehouse shipping order has changed the plant values then communication has to be sent to bothparties.

5. Final confirmation for the warehouse shipping order will be communicated to 3PL from the deliverydocument. If the delivery document is deleted after the confirmation to 3PL then the shipping order hasto be sent from sales order/STO with change status.

6. Warehouse shipping advice (EDI 945) sent by 3PL has to be update the delivery document with Pickquantity, Packing/Unpacking the Handling unit and Post Goods Issue.

7. EDI 945 may contain partial pallet, where the original handling unit has to undergo unpacking andpacking with the quantity sent by the 3PL.

8. Automated reprocess for the failed IDocs to execute the only from the position where it has failed.



Proposed Solution

EDI 940 Warehouse Shipping Order To allow the 3PL to begin advance planned activities for labor and space utilization, the warehouse shippingorder will be generated from the sales order. The 3PL will ensure the sales order will not be shipped fromwarehouse until a final delivery confirmation status is sent. If any changes take place in the sales order, thechanges will be re-communicated to the 3PL via a change delivery notification. Once the delivery is createdthen an EDI 940 document will be triggered to confirm the status with the 3PL. Whenever a sales order, STOor delivery document is created, changed or deleted, a corresponding IDoc must be generated. There wasno standard IDoc type or process code to support the business requirements as defined. Using standard SAPIDocs would have resulted in creating multiple EDI mapping documents with a large volume of unwanteddata for the 3PL thereby increasing the overall VAN transaction costs Additionally, maintaining multiplemapping documents in the EDI middleware would not have been a cost-effective solution. The proposedsolution is to have a custom IDoc type with all the required fields for the Sales order, STO, Delivery andShipment documents. A custom process code was developed to build the logic based on the output type andactions (Create/Change/Delete). When a sales order is created, the plant can be changed basedon the customer requirements (geographic location, stock availability, customer preference).Based on the three variables as defined below, the EDI output is triggered to fulfill the customerrequirement. Custom logic is needed in program MV45AFZZ at USEREXIT_SAVE_DOCUMENT.Whenever the 940 is triggered from the sales order then the status to the 3PL will always be new/



change. Only the document triggered from the delivery should go with a confirmed status. Theconfirmed status will signal the 3PL to ship the goods. Plant number is changed from manufacturingplant to 3PL, and then the IDoc is generated for the 3PL plant. This is the first IDoc sent to the 3PL. Plantnumber is changed from 3PL to manufacturing plant, then a cancellation IDoc is generated to the 3PL. Plantnumber is changed from one 3PL to another 3PL, then a cancellation IDoc is generated for the old 3PL and anew IDoc is triggered for the new 3PL. When the delivery document is deleted then the output hasto be triggered to the corresponding STO or sales document. Custom logic is needed in programMV50AFZ1 at USEREXIT_DELETE_DOCUMENT to trigger output for the preceding document. The3PL will again start the advanced planning to allocate the resources for the confirmed shipmentdocument.

EDI 945 - Warehouse Shipping Advice IDOC_INPUT_DELVRY is the standard SAP function module for processing EDI 945 transactions. Basedon the client and/or 3PL requirements, if minor customization is required then the approach should be toleverage existing user-exits and/or enhancement spots. If more complex customization is required then theapproach should be to copy the standard function module to a custom function module and enhance as perthe requirement. The following items are the major custom requirements to consider for processing EDI 945transactions.

Check if the line item quantity is equal to the handling unit quantity in SAP. Handling unit is nothingbut a Batch number which exists in the IDoc. Retrieve the Handling unit quantity from VEKP andVEPO tables using the batch number.

Before comparing the quantities check that the batch UOM and Delivery UOM are the same, if notthen convert the delivery UOM to batch UOM and decide whether its partial pallet or not.

If the EDI quantity is greater than the delivery quantity then the IDoc will throw an error and it must beprocessed manually. If the quantity is less than delivery quantity then follow the partial pallet processas defined below.

Add the new handling unit number created from partial pallet process or from the IDoc into theinternal table IT_HANDLING_UNITS_1.

Update the delivery with the new batch numbers for the applicable line items and passthe Handling unit number internal table to WS_DELIVERY_UPDATE_2 which will do Pick,Pack and PGI.

Partial Pallet Processing

If the EDI line item quantity doesn't match with the Handling Unit line item quantity then the 3PL hassplit the handling unit while shipping to thecustomer.

Retrieve the Handling unit details from VEKP and VEPO tables. Create a Handling Unit with reference to the packaging material of the existing handling

unit number using the FM BAPI_HU_CREATE. Pass the Packaging Material in theHEADERPROPOSAL-PACK_MAT. It will return the new handling unit number which hasgenerated internally with sequence. Use Commit work after the BAPI and capture thenew handling unit number.



Now we have to unpack the existing handling unit and repack with the new handling unitby adjusting the quantities. Use FM 'BAPI_HU_REPACK (Tcode: HU02) to do the process instandard way. Pass the parameters as defined below.

Import Parameters

HUKEY

Table Parameters

REPACK-SOURCE_HU

REPACK-PACK_QTY REPACK-BASE_UOM

REPACK-MATERIAL

REPACK-BATCH

REPACK-PLANT

REPACK-STGE_LOC

If the BAPI was successful, then use execute the commit work command because the unpack/repackprocess is completed. Now we have to execute last step below to perform the goods movement forthe new handling unit and to change the receiving batch.In the partial pallet process, the new batchwill always be created with a restricted status as per the configuration requirements. Once the batchisgenerated, the batch status is change to unrestricted as per the parent batch characteristics.

Check the both Parent and Child Batch statuses are the same. If yes, then don't change the status. If the Statuses are different and the parent has an unrestricted status, then change the child batch

status to unrestricted using the FMVB_CHANGE_BATCH_STATUS.

For goods movement transfer use FM HU_CREATE_GOODS_MOVEMENT (Tcode: VLMOVE)passing the following parameters.

Import Parameters

IF_TCODE VLMOVE

IT_MOVE_TO-HUWBEVENT 0010

IT_MOVE_TO-MATNR

IT_MOVE_TO-CHARG

IT_MOVE_TO-WERKS

IT_MOVE_TO-LGORT

IT_MOVE_TO-HU_ITEMS-VENUM

IT_MOVE_TO-HU_ITEMS-VEPOS

IT_INTERNAL_ID-VENUM



IDoc Re-ProcessingFor the four processes defined below there is a potential for the IDoc to fail at any point in the process. Whenthe failed IDocs are re-processed we only want to re-process from the point of failure. Any prior steps that werecompleted successfully should not be re-processed. Therefore, to properly manage the IDoc re-processing acustom table was developed to record the results of each process step and to document the correspondingtransactional information created, such as handling unit number, status change and goods movement. Thecustom table may also contain key fields such as IDoc number, delivery number, material number and batchnumber. When posting the IDoc for partial pallet processing the individual process triggers are defined asbelow.

1. Handling Unit Creation2. Repacking of Handling units3. Handling unit status change4. Goods Movement

If the above four steps are completed successfully then we can assume that the partial pallet processing hascompleted successfully for a given line item in the IDoc. We then need to update the custom table with thecompletion indictor. If the pick/pack/PGI process failed, we can retrieve the partial pallet handling unit fromthe custom table. The custom table has to be updated before the IDoc is set to status 51 (Error while postingthe document). A more meaningful error message is provided in the long text of the IDoc. If the 3PL sends aninvalid batch number then the IDoc should raise an error. This is true for even legacy batch numbers (this mayoccur first few months ofGo-Live). To avoid errors with legacy batch numbers a cross-reference table must be established to cross-reference the legacy batch numbers with new SAPbatch number.

ConclusionAfter reading this article, you should have a better understanding of SAP to 3PL integration and the technicaldesign across the areas as highlighted below:

Mapping of EDI 940 and EDI 945 transactions Developing the logic to trigger the EDI 940 document from a Sales Order, STO and delivery Defining the data requirements needed for 3PL integration Managing the output determination Understanding the requirements for batch split and partial pallet process Understanding the requirements and logic for re-processing of failed IDocs

In general, standard SAP IDoc structures and programming will cover most client requirements.Also remember that mapping documents will change based on each clients specific needs.Lastly, the level of customization may be influenced by the overall process design and 3PLsystem integration requirements.

Related ContentFor more information, visit the Supply Chain Management Homepage

Documents

DOC-31471