Framework EDI Reference. SEFManager Utility
.SETS Section

 

Overview

This section of the SEF file describes the implementation guideline of an ASC/X12 Transaction Set or UN/EDIFACT Messages in the EDI document.  The transaction set/message outlines the general format that an EDI document must follow.  It indicates the necessity of data in the document by specifying if the corresponding data segment must or must not exist, should or should not exist, or if the data is dependent on other data in the document.  Furthermore, should the data exist, it must conform to the rules imposed upon its position relative to other data in the document which is indicated by the data segment reference in the transaction set/message -- specifying how each data segment in the document must follow one another.

NOTE: The examples of syntax shown may not be the actual definition, and may have been altered for brevity and emphasis.

An example of an ASC/X12 Transaction Set in the .SETS section looks like the following.

An example of a UN/EDIFACT Message in the .SETS section looks like the following:

 

An example of a .SETS section in a SEF file may look like (UN/EDIFACT example):

.SETS
DOCARE=[UNH,M][BGM,M][RFF,M,2][DTM]{:5[FII,M][RFF,,2][CTA][COM,,5]}{:9[NAD,M][RFF][CTA][COM,,5]}{[AUT][DTM]}[UNT,M]
APERAK=[UNH,M][BGM,M][DTM,,9][FTX,,9][CNT,,9]{:99[DOC][DTM,,99]}{:9[RFF][DTM,,9]}{:9[NAD][CTA,,9][COM,,9]}{:99999[ERC][FTX]{:9[RFF][FTX,,9]}}[UNT,M]
AUTHOR=[UNH,M][BGM,M][DTM][BUS]{:2[RFF][DTM]}{:5[FII][CTA][COM,,5]}{:3[NAD][CTA][COM,,5]}{:9999[LIN,M]{:5[RFF][DTM]}{:9999[SEQ][GIS,M][DTM,,2][MOA][DOC,,5]}{:2[FII][CTA][COM,,5]}{:2[NAD][CTA][COM,,5]}}[CNT,,5]{:5[AUT][DTM]}[UNT,M]
 

Rules

The section conforms to the following rule (NOTE: Quotes around keywords are used for emphasis and for grouping characters of the keyword only, and are not part of the keyword):

General:

  1. The section is started with the ".SETS" keyword on a single line.
  2. Immediately following the ".SETS" line are a series of line.  Each line describes the implementation guideline of the transaction set/message.
  3. A transaction set/message line in the section conform to the following rule.  Using the example "DOCARE=[UNH,M][BGM,M][RFF,M,2][DTM]":
  4. Only one unique transaction set/message identifies entry is accepted.  If the same identifiers occurs in the same section or multiple ".SETS" section across the SEF file, only the last is accepted and the previous are ignored. 

    Example 1:

    .SETS
    DOCARE=[UNH,M][BGM,M][RFF,M,2][DTM]{:5[FII,M][RFF,,2][CTA][COM,,5]}{:9[NAD,M][RFF][CTA][COM,,5]}{[AUT][DTM]}[UNT,M]
    APERAK=[UNH,M][BGM,M][DTM,,9][FTX,,9][CNT,,9]{:99[DOC][DTM,,99]}{:9[RFF][DTM,,9]}{:9[NAD][CTA,,9][COM,,9]}{:99999[ERC][FTX]{:9[RFF][FTX,,9]}}[UNT,M]
    AUTHOR=[UNH,M][BGM,M][DTM][BUS]{:2[RFF][DTM]}{:5[FII][CTA][COM,,5]}{:3[NAD][CTA][COM,,5]}{:9999[LIN,M]{:5[RFF][DTM]}{:9999[SEQ][GIS,M][DTM,,2][MOA][DOC,,5]}{:2[FII][CTA][COM,,5]}{:2[NAD][CTA][COM,,5]}}[CNT,,5]{:5[AUT][DTM]}[UNT,M]
    DOCARE=[UNH,M][BGM,M][RFF,M,2][DTM]

    In the above UN/EDIFACT example, the last message definition "DOCARE=[UNH,M][BGM,M][RFF,M,2][DTM]" is accepted only.

    Example 2:

    .SETS
    DOCARE=[UNH,M][BGM,M][RFF,M,2][DTM]{:5[FII,M][RFF,,2][CTA][COM,,5]}{:9[NAD,M][RFF][CTA][COM,,5]}{[AUT][DTM]}[UNT,M]
    APERAK=[UNH,M][BGM,M][DTM,,9][FTX,,9][CNT,,9]{:99[DOC][DTM,,99]}{:9[RFF][DTM,,9]}{:9[NAD][CTA,,9][COM,,9]}{:99999[ERC][FTX]{:9[RFF][FTX,,9]}}[UNT,M]
    AUTHOR=[UNH,M][BGM,M][DTM][BUS]{:2[RFF][DTM]}{:5[FII][CTA][COM,,5]}{:3[NAD][CTA][COM,,5]}{:9999[LIN,M]{:5[RFF][DTM]}{:9999[SEQ][GIS,M][DTM,,2][MOA][DOC,,5]}{:2[FII][CTA][COM,,5]}{:2[NAD][CTA][COM,,5]}}[CNT,,5]{:5[AUT][DTM]}[UNT,M]

    .SETS
    BAPLTE=[UNH,M][BGM,M][DTM,M][RFF][NAD,,3]{:3[TDT,M][LOC,M][DTM,M,99][RFF][FTX]}{:999[LOC][GID]{:9999[EQD][EQN]}}[UNT,M]
    APERAK=[UNH,M][BGM,M][DTM,,9][FTX,,9][CNT,,9]
    CONAPW=[UNH,M][BGM,M][RFF,M,9][DTM,M,9]{:3[NAD,M]{:2[CTA][COM,,3]}}[LOC,M,99][FTX,M,99][DOC,,9][CNT,,5][AUT][UNT,M]

    In example 2 above, the last occurrence of "APERAK=[UNH,M][BGM,M][DTM,,9][FTX,,9][CNT,,9]" in the second section is accepted.

  5. BNF:

    <SETS_section> ::= <set_section_header> <carriage_return_line_feed> {<set_definitions>}
    <set_section_header> ::= ".SETS"
    <set_definitions> ::= <set_transactionset_message_definition> {<carriage_return_line_feed> <set_transactionset_message_definition>}

