Typical X12/EDIFACT/SAP IDoc mapping: scheduled line items in Purchase Orders

A short explanation on how companies describe/schedule multiple deliveries in their Purchase Orders in different EDI formats. For example, a company wants to purchase 200 kilograms of product ABC, but they want it to be delivered within several days, like 50 kilogram on 06 Oct 2020, 50 kilogram on 08 Oct 2020, 40 kilogram on 10 Oct 2020 and 60 kilogram on 12 Oct 2020.

Order #0000001
Product ABC123 - 200 KG
    2020-10-06: 50 KGM
    2020-10-08: 50 KGM
    2020-10-10: 40 KGM
    2020-10-12: 60 KGM

X12 850
X12 uses SCH loop for this purpose. SCH-01 is the quantity, SCH-02 is the unit of measurement, SHC-05 is the date qualifier (usually 002 – Delivery Requested) and SCH-06 is the requested delivery date.

    SCH*50*KG***002*20201006'     << 002 Delivery Requested

EDIFACT usually uses SCC group with 4017 element of “1” (Firm) + QTY (11, Split quantity) and DTM (2, Delivery date/time, requested)

    QTY+21:200:KGM'     << 21 Ordered quantity
    SCC+1'     << 1 Firm
        QTY+11:50:KGM'          << 11 Split quantity
        DTM+2:20201006:102'     << 2 Delivery date/time, requested

IDoc uses E1EDP20 segments with WMENG for quantity and EDATU for requested delivery date.


      <E1EDP20 SEGMENT="1">
      <E1EDP20 SEGMENT="1">
      <E1EDP20 SEGMENT="1">
      <E1EDP20 SEGMENT="1">

      <E1EDP19 SEGMENT="1">

Gennady Kim

Typical X12/EDIFACT/SAP IDoc mapping: relationship between different O2C business concepts and SAP IDoc/X12/EDIFACT structures

In the following table I’ve tried to connect typical business concepts used in order to cash (O2C) process and EDI documents’ groups/loop, segments/records and elements/fields.
I used structures from SAP IDoc of ORDERS05, INVOIC02 and DELVRY03 (but it could be applied to other DELVRY* and SHPMNT* messages); X12 of 850 (Purchase Order), 810 (Invoice) and 856 (Advanced Ship Notice); EDIFACT – segments used everywhere (ORDERS, INVOIC and DESADV in particular)

This table is based on my experience and your implementation might be different. Please also take into account that different formats might use different codelists so you cannot map codes as is – you’ll need a code conversion.

Continue reading

Typical X12/EDIFACT/SAP IDoc mapping: a batch split

Today I want to explain how batch split works in SAP IDocs. For some reasons many developers have difficulty with this so I hope they would find this helpful.

What is the batch? Imagine a bakery which makes bread. Bread is the product. Batch is the bread of the same type made at one baking, i.e. a specific instance of this product. Batch has the same manufacturing/expiration dates, (usually) the same taste and other characteristics. So, the bakery makes the same bread 5 days a week and every baking produces a new batch – 5 different batches during a work week.

What is the batch split? In SAP IDoc it is a situation when the product contains one or more batches (specific instances) and the IDoc contains information about both product and its batches. It is where people are usually confused because IDoc uses the same records for both product (material) and its batch(es).

For example, in DELVRY SAP IDoc products/batches are described with E1EDL24. When there is no batch split, there will be one E1EDL24 per product:

    POSNR = 000010
    MATNR = 123456
    ARKTX = Wholewheat Bread
    LFIMG = 125.00
    VRKME = EA

A straight-forward situation – 125 loafs of Wholewheat Bread have been shipped. But it becomes different (and a bit tricky) when such IDoc contains information not only about the product, but also about its batches. If these 125 loafs are actually 100 loafs baked yesterday and 25 baked today, it will be something like this:

E1EDL24  <<< this is the product
    POSNR = 000010
    MATNR = 123456
    ARKTX = Wholewheat Bread
    LFIMG = 0.00    <<< its quantity is zero (!!)
    VRKME = EA
E1EDL24  <<< this is the 1st batch
    POSNR = 900001
    MATNR = 123456
    ARKTX = Wholewheat Bread
    LFIMG = 100.00    <<< its quantity is 100
    VRKME = EA
    HIPOS = 000010    <<< link to the "parent" product
    CHARG = ABC1234    <<< Batch ID
    VFDAT = 20200315    <<< Expiration Date
E1EDL24  <<< this is the 2nd batch
    POSNR = 900002
    MATNR = 123456
    ARKTX = Wholewheat Bread
    LFIMG = 25.00    <<< its quantity is 25
    VRKME = EA
    HIPOS = 000010    <<< link to the "parent" product
    CHARG = ABC1235    <<< Batch ID
    VFDAT = 20200316    <<< Expiration Date

