Different Qualifiers in Date/Time/Period (DTM) Segment

In EDI (Electronic Data Interchange), the DTM (Date/Time Reference) segment is used to specify dates, times, or date/time periods relevant to the transaction.

Each DTM segment includes a qualifier that indicates the type of date or time being referenced.

Here’s a list of some common DTM qualifiers used in ANSI X12 and EDIFACT standards, along with their descriptions:

---

Common DTM Qualifiers (X12 Standard)

Qualifier	Description
002	Delivery Requested on This Date
010	Requested Ship Date
011	Shipped
017	Estimated Delivery Date
037	Ship Not Before Date
038	Ship No Later Than Date
050	Received
063	Do Not Deliver Before
064	Do Not Deliver After
066	Requested Pickup Date
067	Actual Pickup Date
097	Transaction Creation Date
150	Service Period Start
151	Service Period End
175	Appointment Date
198	Cycle Start Date
199	Cycle End Date
200	Last Activity Date

---

Common DTM Qualifiers (EDIFACT Standard)

Qualifier	Description
2	Delivery Requested Date/Time
7	Effective Date/Time
10	Shipment Date/Time
35	Delivery Date/Time, Latest
36	Expiry Date/Time
50	Goods Receipt Date/Time
63	Do Not Deliver Before Date
64	Do Not Deliver After Date
203	Start Date/Time
263	Arrival Date/Time
281	Release Date/Time

---

Key Points

1. Structure of DTM Segment in X12:

DTM*Qualifier*Date*Time*Time Code

• Example: DTM*002*20240115 (Requested Delivery Date: January 15, 2024)
1. Structure of DTM Segment in EDIFACT:

DTM+Qualifier:Date:Format

• Example: DTM+2:20240115:102 (Delivery Requested Date: January 15, 2024 in CCYYMMDD format)
2. Format Codes in EDIFACT:
• 102: CCYYMMDD (Year, Month, Day)
• 203: CCYYMMDDHHMM (Year, Month, Day, Hour, Minute)

---

Practical Use in EDI Transactions:

• Purchase Orders (850 / ORDERS): Used to specify requested ship/delivery dates.
• Invoices (810 / INVOIC): Used for invoice creation or due dates.
• Advanced Shipping Notices (856 / DESADV): Includes shipment and estimated delivery dates.

Different Qualifiers in Purchase Order Baseline Item (PO1) Segment

The PO1 (Purchase Order Baseline Item Data) segment in X12 EDI transactions is used to specify details about individual items in a purchase order. 

Each qualifier in the PO1 segment adds context to the item being described, such as product or service identification, pricing, or units.

---

Common Qualifiers in PO1 Segment

PO107 - Product/Service ID Qualifier

This element specifies the type of product or service identifier used in PO108.

Qualifier (PO107)	Description
BP	Buyer’s Part Number
VP	Vendor’s Part Number
UP	UPC (Universal Product Code)
EN	EAN (European Article Number)
MG	Manufacturer's Part Number
PL	Purchaser’s Catalog Number
SK	Stock Keeping Unit (SKU)
PI	Purchaser’s Item Code
PO	Purchase Order Number
ZZ	Mutually Defined

---

PO109 - Product/Service ID

This element contains the actual identifier based on the qualifier in PO107.

For example:

PO1**1*EA*25.00**BP*12345~

Here, 12345 is the Buyer’s Part Number.

---

Other Key Qualifiers in PO1

PO103 - Unit of Measure Code

Code	Description
EA	Each
CA	Case
LB	Pound
KG	Kilogram
DZ	Dozen

PO105 - Basis of Unit Price Code

Code	Description
PE	Price per Each
PP	Price per Pound
PN	Price per Unit

---

PO1 Segment Structure

The structure of the PO1 segment includes:

• PO101: Assigned Identification (line item number).
• PO102: Quantity Ordered.
• PO103: Unit of Measure Code.
• PO104: Unit Price.
• PO105: Basis of Unit Price Code.
• PO106/PO107: Product/Service ID Qualifier.
• PO108/PO109: Product/Service ID.

---

Example PO1 Segment

PO1*001*10*EA*12.50*PE*BP*123456789*VP*987654321~

• PO101: Line item 001.
• PO102: Quantity 10.
• PO103: Unit of measure is "Each" (EA).
• PO104: Unit price is $12.50.
• PO105: Price basis is "Price per Each" (PE).
• PO107: Buyer’s Part Number (BP) with ID 123456789.
• PO108: Vendor’s Part Number (VP) with ID 987654321.

 

Different Versions in EDIFACT Standard

EDIFACT (Electronic Data Interchange for Administration, Commerce, and Transport) is a standardized message format developed by the United Nations. 

Like X12, EDIFACT evolves through versions called directories, each identified by the year and release (e.g., D96A).

---

Structure of EDIFACT Version Names

EDIFACT versions are named using a specific structure:

• Letter: Represents the release within the year (A = 1st release, B = 2nd release).
• Year: Indicates the year of release (e.g., 96 for 1996).

