Free EDI

Free EDI

Post by Joseph H All » Thu, 20 Feb 1997 04:00:00



It's time to start "Free EDI".  EDI (Electronic Data Interchange) is an old
set of document standards designed to allow businesses to communicate with
each other.  Typical of the business transactions covered by EDI are
wholesaler to retailer communications: the retailer sends a PO (Purchase
Order) to the wholesaler, which then sends the ordered materials to the
retailer.  Then the wholesaler sends an Invoice to the retailer.

There are two big problems with EDI as it currently stands.  First, the
standards process is membership based and copies of the standards themselves
cost lots of money.  This results in EDI being very non-open and
inaccessible- supposedly only 20,000 businesses in the US use EDI.  One
tends to think of the X12 committee existing for the sole purpose of
supporting itself.  The only books you can find on EDI are content-free and
read as sales pitches for EDI VANs and the standards committee.

The second problem is that EDI is only a high-level document standard, not a
low-level communications protocol.  This has the effect that when two
companies wish to communicate with each other, they must pay a "VAN" (Value
Added Network) gobs of money to accomplish this goal (VANs charge per
transaction, per byte, per minute, for data conversion, per month, and for
just about every other conceivable "service").  VANs are completely
redundant in these times of cheap modems and the low-cost Internet.

"Dread" is the feeling any company gets when thinking about communicating
electronically.  Any money you save from not requiring as many data-entry
personnel is ofset by the VAN fees and the EDI consulatants required to make
the system work.  Often companies are forced to use EDI anyway- for example
large retail chains may force their vendors to use EDI.

Free EDI would be a public set of standards (down-loadable for free from any
web site which wants to carry them) which allow companies to communicate
with each other either directly (modem to modem or what have you), or
through the Internet.  The process of establishing a standard for a
transaction would be based on the Internet "RFD" (request for discussion)
model.  Basically, someone proposes a standard on a USENET newsgroup.  A two
month discussion period follows, in which anyone interested gets to append
or modify the standard.  A vote is then taken and the standard is considered
established if there are more yeas than nays.  The real test for the
standard would be if companies actually used them.  If a standard seems
insufficient for a set of industries, they are perfectly free to establish
their own set as long as it is publicly available.

To start things off, I'll propose a common structure for Free EDI
transactions:

 - The communications system for Free EDI will be SMTP-TCP/IP Internet
   e-mail.  The advantage of this is its universality.  Everyone has access
   to Internet e-mail and SMTP-TCP/IP is very common for "intra-nets" as
   well.

 - Security will be based on the defacto internet security system: PGP.
   Each message will have a PGP signature from the sender and will be
   encrypted with the recipient's public key.  This will be sufficient
   security so that even EFTs (electronic fund transfers) can occur through
   Free EDI.

 - Free EDI will be transaction based in the database-locking/rollback sense.
   Each EDI transaction will be completely executed or have no effect (no
   partial transactions).  Several transactions can be sent in each email
   message.

 - Transaction IDs will be universally unique.  This will allow Free EDI
   transactions to be broadcast via USENET or in USENET-like environments.
   If the recipient receives the same transaction twice, the second one is
   ignored.  The recipient must keep a list of recently received
   transactions so that it knows which transactions to ignore.

 - An un-encrypted Free EDI message will be in readable text.

 - A Free EDI transaction will be composed of a set of "tables" (or
   relations) in the database sense.  Each table is composed of a table
   header which identifies the columns in the table followed by member
   records.  The first table of each EDI transaction will identify the Free
   EDI transaction standard which is being used for the transaction (and
   perhaps include a version number or other information).

 - An un-encrypted Free EDI message will have this detailed format:

   (In general, ASCII text will be used.  Each line is terminated with a
   line-feed preceded by an optional carriage return).

   HEADER
   Begin Free EDI Message
   TRANSACTIONS
   Z
   TRAILER

   The TRAILER can contain any data.  The HEADER can contain any data
   except the line 'Begin Free EDI Message'.

   Each line in the TRANSACTIONs section will be limited to 77 characters
   (excluding the end-of-line sequence).  Long lines will be split into
   short lines as follows: any line ending with a backslash '\' followed by
   a line beginning with a '+' will be considered the same long line
   (excluding the \, line-feed, + sequence).  Transaction lines will only
   use characters in the range 32 - 255 plus 9 (ASCII tab).

   There are several types of transaction lines, identified by the
   first character (whitespace is to be ignored in these formats: if a space
   is required, the word SPACE will be used):

        X string                Start of transaction.  'string' identifies
                                the transaction.

        E string                End of transaction.  'string' must match
                                the one at the beginning of the transaction.

        T name tab COLUMN-DEFs  Table header.  'name' is the table's name.

                                COLUMN-DEFs are a tab-separated list of
                                column definitions.  The number of
                                COLUMN-DEFs is the number of columns in the
                                table.  The order of the COLUMN-DEFs must
                                match the order of the corresponding fields
                                in the data records.

                                Each COLUMN-DEF is a space-separated list
                                of symbol/value bindings.  Two bindings
                                are required for each column:

                                        name=xxx        'xxx' is the column's
                                                        name.

                                        type=ttt        'ttt' is gives the
                                                        column type and is one
                                                        of:

                                        int     Decimal integer
                                        str     String
                                        frac    Decimal fraction (a number
                                                with an optional decimal point).
                                        date    A date in the format:
                                                  Month Day, Year

                                                Where Month is: Jan, Feb, etc.

        A name tab FIELDs       Add a data record.  'name' is the table for
                                which this record is for.  FIELDs are a tab
                                separated set of fields.  The number of
                                fields must match the number of columns. Any
                                fields can be empty, no matter what the data
                                type.  The seperating tabs are required for
                                even for empty fields, however.

        Each transaction begins with a 'T' line and ends with an 'E' line.
Table headers and data records are contained within the transaction.  The
table header must be given before any data records for that table are given.

        The first table is always the 'transid' table.  For example:

                Ttransid        name=id type=str        name=ack type=str
                Atransid        eft1    free-...@motorola.com

        Might be the first table for an EFT-type transaction called 'eft1'.
        An acknowledgment for this transaction is to be sent to the given
        e-mail address.  A complete EFT transaction would also have
        something like:

                Teft    name=frombank type=str  name=fromaccnt type=str\
                +       name=tobank type=str    name=toaccnt type=str\
                +       name=amnt type=frac
                A       123456  12397654        123456  12387654        1259.37

        - an order to transfer $1259.37 from one account to another of the
        same bank.

