Support for IN810 Functional Group

[Annihilous]

Several users have requested support for Functional Group 810:

2016 #103
2017 #111
2018 #119

I can't find any documentation for extending support to another functional group, but this commit may encompass what's needed:

1162b44

Open PR (WIP):

https://github.com/irobayna/stupidedi/pull/179/files

[kputnam]

Hi @Annihilous, your PR is welcome! You will have to wait until #164 is merged (likely soon), and then bring your branch up to date, before it can be merged. Please make sure to include some example files.

Once #164 is merged, you can put them in spec/fixtures and specs will be generated at runtime. You can add more specs if you like, following the examples in spec/lib/stupidedi/transaction_sets/005010

[Annihilous]

@kputnam thanks!

Does the commit I reference in the OP contain everything necessary to extend the gem to a new Functional Group?

cc: @irobayna

[kputnam]

Regarding how to create new transaction sets, the commit you referenced is a good example, but here's some more notes. Usually this is what's needed:

1. An implementation TransactionSetDef in implementations.rb
2. A standard version of that TransactionSetDef, if you have the documentation available, in standards.rb
3. Define any missing data elements in element_defs.rb
4. Define any missing segments in segment_defs.rb
5. Place some example files in spec/fixtures

Previously the standard version of the TransactionSetDef was superficially required (bullet point 2 above), but once #164 is merged, it isn't required at all. The "standard" is a more general and less-detailed grammar, it's usually not used in practice, and most people only have documentation for the implementation.

In 1162b44, the TransactionSetDefs that were added are standards, not implementations. They still work for the purposes of parsing or generating X12 files, but they impose fewer restrictions so when generating files there is less error-checking (you could send invalid files), and when reading you could request data that will never exist and not realize it.

Implementations (see examples) will include which values are allowed in each ID element; will indicate that some elements are required, optional, or not used (forbidden); will have more descriptive or specific names for segments; and will have "sibling" loops that are like different versions of the same loop but with a particular purpose (eg, "2000A Sender", "2000B Recipient", "2000C Customer", rather than a generic "2000" loop)

The files I linked to above are in #164, which currently isn't merged. You could create your changes from that branch if you like, or wait until it's merged into master. Also, those files are specific to X12 version 005010, but the process is the same for other versions... unless that version isn't already supported. In that case there will be quite a bit more up-front work, so let us know and we can explain it more.

[Annihilous]

I ended up writing my own parser for invoice support, but here's the stupidedi PR if anyone want's to pick up the work: https://github.com/irobayna/stupidedi/pull/179/files

Closing this issue.