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



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

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.