Thread View: comp.protocols.misc
32 messages
32 total messages
Started by Joseph H Allen
Wed, 19 Feb 1997 00:00
Free EDI
Author: Joseph H Allen
Date: Wed, 19 Feb 1997 00:00
Date: Wed, 19 Feb 1997 00:00
181 lines
9456 bytes
9456 bytes
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-edi@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.
--
/* jhallen@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]]);}
Re: Free EDI
Author: Joseph H Allen
Date: Wed, 19 Feb 1997 00:00
Date: Wed, 19 Feb 1997 00:00
128 lines
5226 bytes
5226 bytes
In article <E5v7qE.D85@world.std.com>,
Joseph H Allen <jhallen@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
--
/* jhallen@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]]);}
Re: Free EDI
Author: Clark W. Hanley
Date: Wed, 19 Feb 1997 00:00
Date: Wed, 19 Feb 1997 00:00
233 lines
11435 bytes
11435 bytes
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.hanley@aero.org
On Wed, 19 Feb 1997 19:35:02 GMT, jhallen@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-edi@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.
>
>--
>/* jhallen@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]]);}
Re: Free EDI
Author: Brian Osman
Date: Wed, 19 Feb 1997 00:00
Date: Wed, 19 Feb 1997 00:00
26 lines
2284 bytes
2284 bytes
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. > - 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
Re: Free EDI
Author: Paul Rubin
Date: Thu, 20 Feb 1997 00:00
Date: Thu, 20 Feb 1997 00:00
60 lines
4330 bytes
4330 bytes
In article <E5v7qE.D85@world.std.com>, Joseph H Allen <jhallen@world.std.com> wrote: >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. > - 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).
Re: Free EDI
Author: Ketil Z Malde
Date: Thu, 20 Feb 1997 00:00
Date: Thu, 20 Feb 1997 00:00
30 lines
2022 bytes
2022 bytes
clark.w.hanley@aero.org (Clark W. Hanley) writes: > 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. > 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! > time = optional fractional part of the day (.5, Noon assumed if blank) Huh? > 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
Re: Free EDI
Author: Patrick Juola
Date: Thu, 20 Feb 1997 00:00
Date: Thu, 20 Feb 1997 00:00
29 lines
2364 bytes
2364 bytes
In article <330B6E98.33F2@rpi.edu> osmanb@rpi.edu writes: >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. > >> - 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
Re: Free EDI
Author: Joseph H Allen
Date: Thu, 20 Feb 1997 00:00
Date: Thu, 20 Feb 1997 00:00
78 lines
5594 bytes
5594 bytes
In article <phrE5w244.5vy@netcom.com>, Paul Rubin <phr@netcom.com> wrote:
>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
free-edi@sterling.com and have them forward it to GM or whoever. GM can
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.
>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.
--
/* jhallen@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]]);}
Re: Free EDI
Author: James Durie
Date: Thu, 20 Feb 1997 00:00
Date: Thu, 20 Feb 1997 00:00
35 lines
2679 bytes
2679 bytes
Brian Osman wrote: > > 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. > > > - 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. You could try emailing johnh@apiltd.demon.co.uk he could at least tell you where to look for more information. -- James Durie ----------------------------------------------------------------- Union Bank of Switzerland / Schweizerische Bankgesellschaft DEPT/GFSI +44 171 901 3470 email: James.Durie@ubs.com
Re: Free EDI
Author: James Youngman
Date: Thu, 20 Feb 1997 00:00
Date: Thu, 20 Feb 1997 00:00
18 lines
1800 bytes
1800 bytes
In article <330B6E98.33F2@rpi.edu>, osmanb@rpi.edu says... >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.
Re: Free EDI
Author: Paul Rubin
Date: Thu, 20 Feb 1997 00:00
Date: Thu, 20 Feb 1997 00:00
83 lines
5244 bytes
5244 bytes
In article <E5wM2y.2E0@world.std.com>, Joseph H Allen <jhallen@world.std.com> wrote: >>...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. >>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. >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. >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. >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. >The Free-EDI web site should be a depository for all of these utilities. You have a web site? Where? Thanks. Paul
Re: Free EDI
Author: Brian Osman
Date: Thu, 20 Feb 1997 00:00
Date: Thu, 20 Feb 1997 00:00
31 lines
2419 bytes
2419 bytes
James Youngman wrote: > > In article <330B6E98.33F2@rpi.edu>, osmanb@rpi.edu says... > > >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
Re: Free EDI
Author: Christopher B. Browne
Date: Thu, 20 Feb 1997 00:00
Date: Thu, 20 Feb 1997 00:00
16 lines
2082 bytes
2082 bytes
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> -- Christopher B. Browne, cbbrowne@unicomp.net, chris_browne@sdt.com "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/
Re: Free EDI
Author: Joseph H Allen
Date: Fri, 21 Feb 1997 00:00
Date: Fri, 21 Feb 1997 00:00
1609 lines
77574 bytes
77574 bytes
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
A segment specifying the date and/or time related to the
reference.
0180 Segment group 4: DOC-DTM
A group of segments identifying the documentary requirements
of the specified party.
0190 DOC, Document/message details
A segment identifying and providing information relating
to the documents required by the party specified by the
NAD segment. For example, the party may require a
Certificate of Analysis.
0200 DTM, Date/time/period
A segment specifying the date and/or time of the
document.
0210 Segment group 5: CTA-COM
A group of segments giving contact details of the specific
person or department within the party identified in the NAD
segment.
0220 CTA, Contact information
A segment to identify a person or department, and their
function, to whom communications should be directed.
0230 COM, Communication contact
A segment to identify a communications type and number
for the contact specified in the CTA segment.
0240 Segment group 6: TAX-MOA-LOC
A group of segments specifying tax related information, and
when necessary, the location(s) to which that tax information
relates.
0250 TAX, Duty/tax/fee details
A segment specifying a tax type, category and rate, or
exemption, relating to the whole order e.g. Value Added Tax
at the standard rate is applicable for all items.
0260 MOA, Monetary amount
A segment specifying the amount for the identified tax/fee.
0270 LOC, Place/location identification
A segment indicating the location to which the tax or
exemption specified in the TRI segment applies e.g. city or
state or country.
0280 Segment group 7: CUX-PCD-DTM
A group of segments specifying the currencies and related
dates/periods valid for the whole order. Currency data may be
omitted in national applications but will be required for
international transactions.
0290 CUX, Currencies
A segment identifying the currencies required in the order
e.g. the order currency. A rate of exchange may be given to
convert a reference currency into a target currency.
0300 PCD, Percentage details
A segment specifying the fluctuation beyond those limits
will allow one or either party to re-negotiate prices.
0310 DTM, Date/time/period
A segment specifying the date/time/period related to the
rate of exchange.
0320 Segment group 8: PAT-DTM-PCD-MOA
A group of segments specifying the terms of payment applicable
for the whole order.
0330 PAT, Payment terms basis
A segment identifying the payment terms and date/time basis.
0340 DTM, Date/time/period
A segment giving the specific date/time/period, if needed,
of any payments, discounts, instalments etc.
0350 PCD, Percentage details
A segment specifying the discount, interest, penalty as well
as instalment percentage.
0360 MOA, Monetary amount
A segment specifying amounts related to payment discounts,
penalties or instalments.
0370 Segment group 9: TDT-SG10
A group of segments identifying the mode and means of
transport, location and relevant dates and times for
transportation, relating to the whole order.
0380 TDT, Details of transport
A segment specifying the mode, means and identification of
the transport for the goods being ordered. If required, the
carrier's address should be indicated within the NAD Segment
group.
0390 Segment group 10: LOC-DTM
A group of segments giving the location and date/time
information relative to the transportation.
0400 LOC, Place/location identification
A segment identifying locations relevant to the transport
specified in the TDT segment e.g. place of departure or
border crossing point.
0410 DTM, Date/time/period
A segment identifying the date/time details of departure
and/or arrival of the transported goods for the specified
location.
0420 Segment group 11: TOD-LOC
A group of segments indicating the terms of delivery for the
whole order.
0430 TOD, Terms of delivery or transport
A segment identifying the delivery terms to be used e.g. UN
INCOTERMS code could be used to specify the delivery terms.
0440 LOC, Place/location identification
A segment identifying locations relevant to the delivery
terms specified in the TOD segment.
0450 Segment group 12: PAC-MEA-SG13
A group of segments identifying the packaging, physical
dimensions and marks and numbers for goods referenced by the
whole order.
0460 PAC, Package
A segment specifying the number and type of packages for the
whole order e.g. number and type of pallets.
0470 MEA, Measurements
A segment specifying physical measurements of packages
described in the PAC segment e.g. package length, weight.
0480 Segment group 13: PCI-RFF-DTM-GIN
A group of segments specifying the markings and labels on
individual physical units.
0490 PCI, Package identification
A segment specifying markings and labels used on
individual physical units (packages) described in the PAC
segment.
0500 RFF, Reference
A segment identifying the master label number.
0510 DTM, Date/time/period
A segment specifying the dates relevant to the package
markings.
0520 GIN, Goods identity number
A segment identifying the number or ranges of numbers for
use with the package markings.
0530 Segment group 14: EQD-HAN-MEA-FTX
A group of segments providing information relating to equipment
identification and ownership, handling and identification of
hazardous materials, relating to the whole order.
0540 EQD, Equipment details
A segment to define information regarding equipment to be
used in conjunction with the whole order, and if required,
to indicate responsibility for supply of the equipment.
0550 HAN, Handling instructions
A segment providing information on required handling of
materials and additionally, if required, identifying
hazardous materials in the whole order.
0560 MEA, Measurements
A segment providing measurement information for the
equipment.
0570 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.
0580 Segment group 15: SCC-FTX-RFF-SG16
A group of segments specifying requested delivery schedules
relating to quantities, frequencies, dates and references,
required for the whole order.
0590 SCC, Scheduling conditions
A segment specifying the type and status of the schedule
being given, and optionally defining a pattern to be
established e.g. firm or proposed delivery schedule for a
weekly pattern.
0600 FTX, Free text
A segment with free text information, in coded or clear
form, to give further clarification to scheduling
instructions. In computer to computer exchanges such text
will normally require the receiver to process this segment
manually.
0610 RFF, Reference
A segment for specifying the reference for schedule.
0620 Segment group 16: QTY-DTM
A group of segments to specify the scheduled quantities,
date/time of the schedule, and where required, the reference
of the schedule.
0630 QTY, Quantity
A segment to specify pertinent quantities relating to the
schedule and pattern established in the SCC segment, e.g.
delivery quantity.
0640 DTM, Date/time/period
A segment indicating the date/time details relating to
the quantity and schedule used to indicate date/time
ranges e.g. start and end dates for a delivery pattern,
or delivery window.
0650 Segment group 17: APR-DTM-RNG
A group of segments providing information concerning pricing
related to the type of trade, and where appropriate, indication
of quantities, dates/periods or amounts.
0660 APR, Additional price information
A segment to identify additional pricing information such as
a price multiplier, the class or type of trade and
additionally identifying the reason for any changes.
0670 DTM, Date/time/period
A segment to identify the date/time/period information
related to the price change e.g. period of validity.
0680 RNG, Range details
A segment to identify the quantity or amount ranges to which
the additional price information applies.
0690 Segment group 18: ALC-ALI-DTM-SG19-SG20-SG21-SG22-SG23
A group of segments specifying allowances and charges for the
whole order. The allowance or charge specified within this
Segment group may either relate to the total order in which
case it cannot be overridden at detail level, or it can relate
to the line items as a default allowance/charge and can be
overridden by the ALC Segment group within the detail section.
Where relevant, additional information, tax and alternate
currency details are to be indicated in the TRI and MOA
segments. The basis for the calculation of the allowance/charge
may be a quantity, a percentage, an amount or a rate and one of
the Segment group 19-22 should be used accordingly.
0700 ALC, Allowance or charge
A segment identifying the charge or allowance and, where
necessary its calculation sequence.
0710 ALI, Additional information
A segment indicating that the allowance or charge specified
is subject to special conditions owing to origin, customs
preference or commercial factors.
0720 DTM, Date/time/period
A segment to identify the date/time/period information
related to the allowance or charge, e.g. period of validity.
0730 Segment group 19: QTY-RNG
A group of segments specifying the quantity of the allowance
or charge with its measure unit specifier. A range to which
the allowance or charge applies may be specified e.g. an
allowance of a free quantity of 20 pieces may be specified
if the goods quantity ordered is greater than 1000 pieces.
0740 QTY, Quantity
A segment identifying the type of quantity and the
quantity related to the allowance or charge.
0750 RNG, Range details
A segment specifying, if required, the range to which the
allowance or charge applies.
0760 Segment group 20: PCD-RNG
A group of segments specifying the percentage for the
allowance or charge, e.g. The allowance/charge amount is
calculated as 5% of the goods value or a price reduction of
5% may be specified if the goods quantity ordered is within
the range 5 tons to 10 tons.
0770 PCD, Percentage details
A segment identifying the percentage and the percentage
basis for the calculation of the allowance or charge.
0780 RNG, Range details
A segment specifying, if required, a range for the
application of the percentage.
0790 Segment group 21: MOA-RNG
A group of segments specifying a monetary amount for an
allowance or charge. A range to which the allowance or
charge applies can be specified e.g. an allowance of 5000
BEF may be specified if goods value ordered is greater than
100000 BEF.
0800 MOA, Monetary amount
A segment identifying the monetary amount for the
allowance or charge.
0810 RNG, Range details
A segment specifying, if required, a range for the
application of the allowance/charge amount.
0820 Segment group 22: RTE-RNG
A group of segments specifying the rate per unit and basis
to which the allowance or charge applies e.g. the
allowance/charge amount is 3 DEM per 10 tons.
0830 RTE, Rate details
A segment specifying the rate per unit and the basis for
calculation.
0840 RNG, Range details
A segment specifying, if required, the range for the
application of the allowance/charge rate.
0850 Segment group 23: TAX-MOA
A group of segments specifying tax related information for
the allowance or charge.
0860 TAX, Duty/tax/fee details
A segment specifying the tax type, category and rate, or
exemption, related to the allowance or charge.
0870 MOA, Monetary amount
A segment specifying the tax amount for the allowance or
charge.
0880 Segment group 24: RCS-RFF-DTM-FTX
A group of segments identifying any rules, laws or regulations
with which the supplier must comply to meet requirements e.g.
building regulations, safety requirements, etc.
0890 RCS, Requirements and conditions
A segment to enable industry or national requirements to be
specified.
0900 RFF, Reference
A segment identifying the referenced document by its number
and, where appropriate, a line number.
0910 DTM, Date/time/period
A segment indicating the date/time details relating to the
references.
0920 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.
4.1.2 Detail section
Information to be provided in the Detail section:
0930 Segment group 25: LIN-PIA-IMD-MEA-QTY-PCD-ALI-DTM-MOA-GIN-GIR-
QVR-DOC-PAI-FTX-SG26-SG27-SG28-SG29-SG30-
SG33-SG34-SG35-SG39-SG45-SG47-SG48-SG49-SG51-
SG52
A group of segments providing details of the individual ordered
items. This Segment group may be repeated to give sub-line
details.
0940 LIN, Line item
A segment identifying the line item by the line number and
configuration level, and additionally, identifying the
product or service ordered. Other product identification
numbers e.g. Buyer product number, etc. can be specified
within the following PIA segment.
0950 PIA, Additional product id
A segment providing either additional identification to the
product specified in the LIN segment (e.g. Harmonized System
number), or provides any substitute product identification.
0960 IMD, Item description
A segment for describing the product or service being
ordered as well as product characteristic. This segment
should be used for products or services that cannot be fully
identified by a product code or article number.
0970 MEA, Measurements
A segment enabling the physical measurements of the ordered
item to be specified where this is required for full
identification of the product. Any measurements must refer
to the product in its unpacked form e.g. thickness of
plastic film, length, weight, etc.
0980 QTY, Quantity
A segment identifying the product quantities e.g. ordered
quantity.
0990 PCD, Percentage details
A segment specifying the strength or yield of a product as a
percentage e.g. 80% to indicate the strength of an acid.
1000 ALI, Additional information
A segment indicating that the line item is subject to
special conditions owing to origin, customs preference,
embargo regulations or commercial factors.
1010 DTM, Date/time/period
A segment specifying date/time/period details relating to
the line item only.
1020 MOA, Monetary amount
A segment specifying any monetary amounts relating to the
product e.g. item amount, insurance value, customs value.
1030 GIN, Goods identity number
A segment providing identity numbers to be applied to the
goods being ordered e.g. serial numbers for assembled
equipment.
1040 GIR, Related identification numbers
A segment providing sets of related identification numbers
for a line item e.g. engine numbers, chassis number and
transmission number for a vehicle.
1050 QVR, Quantity variances
A segment identifying order quantity variances, normally
specified by the supplier using an Order Response message.
1060 DOC, Document/message details
A segment to indicate that a certificate/declaration of
origin is required for the ordered article.
1070 PAI, Payment instructions
A segment to indicate that where a central buyer is
purchasing on behalf of different consignees, the means of
payment may differ for each item/consignee combination as
specified in segment group 25.
1080 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.
1090 Segment group 26: CCI-CAV-MEA
A group of segments providing product characteristic and
product characteristic details.
1100 CCI, Characteristic/class id
A segment to identify product characteristic and, or the
characteristic name and characteristic relevance for the
business process.
1110 CAV, Characteristic value
A segment to specify common product characteristic by
value in either coded form or in free format.
1120 MEA, Measurements
A segment indicating characteristic value being physical
measurement (including measurable quantities and
percentages) related to specified product characteristics
(for example voltage, percentage of material contained)
and where relevant measurement ranges.
1130 Segment group 27: PAT-DTM-PCD-MOA
A group of segments specifying the terms of payment
applicable for the line item. This may be used by a central
buyer purchasing on behalf of different item consignee
combinations.
1140 PAT, Payment terms basis
A segment identifying the payment terms and date/time
basis.
1150 DTM, Date/time/period
A segment giving the specific date/time/period, if
needed, of any payments, discounts, instalments etc.
1160 PCD, Percentage details
A segment specifying the discount, interest, penalty as
well as instalment percentage.
1170 MOA, Monetary amount
A segment specifying amounts related to payment
discounts, penalties or instalments.
1180 Segment group 28: PRI-CUX-APR-RNG-DTM
A group of segments identifying the relevant pricing
information for the goods or services ordered.
1190 PRI, Price details
A segment to specify the price type and amount. The price
used in the calculation of the line amount will be
identified as 'price'.
1200 CUX, Currencies
A segment to allow to specify the price in a different
currency that in segment group 7.
1210 APR, Additional price information
A segment to identify pricing information such as a price
multiplier, the class or type of trade and additionally
identifying the reason for any changes.
1220 RNG, Range details
A segment to identify the ranges (quantity, amount, etc)
to which the additional price information applies.
1230 DTM, Date/time/period
A segment to identify the date/time/period information
related to the price change e.g. period of validity.
1240 Segment group 29: RFF-DTM
A group of segments giving references and where necessary,
their dates, relating to the line item.
1250 RFF, Reference
A segment identifying the reference by its number and
where appropriate a line number within a document.
1260 DTM, Date/time/period
A segment specifying the date/time related to the
reference.
1270 Segment group 30: PAC-MEA-QTY-DTM-SG31-SG32
A group of segments identifying the packaging, physical
dimensions, and marks and numbers for goods referenced in
the line item.
1280 PAC, Package
A segment specifying the number of packages and the
physical type of packaging for the line item e.g. pallet
type.
1290 MEA, Measurements
A segment specifying physical measurements of packages
described in the PAC segment e.g. cube or gross weight.
1300 QTY, Quantity
A segment specifying the maximum quantity number of
packages which can be stacked safely on another and/or
the number of items normally contained within the
package.
1310 DTM, Date/time/period
A segment to indicate the validity period in relation to
the specified article.
1320 Segment group 31: RFF-DTM
A segment group to give reference to e.g. a packing
instruction document relevant to a particular package
type and its date/time/period of issue.
1330 RFF, Reference
A segment identifying the packing instruction
document.
1340 DTM, Date/time/period
A segment specifying the dates relevant to the
referred document.
1350 Segment group 32: PCI-RFF-DTM-GIN
A group of segments specifying the markings and labels on
individual physical units.
1360 PCI, Package identification
A segment specifying markings and labels used on
individual physical units (packages) described in the
PAC segment.
1370 RFF, Reference
A segment identifying the master label number.
1380 DTM, Date/time/period
A segment specifying the dates relevant to the package
markings.
1390 GIN, Goods identity number
A segment identifying the number or ranges of numbers
for use with the package markings.
1400 Segment group 33: LOC-QTY-DTM
A group of segments specifying destination and quantity
details for consignments involving multi-destination
deliveries.
1410 LOC, Place/location identification
A segment indicating the location to which part of the
consignment is to be delivered.
1420 QTY, Quantity
A segment specifying the quantity to be delivered to the
identified location.
1430 DTM, Date/time/period
A segment specifying the dates and/or times that the
delivery should be made.
1440 Segment group 34: TAX-MOA-LOC
A group of segments specifying tax related information, and
when necessary, the location(s) to which that tax
information relates.
1450 TAX, Duty/tax/fee details
A segment specifying a tax type, category and rate, or
exemption, relating to the line item.
1460 MOA, Monetary amount
A segment specifying the amount for the identified
tax/fee.
1470 LOC, Place/location identification
A segment indicating the location to which the tax or
exemption specified in the TAX segment applies e.g. city
or state tax.
1480 Segment group 35: NAD-LOC-SG36-SG37-SG38
A group of segments identifying the parties with associated
information, relevant to the line item only.
1490 NAD, Name and address
A segment identifying names and addresses of the parties,
in coded or clear form, and their functions relevant to
the line item . 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.
1500 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.
1510 Segment group 36: RFF-DTM
A group of segments giving references only relevant to
the specified party rather than the line item.
1520 RFF, Reference
A segment identifying the reference by its number and
where appropriate a line number within a document.
1530 DTM, Date/time/period
A segment specifying the date and/or time related to
the reference.
1540 Segment group 37: DOC-DTM
A group of segments identifying the documentary
requirements of the specified party.
1550 DOC, Document/message details
A segment identifying and providing information
relating to the documents required by the party
specified by the NAD segment.
For example, the party may require a Certificate of
Analysis.
1560 DTM, Date/time/period
A segment specifying the date and/or time of the
document.
1570 Segment group 38: CTA-COM
A group of segments giving contact details of the
specific person or department within the party identified
in the NAD segment.
1580 CTA, Contact information
A segment to identify a person or department, and
their function, to whom communications should be
directed.
1590 COM, Communication contact
A segment to identify a communications type and number
for the contact specified in the CTA segment.
1600 Segment group 39: ALC-ALI-DTM-SG40-SG41-SG42-SG43-SG44
A group of segments specifying allowances and charges for
the line item where this is different to or not specified
within the heading section.
1610 ALC, Allowance or charge
A segment identifying the charge or allowance and, where
necessary its calculation sequence.
1620 ALI, Additional information
A segment indicating that the allowance or charge
specified is subject to special conditions owing to
origin, customs preference or commercial factors.
1630 DTM, Date/time/period
A segment to identify the date/time/period information
related to the allowance or charge, e.g. period of
validity.
1640 Segment group 40: QTY-RNG
A group of segments specifying the quantity of the
allowance or charge with its measure unit specifier. A
range to which the allowance or charge applies may be
specified, e.g. an allowance of a free quantity of 20
pieces may be specified if the goods quantity ordered is
greater than 1000 pieces.
1650 QTY, Quantity
A segment identifying the type of quantity and the
quantity related to the allowance or charge.
1660 RNG, Range details
A segment specifying, if required, the range to which
the allowance or charge applies.
1670 Segment group 41: PCD-RNG
A group of segments specifying the percentage for the
allowance or charge e.g. The allowance/charge amount is
calculated as 5% of the goods value or a price reduction
of 5% may be specified if the goods quantity ordered is
within the range 5 tons to 10 tons.
1680 PCD, Percentage details
A segment identifying the percentage and the
percentage basis for the calculation of the allowance
or charge.
1690 RNG, Range details
A segment specifying, if required, a range for the
application of the percentage.
1700 Segment group 42: MOA-RNG
A group of segments specifying a monetary amount for an
allowance or charge. A range to which the allowance or
charge applies can be specified e.g. an allowance of 5000
BEF may be specified if goods value ordered is greater
than 100000 BEF.
1710 MOA, Monetary amount
A segment identifying the monetary amount for the
allowance or charge.
1720 RNG, Range details
A segment specifying, if required, a range for the
application of the allowance/charge amount.
1730 Segment group 43: RTE-RNG
A group of segments specifying the rate per unit and
basis to which the allowance or charge applies e.g. The
allowance/charge amount is 3 DEM per 10 tons.
1740 RTE, Rate details
A segment specifying the rate per unit and the basis
for calculation.
1750 RNG, Range details
A segment specifying, if required, the range for the
application of the allowance/charge rate.
1760 Segment group 44: TAX-MOA
A group of segments specifying tax related information
for the allowance or charge.
1770 TAX, Duty/tax/fee details
A segment specifying the tax type, category and rate,
or exemption, related to the allowance or charge.
1780 MOA, Monetary amount
A segment specifying the tax amount for the allowance
or charge.
1790 Segment group 45: TDT-SG46
A group of segments identifying the mode and means of
transport, location and relevant dates and times for
transportation, relating to the line item, where this is
different to or not specified within the heading section.
1800 TDT, Details of transport
A segment specifying the mode, means and identification
of the transport for the goods item being ordered, where
this is different to or not specified within the heading
section.
1810 Segment group 46: LOC-DTM
A group of segments giving the location and date/time
information relative to the transportation.
1820 LOC, Place/location identification
A segment identifying locations relevant to the
transport specified in the TDT segment.
1830 DTM, Date/time/period
A segment identifying the date/time details of
departure and/or arrival of the transported goods for
the specified location.
1840 Segment group 47: TOD-LOC
A group of segments indicating the terms of delivery for the
line item where this is different to or not specified within
the heading section.
1850 TOD, Terms of delivery or transport
A segment identifying the delivery terms to be used.
1860 LOC, Place/location identification
A segment identifying locations relevant to the delivery
terms specified in the TOD segment.
1870 Segment group 48: EQD-HAN-MEA-FTX
A group of segments providing information relating to
equipment identification and ownership, handling and
notification of hazardous materials, relating to the line
item where this is different to or not specified within the
heading section.
1880 EQD, Equipment details
A segment to define fixed information regarding equipment
to be used in conjunction with the ordered item, and if
required, to indicate responsibility for supply of the
equipment e.g. a container identification.
1890 HAN, Handling instructions
A segment providing information on required handling of
materials and additionally, if required, identifying
hazardous materials in the ordered item.
1900 MEA, Measurements
A segment providing measurement information for the
equipment.
1910 FTX, Free text
A segment with free text information, in coded or clear
form, to give further clarification, when required, to
the equipment and handling details. In computer to
computer exchanges such text will normally require the
receiver to process this segment manually.
1920 Segment group 49: SCC-FTX-RFF-SG50
A group of segments specifying requested delivery schedules
relating to quantities, frequencies, and dates, required for
the line item, where this is different to or not specified
within the heading section.
1930 SCC, Scheduling conditions
A segment specifying the type and status of the schedule
being given, and optionally defining a pattern to be
established e.g. firm or proposed delivery schedule for a
weekly pattern.
1940 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.
1950 RFF, Reference
A segment for specifying references relevant to a
schedule.
1960 Segment group 50: QTY-DTM
A group of segments to specify the scheduled quantities,
date/time details of the schedule and where required the
reference of the schedule.
1970 QTY, Quantity
A segment to specify pertinent quantities relating to
the schedule and pattern established in the SCC
segment e.g. delivery quantity.
1980 DTM, Date/time/period
A segment indicating the date/time details relating to
the quantity and schedule details in the SCC/QTY
segments. This segment may be repeated to indicate
date/time ranges, e.g. start and end dates for a
delivery pattern, or delivery window.
1990 Segment group 51: RCS-RFF-DTM-FTX
A group of segments identifying any rules, laws or
regulations with which the supplier must comply to meet
requirements e.g. building regulations, safety requirements,
etc.
2000 RCS, Requirements and conditions
A segment to enable industry or national requirements to
be specified.
2010 RFF, Reference
A segment identifying the referenced document by its
number and where appropriate, a line number.
2020 DTM, Date/time/period
A segment indicating the date/time details relating to
the references.
2030 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.
2040 Segment group 52: STG-SG53
A group of segments indicating information (quantity and
amount) for the calculation of the amortization.
2050 STG, Stages
A segment providing information related to the kind of
stage in a process, the total number of stages and the
current stage.
2060 Segment group 53: QTY-MOA
A group of segment indicating quantity and monetary
amount related to STG.
2070 QTY, Quantity
A segment giving information on quantity relating to
STG.
2080 MOA, Monetary amount
A segment giving information on monetary amount
relating to STG.
4.1.3 Summary section
Information to be provided in the Summary section:
2090 UNS, Section control
A service segment placed at the start of the summary section to
avoid segment collision.
2100 MOA, Monetary amount
A segment giving the total amounts for the whole order message.
2110 CNT, Control total
A segment by which control totals may be provided by the sender
for checking by the receiver.
2120 Segment group 54: ALC-ALI-MOA
A group of segments specifying allowances and charges summary
totals for the order.
2130 ALC, Allowance or charge
A segment identifying the charge or allowance type to be
summarised.
2140 ALI, Additional information
A segment indicating that allowance or charge specified is
subject to special conditions owing to origin, customs
preference or commercial factors.
2150 MOA, Monetary amount
A segment specifying the summary amount for the allowance or
charge.
2160 UNT, Message trailer
A service segment ending a message, giving the total number of
segments in the message and the control reference number of the
message.
4.2 Data segment index (Alphabetical sequence by tag)
ALC Allowance or charge
ALI Additional information
APR Additional price information
BGM Beginning of message
CAV Characteristic value
CCI Characteristic/class id
CNT Control total
COM Communication contact
CTA Contact information
CUX Currencies
DOC Document/message details
DTM Date/time/period
EQD Equipment details
FII Financial institution information
FTX Free text
GIN Goods identity number
GIR Related identification numbers
HAN Handling instructions
IMD Item description
LIN Line item
LOC Place/location identification
MEA Measurements
MOA Monetary amount
NAD Name and address
PAC Package
PAI Payment instructions
PAT Payment terms basis
PCD Percentage details
PCI Package identification
PIA Additional product id
PRI Price details
QTY Quantity
QVR Quantity variances
RCS Requirements and conditions
RFF Reference
RNG Range details
RTE Rate details
SCC Scheduling conditions
STG Stages
TAX Duty/tax/fee details
TDT Details of transport
TOD Terms of delivery or transport
UNH Message header
UNS Section control
UNT Message trailer
4.3 Message structure
4.3.1 Segment table
Pos Tag Name S R
HEADER SECTION
0010 UNH Message header M 1
0020 BGM Beginning of message M 1
0030 DTM Date/time/period M 35
0040 PAI Payment instructions C 1
0050 ALI Additional information C 5
0060 IMD Item description C 1
0070 FTX Free text C 99
0080 * ����� Segment group 1 ������������������ C 99���������Ŀ
0090 RFF Reference M 1 �
0100 DTM Date/time/period C 5������������
0110 ����� Segment group 2 ������������������ C 99���������Ŀ
0120 NAD Name and address M 1 �
0130 LOC Place/location identification C 25 �
0140 FII Financial institution information C 5 �
�
0150 ����� Segment group 3 ������������������ C 10��������Ŀ�
0160 RFF Reference M 1 ��
0170 DTM Date/time/period C 5����������ٳ
�
0180 ����� Segment group 4 ������������������ C 5���������Ŀ�
0190 DOC Document/message details M 1 ��
0200 DTM Date/time/period C 5����������ٳ
�
0210 ����� Segment group 5 ������������������ C 5���������Ŀ�
0220 CTA Contact information M 1 ��
0230 COM Communication contact C 5������������
0240 ����� Segment group 6 ������������������ C 5����������Ŀ
0250 TAX Duty/tax/fee details M 1 �
0260 MOA Monetary amount C 1 �
0270 LOC Place/location identification C 5������������
0280 ����� Segment group 7 ������������������ C 5����������Ŀ
0290 CUX Currencies M 1 �
0300 PCD Percentage details C 5 �
0310 DTM Date/time/period C 5������������
0320 ����� Segment group 8 ������������������ C 10���������Ŀ
0330 PAT Payment terms basis M 1 �
0340 DTM Date/time/period C 5 �
0350 PCD Percentage details C 1 �
0360 MOA Monetary amount C 1������������
0370 ����� Segment group 9 ������������������ C 10���������Ŀ
0380 TDT Details of transport M 1 �
�
0390 ����� Segment group 10 ������������������ C 10��������Ŀ�
0400 LOC Place/location identification M 1 ��
0410 DTM Date/time/period C 5������������
0420 ����� Segment group 11 ������������������ C 5����������Ŀ
0430 TOD Terms of delivery or transport M 1 �
0440 LOC Place/location identification C 2������������
0450 ����� Segment group 12 ������������������ C 10���������Ŀ
0460 PAC Package M 1 �
0470 MEA Measurements C 5 �
�
0480 ����� Segment group 13 ������������������ C 5���������Ŀ�
0490 PCI Package identification M 1 ��
0500 RFF Reference C 1 ��
0510 DTM Date/time/period C 5 ��
0520 GIN Goods identity number C 10�����������
0530 ����� Segment group 14 ������������������ C 10���������Ŀ
0540 EQD Equipment details M 1 �
0550 HAN Handling instructions C 5 �
0560 MEA Measurements C 5 �
0570 FTX Free text C 5������������
0580 ����� Segment group 15 ������������������ C 10���������Ŀ
0590 SCC Scheduling conditions M 1 �
0600 FTX Free text C 5 �
0610 RFF Reference C 5 �
�
0620 ����� Segment group 16 ������������������ C 10��������Ŀ�
0630 QTY Quantity M 1 ��
0640 DTM Date/time/period C 5������������
0650 ����� Segment group 17 ������������������ C 25���������Ŀ
0660 APR Additional price information M 1 �
0670 DTM Date/time/period C 5 �
0680 RNG Range details C 1������������
0690 ����� Segment group 18 ������������������ C 15���������Ŀ
0700 ALC Allowance or charge M 1 �
0710 ALI Additional information C 5 �
0720 DTM Date/time/period C 5 �
�
0730 ����� Segment group 19 ������������������ C 1���������Ŀ�
0740 QTY Quantity M 1 ��
0750 RNG Range details C 1����������ٳ
�
0760 ����� Segment group 20 ������������������ C 1���������Ŀ�
0770 PCD Percentage details M 1 ��
0780 RNG Range details C 1����������ٳ
�
0790 ����� Segment group 21 ������������������ C 2���������Ŀ�
0800 MOA Monetary amount M 1 ��
0810 RNG Range details C 1����������ٳ
�
0820 ����� Segment group 22 ������������������ C 1���������Ŀ�
0830 RTE Rate details M 1 ��
0840 RNG Range details C 1����������ٳ
�
0850 ����� Segment group 23 ������������������ C 5���������Ŀ�
0860 TAX Duty/tax/fee details M 1 ��
0870 MOA Monetary amount C 1������������
0880 ����� Segment group 24 ������������������ C 100��������Ŀ
0890 RCS Requirements and conditions M 1 �
0900 RFF Reference C 5 �
0910 DTM Date/time/period C 5 �
0920 FTX Free text C 5������������
DETAIL SECTION
0930 * ����� Segment group 25 ������������������ C 200000�����Ŀ
0940 LIN Line item M 1 �
0950 PIA Additional product id C 25 �
0960 IMD Item description C 99 �
0970 * MEA Measurements C 99 �
0980 QTY Quantity C 10 �
0990 PCD Percentage details C 5 �
1000 ALI Additional information C 5 �
1010 DTM Date/time/period C 35 �
1020 MOA Monetary amount C 10 �
1030 GIN Goods identity number C 1000 �
1040 GIR Related identification numbers C 1000 �
1050 QVR Quantity variances C 1 �
1060 DOC Document/message details C 5 �
1070 PAI Payment instructions C 1 �
1080 FTX Free text C 99 �
�
1090 ����� Segment group 26 ������������������ C 999�������Ŀ�
1100 CCI Characteristic/class id M 1 ��
1110 CAV Characteristic value C 10 ��
1120 MEA Measurements C 10���������ٳ
�
1130 ����� Segment group 27 ������������������ C 10��������Ŀ�
1140 PAT Payment terms basis M 1 ��
1150 DTM Date/time/period C 5 ��
1160 PCD Percentage details C 1 ��
1170 MOA Monetary amount C 1����������ٳ
�
1180 ����� Segment group 28 ������������������ C 25��������Ŀ�
1190 PRI Price details M 1 ��
1200 CUX Currencies C 1 ��
1210 APR Additional price information C 1 ��
1220 RNG Range details C 1 ��
1230 DTM Date/time/period C 5����������ٳ
�
1240 * ����� Segment group 29 ������������������ C 999�������Ŀ�
1250 RFF Reference M 1 ��
1260 DTM Date/time/period C 5����������ٳ
�
1270 ����� Segment group 30 ������������������ C 10��������Ŀ�
1280 PAC Package M 1 ��
1290 MEA Measurements C 5 ��
1300 QTY Quantity C 5 ��
1310 DTM Date/time/period C 5 ��
��
1320 ����� Segment group 31 ������������������ C 1��������Ŀ��
1330 RFF Reference M 1 ���
1340 DTM Date/time/period C 5���������ٳ�
��
1350 ����� Segment group 32 ������������������ C 5��������Ŀ��
1360 PCI Package identification M 1 ���
1370 RFF Reference C 1 ���
1380 DTM Date/time/period C 5 ���
1390 GIN Goods identity number C 10���������ٳ
�
1400 ����� Segment group 33 ������������������ C 9999������Ŀ�
1410 LOC Place/location identification M 1 ��
1420 QTY Quantity C 1 ��
1430 DTM Date/time/period C 5����������ٳ
�
1440 ����� Segment group 34 ������������������ C 10��������Ŀ�
1450 TAX Duty/tax/fee details M 1 ��
1460 MOA Monetary amount C 1 ��
1470 LOC Place/location identification C 5����������ٳ
�
1480 ����� Segment group 35 ������������������ C 99��������Ŀ�
1490 NAD Name and address M 1 ��
1500 LOC Place/location identification C 5 ��
��
1510 ����� Segment group 36 ������������������ C 5��������Ŀ��
1520 RFF Reference M 1 ���
1530 DTM Date/time/period C 5���������ٳ�
��
1540 ����� Segment group 37 ������������������ C 5��������Ŀ��
1550 DOC Document/message details M 1 ���
1560 DTM Date/time/period C 5���������ٳ�
��
1570 ����� Segment group 38 ������������������ C 5��������Ŀ��
1580 CTA Contact information M 1 ���
1590 COM Communication contact C 5����������ٳ
�
1600 ����� Segment group 39 ������������������ C 99��������Ŀ�
1610 ALC Allowance or charge M 1 ��
1620 ALI Additional information C 5 ��
1630 DTM Date/time/period C 5 ��
��
1640 ����� Segment group 40 ������������������ C 1��������Ŀ��
1650 QTY Quantity M 1 ���
1660 RNG Range details C 1���������ٳ�
��
1670 ����� Segment group 41 ������������������ C 1��������Ŀ��
1680 PCD Percentage details M 1 ���
1690 RNG Range details C 1���������ٳ�
��
1700 ����� Segment group 42 ������������������ C 2��������Ŀ��
1710 MOA Monetary amount M 1 ���
1720 RNG Range details C 1���������ٳ�
��
1730 ����� Segment group 43 ������������������ C 1��������Ŀ��
1740 RTE Rate details M 1 ���
1750 RNG Range details C 1���������ٳ�
��
1760 ����� Segment group 44 ������������������ C 5��������Ŀ��
1770 TAX Duty/tax/fee details M 1 ���
1780 MOA Monetary amount C 1����������ٳ
�
1790 ����� Segment group 45 ������������������ C 10��������Ŀ�
1800 TDT Details of transport M 1 ��
��
1810 ����� Segment group 46 ������������������ C 10�������Ŀ��
1820 LOC Place/location identification M 1 ���
1830 DTM Date/time/period C 5����������ٳ
�
1840 ����� Segment group 47 ������������������ C 5���������Ŀ�
1850 TOD Terms of delivery or transport M 1 ��
1860 LOC Place/location identification C 2����������ٳ
�
1870 ����� Segment group 48 ������������������ C 10��������Ŀ�
1880 EQD Equipment details M 1 ��
1890 HAN Handling instructions C 5 ��
1900 MEA Measurements C 5 ��
1910 FTX Free text C 5����������ٳ
�
1920 ����� Segment group 49 ������������������ C 100�������Ŀ�
1930 SCC Scheduling conditions M 1 ��
1940 FTX Free text C 5 ��
1950 RFF Reference C 5 ��
��
1960 ����� Segment group 50 ������������������ C 10�������Ŀ��
1970 QTY Quantity M 1 ���
1980 DTM Date/time/period C 5����������ٳ
�
1990 ����� Segment group 51 ������������������ C 100�������Ŀ�
2000 RCS Requirements and conditions M 1 ��
2010 RFF Reference C 5 ��
2020 DTM Date/time/period C 5 ��
2030 FTX Free text C 5����������ٳ
�
2040 ����� Segment group 52 ������������������ C 10��������Ŀ�
2050 STG Stages M 1 ��
��
2060 ����� Segment group 53 ������������������ C 3��������Ŀ��
2070 QTY Quantity M 1 ���
2080 MOA Monetary amount C 1������������
SUMMARY SECTION
2090 UNS Section control M 1
2100 MOA Monetary amount C 12
2110 CNT Control total C 10
2120 ����� Segment group 54 ������������������ C 10���������Ŀ
2130 ALC Allowance or charge M 1 �
2140 ALI Additional information C 1 �
2150 MOA Monetary amount M 2������������
2160 UNT Message trailer M 1
--
/* jhallen@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]]);}
Re: Free EDI
Author: Evan Leibovitch
Date: Fri, 21 Feb 1997 00:00
Date: Fri, 21 Feb 1997 00:00
102 lines
6004 bytes
6004 bytes
In article <E5v7qE.D85@world.std.com>, Joseph H Allen <jhallen@world.std.com> 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. That is the 'official' purpose. The unofficial purpose is to make work for all those COBOL and VM types who were thrown out of their old jobs as Unix and PCs replaced mainframes over the last 20 years. These people dominate the EDI field right now, which is why they do dumb mainframe things such as break documents into 80-column records for transmission. EDI, pure and simple, is e-mail of specific documents in commonly-agreed-to structures. That's it. Everything else is implementation. >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. I am deeply involved in EDI and even at the retail-wholesale level, it involved significantly more than that. There are acknowledgements, purchase-order-changes, statistical reports, and that mother of all retail EDI documents known as the Advance Shipping Notice, incredibly complex but functionally really no more than an electronic Bill of Lading. >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. As with Unix, there are plenty of different standards to go around. The clothing industry uses an entirely different standard from grocery industry for essentially the same documents. And the clothing industry standard has many different versions in current use. Getting the standards are not difficult of expensive if you're working with/for companies dealing with EDI. Let's say you do consulting for a manufacturer that just landed a big sale to Target. Target's EDI department will send you all the specs you need to receive their POs and send them invoices and/or ASNs. There is enough leeway in the specs that an EDI purchase order for Target can (and does) look significantly different from, say, a WalMart PO. Etcetera. >This results in EDI being very non-open and >inaccessible- supposedly only 20,000 businesses in the US use EDI. Everyone selling goods to a major retailer (and an increasing number of minor ones) needs to talk EDI. And it's not just retail. You want to supply parts to GM? You need to talk EDI. >The second problem is that EDI is only a high-level document standard, not a >low-level communications protocol. Not really a problem. You can transmit an EDI document to anyone in any form. The problem comes when you need to transmit documents in a manner mutually acceptable with your 'trading partner'. If you and your partner agree to exchange EDI over the Internet, that's up to you and totally possible right now within the standard(s). But most EDI folk now use VANs (value-added networks, now there's an oxymoron), a handful of large e-mail systems that essentially talk to each other and nobody else. Some VANs have announced intentions to transmit and receive EDI documents over the Internet. Security is an issue, but I see that easily solvable by PGP as suggested here. But there are other issues; acknowledgements and auditing trails are important, and neither is done in a standardized manner on the Internet. >"Dread" is the feeling any company gets when thinking about communicating >electronically. Right now EDI is not a benefit to suppliers. It is a cost of selling to large, highly-automated companies. >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. Standards are only as good as those who follow them. If the big EDI players don't play ball with this scheme, it's just wheel-reinvention. Most EDI users don't care about the standards, they just want to do business as inexpensively as possible. A copylefted program to translate, verify, acknowledge, and audit documents according to existing standards would be a Very Good Idea. VANs are already moving to Internet-based delivery, knowing full well that the Internet will render them obsolete. Such are market forces. But re-inventing the actual standards process, let alone the standards themselves? Give me a break. In EDI, the only standard that counts is the one your partner forces you to follow. -- Evan Leibovitch, Sound Software Ltd, located in beautiful Brampton, Ontario Supporting PC-based Unix since 1985 / Caldera & SCO authorized / www.telly.org Trains stop at train stations. Buses stop at bus stations. I use a workstation.
Re: Free EDI
Author: Evan Leibovitch
Date: Fri, 21 Feb 1997 00:00
Date: Fri, 21 Feb 1997 00:00
61 lines
3958 bytes
3958 bytes
In article <phrE5x9uD.2yD@netcom.com>, Paul Rubin <phr@netcom.com> wrote: >In article <E5wM2y.2E0@world.std.com>, >Joseph H Allen <jhallen@world.std.com> wrote: >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. Absolutely. >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. Right. So making it cheaper means less expensive software to do: - envelope wrappers (ISA, GS, ST, etc segments and associated cruft) - standards verification (are required fields all filled? are there strings in fields defined in the spec as integers? - interface with local databases' import/export facilities (known as mapping) - automatic authentication sending (for received docs) - automatic authentication reconciliation (for sent docs) - auditing - interface with the communications subsystem (internet or something else) >The EDI standards are all quite similar in >structure although the terminology varies (EDIFACT calls "sentences" >what X12 calls "segments" if I remember properly). "The thing I like about standards is that there are so many to choose from" Even within one subset of the standards (X12) there are multiple variants (3020, 3030, 3030VICS, 3040, and many many others). And even using the same standard, two different partners can exploit loopholes to do the same doc in significantly different ways (those who use the SDQ record versus those who don't, for example). >I wrote a generic translator; it wasn't that complicated. Heh. Look at Sterling's Mentor. Five digits to buy, won't run on character terminals and incredibly complex. >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 HL is not the bill of lading itself (that's the ASN). But it is the component that makes the ASN the monster of all retail EDI documents. (That is, of course, if you discount POs and invoices that use SDQs ;-) -- Evan Leibovitch, Sound Software Ltd, located in beautiful Brampton, Ontario Supporting PC-based Unix since 1985 / Caldera & SCO authorized / www.telly.org Trains stop at train stations. Buses stop at bus stations. I use a workstation.
Re: Free EDI
Author: jab
Date: Fri, 21 Feb 1997 00:00
Date: Fri, 21 Feb 1997 00:00
40 lines
2498 bytes
2498 bytes
In article <E5yKMC.8BA@world.std.com>, Joseph H Allen <jhallen@world.std.com> writes >SNIP > It's amusing to note that on >top of everything else, EDI has the year-2000 bug built-in. > >HUGE SNIP Edifact has the capability of specifying an 8 char date by the use of a date format qualifier (102 in the 91.2 directory, haven't checked the others yet), but, generally speaking, 6 char date fields are widely used. Even if an 8 char date is received, if the application can't handle it the you're still stuck. For info, the ANA has just published an algorithm that may help, it goes as follows: Subtract the last 2 digits of today's date (X1X2) from the date under scrutiny (N2N2). As the last two digits of both dates can vary from 00 to 99 over the course of a century, the result can vary from -99 to +99. The following table shows how to interprete the result. -99 to -51 -50 to +50 +51 to +99 N1N2 is in the N1N2 is in the N1N2 is in the NEXT century CURRENT century PREVIOUS century This works for any dates from 49 before to 50 years after the current year. Of course, if you have to track dates over a very wide span (eg. Insurance industry) then you'll still have problems. Have a nice millennium. -- jab
Re: Free EDI
Author: Joseph H Allen
Date: Fri, 21 Feb 1997 00:00
Date: Fri, 21 Feb 1997 00:00
16 lines
1880 bytes
1880 bytes
In article <E5yrEv.4o2@bigbird.telly.org>,
Evan Leibovitch <evan@bigbird.telly.org> wrote:
>The HL is not the bill of lading itself (that's the ASN). But it is the
>component that makes the ASN the monster of all retail EDI documents.
How does this work? Does it give container within container information
with varying recursion depth? Sounds like it would map to a transative
closure problem in relational database theory.
--
/* jhallen@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]]);}
Re: Free EDI
Author: Ralph Jennings
Date: Fri, 21 Feb 1997 00:00
Date: Fri, 21 Feb 1997 00:00
90 lines
5203 bytes
5203 bytes
Joseph H Allen <jhallen@world.std.com> wrote:
> 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).
EDI is now simple and easily readable, so long as you
have an EDI transfer, and a description of all the
fields.
> - It should be possible to compose an EDI message either by hand or with
> the absolute minimum in required software.
Too many typo's if composed by hand, just use software
that can translate the data (which should have gone
through checks to make sure the data is OK as you were
entering it into your system, posibly by drop-down
lists, etc.), into EDI data (which can do more checks
to make sure the data is OK, thus reducing typo's to a
minimum). And it doesn't need that much software, it
just needs a program to translate your data in your
database to an EDI format, and e-mail it.
> - 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).
1. Aren't they?
2. They do! I haven't yet dealt with a company that
said we must switch to EDI, without also giving me a
form telling me what they want (even huge corporate
businesses "mob bosses", have enough of a brain to
know that humans in general can't read each others'
minds).
> - It should be trivial for the trading partners to make changes to the
> standards.
Then what good are *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.
Well, duh. It is.
> An EDI standard should probably look like a form:
I still don't like your format, I'm fine with the current
EDI format.
> >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 crap 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).
Hmm, I just started a few months ago (not very experienced),
and have so far been succesfull. I have no books on EDI
standards, but it's simple enough, and the businesses I'm
doing EDI with, have all given me a list of everything they
need, making it easy for me to understand what it is that
they want, and making them happy. I don't know about cost
of translators, but if that's your concern, it should be
simple enough to write your own. I've written EDI->English
translators for our customer service department, and it
would be trivial to write an our_table->EDI translator (I
have allready had to hack a few things into this translator
for instance, it will allow '*'s to go into the EDI order,
and I had to hack in tr '*' '!', to fix this problem).
BTW -- My EDI->English is written in awk (soon to be C when
I get some free time).
> Of course they're still going to do it (they want the big customer).
Well, of course.
l8r, Me.
--
Sometimes,
you're better off dead.
There's a gun in your hand,
it's pointing at your head.
-- Pet Shop Boys (West End Girls)
Re: Free EDI
Author: Brent Laminack
Date: Fri, 21 Feb 1997 00:00
Date: Fri, 21 Feb 1997 00:00
38 lines
3120 bytes
3120 bytes
Ok, I'll have to put in my $0.02 worth. I work for an EDI company. (See our stuff at http://www.edisoftware.com and http://ecweb.com/catalog). I wrote our X12 translator and mapper. The mapper looks like a cross between awk and perl. Yes, I'm an old Unix bigot. We're implementing an EDI "mini-VAN" using ftp and PGP for low-cost transport. I've even tricked up the incoming mapper to take an 850 purchase order and output a SYLK spreadsheet. Where you get the $4,000+ figure for software, I don't know. Our windows package starts at $1495, and we include all the interface file layouts if you want to write your own interface to your accounting package. I'm afraid I must agree with the general thread here that EDI documents are rater complicated. One mentioned the ASN, affectionately known as "the document from hell". Also the convoluted SDQ segments in an 850 purchase order turn most order-entry applications on their head. I've been a part of a little of the ANSI ASC X12 committees, and the process is long and involved. People are used to a robust standard that can accomplish anything they want. I'm afraid a new, simplistic "free-EDI" standard approach would be viewed as sort of an IBM-PC jr of the standards world. Simple text files that are human-readable is a nice idea, but the classic EDI document is designed to be a transport from one application (i.e. purchasing) to another application (i.e. order entry) at another company. EDI was never designed to be human-readable any more than TCP packets are human- readable. They're supposed to make sense to the program on the other end. That's all. If you want to make both highly structured and human-readable, you'd have to think along the lines of SGML for the machine-readable structure, and supply a "browser" for the humans to interact with. I'm afraid I'm rambling, but it's late on a Friday evening. Have fun, Brent Laminack (brent@ecweb.com)
Re: Free EDI
Author: Joseph H Allen
Date: Fri, 21 Feb 1997 00:00
Date: Fri, 21 Feb 1997 00:00
115 lines
6480 bytes
6480 bytes
In article <phrE5x9uD.2yD@netcom.com>, Paul Rubin <phr@netcom.com> wrote:
>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
E-mail ack: jhallen@world.std.com # Where to send acknowledgement
E-mail dest: orders@motorola.com # Email address of recipient
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
>orders :Refno :Placed :Purchaser :Vendor :Date
:52536 :Joe :jhallen :moto :19970212
# List of addresses
>addr :code :Name :Street :City :State :Zip...
:jhallen :Joe Allen....
:moto :Motorola Inc.....
# Itemlines
>items :code :description :qty
And so on.
>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 crap 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).
--
/* jhallen@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]]);}
Re: Free EDI
Author: Paul Rubin
Date: Sat, 22 Feb 1997 00:00
Date: Sat, 22 Feb 1997 00:00
27 lines
2476 bytes
2476 bytes
In article <E5z5C3.JL1@world.std.com>, Joseph H Allen <jhallen@world.std.com> wrote: >In article <E5yrEv.4o2@bigbird.telly.org>, >Evan Leibovitch <evan@bigbird.telly.org> wrote: > >>The HL is not the bill of lading itself (that's the ASN). But it is the >>component that makes the ASN the monster of all retail EDI documents. > >How does this work? Does it give container within container information >with varying recursion depth? Sounds like it would map to a transative >closure problem in relational database theory. Yes, HL gives container within container info with varying recursion depth. However (although I'm getting email to the contrary now), as far as I could tell nobody really used it that way except possibly for the one company that proposed it. And -nobody- I talked to seemed to understand what it was really supposed to do. The only way I could see to implement something that conformed to the letter of the standard came out looking not too useful, but I did it that way anyway, since no other reasonable choice was apparent. It wasn't so difficult, just ugly. But I have the impression (real EDI users correct me if I'm wrong) that it just isn't important to handle the full generality in practice. I continue to believe relational databases aren't a natural way to represent what goes into EDI documents.
Re: Free EDI
Author: Paul Rubin
Date: Sat, 22 Feb 1997 00:00
Date: Sat, 22 Feb 1997 00:00
111 lines
6611 bytes
6611 bytes
In article <E5yGE3.EG6@world.std.com>, Joseph H Allen <jhallen@world.std.com> wrote: >>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.). Exactly, and this (generally one-way) communication creates a lot of work for the smaller company even after an EDI package is installed. The big company supplies docs to the small company of what it wants all the fields to mean, and the small company has to deal with it. This is for the benefit of the big company, that has to deal with 100's of small companies and doesn't want to make arrangements with all of them separately. For a small company to small company partnership, the solution to this problem is to NOT USE EDI. If you're trying to totally re-invent EDI to lower the amount of communication needed (i.e. redefine the documents to pin everything precisely), good luck. EDIFACT used that approach, made only a very small dent in the problem, and the result is huge bureaucratic documents like the one you posted (the X12 book is a lot simpler). >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. This has nothing to do with the EDI docs themselves. >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. This is exactly what happens. The big company tells the small company how it wants the EDI segments and elements used for what purposes. >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). This isn't realistic. EDI docs are more human-readable than, say, Microsoft Word files, but nobody really worries about Word files being unreadable without a computer. > - It should be possible to compose an EDI message either by hand or with > the absolute minimum in required software. Again not realistic, if you look at the amount of detail that the usage of every segment is spelled out in, as part of a trading partner agreement. > - 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). Yes this would be nice; did you say EDIFACT was freely copyable? If it is, why not just use it? > - It should be trivial for the trading partners to make changes to the > standards. Already trivial. > - 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. Well the X12 books I saw were on paper, but we had people type the info in so the translators could use the descriptions. >An EDI standard should probably look like a form:... Might be fairly reasonable in theory, but existing standards work for what they are designed for. >>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 crap 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). Yes, and if a set of new and incompatible EDI standards appears overnight, you'll find the big customer isn't going to be interested in it. BTW, I think you can get some translation packages for under $4k now, and you shouldn't need a copy of X12 to use a package. The package should come with its own set of document descriptions, and you just pick the fields you want to use etc.
Re: Free EDI
Author: Joseph H Allen
Date: Sat, 22 Feb 1997 00:00
Date: Sat, 22 Feb 1997 00:00
173 lines
7774 bytes
7774 bytes
In article <phrE5zB8v.DJy@netcom.com>, Paul Rubin <phr@netcom.com> wrote:
>I continue to believe relational databases aren't a natural way to
>represent what goes into EDI documents.
Relational databases are a very general- any data structure can be mapped to
them (structures, lists, trees, even self-referential trees like grammars).
Most modern databases are relational: what more natural choice could there
be for transfering data between databases?
Well here's a revised example Free-EDI purchase order. I changed the
overall format so that long lines are broken by whitespace (if a line begins
with whitespace, it is a continuation of the previous line and the
whitespace is reduced to a single space, also whitespace around fields is
ignored). Thus a transaction can be formatted so as to be humanly readable.
Also I've added column and table descriptions and Mandatory/Optional
qualifiers for tables and columns. The idea is that you could have a
program which prompts a user for data given a copy of the standard or even
an instance of any transaction. Alternatively, there could be a program
which verifies syntax and ensures that mandatory data is really given.
Additional information could be given along with the column and table
definitions: column width, whether a column or set of columns must be
unique, range qualifiers for numeric types, whether a column is a code which
indexes another table and so on. It would be conceivable that database
consistency expressions could be specified as in some RDMSs, but I think
that would probably be a little over done. I was also thinking that it
would be neat if a transaction could survive being sorted by cleverly
ordering the line type characters. It would be possible, but is probably
not all that necessary.
I think this would be a vast improvement over the current EDI format. It's
self-documenting, humanly readable and requires only a single simple parser
which doesn't depend on the type of data being transmitted.
Still... if there is no real interest I'll drop the issue. There is already
a push for EDI over e-mail and UN/EDIFACT is publicly available- which were
my biggest complaints in the first place. Free-EDI won't help me in my job,
but I can always wish for a gnu world...
; Begin Free-EDI transactions. The following line tells where the mail
; header ends and our data begins. The first character of the line
; identifies the line type. Blank lines and lines beginning with ; are
; ignored.
beginning of Free-EDI data
; Free-EDI version number
v free-edi.1
; Begin transaction with unique transaction I.D.
x jhallen@world.std.com.1557736
; Tables which make up the transaction
; Header table
t header(m) Standard free-edi.1 transaction header table
; Column descriptions for header table
c date(date,m) Date transaction has been submitted.
c from(text,m) Sender's e-mail address.
c to(text,m) Recipient's e-mail address.
c form(text,m) Form identifier.
; Column ordering for header table '|' is field separator.
|date |from |to
|form
; Records which make up the table
|1997-02-18.04:30 |jhallen@world.std.com |free-edi@motorola.com
|Simple-Order-USA.1
; Orders table
t orders(m) A table of the orders being submitted by this transaction.
; Column descriptions
c refno(text,m) Identifies the order.
c billto(text,m) Identifies who is paying for the order. See the
addresses list which follows.
c shipto(text,m) A code for the address where the order is to be
shipped. See the addresses list which follows.
c placedby(text,o) Optional name of the person who is placing the order.
c paymethod(text,m) A code for the payment method to be used for this
order.
c shipvia(text,m) A code for the shipping method to be employed in
delivering this order.
c shipdate(date,o) Requested arrival date for this order.
; Column ordering
>refno |billto |shipto|placedby|paymeth|shipvia |shipdate
; Records
|1000 |joe |joe |joe |net30 |fedex-2 |1997-02-19
|1023 |joe |joe |joe |ccard |ups-blue |1997-02-19
t addresses(o) A list of addresses used throughout this order.
c addrcode(text,m) Code which identifies this address.
c name(text,m) Company name.
c street(text,m) Street.
c city(text,o) City.
c state(text,o) State.
c zipcode(text,m) Zip.
c contact(text,o) Contact.
c phone(text,o) Phone number.
; Column ordering
>addrid |name
|street
|city |state |zipcode
|contact |phone
; Records. Notice that they can be fairly free-form.
|joe |Joseph Allen
|53 Windor St.
|Hackensack |NJ |11359
|joe |567-133-1234
|pete |Pete Cronin
|125 Edwards ave.
|Plainfield |MA |01010
|pete |508-221-1122
t itemlines(m) A list of the items being ordered.
c refno(text,m) Code which identifies the order
c itemcode(text,m) Code which identifies item
c description(text,o) Description of item.
c qty(int,m) Quantity ordered.
>refno |itemcode|description |qty
|1000 |106041 |1 micron steal bearings |8000
|1002 |104008 |3" steel bearings |50
t shipvia(o) A list of possible shipping methods
c shipvia(text,m) Shipping code.
c description(text,o) Description of the shipping method.
>shipvia |description
|ups-red |Overnight with UPS
|ups-blue|2nd day UPS
|fedex-1 |Fedex priority
|fedex-2 |Fedex 2nd day
t paymeth(o) A list of possible payment methods
c paymeth(text,m) Code for the payment method.
c description(text,o) Description of payment method
c pono(text,o) Purchase order no.
c ccard(text,o) Credit card no.
>paymeth |description |pono |ccard
|net30 |Bill purchaser | |
|po |Use given PO number |123456 |
|ccard |Use this credit card | |1234123412341234 12/99
; End transaction with transaction I.D.
e jhallen@world.std.com.1557736
; End of all transactions
z
--
/* jhallen@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]]);}
Re: Free EDI
Author: Bala Ayres
Date: Sat, 22 Feb 1997 00:00
Date: Sat, 22 Feb 1997 00:00
21 lines
1990 bytes
1990 bytes
Joseph H Allen wrote: > > In article <E5yrEv.4o2@bigbird.telly.org>, > Evan Leibovitch <evan@bigbird.telly.org> wrote: > > >The HL is not the bill of lading itself (that's the ASN). But it is the > >component that makes the ASN the monster of all retail EDI documents. > > How does this work? Does it give container within container information > with varying recursion depth? Sounds like it would map to a transative > closure problem in relational database theory. > Yes, the HL gives container information...In an example at http://www.ayressoft.com i have demonstrated how 856 is used at 4 levels namely shipment, order, packaging and item. The code is in VB demonstrating how the 4 levels is achieved. Bala Ayres Ayres Software Inc. ayres@ayressoft.com
Re: Free EDI
Author: Christopher B. Browne
Date: Sat, 22 Feb 1997 00:00
Date: Sat, 22 Feb 1997 00:00
31 lines
2841 bytes
2841 bytes
On Sat, 22 Feb 1997 05:27:14 GMT, Joseph H Allen <jhallen@world.std.com> posted: >In article <phrE5zB8v.DJy@netcom.com>, Paul Rubin <phr@netcom.com> wrote: >>I continue to believe relational databases aren't a natural way to >>represent what goes into EDI documents. > >Relational databases are a very general- any data structure can be mapped to >them (structures, lists, trees, even self-referential trees like grammars). >Most modern databases are relational: what more natural choice could there >be for transfering data between databases? If the standards are directed towards *specific* algorithmic procedures and operations, then it's quite possible for the "general" solution to not be compatible with the idioms of the standards. Incidentally, you probably should be proposing use of the vCard specification system for addresses, and vCalendar for specification of scheduled events. That's what's in process of becoming the IETF standard for dealing with "address" and "schedule" information. Not so incidentally, people with "rolodex" and "calendar" apps should probably look seriously at the respective standards as well in order to improve interoperability. Wouldn't it be nice to be able to say: "You want to send some addresses, and you're using Frankin Ascend? Send me a .vsc file; Ical can handle that..." -- Christopher B. Browne, cbbrowne@unicomp.net, chris_browne@sdt.com "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/
Re: Free EDI
Author: Bryan G. Olson
Date: Sun, 23 Feb 1997 00:00
Date: Sun, 23 Feb 1997 00:00
16 lines
1818 bytes
1818 bytes
Brian Osman wrote: > 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! [...] What restrictive licensing are you talking about? I try to stay up on these things, and I have not heard of any law restricting domestic crypto in the US. Are you just talking about licensing patents or copyrighted works? Follups directed to talk.politics.crypto. --Bryan
Re: Free EDI
Author: Christopher Horn
Date: Sun, 23 Feb 1997 00:00
Date: Sun, 23 Feb 1997 00:00
27 lines
2385 bytes
2385 bytes
Paul Rubin wrote: > Yes, HL gives container within container info with varying recursion > depth. However (although I'm getting email to the contrary now), > as far as I could tell nobody really used it that way except possibly > for the one company that proposed it. And -nobody- I talked to seemed > to understand what it was really supposed to do. The only way I could > see to implement something that conformed to the letter of the standard > came out looking not too useful, but I did it that way anyway, since > no other reasonable choice was apparent. It wasn't so difficult, just > ugly. But I have the impression (real EDI users correct me if I'm > wrong) that it just isn't important to handle the full generality > in practice. While not explicitely stated, for some reason I was under the impression that it was limited to a depth of 5. Truck, pallet, tote or case, container or unit item, unit item. But then, I only looked at the spec passingly so probably misunderstood it. > I continue to believe relational databases aren't a natural way to > represent what goes into EDI documents. Agreed. Cheers, Chris
Re: Free EDI
Author: Joe Buck
Date: Mon, 24 Feb 1997 00:00
Date: Mon, 24 Feb 1997 00:00
23 lines
2028 bytes
2028 bytes
osmanb@rpi.edu writes: >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! You're talking about patents. Some of the critical public-key crypto patents expire this year (for example the basic Diffie-Hellman patent that purports to cover all public-key crypto). This means that patent-free public-key crypto will be possible by fall. (See the FSF's software tasks list for a mention of this). Even in the presence of a patent, there are workarounds in many cases, such as use of RSAREF, or US commercial users obtaining licenses for the right to use the appropriate free (rather, free for everyone else) software. -- -- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html Help stamp out Internet spam: see http://www.vix.com/spam/
Re: Free EDI
Author: Dave Paulsen
Date: Tue, 25 Feb 1997 00:00
Date: Tue, 25 Feb 1997 00:00
93 lines
5768 bytes
5768 bytes
In article <E5v7qE.D85@world.std.com>, jhallen@world.std.com says... > >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 Hi Joseph...I really sympathize with the sentiment of creating an open standard alternative to EDI. The thing is, we already have one: HTTP and HTML. Before you laugh yourself sick, read on :-) I think it's useful to remember what EDI was originally created for, as you point out... >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. > ...and also remember that this was before every device smarter than a toaster had a tcp/ip stack (so I guess this leaves out Ellison's NetPC). Anyway, the need was to securely communicate business documents and perform transactions. This is taken care of now by HTTP for the communications, HTML for the documents/forms, and security can be handled by SSL or S-HTTP. This leaves transactions. And again, we have an existing open standard:CORBA. Not only does this take care of the database abstraction layer, but it alleviates all the pain of trying to define your own Transaction Processing Monitor (TPM) as you're trying to do in another message in this thread, as object-based TPMs are a special type of ORB. >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 > HTTP and HTML take care of that combination. >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. > As has been pointed out by someone else on this thread, secure MIME specs are available, but to secure e-mail and most other documents, I agree that PGP is the best way to go. And, in regards to another message in this thread, it is available on all sides of the pond, so should be useful internationally. The transport mechanism itself for SMTP, though, I don't think should be overloaded with setting up and tearing down secure communication channels, and I don't think the best method of EFT has an SMTPd in the path. > - 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. > Another reason why, for distributed transaction processing across networked databases (in case anyone was wondering, I stumbled across this thread in comp.databases) to just use existing TPMs. For starters, what mechanism do you intend to build into SMTP servers to handle error reporting. You've said you won't permit partial transactions, which is good, but for a system that will be transferring peoples hard earned money and possibly affect credit ratings, you need a real TPM. > - Transaction IDs will be universally unique. This will allow Free EDI > transactions to be broadcast via USENET or in USENET-like environments. EDI spam...I can see it now...I think even considering to use NNTP is even a worse idea than SMTP...what happens when someone crossposts a PO :-) [SNIP: all the data record and table layout...nice job though] >Please start discussing the sufficiency of this as a data format. > One of the problems with EDI is that it trys to be all things to all people. 99% of those fields will only be used 5% of the time. The strength of the web for enabling commerce is that it allows a company to put its order form online so someone can order x Widgets. If only certain someones are supposed to see certain forms, they can be protected by various means. Companies are already sending sensitive documents across the 'net, according to their unique needs. Banks are using SSL and S-HTTP, it's how I do my banking...no EDI needed or wanted. -- _dave_(seemingly obligatory and definitely bandwidth wasting .sig)
Re: Free EDI
Author: Tony Toews
Date: Wed, 26 Feb 1997 00:00
Date: Wed, 26 Feb 1997 00:00
17 lines
1683 bytes
1683 bytes
dave@ixa.net (Dave Paulsen) wrote: > The strength of the web >for enabling commerce is that it allows a company to put its order form online >so someone can order x Widgets. Or what I see as being fairly useful is the ability for a vendor to put the customer's previously ordered items and/or history as a pre-built order thus allowing for fast re-ordering of common items. Tony ---- Tony Toews, Independent Computer Consultant Jack of a few computer related trades and master (or certified) of none. Microsoft Access Hints & Tips: Accounting Systems, Winfax Pro, Reports and Books at http://www.granite.ab.ca/accsmstr.htm
Re: Free EDI
Author: Ralph Jennings
Date: Mon, 03 Mar 1997 00:00
Date: Mon, 03 Mar 1997 00:00
16 lines
1677 bytes
1677 bytes
In comp.os.linux.misc marcobk@worldonline.nl wrote: > So : Is there a FREE EDI translater and mapper for linux or whatever > OS ? I dunno, but I wouldn't mind working on one (though I don't want to be the sole person working on this). l8r, Me. -- Sometimes, you're better off dead. There's a gun in your hand, it's pointing at your head. -- Pet Shop Boys (West End Girls)
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads