# Typical X12/EDIFACT/SAP IDoc mapping: transportation stages in logistics EDI

(Disclaimer 🙂 I’ve been working with logistics documents (Ocean and Road primarily, plus some Rail and Air) a lot recently, but I see them from the EDI prospective and might not fully understand business behind them. So I probably not always use the right terms, or misunderstand some details. This technical article is more about the structures used to describe transportation stages and related data.)

Another complex EDI case, related to the logistics EDI documents, is how different formats describe transportation stages (legs, conveyances, …). There are 2 main ways of describing transportation legs: stages and stops. For example, we need to move cargo from point A to point D, with points B and C in between.

A -> B -> C -> D

In case of Ocean Logistics it might be:

In case of Motor it might be A as the loading point (warehouse) and B, C and D as Ship To store locations.

So, we could describe this route (A->D) as a set of stops (A, B, C and D) or as a set of legs (stages, conveyances, …) (AB, BC and CD). As we’ll see, different formats use one of these approaches.

Of course, for very simple cases, when we are interested in the first and last points only, we can always use Ship From and Ship To locations (N1 in X12, NAD in EDIFACT and something like E1EDKA1 in SAP Idoc (depends on the document)). It is typical for Orders or ASNs. But when it comes to Logistics, especially complex scenarios (like Ocean) and such things as Booking Request/Response, Shipping Instructions or Load Tender Motor documents, we need to know much more details – locations, requested/estimated/scheduled/actual dates of departure/arrival, carriers and sub-carriers, information about consignments/products loaded/unloaded in different points and so on. And logistic-specific documents contain structures for them.

# Typical X12/EDIFACT/SAP IDoc mapping: ASN (Ship Notice) and Packaging structures

One of the most complex things you can encounter working on the maps is the mapping of hierarchical (nested) packages/products in ASNs (Ship Notices). Things like partners, dates or references usually are straight-forward and in a lot of cases you can use simple direct connections. But different formats use different approaches when it comes to hierarchical (nested) structures.

So, let me show you how X12, EDIFACT and IDocs describe this: one container C1 with 5 pallets, 2 pallets (P1 and P2) are for Product A, 2 pallets (P3 and P4) are for Product B and 1 pallet (P5) is a mixed load with Product A and Product C

C1
P1
Product A, 100 KGM
P2
Product A, 100 KGM
P3
Product B, 90 KGM
P4
Product B, 90 KGM
P5
Product A, 20 KGM
Product C, 90 KGM


# Segments, Records, Elements, Fields and other terms

some people are mixing EDI terms. Remember:

 EDI (X12/EDIFACT) FLAT FILE IDoc XML Segment Record Record Structure/Element Element Field Field Element Sub-Element – – – – – – Attribute

# Variables (and Arrays)

In this lesson we’ll see how to use variables and the difference between variables and arrays.

It’s time to start working with more complex structures which are more similar to the “live” documents. We’ll be using our map “example02” we created on previous step as the base. Let’s change it.

First of all, we need to change the structures of both source and target documents. In the real life documents usually contain three main parts (blocks of data):

• Header. This block usually contains the document number/date, addresses and so on – the common information.
• Details. Usually there some kind of a repeatable data (Line Items and their IDs, names, quantity, price and so on)
• Summary section. This block contains all the total amounts, taxes/fees, total quantities and so forth. This section is very similar to the Header section, but often it is placed at the end of the document to emphasize its “summary” role (like you can see in the paper documents).

# Arrays of data

In this lesson I’ll introduce you a concept of arrays in GXS AI.

Our first map we created on previous lesson is pretty simple. Both source and target have almost the same structure, only one type of records and a few fields. In real life such maps are very seldom. So, we need to gradually work on more and more complicated maps. Let’s get started!

• Create a folder example02 in D:\Trandev\models\
• Copy example01.att, example01S.mdl and example01T.mdl from our previous lesson into this new folder.
• Rename the files to example02.att, example02S.mdl and example02T.mdl respectively.
• Open the content of example02.att in any text editor (such as Notepad) and change it to:
;;                                   example02.att
;;                                    ver 4.0
;;                                --------------
S_ACCESS = "OTFixed.acc"
S_MODEL = "D:\Trandev\models\example02\example02S.mdl"
T_ACCESS = "OTFixed.acc"
T_MODEL = "D:\Trandev\models\example02\example02T.mdl"

Save and close.

# Testing the map

1. Save the map.
2. Select Test->Translate in the top menu.

3. In the opened window enter the following values, clicking “Add” every time you add a new pair:
• Variable Name: S_MODEL, Variable Value: D:\Trandev\models\example01\example01S.mdl
• T_MODEL, D:\Trandev\models\example01\example01T.mdl
• INPUT_FILE D:\Trandev\models\example01\TestData\in.txt
• OUTPUT_FILE D:\Trandev\models\example01\TestData\out.txt