Please start discussing the sufficiency of this as a data format.

To move on from here we are going to need a newsgroup for discussion (I have
no idea how to start the process for newsgroup creation) and an ftp site
for recording the standards.  I can donate an ftp site (ftp.worcester.com),
but it is slow and should probably be mirrored by others.  Another issue is
the name: 'EDI' probably violates someones trademark, so we need a new
name.

--
/*  jhal...@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 
 
 

Free EDI

Post by Joseph H All » Thu, 20 Feb 1997 04:00:00


In article <E5v7qE....@world.std.com>,
Joseph H Allen <jhal...@world.std.com> wrote:

>It's time to start "Free EDI"....

Well here's the first update:

The date type should be in the format: yyyymmdd.hhmmss
Where: mm is 01 - 12 month
       dd is 01 - 31 day
       hh is 00 - 23 hour
       mm is 00 - 59 minute
       ss is 00 - 59 second

Perhaps time should be optional or second should be optional?

Also here are some example preliminary transaction formats in the format of
table descriptions.  I don't have the header table worked out fully yet, but
this gives everyone something to think about.

Transaction-id: Pricelist

                Name                            Type
                ----                            ----
Table name:     itemlines
column 1:       vender-item-code                str
column 2:       purchaser-item-code             str
column 3:       description                     str
column 4:       price-schedule                  str
column 5:       units-available                 int     Optional
column 6:       unit-weight                     frac    In Kg
column 7:       container                       str     Container type required
column 8:       size                            int     Units per container
column 9:       width                           frac    Shipping dimensions in meters
column 10:      height                          frac
column 11:      depth                           frac

Table name:     pricing
column 1:       price-schedule                  str
column 2:       qty                             int
column 3:       price-each                      frac

Transaction-id: Purchase

Tables:
                Name                            Type
                ----                            ----
Table name:     orders
column 1:       refno                           str     Order id
column 2:       billcode                        str     Bill address
column 3:       shipcode                        str     Ship address
column 4:       placed-by                       str     Who is placing order
column 5:       paymeth                         str     Payment method
column 6:       shipvia                         str     Shipping method
column 7:       shipdate                        date    Ship date
column 8:       orderdate                       date    Order date

Table name:     itemlines
column 1:       refno                           str     Order id
column 2:       vender-item-code                str     Vender's code for item
column 3:       purchaser-item-code             str     Purchaser's code
column 4:       description                     str     Optional description
column 5:       qty                             int     Amount ordered

Table name:     addresses
column 1:       addrcode                        str     Address I.D.
column 2:       name                            str     Company name
column 3:       contact                         str     Who to talk to
column 4:       phone                           str     Phone number
column 5:       email                           str     Email address
column 6:       street                          str     Street/PO-Box/Building/Suite
column 7:       city                            str     City
column 8:       state                           str     State
column 9:       zip                             str     Zip-code
column 10:      country                         str     Country

Table name:     shipping
column 1:       shipvia                         str     Purchaser's shipping code
column 2:       vender-shipvia                  str     Vender's shipping code
column 2:       description                     str     Description

Table name:     paymethods
column 1:       paymeth                         str     Payment method
column 2:       description                     str     Description of method
column 3:       pono                            str     PO No. method
column 4:       creditcardno                    str     Credit card No.
column 5:       creditcardexp                   str     Credit card Exp date
column 6:       creditcardname                  str     Name on credit card
column 7:       billdays                        int     Billme: I'll pay in n days

Transaction-id: Invoice

Table name:     invoices
column 1:       invno                           str     Invoice id
column 2:       refno                           str     Order id
column 3:       billcode                        str     Bill address
column 4:       pono                            str     P.O. number
column 5:       subtotal                        frac    Subtotal
column 6:       shipping                        frac    Shipping cost
column 7:       tax                             frac    Tax
column 8:       total                           frac    Total amount due
column 9:       due-date                        date    Due date

Table name:     itemlines
column 1:       invno                           str     Order id
column 2:       vendor-item-code                str     Vender's code for item
column 3:       purchaser-item-code             str     Purchaser's code
column 4:       description                     str     Optional description
column 5:       qty                             int     Amount ordered
column 6:       each                            frac    Price each

Table name:     addresses
column 1:       addrcode                        str     Address I.D.
column 2:       name                            str     Company name
column 3:       contact                         str     Who to talk to
column 4:       phone                           str     Phone number
column 5:       email                           str     Email address
column 6:       street                          str     Street/PO-Box/Building/Suite
column 7:       city                            str     City
column 8:       state                           str     State
column 9:       zip                             str     Zip-code
column 10:      country                         str     Country

--
/*  jhal...@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 
 
 

Free EDI

Post by Clark W. Hanl » Thu, 20 Feb 1997 04:00:00


Hi All

   It all sounds good to me. I would make the following suggestions
for the data format types.

Date should be in the format should be:   Tyyyymmdd.time

T = Time zone letter A through X
yyyy =  4 digit year
mm =  2 digit month
dd = 2 digit day
time = optional fractional part of the day (.5, Noon assumed if blank)

All time and dates to be based on UTC using the Gregorian calander.
Time zone leter codes starting at the international date line with A
and proceding East to West .

You should also add a memo (free form text) field type. In the basic
table columbs a memo filed would have a identifier MEMOxxxx whare xxxx
would be a decimal number 0001 through 99999 and refer to a memo
section that would apper after all tables. Each memo entry would start
with MEMOxxxx zzzz on a seperate line. The number zzzz would indicate
the total number of complete lines (including blank lines) or the
memo. Memos would follow the same rules for line length ect. as
specified for other sections.  Multiple records may refer to the same
memo and memos cold be included that are not referanced by any record
(but this should be avodid)

You should also include a binary attachment facility based on the MIME
standard with a record field type to referance each MIME attachment in
a simaler maner to the MEMO type discribed above. MIME attachments
would follow MEMOs. If MIME is not publicly avalible some other
sutable scheme could be used.

Even if the file was sent in plain text some type of checksum or
fingerprint should be avalaible. This could be based on the
capabilities of PGP or other sutable program.

Clark

Clark.w.han...@aero.org

On Wed, 19 Feb 1997 19:35:02 GMT, jhal...@world.std.com (Joseph H

Allen) wrote:
>It's time to start "Free EDI".  EDI (Electronic Data Interchange) is an old
>set of document standards designed to allow businesses to communicate with
>each other.  Typical of the business transactions covered by EDI are
>wholesaler to retailer communications: the retailer sends a PO (Purchase
>Order) to the wholesaler, which then sends the ordered materials to the
>retailer.  Then the wholesaler sends an Invoice to the retailer.

>There are two big problems with EDI as it currently stands.  First, the
>standards process is membership based and copies of the standards themselves
>cost lots of money.  This results in EDI being very non-open and
>inaccessible- supposedly only 20,000 businesses in the US use EDI.  One
>tends to think of the X12 committee existing for the sole purpose of
>supporting itself.  The only books you can find on EDI are content-free and
>read as sales pitches for EDI VANs and the standards committee.

>The second problem is that EDI is only a high-level document standard, not a
>low-level communications protocol.  This has the effect that when two
>companies wish to communicate with each other, they must pay a "VAN" (Value
>Added Network) gobs of money to accomplish this goal (VANs charge per
>transaction, per byte, per minute, for data conversion, per month, and for
>just about every other conceivable "service").  VANs are completely
>redundant in these times of cheap modems and the low-cost Internet.

>"Dread" is the feeling any company gets when thinking about communicating
>electronically.  Any money you save from not requiring as many data-entry
>personnel is ofset by the VAN fees and the EDI consulatants required to make
>the system work.  Often companies are forced to use EDI anyway- for example
>large retail chains may force their vendors to use EDI.

>Free EDI would be a public set of standards (down-loadable for free from any
>web site which wants to carry them) which allow companies to communicate
>with each other either directly (modem to modem or what have you), or
>through the Internet.  The process of establishing a standard for a
>transaction would be based on the Internet "RFD" (request for discussion)
>model.  Basically, someone proposes a standard on a USENET newsgroup.  A two
>month discussion period follows, in which anyone interested gets to append
>or modify the standard.  A vote is then taken and the standard is considered
>established if there are more yeas than nays.  The real test for the
>standard would be if companies actually used them.  If a standard seems
>insufficient for a set of industries, they are perfectly free to establish
>their own set as long as it is publicly available.

>To start things off, I'll propose a common structure for Free EDI
>transactions:

> - The communications system for Free EDI will be SMTP-TCP/IP Internet
>   e-mail.  The advantage of this is its universality.  Everyone has access
>   to Internet e-mail and SMTP-TCP/IP is very common for "intra-nets" as
>   well.

> - Security will be based on the defacto internet security system: PGP.
>   Each message will have a PGP signature from the sender and will be
>   encrypted with the recipient's public key.  This will be sufficient
>   security so that even EFTs (electronic fund transfers) can occur through
>   Free EDI.

> - Free EDI will be transaction based in the database-locking/rollback sense.
>   Each EDI transaction will be completely executed or have no effect (no
>   partial transactions).  Several transactions can be sent in each email
>   message.

> - Transaction IDs will be universally unique.  This will allow Free EDI
>   transactions to be broadcast via USENET or in USENET-like environments.
>   If the recipient receives the same transaction twice, the second one is
>   ignored.  The recipient must keep a list of recently received
>   transactions so that it knows which transactions to ignore.

> - An un-encrypted Free EDI message will be in readable text.

> - A Free EDI transaction will be composed of a set of "tables" (or
>   relations) in the database sense.  Each table is composed of a table
>   header which identifies the columns in the table followed by member
>   records.  The first table of each EDI transaction will identify the Free
>   EDI transaction standard which is being used for the transaction (and
>   perhaps include a version number or other information).

> - An un-encrypted Free EDI message will have this detailed format:

>   (In general, ASCII text will be used.  Each line is terminated with a
>   line-feed preceded by an optional carriage return).

>   HEADER
>   Begin Free EDI Message
>   TRANSACTIONS
>   Z
>   TRAILER

>   The TRAILER can contain any data.  The HEADER can contain any data
>   except the line 'Begin Free EDI Message'.

>   Each line in the TRANSACTIONs section will be limited to 77 characters
>   (excluding the end-of-line sequence).  Long lines will be split into
>   short lines as follows: any line ending with a backslash '\' followed by
>   a line beginning with a '+' will be considered the same long line
>   (excluding the \, line-feed, + sequence).  Transaction lines will only
>   use characters in the range 32 - 255 plus 9 (ASCII tab).

>   There are several types of transaction lines, identified by the
>   first character (whitespace is to be ignored in these formats: if a space
>   is required, the word SPACE will be used):

>        X string            Start of transaction.  'string' identifies
>                            the transaction.

>    E string                End of transaction.  'string' must match
>                            the one at the beginning of the transaction.

>    T name tab COLUMN-DEFs  Table header.  'name' is the table's name.

>                            COLUMN-DEFs are a tab-separated list of
>                            column definitions.  The number of
>                            COLUMN-DEFs is the number of columns in the
>                            table.  The order of the COLUMN-DEFs must
>                            match the order of the corresponding fields
>                            in the data records.

>                            Each COLUMN-DEF is a space-separated list
>                            of symbol/value bindings.  Two bindings
>                            are required for each column:

>                                    name=xxx        'xxx' is the column's
>                                                    name.

>                                    type=ttt        'ttt' is gives the
>                                                    column type and is one
>                                                    of:

>                                    int     Decimal integer
>                                    str     String
>                                    frac    Decimal fraction (a number
>                                            with an optional decimal point).
>                                    date    A date in the format:
>                                              Month Day, Year

>                                            Where Month is: Jan, Feb, etc.

>    A name tab FIELDs       Add a data record.  'name' is the table for
>                            which this record is for.  FIELDs are a tab
>                            separated set of fields.  The number of
>                            fields must match the number of columns. Any
>                            fields can be empty, no matter what the data
>                            type.  The seperating tabs are required for
>                            even for empty fields, however.

>    Each transaction begins with a 'T' line and ends with an 'E' line.
>Table headers and data records are contained within the transaction.  The
>table header must be given before any data records for that table are given.

>    The first table is always the 'transid' table.  For example:

>            Ttransid        name=id type=str        name=ack type=str
>            Atransid        eft1    free-...@motorola.com

>    Might be the first table for an EFT-type transaction called 'eft1'.
>    An acknowledgment for this transaction is to be sent to the given
>    e-mail address.  A complete EFT transaction would also have
>    something like:

>            Teft    name=frombank type=str  name=fromaccnt type=str\
>            +       name=tobank type=str    name=toaccnt type=str\
>            +       name=amnt type=frac
>            A       123456  12397654        123456  12387654        1259.37

>    - an order to transfer $1259.37 from one account to another of the
>    same bank.

>Please start discussing the sufficiency of this as a data format.

>To move on from here we are going to need a newsgroup for discussion (I have
>no idea how to start the process for newsgroup creation) and an ftp site
>for recording the standards.  I can donate an ftp site (ftp.worcester.com),
>but it is slow and should probably be mirrored by others.  Another issue is
>the name: 'EDI' probably violates someones trademark, so we need a new
>name.

>--
>/*  jhal...@world.std.com (192.74.137.5) */               /* Joseph H. Allen */
>int

