Re: Translating CSV to Data Structure (or iterating through a data structure)

Mike,

what kind of EDI are talking about, EDIfact, XML or some homebrewed formats
from various customers.

If we are talking EDIfact, there is a lot of formats - take the INVOIC
document,
it can be in the original UN standard, it can be "customized" by a trade
asso-
ciation that again can be customized to special country specific needs and
then
again it can be customized by bilateral agreements.

I do a lot of these projects for customers for inhouse programmers, I do the
technical mapping and we always have som inhouse intermediate files.

Just to be able to spot what is wrong in datastructures like this (it a
invoice
line on 2 shoes in european size 40...

LIN+1++4030226396492:EN'
PIA+5+65012505:SA'
IMD+C+35+WEISS:91'
IMD+C+TPE+65012505'
IMD+S+TPE+010101'
IMD+C+98+40:91'
QTY+47:2:PA'
DTM+35:20110406:102'
MOA+203:400'
PRI+AAA:194'
PRI+AAB:200'
RFF+POR:2541343:4'
RFF+AAK:3943113'
TAX+7+VAT+++:::25'
maybe based on 5000 pages of documentation from varous agencies requires
knowledge few have and just the basic understading and segment sequence
looks like this:

I --- Segment Group 25 ---------------------- LIN --- C9999999 ------+
I LIN  Line item                            M      1                 .
I PIA  Additional product id                C     25                 .
I IMD  Item description                     C     10                 .
I MEA  Measurements                         C      5                 .
I QTY  Quantity                             C      5                 .
I PCD  Percentage details                   C      1                 .
I ALI  Additional information               C      5                 .
I DTM  Date/time/period                     C     35                 .
I GIN  Goods identity number                C   1000                 .
I GIR  Related identification numbers       C   1000                 .
I QVR  Quantity variances                   C      1                 .
I EQD  Equipment details                    C      1                 .
I FTX  Free text                            C      5                 .
                                                                    .
I --- Segment Group 26 ---------------------- MOA --- C      5 -----+.
I MOA  Monetary amount                      M      1                ..
I CUX  Currencies                           C      1 ---------------+.

... aprox 200+ lines

I --- Segment Group 47 ---------------------- RCS --- C    100 -----+.
I RCS  Requirements and conditions          M      1                ..
I RFF  Reference                            C      5                ..
I DTM  Date/time/period                     C      5                ..
I FTX  Free text                            C      5 ---------------++

I UNS  Section control                      M      1
I CNT  Control total                        C     10

My own EDIfact converter has more than 310.000 line of RPG code to cover
and map fields to RPGLE fields for every single segment in the 90.1, 93.A
and 96.A EDIfact standard, so this is not a thing you just do.

And no, I haven't writte all this lines myself, the basic EDIfact
documentation
happens to be delivered in a computer generated txt file so I just created
a program generater that read the documentation and wrote the programs, I
call it "reversed documentation" ;-)



On Wed, May 11, 2011 at 6:30 PM, Mark Murphy/STAR BASE Consulting Inc. <
mmurphy@xxxxxxxxxxxxxxx> wrote:

Since a package like Gentran keeps up with the changing standards (which
are revised on nearly an annual basis), manages communications with various
ISV's and direct communication partners, and provides API's for automation.
 I would suspect that a single developer could likely support no more than a
half dozen active trading partners at a time with a home grown EDI solution.
 Unless of course they are large enough to dictate the specifics of the EDI.
 There is a lot involved, even after the mapping of the data, to get that
data from the staging tables into your database.  Fortunately you should be
able to devise a single set of staging tables for each transaction set that
you are sending or receiving.  Then from there a single standard way to get
the data from the staging tables into your database.  I have used an exit
program scheme to deal with the vagaries of various trading partners.  It
goes something like this:
1. Perform generic mapping of data from staging tables into the database
header format.
2. If specified, call an exit program to make trading partner specific
modifications to the formatted data.
3. Write the record to the database.

I have a single driver program to do all of my generic mapping for a
specific transaction set (e.g. 210 shipping invoices).  Embedded in the
driver program between populating the record and actually doing the write or
update I place a call to a trading partner specific exit retrieved from a
configuration file.  This works for both inbound and outbound EDI.  So I can
now integrate virtually any trading partner with all of their warts and
gimmicks by creating an exit to massage the data before writing it to the
database or staging table (for outbound EDI).  Even adjustments that require
additional segments to be mapped or additional staging tables to be created
can be handled easily as long as the basic looping remains compatible with
the existing map.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx

-----rpg400-l-bounces@xxxxxxxxxxxx wrote: -----
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
From: Nathan Andelin
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Date: 05/11/2011 11:46AM
Subject: Re: Translating CSV to Data Structure (or iterating through a data
    structure)

From: Charles Wilt
Biggest complaint about any of the i EDI products is licensing....
some of the big EDI companies don't tend to be very friendly to the
point of more $$$ to move to a new box than the hardware is going to
cost (look in the archives for rants).

I'm not familiar enough with EDI packages to have an opinion about their
cost,
nor have I followed the rants about that, but the annual cost of an
in-house
developer is often a lot more than the cost of a new Power server. So I
wonder
if this is just a case of the pot on the stove calling the kettle black?
Would
it be more cost effective to develop and support an EDI package in-house?

-Nathan

--

This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
Regards,
Henrik Rützou

 http://powerEXT.com <http://powerext.com/>
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.