What a good idea !
> -----Original Message-----
> From: Michael Pokraka [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, December 14, 2000 3:40 AM
> To: [EMAIL PROTECTED]
> Subject: Re: 850 vs 860
>
> ...and just to add my 2<insert local currency>:
> Though we're mostly EDIFACT, I use an alias on our TLE translator to point
> all ORDRSP's to use the corresponding ORDERS map. Makes maintenance etc. a
> lot easier.
>
> -----Original Message-----
> From: William J. Kammerer [mailto:[EMAIL PROTECTED]]
> Sent: 12 December 2000 22:02
> To: [EMAIL PROTECTED]
> Subject: Re: 850 vs 860
>
>
> Michael Weir, of Transform Research, wrote:
>
> I'm looking at the 850 and the 860, trying to figure out
> why there's an 860 in the first place. The 860 seems to
> have just about the same fields that the 850 has. Since
> there's only 999 document numbers available, why did they
> define the 860 instead of adding some semantics to the 850?
> After all, there is a Transaction Set Purpose Code of
> 04-Change, which is valid for the 850.
>
> I assume that I'm missing something. Can anyone explain?
>
> Dear Michael:
>
> You're not missing anything at all. The ASC X12 850 Purchase Order is
> indeed very similar in arrangement to the 860 Purchase Order Change
> Request - Buyer Initiated. And we'd probably find out that both of
> these transaction sets are somewhat like the 855 Purchase Order
> Acknowledgment and the 865 Purchase Order Change
> Acknowledgment/Request - Seller Initiated.
>
> The very same thing happens in UN/EDIFACT, where the ORDERS (Purchase
> Order), ORDCHG (Purchase Order Change Request), and ORDRSP (Purchase
> Order Response) Messages are nearly identical in their segment and
> segment group layouts. I'm sure I could find more examples by comparing
> like-named messages using the EDISIM Comparator. See
> http://www.foresightcorp.com/pages/products/edisim/ese.html.
>
> As Dan Kazzaz indicated, a lot of this is "historical convenience," or
> *Baggage*. Both X12 and EDIFACT have been equivocal about the matter of
> when to create or "spin-off" a new message or transaction, even if of
> similar function. For example, see the UN/EDIFACT WORKING GROUP (EWG)
> Documents at http://www.edifact-wg.org/, where the Message and Code
> Handbook (MACH)(CEFACT/GE.1/1998/4) says in Part I - Guidelines about
> when to design a message: "there is no clear guidance on when to design
> a new message instead of reusing an existing one." This is recognized
> by some examples: "messages which cover several processing activities
> (e.g. original, change, deletion, response, acknowledgement);" and
> "messages which are limited to one processing activity (e.g. ORDERS,
> ORDCHG, ORDRSP)."
>
> Further, in section 2.5, Guidelines, the MACH states: "Message types
> with similar structures may be an indication of similarities at business
> function level. Similar message types may be combined in a more generic
> message type supporting several business functions if it is agreeable to
> parties involved in the business domains."
>
> Even if similar messages or transaction sets were designed at the same
> time, they often start diverging as time goes on and maintenance is
> applied to the segment structure of one, but not the other. EDIFACT has
> done a better job of keeping the messages in sync than X12 has, though.
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Memorial Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "Commerce for a New World"
>
> =======================================================================
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
>
>
> -----------------------------------------------------------------------
>
> The information contained in this email may be privileged, confidential
> and protected from disclosure. The opinions expressed are those of the
> individual and not Samsung Semiconductor Europe Ltd or Samsung
> Electromechanics Ltd. Internet communications are not secure and
> therefore Samsung Semiconductor Europe Ltd and Samsung
> Electromechanics Ltd do not accept legal responsibility for the contents
> of this message. If you think you have received this email in error please
> notify the sender or mail "[EMAIL PROTECTED]" and delete any
> copies of the mail.
>
> =======================================================================
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
