3PL Integration through EDI

community.sap.com/t5/sap-for-travel-and-transportation-blogs/3pl-integration-through-edi/ba-p/13224197

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

Summary
The objective of this article is to provide a detailed overview of the EDI interfaces required
to collaborate effectively with third party logistics providers. This article also describes the
technical approach for typical business 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) transactions for 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 the automated re-processing of
failed IDocs.

Author(s): Prakash K Bodicherla & Anthony Chesnick

Company: Deloitte Consulting LLP

Created 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 Deloitte’s Retail and Distribution practice

1/8
Overview

The objective of this article is to provide a detailed overview of the EDI interfaces required
to collaborate effectively with third party logistics providers. This article also describes the
technical approach for typical business 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) transactions for 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 the automated re-processing of
failed IDocs.

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

Background
Our client is a world leader in premium quality cheese manufacturing and the largest U.S.
exporter of whey products. The client’s mozzarella cheese, cheese blends, and pizza
cheese are made especially for pizzeria and food service operators, frozen food
manufacturers and private label cheese packagers. Our premium mozzarella cheese is
the uniform source of our high-quality sweet whey, whey proteins, and lactose products.

The client has 10 manufacturing plants in US and the client’s whey protein business is
30% of their business. Whey is the by-product from the cheese manufacturing process
and is used for nutritional supplements and ingredients. Whey customers include baby
formula manufacturers, Nestle, Bristol Meyers, and M&M Mars.

As a part of 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 their customers and vendors.

Business Requirements
1. 3PL Shipments to customers and Internal plants

2/8
 2. 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 advance notification.

3. Any changes in the warehouse shipping order have to be communicated to 3PL’s.

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

5. Final confirmation for the warehouse shipping order will be communicated to 3PL
from the delivery document. If the delivery document is deleted after the
confirmation to 3PL then the shipping order has to 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 Pick quantity, 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 and packing 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

3/8
EDI 940 – Warehouse Shipping Order
To allow the 3PL to begin advance planned activities for labor and space utilization, the
warehouse shipping order will be generated from the sales order. The 3PL will ensure the
sales order will not be shipped from warehouse until a final delivery confirmation status is
sent. If any changes take place in the sales order, the changes will be re-communicated
to the 3PL via a change delivery notification. Once the delivery is created then an EDI
940 document will be triggered to confirm the status with the 3PL. Whenever a sales
order, STO or delivery document is created, changed or deleted, a corresponding IDoc
must be generated.

There was no standard IDoc type or process code to support the business requirements
as defined. Using standard SAP IDocs would have resulted in creating multiple EDI
mapping documents with a large volume of unwanted data for the 3PL thereby increasing
the overall VAN transaction costs Additionally, maintaining multiple mapping documents in
the EDI middleware would not have been a cost-effective solution.

The proposed solution is to have a custom IDoc type with all the required fields for the
Sales order, STO, Delivery and Shipment documents. A custom process code was
developed to build the logic based on the output type and actions
(Create/Change/Delete).

When a sales order is created, the plant can be changed based on 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 customer
requirement. 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. The confirmed status will signal the 3PL to
ship the goods.

Plant number is changed from manufacturing plant to 3PL, and then the IDoc is
generated for the 3PL plant. This is the first IDoc sent to the 3PL.

Plant number is changed from 3PL to manufacturing plant, then a cancellation IDoc is
generated to the 3PL.

Plant number is changed from one 3PL to another 3PL, then a cancellation IDoc is
generated for the old 3PL and a new IDoc is triggered for the new 3PL.

When the delivery document is deleted then the output has to be triggered to the
corresponding STO or sales document. Custom logic is needed in program MV50AFZ1 at
‘USEREXIT_DELETE_DOCUMENT’ to trigger output for the preceding document. The
3PL will again start the advanced planning to allocate the resources for the confirmed
shipment document.

EDI 945 - Warehouse Shipping Advice

