× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Follow-Ups:
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.