This project has moved and is read-only. For the latest updates, please go here.

Context Errors (CTX segments) when generating 999

Dec 6, 2013 at 3:31 PM
Are there any example specifications that include context for situational segments such that the AcknowledgmentService will produce CTX segments in a 999 when doing validation?

I'm trying to make modifications to the 270 specification to be a bit more explicit about which segments are situational and which are required so that I can output a more useful 999. Explicitly stating this property on each segment in the xml file seems to work okay, but I don't see how I can get it to generate context errors if particular situational fields are missing when they should be there.

I'll contribute back my modified spec once I'm satisfied with it. Thanks for any help.
Dec 5, 2014 at 6:12 PM
Edited Dec 5, 2014 at 6:15 PM
I was looking for 999 creation details...

See if this helps you out:$File/EDI_5010_Understanding_999.pdf

oops - sorry, I just saw the date of your question...sorry if this is late and useless

A question though; what would be the point of you modifying the 270 spec, unless you're submitting that to
Dec 5, 2014 at 8:26 PM
I think you're misunderstanding my question. I'm not talking about changing the official specification for X12, I'm talking about changing how it is implemented in the X12 Parser. That is, I was wondering if there was any way to mark segments as situationally required when defining the 270 format in X12parser.
Jan 22, 2015 at 10:23 PM
Justin, did you ever figure out your problem?

I think I'm in the same boat... too many IK3 errors in creating the 999, saying segments are missing when, in reality, they are optional.
Jan 27, 2015 at 1:16 AM

I do not believe this exists in the implementation. You really have 2 choices as far as I am concerned.

1) Modify the parser to read some your own properties from the XML elements. Depending on complexity of your requirements (do the values come into play or just the fact it is not empty or not existing ect.) it could be from simple to implement or a nightmare.

2) Modify the code that generates the 999 and either replace or supplement the code that is looping through the spec. The down side to this option is could still use a file or something to read from at runtime but at that point you might as well have went with option 1 and possibly have improved the code for all of us =)
Jan 27, 2015 at 1:24 AM

As JustinTConroy stated in his post required fields can be defined in the xml spec for your document.

Here is the 850 spec unmodified as used in this project

You will see segments that exist in the 850 laid out like this:

<Segment SegmentId="BEG" Usage="Required" Repeat="1" />

You should see that Usage="Required" next to the ones you are having problems with. If you remove that the issue should clear up.

The question then becomes should you really be missing that much initially required data? Unless somebody on your team modified those files and added a ton of usage=required flags for you, I would suspect you are either not getting valid EDI or you are passing in a bad object to the acknowledgement service.
Jan 27, 2015 at 6:27 PM
For some reason the version of the program I have (I just downloaded the latest version last week) makes the assumption that EVERYTHING is required UNLESS you say include Usage="Situational" in the optional Loops and Segments.

Once I did that, then everything worked okay.
Jan 27, 2015 at 6:42 PM
The reason it made the assumption that everything was required was because of the way the Enumerations.cs was laid out:
[XmlType(AnonymousType = true)]
public enum UsageEnum
    [XmlEnum("Not Used")]
It had Required listed first and so it was the default if not referenced specifically.

So, alternately, the other option (preferred) is to put Situational first and then mark the Loops/Segments that are needed as Usage="Required".