...

read more »

 
 
 

Free EDI

Post by Brian Osma » Thu, 20 Feb 1997 04:00:00



> It's time to start "Free EDI".  EDI (Electronic Data Interchange) is an old
> set of document standards designed to allow businesses to communicate with
> each other.  Typical of the business transactions covered by EDI are
> wholesaler to retailer communications: the retailer sends a PO (Purchase
> Order) to the wholesaler, which then sends the ordered materials to the
> retailer.  Then the wholesaler sends an Invoice to the retailer.
>  - Security will be based on the defacto internet security system: PGP.
>    Each message will have a PGP signature from the sender and will be
>    encrypted with the recipient's public key.  This will be sufficient
>    security so that even EFTs (electronic fund transfers) can occur through
>    Free EDI.

This is way out of my league, but from a practical standpoint, I just
want
to mention that if this ever happens (sounds like a good idea) then
there
ought to be some way for "securely" transmitting overseas. Either with
weaker encrpytion, or using a stronger system with escrow, so that the
gov't
will allow it out of the borders.

Brian

 
 
 

Free EDI

Post by Paul Rub » Fri, 21 Feb 1997 04:00:00




Quote:>It's time to start "Free EDI".  ...
>There are two big problems with EDI as it currently stands.  First, the
>standards process is membership based and copies of the standards themselves
>cost lots of money. ... This results in EDI being very non-open and
>inaccessible- supposedly only 20,000 businesses in the US use EDI.  One
>tends to think of the X12 committee existing for the sole purpose of
>supporting itself.  The only books you can find on EDI are content-free and
>read as sales pitches for EDI VANs and the standards committee.
>The second problem is that EDI is only a high-level document
>standard, not a low-level communications protocol.  This has the
>effect that when two companies wish to communicate with each other,
>they must pay a "VAN" (Value Added Network) gobs of money to
>accomplish this goal ...

