EDIFACT i XML część 1: Architektura, składnia i kanoniczny model danych XML

Przez dziesięciolecia standard UN/EDIFACT (United Nations / Electronic Data Interchange for Administration, Commerce and Transport) stanowił fundament globalnego handlu i cyfryzacji łańcuchów dostaw. W dobie nowoczesnych chmurowych systemów ERP, interfejsów REST API oraz platform zakupowych (SAP Ariba, Coupa, Peppol) dominującym językiem wewnętrznym stał się jednak format XML (Extensible Markup Language). W naszej czteroczęściowej serii przedstawiamy pełny obraz inżynierii konwersji EDIFACT → XML: od fundamentów parsowania składniowego po precyzyjne mapowanie zamówień (ORDERS), awiz wysyłki (DESADV) i faktur (INVOIC).

W części 1 skupiamy się na podstawach architektury: jak przekształcić płaski, rozdzielany znakami strumień EDIFACT w ustrukturyzowane, hierarchiczne drzewo XML DOM, jak radzić sobie ze znakami ucieczki i tabelami UNA oraz jak projektować kanoniczny model danych XML.

Różnice strukturalne: Płaskie segmenty vs. Hierarchiczne drzewa XML

Filozofia projektowa standardów EDIFACT i XML diametralnie się różni. Podczas gdy EDIFACT zoptymalizowano w latach 80. pod kątem wąskich pasm transmisji (minimalna liczba bajtów, stałe pozycje, separatory), XML jest w pełni czytelną, opisaną znacznikami strukturą obiektową:

Proces parsowania: Od ciągu UNA do drzewa AST

Translatory EDIFACT → XML (zarówno systemy middleware, jak Altova MapForce, Apache Camel, Smooks, jak i dedykowane konwertery) realizują parsowanie w trzech etapach:

1. Odczyt separatorów (Segment UNA): Jeśli na początku pliku występuje opcjonalny ciąg serwisowy UNA:+.? ', parser dynamicznie konfiguruje aktywne znaki podziału:
   • Separator elementów składowych (domyślnie: dwukropek :)
   • Separator elementów danych (domyślnie: plus +)
   • Znak kropki dziesiętnej (domyślnie: kropka .)
   • Znak ucieczki / zwolnienia (domyślnie: znak zapytania ?)
   • Terminator segmentu (domyślnie: apostrof ')
2. Obsługa znaków ucieczki: Gdy dane biznesowe zawierają znak separatora (np. nazwa firmy: "Schmidt?+Co"), translator musi rozpoznać sekwencję ?+ i wygenerować w XML poprawny znak bez podziału pola (encjowany jako &).
3. Rozpoznawanie pętli (Segment Groups): EDIFACT nie posiada znaczników zamykających. Koniec grupy pozycji (np. pętli LIN) następuje domyślnie po pojawieniu się kolejnego segmentu LIN lub segmentu podsumowania (UNS+S'). Parser musi zarządzać maszyną stanów, aby prawidłowo zamknąć węzły XML.

Modele kanoniczne XML: Generyczny vs. Semantyczny XML

W procesie konwersji stosuje się dwa podejścia architektoniczne:

1. Generyczny EDIFACT-XML (Niskopoziomowe drzewo AST)

Odwzorowuje strukturę 1:1, zamieniając każdy segment i kompozyt na odpowiadający tag XML, bez interpretacji biznesowej:

<?xml version="1.0" encoding="UTF-8"?>
<Interchange xmlns="http://edifact.hu/schema/canonical/d96a">
    <UNB>
        <S001><e0001>UNOC</e0001><e0002>3</e0002></S001>
        <S002><e0004>5991234567890</e0004><e0007>14</e0007></S002>
        <S003><e0010>5999876543210</e0010><e0007>14</e0007></S003>
        <S004><e0017>261021</e0017><e0019>1030</e0019></S004>
        <e0020>000842</e0020>
    </UNB>
    <Message>
        <UNH>
            <e0062>1</e0062>
            <S009><e0065>ORDERS</e0065><e0052>D</e0052><e0054>96A</e0054><e0051>UN</e0051></S009>
        </UNH>
        <BGM>
            <C002><e1001>220</e1001></C002>
            <e1004>PO-2026-9912</e1004>
            <e1225>9</e1225>
        </BGM>
    </Message>
</Interchange>

2. Semantyczny Kanoniczny XML (Business Canonical XML)

W środowiskach integracyjnych drzewo techniczne jest przekształcane w kanoniczny format biznesowy, w którym kody i kwalifikatory zastępowane są czytelnymi polami:

<?xml version="1.0" encoding="UTF-8"?>
<PurchaseOrder xmlns="http://edifact.hu/schema/b2b/order/v1">
    <OrderHeader>
        <OrderNumber>PO-2026-9912</OrderNumber>
        <OrderDate>2026-10-21</OrderDate>
        <MessageType>ORDERS_D96A</MessageType>
        <Buyer>
            <GLN>5991234567890</GLN>
            <Name>Pannon Trading Sp. z o.o.</Name>
        </Buyer>
        <Supplier>
            <GLN>5999876543210</GLN>
            <Name>Fabryka Części Maszyn Sp. z o.o.</Name>
        </Supplier>
    </OrderHeader>
</PurchaseOrder>

Częste pułapki składniowe przy konwersji EDIFACT do XML

• Brak encjowania znaków specjalnych XML: Znak & (np. w nazwie kontrahenta) lub < nieprzekształcony do & powoduje błąd składniowy (not well-formed XML) i uniemożliwia przetworzenie dokumentu.
• Konwersja formatów dat (Kwalifikatory DTM): Kod 102 oznacza datę RRRRMMDD, a kod 203 zawiera godzinę i minutę (RRRRMMDDGGMM). Standardy XML wymagają formatu ISO 8601 (2026-10-21), co wymaga bezwzględnej normalizacji w procesie mapowania.
• Uszkodzony separator kończący segment: Brakujący apostrof ' sprawia, że prosty parser potraktuje kolejny segment jako treść bieżącego elementu, niszcząc strukturę całego pliku.
• Kolejność segmentów i reguły XSD: Standard EDIFACT ściśle definiuje kolejność segmentów. Schematy XSD z dyrektywą <xs:sequence> odrzucą dokument, jeśli generator XML pomyli kolejność znaczników.

Plan całej serii

W kolejnych częściach cyklu omówimy procesy konwersji kluczowych komunikatów biznesowych:

• Część 2: Zamówienia: transformacja EDIFACT ORDERS do formatów SAP Ariba cXML oraz Peppol BIS Order 3.0 UBL.
• Część 3: Logistyka wysyłkowa: odwzorowanie awiza DESADV (hierarchia opakowań CPS, kody SSCC) w UBL Despatch Advice oraz WMS XML.
• Część 4: Finanse i fakturowanie: konwersja EDIFACT INVOIC do formatów Peppol Billing 3.0 oraz węgierskiego NAV Online Számla 3.0 XML.

Chcesz zintegrować komunikaty EDIFACT z nowoczesnymi aplikacjami chmurowymi XML lub API? Przetestuj swoje pliki w naszym walidatorze lub skonsultuj się z naszym zespołem integracyjnym!