Stedi does not support creating an EDI Implementation guide from an uploaded X12 sample file, however it is on our roadmap to do this.

There is a fast way of doing this, though. Some steps I usually take if I am looking to build a Guide from a sample only:

Create a guide with the right version & txn set Go to EDI Inspector tab, drop in the file Look at the first error, and fix it in the guide builder (edit tab) Fix and repeat until the guide parses the file and returns "valid"

For a simple EDI file, this process takes only 15-20 minutes. More complex ones could take up to an hour. Don't forget to add your qualifier codes for the allowed values!

Also, Stedi will build guides for customers - for free - and add them to the catalog. If you want to request a guide to be built for you, feel free to drop us a note: https://www.stedi.com/products/guides/accelerator

@joe-cerulli There is no max repeat on the x298 in the 2000A loop.

https://www.stedi.com/app/guides/view/hipaa/health-care-claim-professional-x222a2/01GRYB6EJ999Y6MZ53ZBAHYBHE#properties.detail.properties.billing_provider_hierarchical_level_HL_loop

@tbieber Yes. TDS-01 can have a value 0. But you cannot have an empty TDS-01 element.

@ross - this was super helpful. One thing I noticed that you need to do as well is mark the first variant to not be repeated, as otherwise the parser will make only pick up the first key and have multiple objects inside of it.

@divyesh-bhagat-prtnr of course, happy to help!

I did notice that the 943 has a similar segment you can use, but the 940 transaction set definition made it seem like a more appropriate document to use.

Separately, if you want to generate EDI documentation and share that with your partner, Stedi Guides might be a good fit. If interested, we can always hop on a call and help you build your 940/943.

https://www.stedi.com/products/guides

thank you for the additional context, @thomasasmith!

@lamarr-henry ... just found the forum.. did you make any progress? LMK if you still need help

@eliot-slevin I see a variety of delimiters used in practice. > is popular, as is :, ^ and <. Many EDI platforms use : as the default.

The important rule to remember is that the delimiters cannot show up in your textual data. If you know that your text data uses mathematical symbols then > and < is probably not a good choice, and : or \ would be better. But, if you know your text data includes time values in the format HH:MM:SS you may want to avoid :.

Communicate with the business groups owning the data being sent. Clearly communicate the character restrictions and get company buy-in, and agree on substitution characters when a delimiter is found in textual data.

Finally, if you are receiving EDI, be very open to the delimiters you allow. The sending party will understand the data being sent and the restrictions, and they have likely done upfront work to ensure there are no conflicts.

Hi @kasia ,

LS/LE segments are used to help parsers (and humans) differentiate between segments which can appear in multiple places in a transaction set. Sometimes it is possible for the last segment of a loop to have the same segment ID as the segment after the loop ends.

For example, in the 846 in the 004010 release, https://www.stedi.com/edi/x12-004010/846, the detail area 450 sequence is an N1 segment. In the loop prior to the 450 there is an N1 segment at the 410 sequence. If you received EDI with an N1 it may not be clear whether it is the N1 at the 410 or the 450 sequence.

But, if the previous loop (380 sequence in this case) is wrapped in LS and LE segments then we can differentiate the two N1 segments, as there will always be an LE segment between the 410 and 450 N1 segments.

@siddharth-sarda personally I tend to trust the usage notes whenever there's a discrepancy between guide PDF and usage notes.

Usage notes are explicitly provided by a trading partner and are (IMO) more likely to be accurate.

We should not sent an acknowledgement for an acknowledgement One of the two options could be picked
a) Create an 824 (text msg with rejection and request for corrected document)
b) If the exceptions get reviewed by someone (like a support team) someone may need to reach the source of bad acks (acks with invalid control numbers)

@lamarr-henry that is correct! I actually wrote a post on this, which you can view here, under "Element Requirements in X12 EDI"

@joost-agerbeek this is very helpful, thank you for the detailed reply!

@lamarr-henry it looks like there’s a missing piece of information in YRC’s guide. If you look at the X12 spec for the L11 segment, you’ll see that element L11-01 has an additional syntax note:

R0103: At least one of L11-01 or L11-03 is required

So, L11-03 is conditionally required – if L11-01 is not provided, then L11-03 must be provided. If L11-01 is provided, then L11-03 is optional.

Hey Siddarth