It's not that bad, there are some real books, and the standards are
readable.  If you don't like X12 you can use EDIFACT or some similar
standards.  Companies are doing EDI over the internet
(see www.premenos.com for example).  But the main problem with
your idea is the way EDI is actually used.  Generally EDI transactions
are between a big company (say General Motors) and a small company
(say Foobar Ball Bearings Inc, which supplies parts to GM) where the
use of EDI is dictated by the big company and the small company
goes along with it to get the business.  And it's the big company
that gets to choose which standards will be used, which VANs will
be used, etc. so of those 20,000 businesses using EDI, only a few
(the big ones) are making these decisions, and they tend to stick
with what they're already doing and they're big enough to not care
about the cost of a set of X12 books or whatever.  

Quote:> - A Free EDI transaction will be composed of a set of "tables" (or
>   relations) in the database sense.  Each table is composed of a table
>   header which identifies the columns in the table followed by member
>   records.  The first table of each EDI transaction will identify the Free
>   EDI transaction standard which is being used for the transaction (and
>   perhaps include a version number or other information).

If you want to have a chance in h*ll of succeeding with real EDI
users, you have to use the same formats as current standards in
order to work with the existing popular software packages.  This
isn't as bad as it sounds; you can follow X12 syntax (segments,
elements separated by *'s, etc.) without having to use the actual
X12 segments or elements.  But you should stick with the same general
organization so implementers need only to add new tables to use
their existing translators.

As for companies not already using EDI, they're probably best off
doing web based transactions, SSL, and maybe defining some kind
of syntax for documents based on HTML tables.  EDI as it currently
exists comes from the Cobol era and is best used by shops still
living in that era.

So I don't have much belief in the need or prospects for a
new and free set of EDI standards.  But it will be interesting
to see what you come up with.

