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 logistics EDI documents, is how different formats describe transportation stages (legs, conveyances, …). There are 2 main types 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:

  • A-B, pre-carriage (warehouse to loading port)
  • B-C, main-carriage (loading to unloading ports)
  • C-D, on-carriage (unloading port to delivery destination)

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.
Continue reading

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

        Product A, 100 KGM
        Product A, 100 KGM
        Product B, 90 KGM
        Product B, 90 KGM
        Product A, 20 KGM
        Product C, 90 KGM

Continue reading

New EDI data

One day you might be asked to add some additional data to the existing EDI message. There are several rules I’d recommend:

  • Some BAs think that every new data they add should have ZZ(Z) qualifier (Mutually Defined). The best practice here is to try to find appropriate value first. So, you should have the standard specifications.
  • Don’t use the first value you’ve found – try to check the whole list and find the best value that matches your data. Example: my colleagues were asked to add SSCC-18 number to their ASN (X12). If you’ve worked a lot with ASNs you know that usually companies use SSCC-18 with the Application Identifier (i.e. “00” + SSCC-18). And in ASNs (X12) it’s MAN segment with “GM” (SSCC-18 and Application Identifier) qualifier. But the “AA” (SSCC-18) goes first in the list of qualifiers – so, they decided to use “AA” in spite of the actual value was SSCC-18 + AI (i.e. they should’ve used “GM”).
  • Don’t use a qualifier which looks like one you’re looking for – check its description. REF-01 “SN” looks like it might stand for “Store Number” but actually it’s “Seal Number”.
  • Check the data type/length if it matches your values.
  • Try to avoid “structures in structures”. I.e. try not to use any prefixes, separators and so on inside your EDI data. Example: on one project I had to parse REF*ZZ*NAME1//NAME2//NAME3~ structure – BAs didn’t know how to send several values and decided to use pseudo sub-elements in REF-02. On the other hand sometimes you have no choice.
  • Don’t put dates into REF segments (I saw it several times)

Gennady Kim

EDI (X12/EDIFACT) notation format for segments/elements

I prefer to use the following style/notation for EDI segments/elements:


For example:
REF-01 (X12, Segment name: REF, element position: 1)
RFF-01C02 (EDIFACT, Segment name: RFF, element position: 1, sub-position: 2).

This approach gives me ability to check EDI data easily. I don’t like EDIFACT-style notations like RFF C506 1154 because it requires to use the standard along with the specification/bridge/design.

Gennady Kim

EDIFACT specification

There are some links to the EDIFACT specifications by versions:

… and so on. Or even easier to use a link to the parent directory: http://www.unece.org/trade/untdid/

UPDATE (01 Jun 2015): they’ve changed the structure recently, so now you should use this link (there will be a menu on the left) http://www.unece.org/tradewelcome/un-centre-for-trade-facilitation-and-e-business-uncefact/outputs/standards/unedifact/directories/1995-1999.html

Gennady Kim