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

Yes, but you know how they say in England? "Left side is right side, right
side is suicide!"


Thank you


Florin Todor



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Henrik Rützou
Sent: Wednesday, May 11, 2011 4:07 PM
To: RPG programming on the IBM i / System i
Subject: Re: Translating CSV to Data Structure (or iterating through a
datastructure)

Mike

<tongue-in-cheek>Yes, us US people are blind to the rest of the world.
Until we have to work with them...then we swear at them under our
breath for not using US standards.</tongue-in-cheek>

LOL - In spite of everything, you are driving in the right side of the road
;-)

On Wed, May 11, 2011 at 10:01 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Mike

how funny, I have actual been a member of the early advisory and
standardization board under
Danish goverment of this:

http://www.editeur.org/

But anyway, I have no software that supports US standards and as I see

it,

the world is
moving (slowly) into XML and webservices.

And EDIfact or X12 sucks because it is in fact easier to learn to read
chinese than to read
these formats





On Wed, May 11, 2011 at 9:10 PM, Mike Wills <mike@xxxxxxxxxxxx> wrote:

Here is the link on PubNet.
http://www.pubnet.org/scs/13digit/standards.html. This is the type
they work with. First one we are implementing is 850 since this big
company is pushing them the documents now.

--
Mike Wills
http://mikewills.me



On Wed, May 11, 2011 at 1:34 PM, Henrik Rützou <hr@xxxxxxxxxxxx>

wrote:

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/> <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.

--
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/> <http://powerext.com/>

--
Regards,
Henrik Rützou

http://powerEXT.com <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.

--
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.