--Paul (main designer of Premenos EDI/e translator back in the 80's).

 
 
 

Free EDI

Post by Ketil Z Mald » Fri, 21 Feb 1997 04:00:00



Quote:> It all sounds good to me. I would make the following suggestions
> for the data format types.
> Date should be in the format should be:   Tyyyymmdd.time

I'd prefer dates to be sortable as they are, in particular, putting time
zone at the start seems pretty weird to me.

Quote:> T = Time zone letter A through X

Preferably, this should always be Z (UTC)  Time zones are a mess, and
don't you even try to mention DST!

Quote:> time = optional fractional part of the day (.5, Noon assumed if blank)

Huh?

Quote:> All time and dates to be based on UTC using the Gregorian calander.
> Time zone leter codes starting at the international date line with A
> and proceding East to West .

Time zone letter codes start with UTC being Z, and then proceed from A
going _eastwards_.  (MET is A, EET is B, and so forth).

~kzm
--
If I haven't seen further, it is by standing in the footprints of giants

 
 
 

Free EDI

Post by Patrick Juo » Fri, 21 Feb 1997 04:00:00




>> It's time to start "Free EDI".  EDI (Electronic Data Interchange) is an old
>> set of document standards designed to allow businesses to communicate with
>> each other.  Typical of the business transactions covered by EDI are
>> wholesaler to retailer communications: the retailer sends a PO (Purchase
>> Order) to the wholesaler, which then sends the ordered materials to the
>> retailer.  Then the wholesaler sends an Invoice to the retailer.

>>  - Security will be based on the defacto internet security system: PGP.
>>    Each message will have a PGP signature from the sender and will be
>>    encrypted with the recipient's public key.  This will be sufficient
>>    security so that even EFTs (electronic fund transfers) can occur through
>>    Free EDI.

>This is way out of my league, but from a practical standpoint, I just
>want
>to mention that if this ever happens (sounds like a good idea) then
>there
>ought to be some way for "securely" transmitting overseas. Either with
>weaker encrpytion, or using a stronger system with escrow, so that the
>gov't
>will allow it out of the borders.

Or build a stronger system w/o escrow in Antigua....

        Patrick

 
 
 

Free EDI

Post by Joseph H All » Fri, 21 Feb 1997 04:00:00



>Generally EDI transactions are between a big company (say General Motors)
>and a small company (say Foobar Ball Bearings Inc, which supplies parts to
>GM) where the use of EDI is dictated by the big company and the small
>company goes along with it to get the business.  And it's the big company
>that gets to choose which standards will be used, which VANs will be used,
>etc. so of those 20,000 businesses using EDI, only a few (the big ones) are
>making these decisions, and they tend to stick with what they're already
>doing and they're big enough to not care about the cost of a set of X12
>books or whatever.

Sigh.  Yes mob-boss rule is exactly the problem, and one which is difficult
to solve.  All I can say is that to change the process it will help if there
is a developed alternative.  It is possible that one industry will start
using Free-EDI... if it does then others wishing to join that industry get
to use our standard instead...  Another possibility is that if Free-EDI
becomes popular, the EDI VANs might become gateways between Free-EDI and
legacy EDI.  It would be nice to be able to send Free-EDI email to

continue to pay the VAN, but new vendors maybe wouldn't have to.

Also there is the possibility that smaller industries (which can't affoard
EDI) could use Free-EDI.  If that happens then the larger companies will be
forced to change if they ever want to get in on the smaller industries.

It may also be in the larger company's interest to accept Free-EDI.  They
try to muscle their trading partner's into using EDI, but they don't always
succeed.  If they want their trading partner's to communicate with them
electronically, then they should make it easy for them to do so.

Quote:>If you want to have a chance in h*ll of succeeding with real EDI
>users, you have to use the same formats as current standards in
>order to work with the existing popular software packages.

I don't think I want to use any of the existing EDI formats (although I
would love to hear more contrary arguments- I'm certainly no EDI expert).
Although it would certainly be nice to be able to translate into them.

From what I gather, each EDI standard requires almost a parser (even though
the EDI standards themselves are not formalized context-free grammars, BNFs
or regular expressions), and a generic EDI translator essentially is a
parser generator- one of the most complex pieces of software one can write.

The approach I'm thinking of is to make Free-EDI transactions look like
databases.  The software to read a transaction into a relational database
system should be trivial (and you only need one trivial parser).  Once the
data is in the database, one can use the database system to map vender's
codes and customer's codes, merge the data with the custmer's database or
whatever.

I'm thinking of providing a bunch of utilities for doing as much generic
data conversion as I can think of.  One neat one would be something to read
an accounting system's line-printer output (assuming it can be captured in a
file, as it always can be for UNIX systems) and convert it into a Free-EDI
transaction (you'd supply a set-up file giving field positions and form
lengths and so on).  So the company prints invoices using its old accounting
software to a file, and presto they're Free-EDI capable.  Another peice of
software would receive a Free-EDI transaction and pretty print it.  It
should be easy to write JAVA applets to compose an EDI transaction, and
netscape plug-ins can certainly send e-mail...

Free-EDI transactions should also be UNIX friendly.  You should be able to
use UNIX's database commands: sort, uniq, awk, join, etc. and be able to
build simple shell-scripts to process Free-EDI data.

Free-EDI transactions should also be Visual-Basic, MS-Access and MS-mail
friendly.

I don't know much about it, but it would certainly be nice if Free-EDI
transaction could be AS/400 friendly as well.

The Free-EDI web site should be a depository for all of these utilities.
--

int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 
 
 

Free EDI

Post by James Duri » Fri, 21 Feb 1997 04:00:00




> > It's time to start "Free EDI".  EDI (Electronic Data Interchange) is an old
> > set of document standards designed to allow businesses to communicate with
> > each other.  Typical of the business transactions covered by EDI are
> > wholesaler to retailer communications: the retailer sends a PO (Purchase
> > Order) to the wholesaler, which then sends the ordered materials to the
> > retailer.  Then the wholesaler sends an Invoice to the retailer.

> >  - Security will be based on the defacto internet security system: PGP.
> >    Each message will have a PGP signature from the sender and will be
> >    encrypted with the recipient's public key.  This will be sufficient
> >    security so that even EFTs (electronic fund transfers) can occur through
> >    Free EDI.

I didn't see the original post but i would like to make a quick note to
the original poster that edi over mime is already in the works and has
been for some time now.  And the security it will use is whatever
standard exists for encrypting mime mail (i think this is in the works
also).  The company i used to work for is in one of the groups doing
interoperability testing.


he could at least tell you where to look for more information.

--
James Durie
-----------------------------------------------------------------
Union Bank of Switzerland / Schweizerische Bankgesellschaft

 
 
 

Free EDI

Post by James Youngm » Fri, 21 Feb 1997 04:00:00



Quote:>This is way out of my league, but from a practical standpoint, I just
>want
>to mention that if this ever happens (sounds like a good idea) then
>there
>ought to be some way for "securely" transmitting overseas. Either with
>weaker encrpytion, or using a stronger system with escrow, so that the
>gov't
>will allow it out of the borders.

Simple.   Just develop the code outside the USA.  Problem solved.

--
James Youngman       VG Gas Analysis Systems  The trouble with the rat-race
Before sending advertising material, read     is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html         still a rat.

 
 
 

Free EDI

Post by Paul Rub » Fri, 21 Feb 1997 04:00:00




Quote:>>...of those 20,000 businesses using EDI, only a few (the big ones) are
>>making these decisions, and they tend to stick with what they're already
>>doing and they're big enough to not care about the cost of a set of X12
>>books or whatever.