So you could see the difference – now there is one E1EDL24 with zero quantity and no HIPOS, and 2 E1EDL24s with HIPOS which is the same as POSNR of the “parent” product. Usually there are 2 indicators of a batch split situation – (1) when some E1EDL24s have POSNRs which start with “9” and (2) when some E1EDL24s contain HIPOS elements. If you see such E1EDL24s – they are batches. I personally check the presence of HIPOS to understand if this is a batch and LFIMG of zero to understand it is the main product.

CHARG is the batch number, unique ID assigned to this particular batch.

I think it is obvious you cannot treat E1EDL24s equally when there is a batch split situation. Your implementation will depend on the requirements. If the trading partner isn’t interested in batches – you should use the main item only (“E1EDL24 with no HIPOS”) and use LFIMG of this item (if not zero) or the sum of LFIMGs of its batches (E1EDL24s where HIPOS is equal to the POSNR of this item). If they need batches – use batches (“E1EDL24 with HIPOS”) for items.

Also, there could be some mixed situations – when SAP IDoc might contain both products with and without batches. Or when the trading partner wants to have only one product but list all the batch numbers under it. And so on – but I hope it is clear now how to process such things.

Gennady Kim

Typical X12/EDIFACT/SAP IDoc mapping: Allowances/Charges

Allowances/Charges are typical information you can find in Invoices. Usually allowance is a discount/credit provided by seller. Charge – amount buyer should pay in addition to money paid for goods/services (such as freight cost, late payment fees and others). There could be multiple Allowances/Charges per invoice, they could be applied to different levels (products or total amount). There are several ways to describe allowances/charges in EDI – as a percent from the total amount (for example, 5%), as a fixed sum (for example $120) or as an amount per unit (for example $0.10 per kilogram). In EDI data the following segments/records are used for Allowances/Charges: SAC (Service, Promotion, Allowance, or Charge Information) in X12, ALC (Allowance or charge) + MOA (Monetary amount) + PCD (Percentage details) in EDIFACT and E1EDK05 (Document header conditions)/E1EDP05 (Document Item Conditions) in IDoc (INVOIC02).

Sometimes terms “surcharge”, “discount”, “adjustment”, “A/C” and other might be used instead.


SAC*C*D240***5935**********VAL FR CHARGE~





Continue reading

Typical X12/EDIFACT/SAP IDoc mapping: Hazardous Materials / Dangerous Goods

Recently I’ve been working with different logistic documents (SAP IDoc/X12/EDIFACT and CIDX/ChemXML) which contain information about Hazardous Materials/Dangerous Goods. I used a lot of sources to find information about the data and its usage, and want to share my humble knowledge here.

As always, it is just an idea, and your implementation might be different. But in the most cases the core logic will follow this idea. Mention should be made that HazMat data is very important and you must understand what you are doing. If you have any concerns, or not sure you understand it completely – you must contact subject matter experts (SMEs). This article is more about “HazMat data from EDI point of view” rather than ready-to-use implementation guide.
Continue reading

Typical X12/EDIFACT/SAP IDoc mapping: Purchase Order

Here is a typical mapping between Purchase Order business documents in different formats – X12 850, EDIFACT ORDERS and SAP IDoc ORDERS05.

As always, it is just an idea, and you implementation might be different. But in the most cases the core logic will follow this idea.

Please also use this to find more detailed information about typical mapping for References, Dates, Partners, FreeText and other.

Continue reading

Typical X12/EDIFACT/SAP IDoc mapping: Demand Forecast

Today I want to show how different EDI documents are used for transferring forecast information between organizations.

Demand Forecast documents are widely used between manufacturers and their suppliers. For example, a company which produces DVDs with movies needs to be supplied with a certain amount of blank DVD discs. Demand for these blanks varies depending on different parameters, such as new movies releases, holidays (like Christmas) and so on. So, to be sure their trading partner(s) which produces blank DVDs is aware of this demand, they are sending demand forecast documents on a regular basis.

Usually manufacturer knows exactly how many blanks they need today, tomorrow, this and next week, but might be not that sure about next month or next quarter. But they could forecast these amounts.

Another example is “Delivery Just In Time” process (also known JIT manufacturing/production), used (for example) in automotive industry. To reduce inventory costs, manufacturer requests its supplier to deliver a certain amount of parts/raw materials needed this particular day. So, they only have enough inventory for one day production (for example). I hope it is clear that this requires a very accurate demand forecast process.
Continue reading

Business Analysis in B2B/EDI: 2.5.3. Paths

In my spare time I’m working on a huge document/book “Business Analysis in B2B/EDI”, decided to share a small part…

  • 2.5.3. Paths
  • In the structures of different complexity, it is necessary to be able to indicate the exact path to the record/segment and/or field/element. For example, in X12 there might be DTM segments at different levels, and just “DTM” won’t be enough to understand which one is needed in many cases. So, you should know how to provide the right paths. And, different formats use different approaches.

    Since records/segments are named entities, their names are a good starting point to use. But while records in SAP IDoc are unique (i.e. you cannot have 2 records with the same name at the different levels) and you can use the name to identify its exact position, the other formats can use the same records/segments at different levels.
    Continue reading

    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:

    • 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