Translation Version 3

Inbound EDI now translates to JSON with version 3, which writes every date and time exactly as sent. Accounts must transition to version 3 by November 27.

Impact: if your account is still on version 2, we have emailed you with what changes in your own documents. Paste one of them into the EDI Translator, which already uses version 3, and compare it with what your system receives today. Then make your code and your inbound mappings accept the new forms below.

Code that accepts both forms needs no coordination with us. If you are ready before November 27, email us and we will move your account sooner. Every other account is already on version 3 and has nothing to do.

What changes, starting with what is most likely to affect your traffic:

Dates and times in a single G62

A date or time in a segment that occurs once, such as a single G62, is now written as the document’s digits. Version 2 reformatted it, while it wrote digits everywhere else, including in a G62 that repeats, so one document could hold both forms.

G62*64*20261026*1*173200

In version 2:

"date_time_G62": {
  "date_qualifier_01": "must_respond_by_64",
  "date_02": "2026-10-26",
  "time_qualifier_03": "must_respond_by_1",
  "time_04": "17:32:0",
  "time_code_05": ""
}

In version 3:

"date_time_G62": {
  "date_qualifier_01": "must_respond_by_64",
  "date_02": "20261026",
  "time_qualifier_03": "must_respond_by_1",
  "time_04": "173200"
}

What to do: parse date_02 as CCYYMMDD, and parse time_04 by its length: HHMM, HHMMSS, or longer for fractions of a second. Code that parses the dashed form will fail on 20261026. If you parse G62s in more than one place, one parser for the digit form now covers all of them.

Times with seconds

A time with seconds is written as sent. Version 2 handled the seconds incorrectly: 123005 became 123050 where it wrote digits, and 12:30:5 in a single G62.

G62*68*20261028*U*123005

In version 2: "time_04": "123050"
In version 3: "time_04": "123005"

What to do: nothing in your parser, since the form does not change. If your code corrected for version 2’s value, remove the correction.

A second G62 in a 204’s heading

A segment the standard allows once, sent twice, is read as a second occurrence. The usual case is a second G62 in a 204’s heading. date_time_G62 holds an array of both in either version, so its shape does not change. The second entry does: version 3 writes it under its real names with its codes’ meanings, and the document no longer carries a rejected-segments warning for it.

G62*64*20261026*1*173200
G62*69*20261027*U*123005

In version 2:

"date_time_G62": [
  {
    "date_qualifier_01": "must_respond_by_64",
    "date_02": "20261026",
    "time_qualifier_03": "must_respond_by_1",
    "time_04": "173200"
  },
  {
    "element_01": "69",
    "element_02": "20261027",
    "element_03": "U",
    "element_04": "123005"
  }
]

In version 3, the second entry:

{
  "date_qualifier_01": "scheduled_pick_up_date_69",
  "date_02": "20261027",
  "time_qualifier_03": "scheduled_pick_up_time_U",
  "time_04": "123005"
}

What to do: wherever your code or inbound mapping reads element_01, element_02 and so on, read the named keys instead, and expect a qualifier with its meaning, scheduled_pick_up_date_69, rather than the bare 69. If you used the rejected-segments warning to spot these documents, it no longer appears for them.

Characters version 2 deleted

Every character is kept. Version 2 deleted some characters outside plain ASCII, such as en dashes and curly quotes.

NTE*GEN*Dock 4 – rear entrance

In version 2: "description_02": "Dock 4 rear entrance"
In version 3: "description_02": "Dock 4 – rear entrance"

What to do: make sure the system that receives the JSON stores and displays these fields as UTF-8. If you compare text values against ones you stored from version 2, expect some to differ.

Outbound writes text exactly as your data gives it, including characters outside ASCII. If a partner accepts only ASCII, transliterate before the outbound mapping.

Empty elements

An empty element is left out wherever it appears. Version 2 wrote some as "". In the single G62 above, version 2 has "time_code_05": "" and version 3 has no time_code_05 key.

What to do: treat a missing key the same as an empty string, and read optional elements with a default rather than assuming the key is there.

Less common changes:

A date or time that is not valid, such as month 13, is kept as sent, and the transaction set carries an invalid_date or invalid_time warning. Version 2 left an invalid date out.
A numeric element whose text is not a number is still left out, and now carries an invalid_number warning.
A number sent with its own decimal point is taken as written: 12.50 in an N2 element is 12.5, where version 2 gave 0.125.

Version 3 also translates documents that version 2 failed:

Control characters as delimiters.
A GS08 that carries an industry identifier, such as 004010VICS.
Files larger than 1MB, up to 16MB, for an account whose limit we have raised on request. The limit is 1MB unless you ask.

Notes and limits:

Outbound is unchanged. Your outbound mappings and the X12 Tediware writes from them do not change.
A mapping source sample made with “From sample EDI” follows your account’s version, so one made before your account moves has version 2’s forms.
The move is one step for the whole account. Partners and flows cannot be moved one at a time.

The full format is described in the JSON format docs, and the warnings in the EDI transactions docs.

This update was written with AI assistance. It has been reviewed and edited by a human.