SAP EDI Integration Best Practice

Applies to: SAP ECC 6.0, Supply Chain Management and EDI.
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 reprocessing of failed IDocs.
Third party logistics providers offer outsourced services to support supply chain management
and the delivery of shippers 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 clients 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 highquality sweet whey, whey proteins, and lactose products.
The client has 10 manufacturing plants in US and the clients 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. 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 3PLs.
Changes may be quantity, date, address or product.
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

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.

Warehouse Shipping Advice

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.
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
Table
Parameters
REPACKSOURCE_HU
REPACKPACK_QTY
REPACKBASE_UOM
REPACKMATERIAL
REPACK-BATCH
REPACK-PLANT
REPACKSTGE_LOC

<New Handling Unit

Number>

<Existing Handling Unit

Number>
<Picked Qty >
<UOM>
<Material Number>
<Batch Number>
<Plant>
<Storage Location>