"U.S." Layouts

[gslindstrom]

Hello,

I've been following this list for quit a while, now, and am interested
in using Bots in our applications (Novasys Health, Inc. is a third
party processor). The main problem is that we operate in the U.S.
which, for whatever reason, does not use the "standard" layout but the
"implementation" on our manuals.

Please do not scold me for the different layouts. Nobody asked me
about it :-)

Are the U.S. layouts defined? If not, how much work would it be to
get them defined (I would be willing ot work on it, certainly).

Thanks for your time,

Greg Lindstrom
Novasys Health, Inc.
Little Rock, Arkansas

[henk-jan ebbers]

hi Greg,

US x12 transactions are based upon the x12 standard.
(versions 004010 and 005010).
the grammars for these transactions can be downloaded from bots web site.

the 'layouts' are implementation guides, containing specific instructions how a party uses the standards.
(often called MIG: Message Implementation Guide)
MIG are in line with standards - or should be ;-) (do not worry, mostly they are. )
MIG are just smaller: not all records and fields are used etc.

in a typical bots translations you have (for incoming, but outgoing uses the same principles):
- grammar for incoming x12 transactions (as said, grammars can be downloaded)
- mapping script: fetches the data from incoming x12 transaction (this is where the MIG comes into play) and placethis in the outgoing file
- grammars fro the outgoing file; this is what you will import in your application. use the format that is most easy to work with in your system; maybe you have an existing import. This cna be eg csv,
fixed files, xml, etc)

hope this helps,
henk-jan

[jeffk]

This is pretty typical.

As H-J has described, most TPs expect you to conform to their implementation of the X12 document.  Most of the time, in my experience, these docs conform to:
* A subset of the standard both syntactically and semantically OR
* A subset of the standard, syntactically, yet overloaded semantically to better satisfy the needs of the TP's business process.

For instance, I've adapted the X12 855 (Order Confirmation) doc for use as a Credit Request/Response doc type, at the request of one of our credit factor's.  Oftentimes the X12 spec (aka the layout) is ambiguous enough to allow a TP to define a very liberal interpretation of the data element semantics in their implementation spec.

Jeff K