Example File Description Documents
The file description documents for the X12 850 Purchase Order and 810 Invoice examples are available from the book's Web site as:
PurchaseOrderX12SourceDescription.xml
InvoiceX12TargetDescription.xml
| Element | Allowable Child Elements | Attribute | Schema Language Data Type | Description | Allowable Values, Restrictions, or Comments |
|---|---|---|---|---|---|
| Grammar | SegmentDescription, GroupDescription | Describes the grammar of both the transaction set and the corresponding XML representation. | The Grammar Element may have any combination of Segment-Description or GroupDescription Elements as children. | ||
| ElementName | NMTOKEN | Specifies the name of the document's root Element. | When creating XML documents, the specified name is assigned to the document's root Element. When creating an X12 interchange, the input XML document's root Element must match this name. Maximum length reflects restriction on the length of Element names. | ||
| TagValue | token | Specifies the segment identifier of the transaction set's beginning segment. | Note: This is the first segment expected in the implementation following the ST segment. | ||
| GroupDescription | SegmentDescription, GroupDescription | Describes a segment group. | One GroupDescription Element is required for each position at which the segment group might appear in the implementation. The first child Element must be a Segment-Description Element. It may be followed by any combination of SegmentDescription or Group Description Elements. | ||
| ElementName | NMTOKEN | Specifies the name of the Element representing the group. | Maximum length reflects restriction on the length of Element names. | ||
| TagValue | token | Specifies the segment identifier of the group's beginning segment. | |||
| SegmentDescription | CompositeStructure-Description, SimpleElement-Description | Describes the grammar of an individual X12 segment and the corresponding XML representation. | One Segment Description Element is required for each position at which the segment might appear in the implementation. One or more Simple ElementDescription or CompositeStructure Description Elements are required to specify the data elements used within the segment. | ||
| ElementName | NMTOKEN | Specifies the name of the Element representing a segment. | Maximum length reflects restriction on the length of Element names. | ||
| TagValue | token | Specifies the value of the segment identifier as specified in the X12 standard. | |||
| CompositeStructure-Description | SimpleElement-Description | Describes the grammar of an X12 composite data structure and the corresponding XML representation. | One CompositeStructure- Description Element is required for each position in a segment where the composite data structure might appear. One or more Simple-Element Description Elements are required to specify the X12 component data elements used within this composite. | ||
| ElementName | NMTOKEN | Specifies the name of the XML Element representing the data element. | Maximum length reflects restriction on the length of Element names. | ||
| FieldNumber | positive-Integer | Specifies the data element position within the segment. | Maximum value reflects restriction on the maximum number of data elements per segment. | ||
| SimpleElement-Description | None | Describes the characteristics of an X12 simple data element and the corresponding XML representation. | One SimpleElement Description Element is required for each position in a segment or composite data structure where the simple data element might appear. | ||
| ElementName | NMTOKEN | Specifies the name of the XML Element representing the data element. | Maximum length reflects restriction on the length of Element names. | ||
| FieldNumber | positive-Integer | Specifies the data element position within the segment. | Maximum value reflects restriction on the maximum number of data elements per segment. | ||
| SubField-Number | positive-Integer | Specifies the component data element position within the composite data structure. | Optional; this Attribute is required only when the data element is part of a composite data structure. It has a default value of zero if missing. Maximum value reflects restriction on the maximum number of component data elements per composite data structure. | ||
| DataType | token | Specifies the X12 data type of the data element. | See Table 9.6. | ||
| MinLength | nonNegative-Integer | Specifies the minimum length for the data element, as specified in the standard or implementation guide. | |||
| MaxLength | positive-Integer | Specifies the maximum length for the data element, as specified in the standard or implementation guide. | |||
| Truncatable | boolean | Indicates whether or not truncation is permitted. See comments regarding truncation in Table 9.6. | Optional, defaults to false. |
| X12 Data Type | Grammar Data Type Code | Schema Language Data Type | Actions with X12 as Source | Actions with X12 as Target | Action with X12 as Target if Truncatable Is True | Comments and Restrictions |
|---|---|---|---|---|---|---|
| Numeric, Nn | X12-Nx, where x represents the number of implied decimal places (corresponds to Nx) | Decimal | Leading zeroes are removed. All whitespace is trimmed. | The number is rightjustified within the field. If the number of fractional digits in the source decimal number exceeds x, the number is right-truncated to x fractional digits. Zeroes are added as fractional digits if the source number has fewer than x fractional digits. Leading zeroes are added if the source is shorter than the target. If a minus sign character is present in the source, it appears in the left-most position in the target. The plus sign is not converted. | Ignored, not truncatable. | |
| Decimal Number, R | X12-R (corresponds to R) | Float or double | Leading zeroes are removed. All whitespace is trimmed. | The number is right-justified within the field. Leading zeroes are added if the source is shorter than the target. If a minus sign character is present in the source, it appears in the left-most position in the target. The plus sign is not converted. | Fractional digits to the right of the decimal point are truncated until the Element contents are equal to the field length. An error occurs if digits to the left of the decimal exceed the field length. | The X12 decimal number data type supports base 10 exponential notation using an uppercase E followed bythe exponent. The schema language float and double data types also allow a lowercase e, which we convert to an uppercase E. The schema language data type allows the special values—0, INF, -INF, and NaN for minus zero, positive infinity, negative infinity, and “not a number,” respectively. These are not converted and force an error if present since there are no equivalent X12 values. |
| Identifier, ID | X12-ID | token, constrained with enumeration facets | Leading and trailing whitespace (any character with an integer value less than or equal to a space character) is trimmed. All other whitespace within the string is preserved. | If the source is shorter than the minimum length, the data is left-justified and filled to the right with spaces. Leading and trailing whitespace is trimmed. If trimming results in a single space character, the data element becomes empty (with exceptions for ISA data elements). | Not truncatable. | Identifier data elements may either have their values enumerated in the standard or reference an external code list. While it is generally the rule that neither leading nor trailing spaces are present, trailing spaces are allowed if required to satisfy minimum length requirements. ID data elements with only spaces are allowed in the ISA segment. |
| String, AN | X12-AN (corresponds to AN) | string | Leading and trailing whitespace (any character with an integer value less than or equal to a space character) is trimmed. All other whitespace within the string is preserved. | If the source is shorter than the minimum length, the data is left-justified and filled to the right with spaces. Leading and trailing whitespace is trimmed. If trimming results in a single space character, the data element becomes empty. | The string is right-truncated to the field length. | X12.6 says that leading spaces are considered significant. However, in more than ten years of working with EDI I've never seen them used. We're going to trim them if we find any.There is another significant difference between the data types. In the X12 there must be at least one nonspace character, while a single space character in XML is schema valid. |
| Date, DT | X12-DT | date | For six-digit dates the prefix 20 is added for hundred years. | The thousand and hundred years are omitted for six-digit dates. | Ignored, not truncatable. | The X12 committee sort of punted when it came to defining dates. Both YYYYMMDD (or CCYYMMDD if you pre -fer) and YYMMDD are supported in the X12.6 definition. However, most date data elements, such as 373 Date, use YYYYMMDD since they have both minimum and maximum lengths of 8. |
| Time, TM | X12-TM | time | Seconds, if absent, are added. Fractional seconds, if specified, are preserved. | N/A | Fractional seconds and seconds are truncated to satisfy maximum length requirements. | |
| Binary, B | Not supported. |
The concepts and appearance are very similar to what we saw in previous chapters, so I'm not inserting the file description documents for the X12 utilities into the book. However, there are a few very important points that need to be made. These particular file description documents reflect usage as defined in an implementation and not the full standard. But, again in keeping with our strategy of using schema validation as the primary mechanism for enforcing business rules, you won't see any mandatory, optional, maximum count, or code list information in these definitions. If you wish to enforce these types of constraints for a particular implementation, you can develop a schema for the XML representation of the transaction set.
This aspect of the file description documents leads to another observation about EDI conversions. The file description documents describe transaction set grammar only to a level sufficient for an XML representation. While these two examples describe only the segments and data elements that appear in these particular implementations, there would be no harm if they described items that aren't used. These unused groups, segments, and data elements in the grammar would simply be ignored during processing. For this reason it would be possible to develop a file description document directly from the standard for a transaction set that covers all possible implementations of the transaction set. So, while we would probably want schemas that validated particular implementations, we could conceivably have only one file description document for each version and release of a transaction set.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.