>Sigh.  Yes mob-boss rule is exactly the problem, and one which is difficult
>to solve.  All I can say is that to change the process it will help if there
>is a developed alternative.

The thing is, EDI just doesn't benefit smaller companies that much.
The people who really gain from EDI are the ones who have to deal with
a -lot- of different trading partners, and that means the "mob bosses".
The smaller companies who trade with them just consider EDI to be a
nuisance and wouldn't bother with it even it were free, if their
larger partners didn't insist on it.

Quote:>>If you want to have a chance in h*ll of succeeding with real EDI
>>users, you have to use the same formats as current standards in
>>order to work with the existing popular software packages.

>I don't think I want to use any of the existing EDI formats (although I
>would love to hear more contrary arguments- I'm certainly no EDI expert).
>Although it would certainly be nice to be able to translate into them.

The only reason I see for doing free EDI is to make it easier (cheaper)
for small companies to trade with large EDI users.  The large users
are using existing standards and won't be interested in changing to new ones.

Quote:>From what I gather, each EDI standard requires almost a parser (even though
>the EDI standards themselves are not formalized context-free grammars, BNFs
>or regular expressions), and a generic EDI translator essentially is a
>parser generator- one of the most complex pieces of software one can write.

It's not that bad.  The EDI standards are all quite similar in
structure although the terminology varies (EDIFACT calls "sentences"
what X12 calls "segments" if I remember properly).  I wrote a generic
translator; it wasn't that complicated.  Remember that EDI was
designed to be processed by Cobol and RPG programs.  I had to explain
that to several of the programmers who joined the project I worked
on--that EDI is low tech, and if they were trying to approach it with
parser generators and other fancy methods, they were probably thinking
of the problems in the wrong way.  The one thing that didn't fit into
the generic framework was the X12 HL segment, a kind of recursive bill
of lading that nobody actually used or understood as far as I could
tell, but we had to support it because it was in the standard, so I
put a special hack into the translator for it.  The generic translator
was a simple recursive descent "parser" driven by a machine readable
document description that came pretty much directly out of the
standard.

Quote:>The approach I'm thinking of is to make Free-EDI transactions look like
>databases.  The software to read a transaction into a relational database
>system should be trivial (and you only need one trivial parser).  Once the
>data is in the database, one can use the database system to map vender's
>codes and customer's codes, merge the data with the custmer's database or
>whatever.

Relational databases aren't really what you want.  EDI documents are
more like tree structures, with repeated segments, nested loops, etc.

Quote:>Free-EDI transactions should also be UNIX friendly.  You should be able to
>use UNIX's database commands: sort, uniq, awk, join, etc. and be able to
>build simple shell-scripts to process Free-EDI data.

>Free-EDI transactions should also be Visual-Basic, MS-Access and MS-mail
>friendly.

>I don't know much about it, but it would certainly be nice if Free-EDI
>transaction could be AS/400 friendly as well.

If you don't mind my asking, why are you interested in EDI if you
haven't been using it?  I'm not trying to give you a hard time;
I'm just wondering.

Quote:>The Free-EDI web site should be a depository for all of these utilities.

You have a web site?  Where?
Thanks.

Paul

 
 
 

Free EDI

Post by Brian Osma » Fri, 21 Feb 1997 04:00:00




> >This is way out of my league, but from a practical standpoint, I just
> >want
> >to mention that if this ever happens (sounds like a good idea) then
> >there
> >ought to be some way for "securely" transmitting overseas. Either with
> >weaker encrpytion, or using a stronger system with escrow, so that the
> >gov't
> >will allow it out of the borders.

> Simple.   Just develop the code outside the USA.  Problem solved.

> --
> James Youngman       VG Gas Analysis Systems  The trouble with the rat-race
> Before sending advertising material, read     is, even if you win, you're
> http://www.law.cornell.edu/uscode/47/227.html         still a rat.

I'm going to be sorry for ever getting involved in this, but:

Developing outside the USA is not the end-all solution of crypto.
Most of the stronger algorithms have restrictive licensing within
the US, so using code that was written elsewhere could be illegal
HERE! Sure everyone else can use it, but now you've alienated all
of the US businesses. Face it, US crypto policy sucks, and harms
efforts like this. There is no "Simple" solution.

Brian

 
 
 

Free EDI

Post by Christopher B. Brow » Fri, 21 Feb 1997 04:00:00


I would suggest that before starting to create some new protocol that may or
may not have anything to do with EDI as anyone else knows it that you
consult some of the existing info sources.

Here are two URLs that would be of relevance if you want to look into the
possibility of building some new EDI standard.  (Does it not make sense to
see what other Internet-related standards there might be out there?)

<LI><a href="http://www.ietf.cnri.reston.va.us/home.html">Internet Engineering Task Force home page</a>
<LI><a href="http://www.ietf.org/html.charters/ediint-charter.html">Electronic Data Interchange-Internet Integration (ediint) </a>
--

"When you say 'I wrote a program that crashed Windows', people just stare at
you blankly and say 'Hey, I got those with the system, *for free*"
  - Linus Torvalds      URL: http://www.conline.com/~cbbrowne/

 
 
 

Free EDI

Post by Joseph H All » Sat, 22 Feb 1997 04:00:00



>The thing is, EDI just doesn't benefit smaller companies that much.
>The people who really gain from EDI are the ones who have to deal with
>a -lot- of different trading partners, and that means the "mob bosses".
>The smaller companies who trade with them just consider EDI to be a
>nuisance and wouldn't bother with it even it were free, if their
>larger partners didn't insist on it.

Ah, but it should be benificial to small companies.  I've been rethinking
this a bit.  EDI is costly and unfriendly: the big company tells the small
company that it should send its invoices via EDI in x12 standard no. 950 (or
whatever).  This has no meaning and only attains meaning after the small
company invests lots of money in software and services.  Even once the small
company is prepared to understand x12 950, it still has to communicate with
the large company for the purpose of pinning down exact details (the
interpretation and necessity of various fields, common item codes, etc.).

Now what do the companies really want?  The big company wants all of its
received data in a standard machine readable format to lower its data
processing costs.  The small company wants to make the big company happy and
so wants to know how to format the data with least amount of fuss.