For example:

• D96A: Directory from 1996, first release.
• D21B: Directory from 2021, second release.

---

Commonly Used EDIFACT Versions

Version	Release Year	Description
D93A	1993	Early widely adopted version for trade and logistics.
D96A	1996	Most commonly used; supports extensive trade and commerce scenarios.
D99B	1999	Popular in automotive and manufacturing industries.
D03A	2003	Includes updates for transportation and customs.
D07A	2007	Introduced modernized elements for logistics and retail.
D16A	2016	Updated to support e-commerce and global trade regulations.
D21B	2021	Latest directory with enhanced support for digital transformations and APIs.

---

Key Features of EDIFACT Versions

1. Backwards Compatibility:
• Most versions are backward-compatible with previous directories, allowing gradual adoption.
2. New Messages Added:
• Later versions include messages for modern industries like e-commerce, healthcare, and financial services.
3. Enhanced Segments and Codes:
• Updates in code lists, qualifiers, and data elements to reflect regulatory and technological advancements.
4. Support for Emerging Needs:
• Newer versions cater to cloud integration, real-time data exchange, and global compliance.

---

Frequently Used Directories in Industries

• Automotive: D96A, D99B.
• Retail: D96A, D07A.
• Logistics: D03A, D16A.
• Healthcare: D21B.

Different Versions in X12 Standard

X12 standards have evolved over time with several versions released by the Accredited Standards Committee X12 (ASC X12). Each version introduces new transaction sets, segments, and updates to existing structures to meet industry needs.

---

Commonly Used X12 Versions

Version	Release Year	Description
3010	1980s	Early adoption for EDI standards.
4010	1997	Widely used; supports HIPAA standards for healthcare transactions.
5010	2003	Updated to comply with HIPAA 5010 regulations; widely used in healthcare.
6010	2010	Introduced additional enhancements, including structural changes.
7010	2020s	Latest versions with support for emerging industries and modernized standards.

---

Key Differences Across X12 Versions

1. Introduction of New Transaction Sets:
• New transaction types added to support various industries, such as retail, healthcare, and logistics.
2. Segment and Data Element Changes:
• Additions or modifications in existing segments to meet regulatory or industry-specific requirements.
3. Compliance with Regulations:
• For example, X12 4010 and 5010 introduced changes specifically for HIPAA compliance.
4. Support for Emerging Industries:
• Later versions like 7010 include enhancements for e-commerce, transportation, and cloud-based integrations.

---

Version-Specific Transaction Sets

Each version includes a specific set of transaction sets (e.g., 850, 810, 997), with updates or additions based on the release.

For example:

• 4010: 850 (Purchase Order), 810 (Invoice), 997 (Functional Acknowledgment).
• 5010: Enhanced segments for healthcare transactions like 837 (Claim), 835 (Payment).
• 7010: Expanded for modern industries, with improved JSON and API support.

Different Qualifiers in X12 Reference Identification (REF) Segment

The REF (Reference Identification) segment in X12 EDI transactions is used to specify reference information, such as codes, numbers, or identifiers that provide additional context to a transaction. 

Each qualifier in the REF01 element indicates the type of reference being provided.

---

Common Qualifiers in the REF Segment

Qualifier (REF01)	Description
PO	Purchase Order Number
IA	Internal Vendor Number
DP	Department Number
CR	Customer Reference Number
CO	Customer Order Number
SI	Shipper’s Identifying Number for Shipment
IN	Invoice Number
PK	Packing List Number
BT	Batch Number
IT	Internal Customer Number
QN	Purchase Order Change Number
ZZ	Mutually Defined Reference Identifier
BM	Bill of Lading Number
CN	Carrier’s Reference Number (PRO/Tracking Number)
E9	Department of Transportation (DOT) Hazardous Certificate Number
ST	Store Number
VC	Vendor Contract Number
PG	Product Group
TN	Transaction Reference Number
18	Plan Number
19	Division Identifier
BL	Government Bill of Lading
LU	Location Number
MC	Motor Carrier Number
SC	Shipper’s Car Order Number
AG	Agent's Shipment Number
DO	Delivery Order Number
RZ	Returned Goods Authorization Number

---

REF Segment Structure

The REF segment includes three data elements:

• REF01: Reference Identification Qualifier (e.g., PO, SI).
• REF02: Reference Identification (actual value associated with the qualifier, e.g., 12345 for a Purchase Order Number).
• REF03: Optional Description (additional context for the reference).

Example:

REF*PO*123456789~

REF*BM*PRO123456~

REF*VC*Contract56789~

---

X12 - REF Segment Key Points

1. Context-Sensitive: The meaning of a qualifier depends on the EDI transaction set (e.g., 850, 856, 810). For example:
• PO in an 850 refers to the Purchase Order Number.
• BM in an 856 refers to the Bill of Lading Number.
2. Mandatory or Optional: Some REF segments are mandatory depending on the business use case and EDI standards.
3. Custom Qualifiers: ZZ can be used for mutually defined codes that are agreed upon between trading partners.