Don’t be fooled by someone telling you that there is a model that will work for all companies and all trading partners. There are variations both big and small that make it such that each customer you are setting up requires individualized attention. Let’s dive into the nuances of a new EDI trading partner implementation to uncover some of the differences that may exist that you need to watch out for.

UNITS OF MEASURE

A scenario that is coming up all too often is customers who don’t abide by the ordering unit of measure laid out by the vendor. We all know that large retailers out there will keep things the way they want, and trying to get any changes made in their product catalog is like moving mountains. You may need to have logic in place specific to a trading partner whether in your EDI mapping or ERP system to accommodate for these – otherwise you may ship your customer 100 eaches, when they want 100 cases.

PASS THROUGH DATA

This is information that your trading partner may send on their order and they want back on their order acknowledgement, invoices or ASN. This is information that is really not relevant to you at all, and you may not have a great spot to store in your back end. Things like the Wal-Mart department number for example. You’ll need something in the map or ERP system to get this information back out to your trading partner as they wish. In SAP often a header text is used for this since it doesn’t require customization.

LOCATION INFORMATION

There can be nuances your customers have regarding their location that you don’t want to capture as separate trading partners in your ERP. For example, the same address with “front door” vs. “back door” could be a different DUNS or location code for your trading partner. In SAP, you might not want two ship-to locations set up, so you’ll need something in place to accommodate for these locations and ensure not only that you deliver the product to the right location, but that you send out your invoice and ASN accurately as well.

DISCOUNT AND ALLOWANCE CODES

While there is some standardization in X12 and EDIFACT for discounts and allowances, there is definitely room for interpretation and choice of what code to use. If you are using a standard template that will treat the code the same no matter what partner it comes from, then you are leaving yourself open to errors and issues of recording the wrong type of discount in your system. This needs to be set up specific to a trading partner by matching the code that they are sending, to the code you have in your system while taking into account if it is a gross or net value.

PACKING AND PALLETIZATION

There are many different ASN scenarios you will see in your trading partner requirements. Shipment/Order/Pallet/Item Shipment/Order/Pallet/Tare/Item are a couple examples. Each ASN map needs to be tailored to what your trading partner wants to see. On top of that, you can have 1 partner that wants to see different ASN levels depend on what is ordered, whether it is small parcel or LTL. This means setting up the logic in your mapping to omit certain levels in certain scenarios. This definitely requires individual attention!

IF YOU TREAT THEM ALL THE SAME

If you try to accomplish an EDI customer set up by treating them all the same, you are guaranteed to have problems! There will certainly be a requirement that can’t be handled by a generic set up. You will end-up highly customizing your back end SAP system to accommodate for a generic EDI Mapping leaving you with a lot of maintenance going forward. Consider working with someone like CONTAX who has an in depth understand of what is possible in SAP and how to leverage standard functionality as much as possible, but knows that you need to give individual attention to each trading partner as well in the EDI landscape. To learn more, please reach out to us at info@contax.com and we can arrange a discussion.