The way this would be accomplished in the absence of EDI would be this: the
big company would send a copy of its standard form to the small company, and
the small company would fill it out and send it back.

Today PGP signatures for authentication and encryption for secrecy allow
E-mail to replace the post office for this last step- so companies can now
communicate electronically in the same way that they do with paper.

Now you still want the data to be machine readable, but you don't want to
require small companies to become EDI experts- its too difficult and costly.
They want make ball bearings and don't want to concern themselves with
obscure computer standards.

So instead of a common set of standards, the big company needs to just tell
the small company what it wants in a way that it can comprehend.

An EDI "standard" should then meet these goals:

 - EDI data should be directly human readable.  The small company could
   learn how the data is to be formatted just be looking at an example.  A
   human should be able to process the data (perhaps the small company only
   receives a few purchase orders- this goal is always a good idea anyway,
   you still want to be able to conduct business if your machine is down).

 - It should be possible to compose an EDI message either by hand or with
   the absolute minimum in required software.

 - Any standards should be freely copyable.  The big company should be able
   to just send the small company a copy of the standard (akin to sending it
   a form).

 - It should be trivial for the trading partners to make changes to the
   standards.

 - EDI data should also of course be machine readable so that the goal of
   automated processing can be met.  The standard itself should also be machine
   readable.

An EDI standard should probably look like a form:

# Order form - Free EDI standard No. 2

# Fill out the following header information
Standard: free-edi.order.2
Date: 19970212                          # Please use yyyymmdd


Comment:                                # Comment

# List of orders
#  Refno is an identifier (reference number) for the order
#  Placed is the person who placed the order
#  Purchaser is the address code of the purchaser (see the List of addresses
#  table which follows).
#  Vendor is the address code of the vendor
#  Pay is the payment method code
#  Date is the date the order is placed

Quote:>orders :Refno  :Placed  :Purchaser  :Vendor    :Date

        :52536  :Joe     :jhallen    :moto      :19970212

# List of addresses

Quote:>addr   :code    :Name     :Street    :City     :State    :Zip...

        :jhallen :Joe Allen....
        :moto    :Motorola Inc.....

# Itemlines

Quote:>items  :code    :description                       :qty

And so on.

Quote:>If you don't mind my asking, why are you interested in EDI if you
>haven't been using it?  I'm not trying to give you a hard time;
>I'm just wondering.

I consult for a company which needs to become EDI capable (and I'm the one
who has to do it).  This effort is result of: Discovering that all books an
EDI are *of the form "you must reengineer your business to conform to
the new EDI paradigm...".  Discovering that "translator software" costs
$4000.  Discovering that to get a copy of x12 costs $3000.  Discovering that
the software is just not going to integrate well with the accouning system
(unless we upgrade it: $10,000 - $20,000 plus everyone has to learn
something new).

Of course they're still going to do it (they want the big customer).

--

int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

 
 
 

Free EDI

Post by Joseph H All » Sat, 22 Feb 1997 04:00:00


To illustrate the current problems with EDI I've enclosed a copy of the
UN/EDIFACT (a set of EDI standards created by the UN which compete with ANSI
X12- at least these are free) purchase order (available at
ftp.premenos.com).  I apologize for the long post.  People actually believe
that standards like this are going to make businesses more efficient.  It's
really very Brazil-esque: "No no... See? There's no stamp.  You'll have to
go back to Information Retrieval and get it properly stamped!" This is more
complex than any IRS document I've ever seen.  It's amusing to note that on
top of everything else, EDI has the year-2000 bug built-in.

                              UN/EDIFACT
                         DRAFT RECOMMENDATION

                        Purchase order message

----------------------------------------------------------------------
This message is available for formal trial for at least six months
from the date of approval by UN/ECE/TRADE/WP.4.

Organisations are invited to trial this message. Comments on the
results from the trial should be forwarded to their Rapporteur's Team
Secretariat as soon as they are available. Based on the results of the
trials, a UNSM may be issued.

The segments, composite data elements, data elements and codes for
use in the trial of this message are contained in the Draft directory.
However, this information may differ from that in the Standard
directory (UNTDID), even for material having the same identifying
tags.
----------------------------------------------------------------------

                                            Message Type : ORDERS
                                            Version      : D
                                            Release      : 96B
                                            Contr. Agency: UN
                                            Status       : 2
                                            Revision     : 6
                                            Date         : 96-07-04

SOURCE: Submitted by WEEB-MD1 on behalf of PAEB

                               CONTENTS

                        Purchase order message

0.   INTRODUCTION

1.   SCOPE

     1.1   Functional definition

     1.2   Field of application

     1.3   Principles

2.   REFERENCES

3.   TERMS AND DEFINITIONS

4.   MESSAGE DEFINITION

     4.1   Data segment clarification

           4.1.1 Header section
           4.1.2 Detail section
           4.1.3 Summary section

     4.2   Data segment index (alphabetical sequence)

     4.3   Message structure

           4.3.1 Segment table

----------------------------------------------------------------------
For general information on UN standard message types see UN Trade Data
Interchange Directory, UNTDID, Part 4, Section 2.6, UN/ECE UNSM
General Introduction
----------------------------------------------------------------------

0.     INTRODUCTION

       This specification provides the definition of the Purchase
       order message (ORDERS) to be used in Electronic Data
       Interchange (EDI) between trading partners involved in
       administration, commerce and transport.

1.     SCOPE

1.1    Functional Definition

       A message specifying details for goods or services ordered
       under conditions agreed between the seller and the buyer.

1.2    Field of Application

       The UN Standard Purchase Order Message may be applied for both
       national and international trade. It is based on universal
       commercial practice and is not dependent on the type of
       business or industry.

1.3    Principles

       - A buyer may order for one or more goods items or services.

       - A purchase order may refer to goods items or services related
       to one or more delivery schedules, call-offs, etc.

       - A purchase order for cross-border transactions may contain
       additional information for customs and/or statistical purposes.

       - A purchase order may contain details for transport and
       destination as well as delivery patterns.

2.     REFERENCES

       See UNTDID, Part 4, Chapter 2.6 UN/ECE UNSM - General
       Introduction, Section 1.

3.     TERMS AND DEFINITIONS

       See UNTDID, Part 4, Chapter 2.6 UN/ECE UNSM - General
       Introduction, Section 2.

