Warn about re-assigning configuration

[kputnam]

Configuration documentation should be reviewed (and tangentially, an explanation for the difference between a TransactionSetDef and Guide would be useful). It's likely someone may unknowingly do something like this:

x.register("004010", "SM", "204") { FortyTen::TransactionSetDefs::SM204 }
x.register("004010", "SM", "204") { Guides::FortyTen::SM204 }

... which probably has unintended consequences: the first configuration is overwritten. Printing a warning would be appropriate.

[andrewthad]

As someone interested in your tangential comment, what exactly is the motivation behind having TransactionSetDef and Guide. As I am building grammars for the EDI files of vendors we deal with, I keep feeling like there's an odd repetitiveness to the way they're defined. Can I use a TransactionSetDef instead of a Guide. The definitions look shorter, so it seems like it would make building the IB846 parser I'm working on a lot easier.

On another side note, why do we list all the elements when we define a segment and then have to list them all again when we use the segment in a Guide?

[kputnam]

Beware, incoming wall of text. It does seem strange to me too. However, in the official X12 documentation, the thing that corresponds to TransactionSetDef (I think X12 refers to it as the "STANDARD") is kind of a template and a Guide is an instance of it (X12 refers to this as "IMPLEMENTATION", I think).

The TransactionSetDef describes the basic structure of each loop, like which segments can occur, and how many times they can repeat. Each implementation of it might never use certain segments, or further limit the number of repetitions, or make some Situational segments mandatory, etc.

Most importantly, the Guide will spell out the differences between instances of a loop -- like, the TransactionSetDef might allow 10 NM1 loops but the Guide will specify that there are three, and that NM1*XX is for the sender, NM1*YY is for the receiver, and NM1*ZZ is who will pay the bill. The Guide also can indicate which elements are required, and limit which values they are allowed to take, on a per-occurrence basis. For instance NM1 might normally have 8 elements, and the Guide can specify which ones are required or optional in particular locations.

The constraints specified in the Guide make stupidedi more useful, because they add meaning to the document and allow better error checking. For instance find(:NM1, "XX") would still work using only a TransactionSetDef, but stupidedi wouldn't be able to tell you that some find calls would never return results (on any parse tree), etc. Maybe more importantly, the constraints in the Guide can be used to ensure you don't generate an invalid document (if your document is an invoice or claim, sending an invalid one means you don't get paid).

Rant: The weird thing to me is X12's concept of reuse -- even the segments are designed to be "reusable" but sometimes have elements that are completely inappropriate for most situations. These seem to have been added to accommodate an edge case. Sometimes this devolves into generic "free-form text" elements or segments which carry no structure at all. Imagine all kinds of documents use DTM to represent an interval between two dates, but a new use case requires a start date and a duration -- the options seem to be either add new optional element tacked on to DTM or a whole new segment. This also describes TransactionSetDef. For instance there are three kinds of health insurance claims (837P for professional office claims, 837I for institutional/hospital claims, and 837D for dental claims) that are derived from a single 837 template, but I couldn't see any advantage provided by sharing a template when the instances are quite distinct. My guess is this notion of templates is an artifact of something that no longer makes sense, if it ever did, like maybe each pair of trading partners develops their own Guide starting from some common TransactionSetDef customizing it to their requirements.

That leaves the question of why does stupidedi implement TransactionSetDef at all, instead of just using a Guide. Well, the main reason is to be faithful to the official X12 documentation, which was crucial to making sure the library could work in general, beyond the few implementation guides for which I had documentation. In hindsight, it seems most people don't have official documentation and can only infer small parts of it from their trading partner's documentation (probably what amounts to an incomplete Guide).

It's possible to change the way Guides are built so they don't require a TransactionSetDef... it's only used for validating the Guide anyway, and both are translated into grammars. The only difference in their result is Guides provide more constraints. I don't have the time to do this myself, but I would be happy to guide someone in making a pull request.

[rkoloski]

We are in the process of evaluating stupidedi for a healthcare scenario, and our customer's trading partners (their customers) are either familiar with this distinction or the software provider, in order to be consistent with the spec, attempts to explain the implementation process using these concepts. So while looking at the dates on this trail would seem to indicate we're not at risk of you pulling out the ability to make this distinction, I figured I'd at least add a note that it's appreciated, and why we find it relevant, if not in technical terms, in business-y solution architecture terms.