Format: EDI ANSI ASC X12
- EDI Document Structure
This article provides a description of the EDI ANSI ASC X12 standard. It is primarily intended for beginners who have only started to work with electronic document management in the format of EDI ANSI ASC X12, but may also be of interest to professionals who have work experience in the field.
The article’s body paragraphs delve upon general terminology (interchange, functional group, document), and furthermore provide a detailed description of an EDI document’s core components as well as the relationships between them (segments, elements). This is followed by both an explanation of how these components come together to construct documents and an in depth analysis of their hierarchical structure.
The electronic document management system EDI (Electronic Data Interchange) provides an exchange of structured information between computer systems according to mutually agreed rules.
Initially EDI first saw use in the rail and road freight industry during the mid-60s. It was in 1968 that the United States Transportation Data Coordinating Committee (TDCC) was organized for the purpose of designing a standard electronic document management system for rail and road freight. Following this decision the American National Standards Institute (ANSI) began working to perfect and broaden the standard.
The standard of electronic document exchange ANSI ASC X12 (American National Standards Institute Accredited Standards Committee X12) was developed in the 70s when electronic document size truly mattered (for modems with speeds of 300-1200 bytes per second) and every byte had to efficiently carry large amounts of information. Thus, the “readability” of electronic documents was tossed in favour of “information density”. At the time communications between companies were far from ideal and line breaks as well as data loss were frequent occurrences. As such the format of electronic documents was developed with an intent to preserve integrity of data, for which the mechanisms of “envelopes” and check digits were utilized as evidence of proper data transfer without line breaks or data loss.
The EDI standard can be identified as a ruleset which identifies the structure and format of an EDI document.
There are several organizations currently working on EDI standards.
- ANSI (American National Standards Institute) is an institute which sets the standard for a wide range of activities. EDI is handled by the ANSI X12 Committee, the main body for EDI standards in the United States.
- EDIA (Electronic Data Interchange Association, previously known as Transporting Data Coordinating Committee (TDCC))
- AIAG (Automotive Industry Action Group) provides a group of standards for the automotive industry. This standard is a subset of ANSI X12 standards.
- UCS (Uniform Communications Standard) is a standard used for the grocery industry.
- EDIFACT (Electronic Data Interchange for Administration, Commerce, and Transport) is an organization dedicated to the standardization of EDI at the United Nations Council on Economic and Social Policy. EDIFACT standards, unlike ANSI X12, are used mainly in Europe, while X12 is used in America.
- ODETTE (The Organization for Data Exchange by Tele-Transmission in Europe)
- VICS (The Voluntary Inter-industry Communication Standards) is an organization that is a subgroup of ANSI X12 and deals with standards for the retail industry.
The EDI standard ANSI ASC X12 (hereinafter simply X12) includes a description of document formats (transaction sets) and has different versions (related to the development of standards) – 4030VICS, 5010, etc.
Document (Transaction Set)
The X12 standard operates with the concept of a document, or a transaction set. A document is a set of data that collectively represents complete information useful to the parties involved in business communications.
The Transaction set is in most cases a common document that companies use in their work – for example, Invoice or Purchase Order.
A functional group is a group (set) of documents of the same type (orders, invoices, etc.) that are included in the interchange. The EDI structure will be described later, but for now just note that the start and end of the functional group are defined by the GS/GE segments (GS/GE Envelope). The type of the functional group is determined by the element GS-01 (for example, the PO functional group contains purchase orders, the IN functional group contains invoices). The GS segment is also sometimes used to route documents between departments of the recipient partner.
Interchange is a structured (according to the rules defined by the X12 standard) set of data that is exchanged by partners through (electronic) workflow.
An interchange is more than just a document; rather, it is a batch of document groups (although an interchange can only contain one group with one document).
In what follows, I will use the term “EDI document” when referring to Interchange and simply “document” when referring to a separate document (transaction set) from this Interchange.
It is possible to depict the structure of the Interchange like this (later we will break down the constituent parts and the structure in more detail):
Interchange begins with the ISA segment and ends with the IEA segment (ISA/IEA Envelope). The ISA segment is used, among other things, for routing a document between partners participating in the workflow.
X12 defines each EDI document as a set of segments and elements that define that document, asserts the order of the segments in the document, the order of the elements in the segment, and the relationship between the segments and/or elements.
In X12, each specific document, for example an invoice or purchase order, has a special name – a three digit identifying number. For example, the invoice is 880, PO is 850, ship notice/manifest is 856, etc.
What an EDI document looks like (example):
ISA*00* *00* *ZZ*A1STORES *ZZ*LEXINGTON *020115*0900*U*00400*000000005*0*T*>~ GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~ ST*850*50001~ BEG*00*SA*ASNTESTORD**20060615~ PER*BD*JOHN SMITH~ PER*DC**TE*(123) 456-7890~ FOB*PP~ DTM*002*20060625~ DTM*010*20060618~ N1*ST*A1 STORES*93*0655~ N3*142 WAGON DRIVE~ N4*MIDDLETOWN*AR*72222~ N1*BT*A1 STORES*93*0655~ N3*75 CROSS ROAD~ N4*MIDDLETOWN*AR*72222~ PO1*001*10*EA*15**BP*123456411~ PID*A****ADIDAS BLUE T-SHIRT~ ITA*A***CC***1000~ PO1*002*20*EA*20**BP*123456817~ PID*A****NIKE RED T-SHIRT~ ITA*A***CC***1500~ PO1*003*10*EA*10**BP*123456908~ PID*A****PUMA WHITE T-SHIRT~ ITA*A***CC***1200~ PO1*004*10*EA*15**BP*123456321~ PID*A****REEBOK T-SHIRT~ ITA*C***CB***1400~ PO1*005*10*EA*20**BP*123456287~ PID*A****UMBRO UEFA CUP T-SHIRT~ ITA*A***CC***1600~ PO1*006*20*EA*1**BP*123456413~ PID*A****DEMIX BLUE T-SHIRT~ ITA*A***CC***1800~ CTT*6~ SE*33*50001~ GE*1*5~ IEA*1*000000005~
It should be noted that in this example, line breaks between segments are set on purpose to make it easier to “see” the data structure. In fact, line breaks are not used (or are ignored) in most cases and this EDI document in the original should have looked like this, in the form of a “one line”:
ISA*00* *00* *ZZ*A1STORES *ZZ*LEXINGTON 020115*0900*U*00400*000000005*0*T*>~GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~ST*850*50001~BEG*00*SA*ASNTESTORD**20060615~PER*BD*JOHN SMITH~PER*DC**TE*(123) 456-7890~FOB*PP~DTM*002*20060625~DTM*010*20060618~N1*ST*A1 STORES*93*0655~N3*142 WAGON DRIVE~N4*MIDDLETOWN*AR*72222~N1*BT*A1 STORES*93*0655~N3*75 CROSS ROAD~N4*MIDDLETOWN*AR*72222~PO1*001*10*EA*15**BP*123456411~PID*A****ADIDAS BLUE T-SHIRT~ITA*A***CC***1000~PO1*002*20*EA*20**BP*123456817~PID*A****NIKE RED T-SHIRT~ITA*A***CC***1500~PO1*003*10*EA*10**BP*123456908~PID*A****PUMA WHITE T-SHIRT~ITA*A***CC***1200~PO1*004*10*EA*15**BP*123456321~PID*A****REEBOK T-SHIRT~ITA*C***CB***1400~PO1*005*10*EA*20**BP*123456287~PID*A****UMBRO UEFA CUP T-SHIRT~ITA*A***CC***1600~PO1*006*20*EA*1**BP*123456413~PID*A****DEMIX BLUE T-SHIRT~ITA*A***CC***1800~CTT*6~SE*33*50001~GE*1*5~IEA*1*000000005~
However, in the future, for convenience, I will separate the segments from each other with a line break.
Let’s return to the example EDI document. The second GS segment indicates that this is an EDI document of the X12 (X) standard, version 4010 (004010). From the ST segment, we can say that this is an 850 document, or purchase order. From the rest of the content, you can determine that we are talking about ordering t-shirts from various companies, and find out their price and quantity. Actually reading the documents will be discussed later, but for now you can try to “understand” this example by yourself.
To better visualize the structure of an EDI document, you can draw an analogy between it and ordinary paper documents that are sealed in envelopes.
The topmost envelope (ISA/IEA Envelope) contains one or more envelopes (GS/GE Envelopes), which contain the documents themselves, each in a separate envelope (ST/SE Envelopes).
The ISA/IEA envelope has the addresses of the receiving and sending companies.
The type of documents contained in the GS/GE envelope are “written” on it. Such an envelope contains only documents of one type – orders, invoices, etc. Also on this envelope it can be “written” to which department of the recipient company the final documents were sent.
Finally, the last envelopes contain the final documents themselves – for example, purchase orders number 000000123 and 000000124.
You can depict the structure of an EDI document for clarity as follows:
ISA <<< “topmost” envelope GS <<< "inner" envelope, contains documents of the same type ST <<< envelope with document <document 1> <<< directly the document itself SE ... ST <document X> SE GE ... GS ST <document 1> SE ... ST <document Y> SE GE IEA
ISA*00* *00* *ZZ*A1STORES *ZZ*LEXINGTON *020115*0900*U*00400*000000005*0*T*>~ GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~ ST*850*50001~ BEG*00*SA*ASNTESTORD**20060615~ ... CTT*6~ SE*33*50001~ GE*1*5~ IEA*1*000000005~
A segment is a combination of related elements or composite data that is grouped to provide useful information. For example, a segment can contain information about a product, its color, weight, size, volume, etc. The segment can appear once in the document, or it can occur several times.
In X12, the first place is always a unique segment identifier (tag), consisting (usually) of 2-3 letters/numbers.
A segment consists of an identifier (tag) and elements separated by special characters (element separators) – in our example, this is an asterisk – “*”. Segments end with another character (segment terminator) – in our example, the tilde “~”. It should be noted that the element and segment separators may differ from this example.
The standard specifies the order in which the elements appear in the segment.
The example above shows an X12 segment named PO1 that has a baseline item data value. Let’s examine it in further detail.
First comes the segment identifier (PO1), then the segment elements:
- PO1-01: Assigned identificator (002)
- PO1-02: Quantity ordered (20)
- PO1-03: Unit/Basis measurement code (EA = Each)
- PO1-04: Unit price (20)
- PO1-05: Element is missing (!) (basis unit price code is missing – a code that identifies the type of unit price)
- PO1-06: Product/Service id qualifier (BP = Buyer’s Part Number, type of product/service identifier)
- PO1-07: Product/Service id (123456817)
This segment tells the recipient – “in position 002 in our order, we are requesting 20 units of goods, which in our database is listed under the identifier 123456817, at $20 per unit”.
Optionality of Segments
Segments in a document possess two types of optionality:
M – mandatory segment
Typically, such segments carry the main information in the document (without it, the document or other dependent segments cannot be understood completely and/or correctly). If the standard for a given document defines a segment as mandatory, then it cannot be omitted in the document. Examples of required segments:
This is a (BEG) heading segment (see below under Document structure). It contains general information about the document (how to “read” segments – see below):
- Appointment (00 – original)
- Type (SA – Stand-Alone order)
- Order number (ASNTESTORD)
- Date (20060615 – June 6, 2006)
Without this segment, it would be impossible to identify this order.
This is a (PO1) part segment (see below under Document structure). It contains basic product data. A purchase order (PO) is used to order a product, and the product data is obviously the vital information of this type of document, so this segment is also mandatory.
O – optional segment
Usually these are segments containing secondary/auxiliary information. If the standard defines a segment in a document as optional, then it can be present or absent, and the absence of an optional segment will not be an error. An example of an optional segment:
This (PER) segment is administrative communications contact, i.e. “contact information”. It contains the following information (how to “read” segments – see below):
- Delivery contact (DC)
- Telephone (TE)
- Phone number ((123) 456-7890)
This information is optional, without it this document can still be read – what is ordered, quantity, cost, etc.
Order of Segments
In the document segments follow each other in the order specified by the standard.
Repetition of Segments
As you may have noticed, in the sample document, some of the segments are repeated. Some of them are placed immediately after each other (DTM, PER), some are repeated in groups (PO1/PID/ITA and N1/(N2)/N3/N4). There are two types of segment “repetition”:
In this case, the segment can be repeated several times, but each segment has a different meaning, i.e. carries different information (similar in meaning, but different in content). For example, two DTM segments in the sample document define dates, but the first one (DTM*002*20060625~) defines the delivery date and the second (DTM*010*20060618~) defines the ship date. Likewise with PER segments – each defines contact information, with the first (PER*BD*JOHN SMITH~) defining the name or title of the customer, and the second (PER*DC**TE*(123) 456-7890~) defining the phone number of the delivery issues contact. In a printable document (used by people) it might look like this:
|Sales department: +1 555 765 4321, John Smith
Warehouse: +1 555 321 7654, Silvia Cortes
It should be noted that often the uniqueness of a segment lies in the use of different element values (one or sometimes more) of the identifier. In most cases, a segment has a special element that identifies the content of the segment. In the DTM segment this is, for example, DTM-01, in the PER segment, PER-01.
The standard defines the maximum possible number of such repetitions (max use).
A repeatable group (loop) is a set of connected segments and/or other groups that are repeated in an EDI document in a specific sequence. For example, a segment group N1/N2/N3/N4 represents information about an address, with N1 carrying information about that address, N3 being the address itself, and N4 being a geographic location.
N1*ST*A1 STORES*93*0655~ N3*142 WAGON DRIVE~ N4*MIDDLETOWN*AR*72222~ N1*BT*A1 STORES*93*0655~ N3*75 CROSS ROAD~ N4*MIDDLETOWN*AR*72222~
The PO1/PID/ITA group carries information about the ordered product, its price and quantity (PO1), its description (PID) and discount/markup (ITA).
PO1*001*10*EA*15**BP*123456411~ PID*A****ADIDAS BLUE T-SHIRT~ ITA*A***CC***1000~ PO1*002*20*EA*20**BP*123456817~ PID*A****NIKE RED T-SHIRT~ ITA*A***CC***1500~
Such repeatable groups may in turn include other groups.
X12 defines two types of groups – bounded and unbounded.Fig 5.
These have a start segment that defines the entire group. The rest of the segments are “inside” this group, their optionality is defined as above, however, these “child” segments of the group cannot exist separately from the start segment. In our example, PO1/PID/ITA, the PID and ITA segments cannot appear in the document unless they are preceded by the PO1 segment. There may be a situation where either the PID segment or the ITA segment is absent from the group (since they are optional), but there cannot be a situation when the PID and/or ITA are present but there is no PO1 segment. This is true even if the group itself is optional. The next group is determined by the start segment, for example N1/N2/N3/N4/N1/N2/N3/N4/N1/N2/N3/N4/… (start segment – N1) or PO1/PID/ITA/PO1/PID/ITA/PO1/PID/ITA/PO1/PID/ITA… (starting segment – PO1) – that is, if a starting segment appears in the document, it indicates the next group.
These are very similar to unbounded ones, but they possess a difference – such groups are “wrapped” with special segments – LS (Loop Start) and LE (Loop End). This approach is used by the standard when it may not be possible to determine the beginning and end of a group. In such cases, the beginning and end of the group are determined not by the starting segment itself and the next group, but by the special segments LS and LE, respectively.
As in the previous case, the standard indicates the maximum number of repetitions of groups.
An element of a segment is a “quantum” of information contained in a segment. In the description of the segment above, it is clear how a segment is composed of elements.
It should be noted that an element outside of the segment is meaningless.
Elements in a segment have their own “address” (path), which consists of the name of the segment and the position of the element in the segment. Usually referred to as
<SEGMENT NAME>-<POSITION> or <SEGMENT NAME><POSITION>.
For example, PO1-01 or PO101 for the first (01) element in segment PO1.
The X12 standard defines the data types that an element can contain:
AN – alpha-numeric
A line that can contain letters, numbers, and punctuation marks. This can be an arbitrary line, for example, the name of the product or the name of the street to which the product needs to be delivered, etc. Examples: “3.25% ORGANIC MILK”, “221b, Baker Street”.
For this data type, a restriction on the length of the line is also imposed, for example 1/20 – from 1 to 20 characters, 2/2 – exactly 2 characters, etc.
R – real
A decimal number. This data type is used for information about price, product weight, distance, discount amount, etc. Examples: 1.23; 75.99. Exponential notation has been supported since version 4010.
N[X] – number
A special number format. [X] determines how many characters to the right must be “moved” to put a comma. For example, for data type N2, the value of the element will be 123 to denote the number 1.23, and for 10.5 – 1050 (that is, to get the desired value, we take the value of the element and divide it by 100). N0 corresponds to an integer, that is, its value remains as it is. Very often N2 is used for different amounts, and N0 (integer) for whole quantities (like number of pallets).
ID – code (qualifier)
This data type should be discussed in more detail. The simplest real-life example of codes is units of measurement, such as “MM” (millimeters), “CM” (centimeters), “RUB” (rubles), etc. In X12, all identifiers are collected in logical groups (classifiers), and these groups are assigned unique identifiers – numbers. The classifier consists of several values, and each value has its own unique name (usually 2-3 letters and numbers) and decoding (definition).
Examples of classifiers are units of weight, types of currencies, and country codes.
Consider, for example, classifier (group of identifiers) number 90.
It becomes clear that if the segment element has the type ID from the classifier 90, then we are talking about length measurements. And if the value of this element is, for example, “N”, then the length is determined in inches.
I would like to emphasize that if an element has the ID data type, then its value can only belong to one classifier, defined by the standard for this element in this segment. In other words, there cannot be a situation when an element of type ID can be a unit of mass (for example, classifier 188 Weight Unit Code) and at the same time – a unit of measure for length (for example, classifier 90 Measurement Unit Qualifier).
Also, there is often a special value in the classifier – “Z”, “ZZ” or “ZZZ”, depending on the restrictions on the length of the identifier value. This name has a definition “Mutually Defined”, and is used to designate units that are absent in the standard for this classifier, about which the participants in the workflow agreed in advance. Companies, exchanging documents, when they encounter such an identifier value, in most cases, know what it is about – it could be “(33) hamsters” or “(10) handfuls”.
For this data type, a restriction on the length of the line is also imposed, for example 3/3 – from 3 to 3 characters, or (more simply) 3 characters exactly. This limitation does not come from the standard of the document segment, but from the type of classifier used (if the classifier 90 defines the limitation on the length of the value as 1/1, then the identifier element that uses this classifier will also have a limitation of the length as 1/1).
Usually there is special reference documentation by which you can determine the set of values of a given code or use the value of the element and the classifier number to find the definition of the value.
DT – date
Date. This data type is designed to store a date value and is in the CCYYMMDD format (before version 4010 – YYMMDD). Examples: 20060625 (June 25, 2006).
TM – time
Time. This data type is for storing a time value and is in the HHMM format. Examples: 1259 (12:59). It can also include seconds (optional).
B – binary
Binary data, a sequence of 8-bit bytes.
<composite> – composite element
Composite element. This is an element that contains several values at once, separated by a special character (this character is indicated in the ISA segment, ISA-16 element). Examples: 12345.67>12.55 (in this example, the separator is “>”). The elements that make up a composite element are also called component data elements or sub-elements.
Optionality of Elements
Segment elements have three types of optionality:
M – mandatory element
Usually the required elements are those that carry the basic information of the segment. For example, in the DTM segment (Date/Time Reference, describes the date and/or time), the DTM-01 element (Date/Time Qualifier, the Date and/or time type) is required, since without it we could not exactly determine what data it is. In our example:
The DTM-01 elements have values 002 and 010. The data type is DTM-01 – ID, classifier – 374 (Date/Time Qualifier). Using the reference book, we find the values for 002 and 010:
002 Delivery Requested 010 Ship Requested
So the document states that for the goods described, the requested ship date is June 18, 2006 and the requested delivery date is June 25, 2006.
If DTM-01 were an optional element, and it was absent in both segments, then the recipient of the document would not be able to determine what these dates are.
O – optional element
These elements usually carry secondary information that is not required to understand the information contained in the segment. In our example:
You can notice that between the PO1-04 elements (value 15) and the PO1-06 element (BP value) there is a PO1-05 element which has no value (missing). PO1-05 (Basis Unit Price Code) is an optional item. This element describes the type of price, for example BD (Before Discount) or HF (Per 100 Feet – cable, for example), or HP (Price per Hundred), etc. In this case, we do not need to additionally indicate that the price is per unit of goods; therefore, this element is omitted in the segment.
C – conditional element
A dependent element whose optionality is conditional. In our example:
PO1-06 (Product/Service Id Qualifier) and PO1-07 (Product/Service Id) are examples of similar elements. X12 defines the condition of their optionality as follows:
|P0607 – If either PO1-06 or PO1-07 is present, then the other is required.|
That is, if either PO1-06 or PO1-07 is present in the segment, then the second is required. In this case, it is obvious – if there is a product identifier, then we need to know its type. Conversely, if there is an identifier type, then it would be strange if the identifier itself was missing.
Next, we will briefly discuss the main types of rules and restrictions that the standard imposes on the elements of the segment.
For dependent items in a segment, the standard defines a set of rules/notes. Each rule has a special identifier name. The identifier name is “built” according to special rules – the first letter defines the type of the rule, then there are numbers indicating the position of the segments in the element for which this rule applies. Depending on the type of rule, the positions of the elements also go in a certain order:
C – conditional
Dependence of the optionality of one element (s) on the existence of another (the first in the description):
|C0302 – If PO103 is present, then PO102 is required.C060504 – If PR106 is present, then PR105 and PR104 are required.|
P – paired of multiple
Dependence of the optionality of a group of elements (if at least one of the group is present, then the rest are required):
|P0607 – If either PO106 or PO107 is present, then the other is required.P040506 – If either AT904, AT905 or AT906 are present, then the others are required.|
L – list conditional
Dependence of three or more elements among themselves, when in the case of the existence of the first element in the description, at least one of the others is required:
|L13101112 – If PO413 is present, then at least one of PO410, PO411 or PO412 is required.|
R – required
At least one of the listed elements is obligatory:
|R1012 – At least one of PR110 or PR112 is required.R020607 – At least one of AT302, AT306 or AT307 is required.|
E – exclusion
Only one of the listed elements may be present:
|E0309 – Only one of PSD03 or PSD09 may be present.E020607 – Only one of AT302, AT306 or AT307 may be present.|
The standard may define semantic rules for segment elements. These notes are intended to help you better understand the purpose of the elements. For example, for segment PO1, there is such a semantic note:
|PO106 through PO125 provide for ten different product/service IDs per each item. For example: Case, Color, Drawing No., U.P.C. No., ISBN No., Model No., or SKU.|
Finally, let’s take a look at our PO1 segment as an example, and see how the X12 standard (version 4010) describes its elements:
EDI Document Structure:
As mentioned above, an EDI document can be presented in the form of a document/documents enclosed in envelopes, which have different purposes.
There are three types of envelopes – ISA/IEA Envelopes, GS/GE Envelopes, and ST/SE Envelopes. The initial segments of the envelopes are named Header, and the final segments are named Trailer:
- ISA – Interchange Control Header
- GS – Function Group Header
- ST – Transaction Set Header
- SE – Transaction Set Trailer
- GE – Function Group Trailer
- IEA – Interchange Control Trailer
Let’s take a closer look at these segments.
ISA – interchange control header
A segment that identifies the sender and recipient of the document.
It is important that the elements of this segment have a fixed length, for example ISA-06 has a size of 15/15 and is padded with spaces to the required length, as a result, instead of *A1STORES* we have *A1STORES *. This property is used to define the separator elements that are used in this EDI document. The segment end character is taken from position 106 (~), the separator from position 4 (*). The sub-element separator in the composite element is at position 105 (>).
|ISA*00* *00* *ZZ*A1STORES
IEA – interchange control trailer
The closing interchange segment.
GS – function group header
This segment defines the type of document(s) that are included in this group and contains control information. It can be used to route an EDI document between different systems and/or the addresses of the companies that exchange these documents. Once again – GS/GE segments are an “envelope” for documents of the same type (the type is determined by the GS-01 segment).
GE – function group trailer
This segment defines the end of the data that was started by the GS segment. Several functional groups can be included in an EDI document (interchange) and the GE segment is used to define where the functional group ends.
ST – transaction set header
This segment identifies the type of document and starts a document (for example, an order or invoice). As mentioned at the beginning, in X12 the document type has a three-digit identifier number.
SE – transaction set trailer
This segment defines the end of the document and contains information about the total number of data segments (including ST and SE segments). This number is used to verify the document.
Header, Details, and Summary
Finally, let’s take a look at the document itself (the transaction set). As mentioned above, a document (transaction set) is a set of data that together represents complete information that is valuable to the parties involved in the document exchange. Examples of documents – order, invoice, document with information about discounts, catalog, etc. Each document is enclosed in an ST/SE “envelope”, which indicates the type of document. The document, in turn, is divided into three groups – Header, Details and Summary.
The document header contains general document data – for example, number, contact information, ship/delivery dates, addresses, etc.
In the details of the document, the content of the document is included, for example, for a purchase order – information about the ordered product, quantity, price and discounts for this type of product.
The summary data usually contains summary information – for an order it can be the number of purchased goods, for an invoice – the total cost of the goods, total discounts, etc.