4.     MESSAGE DEFINITION

4.1    Data Segment Clarification

       This section should be read in conjunction with the Branching
       Diagram and the Segment Table which indicate mandatory,
       conditional and repeating requirements.

       The following guidelines and principles apply to the whole
       message and are intended to facilitate the understanding and
       implementation of the message:

       All specified dates/times should be in the format
       'yymmdd'/'hhmm' unless all parties involved in the transaction
       agree that there is a functional requirement for an alternative
       format. Periods should be specified as whole numbers
       representing the required period as indicated in the format
       qualifier (weeks, months, etc.)

       Where a choice of code or text is given only the code element
       should be used wherever possible.

       Conditional data that is not required in the message should not
       be included.

       Care must be taken that the segment qualifier in dependent
       segments do not conflict with the segment qualifier of the
       trigger segment of a group.

       Free text information within the message should be avoided as
       this inhibits automatic processing.

4.1.1  Header section

       Information to be provided in the Header section:

0010   UNH, Message header
       A service segment starting and uniquely identifying a message.
       The message type code for the Purchase order message is ORDERS.

       Note: Purchase order messages conforming to this document must
       contain the following data in segment UNH, composite S009:

       Data element  0065 ORDERS
                     0052 D
                     0054 96B
                     0051 UN

0020   BGM, Beginning of message
       A segment by which the sender must uniquely identify the order
       by means of its name and number and when necessary its
       function.

0030   DTM, Date/time/period
       A segment specifying general dates and, when relevant, times
       related to the whole message. The segment must be specified at
       least once to identify the order date.
       Examples of the use of this DTM segment are: Lead times that
       apply to the whole of the Order and, if no schedule is to be
       specified, the delivery date.
       The Date/time/period segment within other Segment group should
       be used whenever the date/time/period requires to be logically
       related to another specified data item. e.g. Payment due date
       is specified within the PAT Segment group.

0040   PAI, Payment instructions
       A segment requesting or confirming conditions of payment,
       guarantee and method of payment for the whole order. An example
       of the use of this segment is to specify that a documentary
       credit will be used.

0050   ALI, Additional information
       A segment indicating special conditions related to the total
       order owing to origin, customs preference or other commercial
       factors.

0060   IMD, Item description
       A segment providing a description common to all line items of
       the order.

0070   FTX, Free text
       A segment with free text information, in coded or clear form,
       used when additional information is needed but cannot be
       accommodated within other segments. In computer to computer
       exchanges such text will normally require the receiver to
       process this segment manually.

0080   Segment group 1:  RFF-DTM
       A group of segments for giving references and where necessary,
       their dates, relating to the whole message e.g. contract
       number, import/export license number, reservation number.

0090      RFF, Reference
          A segment identifying the reference by its number and where
          appropriate a line number within a document.

0100      DTM, Date/time/period
          A segment specifying the date/time related to the reference.

0110   Segment group 2:  NAD-LOC-FII-SG3-SG4-SG5
       A group of segments identifying the parties with associated
       information.

0120      NAD, Name and address
          A segment identifying names and addresses of the parties, in
          coded or clear form, and their functions relevant to the
          order. Identification of the seller and buyer parties is
          mandatory for the order message. It is recommended that
          where possible only the coded form of the party ID should be
          specified e.g. The Buyer and Seller are known to each other,
          thus only the coded ID is required, but the Consignee or
          Delivery address may vary and would have to be clearly
          specified, preferably in structured format.

0130      LOC, Place/location identification
          A segment giving more specific location information of the
          party specified in the NAD segment e.g. internal
          site/building number.

0140      FII, Financial institution information
          A segment identifying the financial institution (e.g. bank)
          and relevant account numbers for the seller, buyer and where
          necessary other parties e.g. the buyer may provide a choice
          of financial institutions for direct debit purposes.

0150      Segment group 3:  RFF-DTM
          A group of segments giving references only relevant to the
          specified party rather than the whole order.

0160         RFF, Reference
             A segment identifying the reference by its number and
             where appropriate a line number within a document.

0170         DTM, Date/time/period
...

read more »

 
 
 

1. MI-DETROIT-224223--EDI-PL/SQL-ORACLE-EDI, Oracle Developers

******** VISIT US AT http://www.selectjobs.com ***********
=
*************************************************************
Company    : Vega Consulting Solutions
Website    : http://www.vegaconsulting.com
Job Title  : EDI, Oracle Developers
Location   : DETROIT, MI
Job Type   : Contract or Full-Time Salaried
============================
At Vega Consulting we know that good consultants are our greatest strength.
That's why we offer the most professionally stimulating assignments you'll find
anywhere.

Work with users, create specs and code using EDI tools and Oracle backend tools
such as Pl/SQL. This is an open ended contract.

Travel Required          :None
Educational Requirements :None
=
Required Skills
* EDI
* PL/SQL
* ORACLE
=
Along with stable, long term projects we offer competitive compensations
packages (hourly or salary), health and dental insurance, 401K plan, &
relocations assistance.
=
Contact Information:
Reference : SJ224223
Kim Shand

Phone: 800-810-8342
   -   -    
Fax No: 973-335-1677
***********************  http://www.selectjobs.com  ****************************

                The On-Line, On-Target Job Finder for Computer Professionals  

** Post Your Resume and see results immediately!! ** Always free **
** Matching Resumes E-mailed daily
**  Your ads are virtually guaranteed to be seen by jobseekers on the NET **

                    ** Automatic Posting to **
   ** Yahoo            ** Americas Job Bank    ** AltaVista   *** ClassifiedsWarehouse
   ** erpcentral.com   ** Classifieds 2000     ** Usenet Newsgroups
           ** VBOnline.com   ** ORASearch.com  
               *** OVER 100 MILLION HITS/MONTH COMBINED !!! ***

***********************  http://www.selectjobs.com  ****************************

2. To German readers

3. IN-Indianapolis-267442--EDI-UNIX-ORACLE-FTP-EDI Functional Resource

4. How to more than 8 iigcc processes?

5. 18728-TN-EAST-EDI-ORACLE-GENTRAN-X12-MAPP-EDI / ORACLE PROGRAMMER ANALYST

6. Q: Howto apply cursorpos from one recset to another?

7. odbc leaves droppings