That has indeed been my experience with proprietary CSV or fixed format files. But with EDI, you might have trading partners on three or four standards, in fact this might be different versions of X12, or totally different standards, and when they decide to modernize, they move up to the most recent version. And, hey, might as well add a few new pieces of data in the process. Now you have to create a new map for that new standard. If you have custom programs for everyone, you are going to have to modify some of them to understand the new segments that you will be seeing. If you have a commercial mapper, you will likely be able to get away with just creating a new map because they have already created the definitions for the new standard. You just have to load it in.

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: Henrik Rützou
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Date: 05/11/2011 05:33PM
Subject: Re: Translating CSV to Data Structure (or iterating through a data structure)

Mark,

my experience is, that when someone that wants to communicate
electronically in one or another format first has established the format is
will not changed in decades - "If it ain't broke, don't fix it!" - you may
call it

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

Yes there are many standards, and standards within standards.
 International standards, National standards, Industry standards, and for
each standard about as many implementations of that standard as there are
trading partners.  It's funny how the word standard is used to describe
something so non-standard.  That is why a commercial mapping program is
critical, they keep track of the standards when they change, and validate
the transaction sets to make sure they conform to the standard.  Fortunately
within any given industry there are at most a dozen EDI documents that are
in common use.  Still things change, and everyone uses the standards in a
different way, and at times for things they weren't meant to do.  You have
to be able to adapt quickly, and a home grown application will make that
difficult.  Particularly if you don't have any full time staff.

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: Henrik Rützou
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Date: 05/11/2011 03:08PM
Subject: Re: Translating CSV to Data Structure (or iterating through a data
    structure)

Mark,

and here comes the beauty of EDI,

In US you says "210 shipping invoices"

In Europe we says "EDIfact INVOICE" that happens to be a internationalized
standard
under UN

http://www.unece.org/trade/untdid/d99b/trmd/invoic_c.htm





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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.