in reply to EDIFACT - edi - Validator

I have been watching for EDI-specific modules, and in general, tools like the module you mention are what we find. Tools that work on the segment level. The effort necessary to put together such things on the document level seems to be more than people are willing to do. Having done all that work, you might as well sell it as a translator or syntax-checking tool :). I would think a grammar approach might work, if you have file-based specifications to work from.

Are you wanting to check syntax of documents you're producing?

But God demonstrates His own love toward us, in that while we were yet sinners, Christ died for us. Romans 5:8 (NASB)

Replies are listed 'Best First'.
Re^2: EDIFACT - edi - Validator
by Cow1337killr (Monk) on Aug 13, 2016 at 12:59 UTC
[reply]

      EDI is one of the illustrations of the maxim "the nice thing about standards is there are so many to choose from." Well, almost. There are not that many to choose from. The most popular, ANSI X12 and EDIFACT, were developed by multi-industry committees and it shows it. The standards allow so many options that they might as well not be a standard. But it's kept food on my table since 1991.

      Because very frequently trading partners supply each other with written specifications, I have often thought an automated method to read those files (maybe based on a grammar) would help with developing a practical system to validate a particular document for a particular trading partner, without having to put together the full standard for the hundred of document types, each composed of some subset of thousands of segment types, each of which is composed of a subset of thousands of element types. Because even if the standard says, for instance, a G62 segment is required in a 204 document, a particular trading partner can say it isn't required for them, and the same personalization can happen at the element level. Ranting aside, I should actually try this sometime. The potential time savings could be significant.

      You want to hear something funny? Some people think XML would be preferable.

      But God demonstrates His own love toward us, in that while we were yet sinners, Christ died for us. Romans 5:8 (NASB)
[reply]

        I have been researching EDI on the web.

        What would constitute a proof of concept? That is, without investing a whole bunch of resources to a test, what would the input and the output look like? When I say input, I also mean the reference files or tables that the validator would read as it encountered each data segment and data element in the EDI input file.

        I propose validating a simple purchase order. I further propose that we stick to X12 initially.

        I have seen a validator on the web, so I have an idea what kind of error messages a validator would generate.

        If the proof of concept works, then we can complicate it further.

[reply]
Re^2: EDIFACT - edi - Validator
by tosaiju (Acolyte) on Aug 12, 2016 at 08:52 UTC
    Thanks GotToBTru
    yes, I'm looking at something where we can check edi syntax - e.g. MIN/MAX length, dependent/mandatory segments/qualifier and get specific error messages. There are online tools/editors available; but I wanted something to be automated.
    Thanks for the tips - yeah I think a self dictionary should help as well.
[reply]
      In my limited EDI experience, much like with an XML schema -- I wouldn't trust anything you get to perfectly/fully comply. I like the approach of treating it like an unrestricted DOM and dealing with whatever comes down. People end up sticking weird things into the wrong fields anyway, and business rules will often further restrict things.

      What's your use case?

[reply]

In Section Seekers of Perl Wisdom