It should be written as ".1". As section 3.5.1.2 states [The length of a decimal type data element does not include the optional minus signs, decimal point, or trailing exponent indicator "E".] the length of ".1" is 1. The length of "0.1" is determined as it is given. In this case an EDI element with value "0.1" is 2. Answering this question in two parts:
4.1 According to the spec "0.1" should be written as ".1" in an EDI element unless leading 0s are required to pad the number to meet a minimum length constraint.
4.2 1000 will have length 4 when written as "1000" and length 2 when written as "1E3". It will, "0.1" has length 2 and ".1" has length 1 even though the same numeric quantity is being represented by both.

You can see some of these details discussed in this request for clarification on the x12 website - https://x12.org/resources/requests-for-interpretation/rfi-2596-request-clarification-representation-numeric-types

The short answer

The MTX Text segment allows you to send messages of up to 4096 characters long, which is the longest available in X12. You can’t just swap out an MSG segment for an MTX segment, though. You can only use MTX if it’s included in the transaction set, and that depends on which X12 'release' (version) you're using.

For the 005010 release (one of the more popular ones), here are the transaction sets that MTX appears in:

105 Business Entity Filings 113 Election Campaign and Lobbyist Reporting 150 Tax Rate Notification 155 Business Credit Report 179 Environmental Compliance Reporting 194 Grant or Assistance Application 251 Pricing Support 274 Healthcare Provider Information 284 Commercial Vehicle Safety Reports 500 Medical Event Reporting 620 Excavation Communication 625 Well Information 650 Maintenance Service Order 805 Contract Pricing Proposal 806 Project Schedule Reporting 814 General Request, Response or Confirmation 832 Price/Sales Catalog 836 Procurement Notices 840 Request for Quotation 843 Response to Request for Quotation 850 Purchase Order 855 Purchase Order Acknowledgment 860 Purchase Order Change Request - Buyer Initiated 865 Purchase Order Change Acknowledgment/Request - Seller Initiated Some additional clarification Technically, character limits don't apply to X12 segments – what you're referring to is an X12 element. A segment is just a container for elements, and the element you're referring to is the element referenced in MSG01 (the first element of the MSG segment). Each X12 element references an ID number. For each element, the ID number points to a dictionary that specifies the name, description, type, minimum length, and maximum length. In the case of MSG01, it points to data element [933][1]. Data element 933 – the one you're currently using – actually has a character limit of 264 characters (more than 256 characters, but not by much). Note: the link above is to the 005010 X12 release, but I checked backed to 003010 and up to 008030 and it seems to be 264 characters all the way through.

Now, back to your original question: is there a data element that allows for a larger character payload?

The answer is that there are 8 data elements that accept a payload larger than 264 characters.

Two of them are binary data types, which we can likely eliminate off the bat:

785. Binary Data. A string of octets which can assume any binary pattern from hexadecimal 00 to FF. Note: The maximum length is dependent upon the maximum data value that can be entered in DE 784, which value is 999,999,999,999,999. Max characters: 999999999999999. 1700. Transformed Data. Binary or filtered data having one or more security policy options applied; transformed data may represent compressed, encrypted, or compressed and encrypted plaintext. Max characters: 10000000000000000.

The rest are strings, which is promising:

364. Communication Number. Complete communications number including country or area code when applicable. Max characters: 2048. 1565. Look-up Value. Value used to identify a certificate containing a public key. Max characters: 4096. 1566. Keying Material. Additional material required for decrypting the one-time key. Max characters: 512. 1567. One-time Encryption Key. Hexadecimally filtered encrypted one-time key. Max characters: 512. 1573. Encoded Security Value. Encoded representation of the Security Value specified by the Security Value Qualifier. Max characters: 1.00E+16.

And, last but not least:

1551. Textual Data. To transmit large volumes of message text. Max characters: 4096.

Looks like a winner!

Note that element 1551 appears in only one segment: MTX, which was introduced in the 003060 X12 release. And in the initial 003060 release, it was only included in one X12 Transaction Set: 194 Grant or Assistance Application (which makes sense – a longer field was needed for grant applications).

It seems that as new releases were developed, the MTX segment made its way into more and more transaction sets – likely for exactly the reason you're asking. In 003070, it was included in 5 transaction sets; in 004010, 15; in 005010, 24, and so on.

The MTX segment uses element 1551 in both MTX02 and MTX03, so you can get double the length by using both of them. Note that there's a 'relational condition': If MTX-03 is present, then MTX-02 is required (in other words, you can't use MTX03 if you don't use MTX02 first).

And depending on the transaction set, the MTX segment may be able to be repeated as well.

Long story short: if the MTX segment is in the transaction set / release you're using, you're likely in luck.

Hope this helps.