Table

  1. The start of a table is denoted by the circumflex character "^".  Only one circumflex MUST exist.  If a string of multiple circumflex ("^^") exists then the entire string is still interpreted as the start of a single table.  This interpretation is reinforced by the rule that a table MUST contain a segment reference and an empty table cannot exist.

    Example:

    In the above example, the message is divided into 3 tables:

  2. BNF:

    <set_table> ::= "^" {"^"}

Segment Reference

  1. Segment.  The unit of information that define a single segment reference contain at least the following properties that are separated by a comma, and are enclosed in brackets ("[" and "]").
    1. Segment Identifier.  Identifies the data segment to use at this position.  The data segment definition MUST be in the data segment dictionary in the .SEGS section of the SEF file.  The data segment defines the format the data in the document has to follow.  Thus the data discovered in the corresponding position of the document must follow the format defined by the data segment.
    2. Requirement.  Required presence of the segment reference within the transaction set/message.  If this property is not specified then the requirement of the segment reference at the specified position is optional.  The following are the requirement designator as defined in the published standard:
      • ASC/X12
        • "M" for mandatory.
        • "O" for optional.
        • "F" for floating.
        • If the requirement has not been specified then the requirement designator defaults to optional "O".
      • UN/EDIFACT
        • "M" for mandatory.
        • "C" for optional.
        • "F" for floating.
        • If the requirement has not been specified then the requirement designator defaults to optional "C".
    3. Maximum Use.  Number of times the presence of the data segment can occur in the same position.
      • This value MUST be 1 or greater than 1.
      • For infinite repetition the Maximum Use is set to ">1".
      • If this property is not specified or is set to zero, then the Maximum Use property defaults to 1.
    4. BNF:

      <set_segreference> ::= "[" <set_segment> ["," [<set_segrequirement>] ["," <set_segmaxuse>] "]"

    Examples.

  2. User Requirement.  For custom requirements that are specific to trading partners, the User Requirement property can be used to specify the required presence of data.  To specify a user requirement, it must conform to the following rules:
    1. The following symbols signify the type of user requirements.  
      2. Symbol Meaning
      . (dot) NOT USED.
      $ RECOMMENDED.
      - NOT RECOMMENDED.
      & DEPENDENT
      ! MUST BE USED

    2. The symbol MUST occur immediately after the opening square bracket.
    3. If no symbol is present then the requirements of the published standard MUST be used.
    4. BNF:

      <user_requirement> ::= "." | "$" | "-" | "&" | "!"

    Examples.

  3. Mask.  The mask specifies an alternate variation of the data segment to reference in the data segment dictionary.  For any one data segment definition in the dictionary, there can be one or more variations of the definition.  The mask specifies which of the variation to use.  If a mask is specified, it conforms to the following rules:
    1. An asterisk (*) followed by a number greater than zero specifies the mask.
    2. The mask immediately follows the segment identifier.
    3. BNF:

      <set_segrefmask> ::= "*" <unsigned_integer>

    Example:

  4. Ordinal Number.  The ordinal number is a unique and permanent number assigned to a segment reference or a loop in the transaction set/message.  The permanence of the ordinal number is imperative because it is with the ordinal number that the segment reference can be referenced by other semantic objects in the SEF file (e.g. text, semantic rules, etc.).  When segment references are added or removed, the ordinal numbers MUST not change.  By default, the ordinal number of a segment reference is determined automatically in sequential order in the transaction set/message.  The sequential assignment is dependent on whether the loop also participates in ordinal assignment which is indicated by the LS flag in the STD section of the SEF file.

    The example below shows an automatic assignment of ordinal numbers when loops do not participate in the ordinal count.

    The example below shows an automatic assignment of ordinal numbers when loops participate in the ordinal count.  In the example below, the loop FII and AUT has been assigned ordinal number 5 and 11.

    If a different ordinal number is specified, it conforms to the following:

    1. An at-sign (@) followed by a number greater than zero specifies the ordinal number.
    2. The ordinal number follows the segment identifier.  If a mask has been specified, it follows the mask number.
    3. If the ordinal number is assigned to a loop, then it occurs before the open brace that indicates the start of a loop.
    4. When a new segment reference is inserted, the next available number in the sequence is assigned to the new segment reference.  In the example below, when a new segment reference CAV is added, the ordinal number assigned is 15 since the highest ordinal number is 14.

    5. When an out-of-sequence ordinal number is encountered, the next segment reference is determined to have an ordinal number in the next sequence, and subsequence segment references' ordinal numbers continue to follow the sequence to the end of the transaction set/message, or until the next out-of-sequence ordinal number is encountered.  In the example below:

      • The ordinal number of [DTM] is 18 after ordinal 17 of [RFF@17,M,2] because it is the next sequence number.
      • The ordinal number of RFF and  CTA after FII@30 are the sequence numbers 31 and 32 respectively.  
      • Finally, segment references AUT, DTM, and UNT have ordinals 9, 10 and 11 respectively - the sequence numbers following ordinal 8 in COM@8.

    6. BNF:

      <set_ordinal> ::= "@" <unsigned_integer>

    Example:

  5. Position Number Increment.  In the EDI standard, the data segments in the transaction set/message have position numbers. The position number increment specifies how much the position number increments, or decrements,  from one segment reference to the next.  By default, the position number increments by 10.  If the increment changes, then it is specified as follows:
    1. A plus sign (+) or a minus (-) followed by a number depending on whether it increments or decrements respectively.
    2. The position number increment occurs before the open bracket of the segment reference.
    3. If the position number increment starts before a loop, it occurs before the brace that indicates a loop.

    Position Numbers:

    1. Loops do not participate in position numbering.  If the LS flag is set in the STD section then the loops participate in position numbering.
    2. Position numbers reset at the start of every table.  If the position number increment occurs at the start of the table then that is the position number of the first segment reference in the table.  If the LS flag is set in the STD section then the position does not reset at the start of every table but continue to increment through table boundaries.
    3. Position numbers are unique within the transaction set/message except when there are alternate definitions of loops and segment references.  The alternate definitions are adjacent to each other.
    4. BNF:

      <set_pos_increment> ::= "+" <unsigned_integer> | "-" <unsigned_integer>

    Example:

     

  6. BNF:

    <set_segreference> ::= [<set_pos_increment>] "[" <set_segment> ["," [<set_segrequirement>] ["," <set_segmaxuse>] "]"
    <set_segment> ::= [<user_requirement>] <segment_id> [<set_segrefmask>] [<set_ordinal>]
    <set_segrefmask> ::= "*" <unsigned_integer>
    <set_ordinal> ::= "@" <unsigned_integer>
    <user_requirement> ::= "." | "$" | "-" | "&" | "!"
    <set_pos_increment> ::= "+" <unsigned_integer> | "-" <unsigned_integer>

Loops or Groups

  1. Loops contain one or more segment references.  Loops can also contain one or more loops that are nested.
  2. Loops begin with an open curly brace "{" and end with the closing curly brace "}".