4/8
IDOC_INPUT_DELVRY is the standard SAP function module for processing EDI 945
transactions. Based on the client and/or 3PL requirements, if minor customization is
required then the approach should be to leverage existing user-exits and/or enhancement
spots. If more complex customization is required then the approach should be to copy the
standard function module to a custom function module and enhance as per the
requirement.

The following items are the major custom requirements to consider for processing EDI
945 transactions.

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

Before comparing the quantities check that the batch UOM and Delivery UOM are
the same, if not then 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 be processed manually. If the quantity is less than delivery quantity
then follow the partial pallet process as defined below.

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

Update the delivery with the new batch numbers for the applicable line items and
pass the 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 has split the handling unit while shipping to the
customer.

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 the ‘HEADERPROPOSAL-PACK_MAT’. It will return the new handling
unit number which has generated internally with sequence. Use Commit work after
the BAPI and capture the new handling unit number.

5/8
Now we have to unpack the existing handling unit and repack with the new handling
unit by adjusting the quantities. Use FM 'BAPI_HU_REPACK’ (Tcode: HU02) to do
the process in standard way. Pass the parameters as defined below.

Import Parameters

HUKEY <New Handling Unit Number>

Table Parameters

REPACK-SOURCE_HU <Existing Handling Unit Number>

REPACK-PACK_QTY <Picked Qty >

REPACK-BASE_UOM <UOM>

REPACK-MATERIAL <Material Number>

REPACK-BATCH <Batch Number>

REPACK-PLANT <Plant>

REPACK-STGE_LOC <Storage Location>

If the BAPI was successful, then use execute the commit work command because
the unpack/repack process is completed. Now we have to execute last step below
to perform the goods movement for the new handling unit and to change the
receiving batch.

In the partial pallet process, the new batch will always be created with a restricted
status as per the configuration requirements. Once the batch is
generated, 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 FM
‘VB_CHANGE_BATCH_STATUS’.

6/8
 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 <Material Number>

IT_MOVE_TO-CHARG <New Created HU number>

IT_MOVE_TO-WERKS <Plant>

IT_MOVE_TO-LGORT <Storage Location>

IT_MOVE_TO-HU_ITEMS-VENUM <VEPO-VENUM>

IT_MOVE_TO-HU_ITEMS-VEPOS <VEPO-VEPOS>

IT_INTERNAL_ID-VENUM <VEPO-VENUM>

IDoc Re-Processing
For the four processes defined below there is a potential for the IDoc to fail at any point in
the process. When the failed IDocs are re-processed we only want to re-process from the
point of failure. Any prior steps that were completed successfully should not be re-
processed. Therefore, to properly manage the IDoc re-processing a custom table was
developed to record the results of each process step and to document the corresponding
transactional information created, such as handling unit number, status change and
goods movement. The custom table may also contain key fields such as IDoc number,
delivery number, material number and batch number.

When posting the IDoc for partial pallet processing the individual process triggers are
defined as below.

1. Handling Unit Creation

2. Repacking of Handling units

3. Handling unit status change

4. Goods Movement

If the above four steps are completed successfully then we can assume that the partial
pallet processing has completed successfully for a given line item in the IDoc. We then
need to update the custom table with the completion indictor. If the pick/pack/PGI process

7/8
failed, we can retrieve the partial pallet handling unit from the custom table. The custom
table has to be updated before the IDoc is set to status 51 (Error while posting the
document). A more meaningful error message is provided in the long text of the IDoc.

If the 3PL sends an invalid batch number then the IDoc should raise an error. This is true
for even legacy batch numbers (this may occur first few months of
Go-Live). To avoid errors with legacy batch numbers a cross-reference table must be
established to cross-reference the legacy batch numbers with new SAP
batch number.

Conclusion
After reading this article, you should have a better understanding of SAP to 3PL
integration and the technical design 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
client’s specific needs. Lastly, the level of customization may be influenced by the overall
process design and 3PL system integration requirements.

Related Content

For more information, visit the Supply Chain Management Homepage

8/8