EligibilIty 271

[scriptsure]

What is the best way to put together the segments and elements file for an edifact 271 message. How do I get the info to create the files for parser. All the docs I have don't really present it like the parser requires it

[tdecaluwe]

The 271 message is an X12 standard, not EDIFACT. To answer your question however, the parser doesn't need a segment table file. This is used for validation only.

[scriptsure]

Docs on it are really not explaining how the segment and element files are used or setup. Is there something more comprehensive. Sorry I meant to write x12 not edifact.

[RovoMe]

IMO the segments and elements entries are rather self-explanatory. Basically they just map the data outlined in the Edifact spec, ie. such as the BGM segment segment. The segments entry for BGM will define the respective element part, such as C002 or C106 which are further defined in the elements array, which defines what data type and length the respective components have. Note, however, that the definition seems to use the most common definitions of the segments, probably a separation into own specs, such as EANCOM D96A or D01B or the like would be beneficial as there might be slight differences between the respective specs. #4 further suggests to refactor these two array definitions to JSON files, which would further simplify that separation into respective Edifact versions and the like, at least on a typescript port I'm currently working on, this seems to work quite well, though I'm quite new to the whole JavaScript/TypeScript ecosystem.

I am more surprised however, that the node-edifact library does not help to build a tree-like structure of the Edifact interchange parsed at all. While the Tracker class makes use of a message structure table (i.e. INVOIC) to validate whether mandatory segments are missing or whether the maximum repetition count is exceeded, there is no support yet available to help on generating an interchange object that allows to list the number of messages contained in that particular exchange and further drill down to the message internals, such as line items or MOAs for these line items to simplify further validation calculation on the processed interchange/messages. While I saw a PR for adding envelop support, I'm not yet sure if this is what I actually need.