[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-lcsc] Re: RE: [Order Response] Order Response in the businessprocess
in which case, it would be useful if we would prepare for the disucssion next week by having an outline of the components we think will be necessary and which of the existing ones are re-usable. sally.m.chan@boeing.com wrote: > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C2066D.A38F61C0 > Content-Type: text/plain; > charset="iso-8859-1" > > Your model looks fine, and it supports your business process described in > the second paragraph in your email. And UBL should support a more generic > model rather than the Boeing specific model. > > Yes, the Order Response message should reference the original PO message, > whether the Order Response is for an Order Change or an Order Cancellation, > it still ties back to an original PO. (in my ATA PO experience, they use an > Acknowledgement Number for this tracking purpose, this data element is used > in the PO Change and Shipment Advisory messages.) > > > Thanks, > Sally Chan > > -----Original Message----- > From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] > Sent: Tuesday, May 21, 2002 1:45 AM > To: Chan, Sally M > Cc: 'Michael Adcock'; ubl-lcsc@lists.oasis-open.org > Subject: [Order Response] Order Response in the business process > > > how does this model now look? bear in mind, it is not intended to be the > exact implementation used by Boeing. Rather, it should be a more generic > model. > > most importantly, i would like us to agree that the Order Response message > can indicate acceptance or rejection of an Order, acceptance or rejection of > an Order Change or acceptance or rejection of an Order Cancellation. As > previously agreed, it will not allow changes to anything on the Order. > > If this is true, then the question we must resolve is: does the message we > are building need only reference the original Order (or Orders??) and its > message (or messages ??) and indicate a condition of status? > > > Chan, Sally M wrote: > > > Tim, > page 17-21 of the eBTWG BP worksheet I sent our few weeks ago has several > diagrams showing the collaboration of the parties and the documents > (transactions) exchanged between the parties. Your diagram is fine the way > it is. To represent the Boeing procurement process, please see my diagram > attached. Either diagram is just an example of the many ways an Order > Acknowledgement document used in a business process, and we will not cover > them all. > > I called ATA (Air Transport Association) this morning to discuss "What is > the Order Acknowledgment used for?" In my previous email, see below, we > checked for certain data in the PO and then decide whether to process it or > not. If we process it, we send out an acknowledgement, otherwise we reject. > These data are not really the content of the Purchase Order. So the use of > Order Acknowledgement in Boeing's procurement process is for a functional > purpose, it is acknowledging the receiving of the PO transmition, nothing > more. > > Now, with more understanding of the purpose of an Order Acknowledgment, > where do we go from here? I think we need to define what we want the Order > Response document do and go from there. > > Thanks, > Sally Chan > > -----Original Message----- > From: Tim McGrath [ mailto:tmcgrath@portcomm.com.au > <mailto:tmcgrath@portcomm.com.au> ] > Sent: Tuesday, May 14, 2002 11:48 PM > To: Chan, Sally M > Cc: 'Michael Adcock'; ubl-lcsc@lists.oasis-open.org > <mailto:ubl-lcsc@lists.oasis-open.org> > Subject: Re: [ubl-lcsc] [Order Response]Re: Getting started on Order Respo > nse > > > following our discussion yesterday, i have attempted a sequence digram of > the messages we are discussing (see attached). i have attempted to show > that there are a set of exchanges prior to the seller's acknowledgement (ie > acceptence or rejection of the order) which cover the negotiation of > amendments prior to contract. to keep it simple i am assuming that before > this any modifications cause a new order to be created. (a la boeing) > > once an order has been accepted then we can have order changes and order > cancellations. > > let me know if this makes sense to you. > > the document we are talking about as our next schema is the 'Acknowledge > Order' document - which we will call Order Response. > > Chan, Sally M wrote: > > > The Order Acknowledgement is used to confirm some PO information ( i.e. > supplier code, total quantities ordered, total amount ) are correct and can > be processed downstream. If incorrect information found, system will send a > Rejection to the PO submitted. Order Acknowledgement is sent from Buyer to > Seller. > > The Order Exception (order change) is used to inform the customer, airlines, > about changes to their PO submitted (i.e. part number replacement, > quantities increased/decreased, unit of measure changes, schedule ship date > changes, and unit price changes). Order Exception is sent from Seller to > Buyer. If Buyer decided to make changes to the original PO, Buyer will > submit a new PO, not an Order Exception. > > Thanks, > Sally Chan > > > -----Original Message----- > From: Michael Adcock [ mailto:Michael.Adcock@apacs.org.uk > <mailto:Michael.Adcock@apacs.org.uk> ] > Sent: Frida > > y, M > ay 10, 2002 1:23 AM > To: tmcgrath@portcomm.com.au <mailto:tmcgrath@portcomm.com.au> > Cc: ubl-lcsc@lists.oasis-open.org <mailto:ubl-lcsc@lists.oasis-open.org> > Subject: [ubl-lcsc] [Order Response]Re: Getting started on Order > Response > > > Hi Tim! > > The one thing that I baulk at just a little is what UN/EDIFACT ORDRSP > says under 1.3 Principles, " - a proposal of amendment..." I recall that > we ran into a scope and 'business rules' problem with this phrase in > Scandinavia (construction industry), where they insisted on the Order > Response being a confirmation of an order or an order change, with Order > Change going in either direction and being the only means of amending an > order. The seller substituting an item would raise an Order Change, and > the buyer would respond with the confirming order Response. > The Order response is therefore a busin > > ess conf > irmation of 'what is'. > > I feel we should wait and see what reaction comes from people on the > circulation. So, is there anybody there with a comment, please... > > > Mike Adcock > Standards & Security Unit > APACS - Association for Payment Clearing Services > Mercury House, Triton Court > 14 Finsbury Square > London EC2A 1LQ > Tel: +44 (0) 20 7711 6318 > Fax: +44 (0) 20 7711 6299 > e-mail: michael.adcock@apacs.org.uk <mailto:michael.adcock@apacs.org.uk> > > > Tim McGrath <mailto:tmcgrath@portcomm.com.au> <tmcgrath@portcomm.com.au> > 10/05/02 09:12:20 >>> > > I think your question relates to the discussion we had with Arofan on > > tuesday's call. Each document needs to be defined in the context of > the > purpose it serves in a business process. Sally and Frank are fleshing > > this out as part of the SCM business process definition. In the > meantime, we are pushing on using 'common practice' as our guide. > > With Order Response i think we agreed it would be the document sent by > a > seller in response to an order (or order change) sent a buyer. This > fits the xCBL definition "to respond at the application level to an > order or change order that has been received.". this is consistent > with > the EDIFACT use as well. > > To get a better definition of the purpose, i went through the various > documents given in the ebXML Catalog of Common Business Processes for > the Manage Purchase Order business process. I came up with.... > > UN/EDIFACT ORDRSP says > > ...< > br>" > > 1.3 Principles > > - A seller may respond for one or more goods items or services. > > - The response may be for a Purchase order or a Purchase order > change request: > > - an acknowledgment of receipt and understanding of data, > > - confirmation of acceptance, > > - a proposal of amendment, > > - a notification of non-acceptance for all or part of the > message. > > - A purchase order response may refer to goods items or > services related to one or more delivery schedules, call-offs, > etc. > > - A purchase order response for cross-border transactions may > contain additional information for customs and/or statistical > purposes. > > - A purchase order response may contain details for transport > and destination as well as delivery patterns. > > > > - A buyer's purchase order may be responded to by one or more > response messages, according to business practice." > > OAG 004 Acknowledge PO says..."The purpose of the ACKNOWLDGE PO > Business > Object Document is to acknowledge receipt of the Purchase Order and to > > reflect any changes." > > I cant afford the X12 875/876 specs :-( , but I know from experience > they also cover changing any component within the Order. So do other > proprietary EDI business processes, such as BISAC in the book > publishing > industry. > > I suspect the major difference between Order Response and Order Change > > is the direction of the flow (seller->buyer not buyer->seller) and the > > contractual obligations associated with that. It is also likely an > Order Response may need to reference the item or components of the > original Order(s) that this responding to. For example, "i wish to > substitute product XYZ for A > > BC on line 23" > . > > An Order Change is the document used for every modification to goods, > services or conditions that are sent by the buyer to seller after the > original Order. > > An Order Response is the way a seller communicates their ability to > satisfy the conditions of the Order. As for your example, whilst none > > of this is caste in stone, i suggest in common practice, in cases where > > prices are being sought, another set of documents (the pre-order set) > are used, i.e. Request for Quote and Quote. > > What you have also done is highlight that Order Response can (and > sometime is) used just as a implementation convention response, that is > > 'you got all the structures and codes right/wrong' - not an application > > response at all, in that these are often sent by corporate gateway > systems. A true Order Response (the one we want to define) is one that > > is generated out of the Sales application that says thin > > gs like 'i have > > have checked the stock and my catalog and can supply the > following...'. > > Does that make sense? Can we proceed on this basis? > > > Michael Adcock wrote: > > > H! > > At first glance I only have one or two comments, which are attached. I > > stress this is very much a first glance! > > But it led to a fundamental question: "What do we see the Order > > Response as being?" > > I think it is simply a confirmation of agreed facts going back from > > the supplier to the buyer. Therefore I do not see it as the message in > which the supplier would propose any changes, such as substituting > items, changing the requested delivery date etc. These would be done by > Order Change messages going in either direction, and could be achieved > by (if simple) telephone call or by full messages. > > However, if the buyer did not specify prices or a required delivery > > date, the Order Response could convey the prices and the offered > delivery date. > > SO I think we have some scope discussion/decision to make first. Any > > thoughts? Or have I missed this being decided? > > regards > > Mike Adcock > Standards & Security Unit > APACS > > - Association for Payment Clearing Services > Mercury House, Triton Court > 14 Finsbury Square > London EC2A 1LQ > Tel: +44 (0) 20 7711 6318 > Fax: +44 (0) 20 7711 6299 > e-mail: michael.adcock@apacs.org.uk <mailto:michael.adcock@apacs.org.uk> > > <mailto:michael.adcock@apacs.org.uk> <mailto:michael.adcock@apacs.org.uk> > > > > ********************************************************************** > The opinions expressed are those of the individual and not the > > company. > > Internet communications are not secure and therefore APACS does not > > > > accept legal responsibility for the contents of this message. > If the reader of this message is not the intended recipient, or the > employee responsible for delivering this communication to the > > intended > > recipient, you are hereby notified that any disclosure, distribution > > or > > copying of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately > > by > > teleph > o > ne to arrange for its return. Thank you. > ********************************************************************** > > Part 1.1 > > Content-Type: > > text/plain > Content-Encoding: > > quoted-printable > > > > > ------------------------------------------------------------------------ > > OrderResponse-Comment1.doc > > Content-Type: > > application/msword > Content-Encoding: > > base64 > > > > > > > -- > regards > tim mcgrath > fremantle western australia 6160 > phone: +618 93352228 fax: +618 93352142 > > > > Figure3b ProcurementSequenceDiagram.doc > > Content-Type: > application/msword > > Content-Encoding: > base64 > > > > -- > > regards > > tim mcgrath > > fremantle western australia 6160 > > phone: +618 93352228 fax: +618 93352142 > > > > ------_=_NextPart_001_01C2066D.A38F61C0 > Content-Type: text/html; > charset="iso-8859-1" > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <HTML><HEAD> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> > > > <META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD> > <BODY> > <DIV><SPAN class=803012017-28052002><FONT face=Arial color=#000080 size=2>Your > model looks fine, and it supports your business process described in the second > paragraph in your email. And UBL should support a more generic model > rather than the Boeing specific model. </FONT></SPAN></DIV> > <DIV><SPAN class=803012017-28052002><FONT face=Arial color=#000080 > size=2></FONT></SPAN> </DIV> > <DIV><SPAN class=803012017-28052002><FONT face=Arial color=#000080 size=2>Yes, > the Order Response message should reference the original PO message, whether the > Order Response is for an Order Change or an Order Cancellation, it still ties > back to an original PO. (in my ATA PO experience, they use an > Acknowledgement Number for this tracking purpose, this data element is used in > the PO Change and Shipment Advisory messages.)</FONT></SPAN></DIV> > <DIV> </DIV> > <P><FONT face=Arial size=2>Thanks,</FONT> <BR><FONT face=Arial size=2>Sally > Chan</FONT> </P> > <BLOCKQUOTE> > <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma > size=2>-----Original Message-----<BR><B>From:</B> Tim McGrath > [mailto:tmcgrath@portcomm.com.au]<BR><B>Sent:</B> Tuesday, May 21, 2002 1:45 > AM<BR><B>To:</B> Chan, Sally M<BR><B>Cc:</B> 'Michael Adcock'; > ubl-lcsc@lists.oasis-open.org<BR><B>Subject:</B> [Order Response] Order > Response in the business process<BR><BR></FONT></DIV>how does this model now > look? bear in mind, it is not intended to be the exact implementation > used by Boeing. Rather, it should be a more generic model.<BR><BR>most > importantly, i would like us to agree that the Order Response message can > indicate acceptance or rejection of an Order, acceptance or rejection of an > Order Change or acceptance or rejection of an Order Cancellation. As > previously agreed, it will not allow changes to anything on the > Order.<BR><BR>If this is true, then the question we must resolve is: does the > message we are building need only reference the original Order (or Orders??) > and its message (or messages ??) and indicate a condition of > status?<BR><BR><BR>Chan, Sally M wrote:<BR> > <BLOCKQUOTE > > type="cite"> > <META content="MSHTML 6.00.2600.0" name=GENERATOR> > <DIV><SPAN class=992061722-15052002><FONT face=Arial color=#000080 > size=2>Tim, </FONT></SPAN></DIV> > <DIV><SPAN class=992061722-15052002><FONT face=Arial color=#000080 > size=2>page 17-21 of the eBTWG BP worksheet I sent our few weeks ago has > several diagrams showing the collaboration of the parties and the documents > (transactions) exchanged between the parties. Your diagram is fine the > way it is. To represent the Boeing procurement process, > please see my diagram attached. Either diagram is just an example > of the many ways an Order Acknowledgement document used in a > business process, and we will not cover them all.</FONT></SPAN></DIV> > <DIV><SPAN class=992061722-15052002></SPAN><SPAN > class=992061722-15052002></SPAN> </DIV> > <DIV><SPAN class=992061722-15052002><FONT face=Arial color=#000080 size=2>I > called ATA (Air Transport Association) this morning to discuss "What is the > Order Acknowledgment used for?" In my previous email, see below, we > checked for certain data in the PO and then decide whether to process > it or not. If we process it, we send out an acknowledgement, otherwise > we reject. These data are not really the content of the Purchase > Order. So the use of Order Acknowledgement in Boeing's procurement > process is for a functional purpose, it is acknowledging the receiving > of the PO transmition, nothing more. </FONT></SPAN></DIV> > <DIV><SPAN class=992061722-15052002></SPAN> </DIV> > <DIV><SPAN class=992061722-15052002><FONT face=Arial color=#000080 > size=2>Now, with more understanding of the purpose of an Order > Acknowledgment, where do we go from here? I think we need to define > what we want the Order Response document do and go from > there.</FONT></SPAN></DIV> > <P><FONT face=Arial size=2>Thanks,</FONT><BR><FONT face=Arial size=2>Sally > Chan</FONT></P> > <BLOCKQUOTE> > <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma > size=2>-----Original Message-----<BR><B>From:</B> Tim McGrath [<A > class=moz-txt-link-freetext > > Tuesday, May 14, 2002 11:48 PM<BR><B>To:</B> Chan, Sally M<BR><B>Cc:</B> > 'Michael Adcock'; <A class=moz-txt-link-abbreviated > > Re: [ubl-lcsc] [Order Response]Re: Getting started on Order Respo > nse<BR><BR></FONT></DIV>following our discussion yesterday, i have > attempted a sequence digram of the messages we are discussing (see > attached). i have attempted to show that there are a set of > exchanges prior to the seller's acknowledgement (ie acceptence or > rejection of the order) which cover the negotiation of amendments > prior to contract. to keep it simple i am assuming that before this > any modifications cause a new order to be created. (a la > boeing)<BR><BR>once an order has been accepted then we can have order > changes and order cancellations.<BR><BR>let me know if this makes sense to > you.<BR><BR>the document we are talking about as our next schema is the > 'Acknowledge Order' document - which we will call Order > Response.<BR><BR>Chan, Sally M wrote:<BR> > <BLOCKQUOTE > > type="cite"><PRE wrap="">The Order Acknowledgement is used to confirm some PO information ( i.e.<BR>supplier code, total quantities ordered, total amount ) are correct and can<BR>be processed downstream. If incorrect information found, system will send a<BR>Rejection to the PO submitted. Order Acknowledgement is sent from Buyer to<BR>Seller.<BR><BR>The Order Exception (order change) is used to inform the customer, airlines,<BR>about changes to their PO submitted (i.e. part number replacement,<BR>quantities increased/decreased, unit of measure changes, schedule ship date<BR>changes, and unit price changes). Order Exception is sent from Seller to<BR>Buyer. If Buyer decided to make changes to the original PO, Buyer will<BR>submit a new PO, not an Order Exception.<BR><BR>Thanks,<BR>Sally Chan<BR><BR><BR>-----Original Message-----<BR>From: Michael Adcock [<A class=moz-txt-link-freetext > ent: Frida > y, M<BR>ay 10, 2002 1:23 AM<BR>To: <A class=moz-txt-link-abbreviated href="mailto:tmcgrath@portcomm.com.au";>tmcgrath@portcomm.com.au</A><BR>Cc: <A class=moz-txt-link-abbreviated > ess conf<BR>irmation of 'what is'.<BR><BR>I feel we should wait and see what reaction comes from people on the<BR>circulation. So, is there anybody there with a comment, please...<BR><BR><BR>Mike Adcock<BR>Standards & Security Unit<BR>APACS - Association for Payment Clearing Services<BR>Mercury House, Triton Court<BR>14 Finsbury Square<BR>London EC2A 1LQ<BR>Tel: +44 (0) 20 7711 6318<BR>Fax: +44 (0) 20 7711 6299<BR>e-mail: <A class=moz-txt-link-abbreviated > <BLOCKQUOTE type="cite"> > <BLOCKQUOTE type="cite"> > <BLOCKQUOTE type="cite"><PRE wrap="">Tim McGrath <A class=moz-txt-link-rfc2396E href="mailto:tmcgrath@portcomm.com.au";><tmcgrath@portcomm.com.au></A> 10/05/02 09:12:20 >>><BR></PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=""><!----> I think your question relates to the discussion we had with Arofan on<BR><BR>tuesday's call. Each document needs to be defined in the context of<BR>the <BR>purpose it serves in a business process. Sally and Frank are fleshing<BR><BR>this out as part of the SCM business process definition. In the <BR>meantime, we are pushing on using 'common practice' as our guide.<BR><BR>With Order Response i think we agreed it would be the document sent by<BR>a <BR>seller in response to an order (or order change) sent a buyer. This <BR>fits the xCBL definition "to respond at the application level to an <BR>order or change order that has been received.". this is consistent<BR>with <BR>the EDIFACT use as well.<BR><BR>To get! > a better definition of the purpose, i went through the various <BR>documents given in the ebXML Catalog of Common Business Processes for <BR>the Manage Purchase Order business process. I came up with....<BR><BR>UN/EDIFACT ORDRSP says > ...<<BR>br>"<BR><BR>1.3 Principles<BR><BR> - A seller may respond for one or more goods items or services.<BR> <BR> - The response may be for a Purchase order or a Purchase order<BR> change request: <BR> <BR> - an acknowledgment of receipt and understanding of data, <BR> <BR> - confirmation of acceptance, <BR> <BR> - a proposal of amendment, <BR> <BR> - a notification of non-acceptance for all or part of the<BR> message.<BR> <BR> - A purchase order response may refer to goods items or<BR> services related to one or more delivery schedules, call-offs,<BR> etc.<BR> <BR> - A purchase order response for cross-border transactions may<BR> contain additional information for customs and/or statistical<BR> purposes.<BR> <BR> - A purchase order response may contain details for transport<BR> and destination as well as delivery patterns. > <BR> <BR> - A buyer's purchase order may be responded to by one or more<BR> response messages, according to business practice."<BR><BR>OAG 004 Acknowledge PO says..."The purpose of the ACKNOWLDGE PO<BR>Business <BR>Object Document is to acknowledge receipt of the Purchase Order and to<BR><BR>reflect any changes."<BR><BR>I cant afford the X12 875/876 specs :-( , but I know from experience <BR>they also cover changing any component within the Order. So do other <BR>proprietary EDI business processes, such as BISAC in the book<BR>publishing <BR>industry.<BR><BR>I suspect the major difference between Order Response and Order Change<BR><BR>is the direction of the flow (seller->buyer not buyer->seller) and the<BR><BR>contractual obligations associated with that. It is also likely an <BR>Order Response may need to reference the item or components of the <BR>original Order(s) that this responding to. For example, "i wish to <BR>substitute product XYZ for A > BC on line 23"<BR>. <BR><BR>An Order Change is the document used for every modification to goods, <BR>services or conditions that are sent by the buyer to seller after the <BR>original Order. <BR><BR>An Order Response is the way a seller communicates their ability to <BR>satisfy the conditions of the Order. As for your example, whilst none<BR><BR>of this is caste in stone, i suggest in common practice, in cases where<BR><BR>prices are being sought, another set of documents (the pre-order set) <BR>are used, i.e. Request for Quote and Quote.<BR><BR>What you have also done is highlight that Order Response can (and <BR>sometime is) used just as a implementation convention response, that is<BR><BR>'you got all the structures and codes right/wrong' - not an application<BR><BR>response at all, in that these are often sent by corporate gateway <BR>systems. A true Order Response (the one we want to define) is one that<BR><BR>is generated out of the Sales application that says thin > gs like 'i have<BR><BR>have checked the stock and my catalog and can supply the<BR>following...'.<BR><BR>Does that make sense? Can we proceed on this basis?<BR><BR><BR>Michael Adcock wrote:<BR><BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap="">H!<BR><BR>At first glance I only have one or two comments, which are attached. I<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->stress this is very much a first glance!<BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap="">But it led to a fundamental question: "What do we see the Order<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->Response as being?"<BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap="">I think it is simply a confirmation of agreed facts going back from<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->the supplier to the buyer. Therefore I do not see it as the message in<BR>which the supplier would propose any changes, such as substituting<BR>items, changing the requested delivery date etc. These would be done by<BR>Order Change messages going in either direction, and could be achieved<BR>by (if simple) telephone call or by full messages.<BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap="">However, if the buyer did not specify prices or a required delivery<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->date, the Order Response could convey the prices and the offered<BR>delivery date.<BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap="">SO I think we have some scope discussion/decision to make first. Any<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->thoughts? Or have I missed this being decided?<BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap="">regards<BR><BR>Mike Adcock<BR>Standards & Security Unit<BR>APACS <BR><BR>- Association for Payment Clearing Services<BR>Mercury House, Triton Court<BR>14 Finsbury Square<BR>London EC2A 1LQ<BR>Tel: +44 (0) 20 7711 6318<BR>Fax: +44 (0) 20 7711 6299<BR>e-mail: <A class=moz-txt-link-abbreviated > <BLOCKQUOTE type="cite"><PRE > <BLOCKQUOTE type="cite"><PRE wrap=""> Internet communications are not secure and therefore APACS does not <BR></PRE></BLOCKQUOTE><PRE wrap=""><!----><BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap=""> accept legal responsibility for the contents of this message.<BR> If the reader of this message is not the intended recipient, or the<BR>employee responsible for delivering this communication to the<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->intended<BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap="">recipient, you are hereby notified that any disclosure, distribution<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->or<BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap=""> copying of this communication is strictly prohibited. If you have<BR>received this communication in error, please notify us immediately<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->by<BR></PRE> > <BLOCKQUOTE type="cite"><PRE wrap=""> teleph<BR>o<BR>ne to arrange for its return. Thank > <BLOCKQUOTE type="cite"><PRE > <CENTER> > <TABLE border=1> > <TBODY> > <TR> > <TD> > <DIV class=headerdisplayname style="DISPLAY: inline" > align=right>Figure3b ProcurementSequenceDiagram.doc</DIV></TD> > <TD> > <TABLE border=0> > <TBODY> > <TR> > <TD> > <DIV class=headerdisplayname style="DISPLAY: inline" > align=right>Content-Type:</DIV></TD> > <TD>application/msword</TD></TR> > <TR> > <TD> > <DIV class=headerdisplayname style="DISPLAY: inline" > align=right>Content-Encoding:</DIV></TD> > > regards > tim mcgrath > fremantle western australia 6160 > phone: +618 93352228 fax: +618 93352142 </PRE><BR></BLOCKQUOTE></BODY></HTML> > > ------_=_NextPart_001_01C2066D.A38F61C0-- > > cite=mid:1238DC70E16C9B4797E000A2C5782E850113A6F9@xch-knt-22.nw.nos.boeing .com href="mailto:tmcgrath@portcomm.com.au";>mailto:tmcgrath@portcomm.com.au</A> ]<BR><B>Sent:</B> href="mailto:ubl-lcsc@lists.oasis-open.org";>ubl-lcsc@lists.oasis-open.org< /A><BR><B>Subject:</B> cite=mid:1238DC70E16C9B4797E000A2C5782E850113A6E0@xch-knt-22.nw.nos.boeing .com href="mailto:Michael.Adcock@apacs.org.uk";>mailto:Michael.Adcock@apacs.org. uk</A>]<BR>S! href="mailto:ubl-lcsc@lists.oasis-open.org";>ubl-lcsc@lists.oasis-open.org< /A><BR>Subject: [ubl-lcsc] [Order Response]Re: Getting started on Order<BR>Response<BR><BR><BR>Hi Tim!<BR><BR>The one thing that I baulk at just a little is what UN/EDIFACT ORDRSP<BR>says under 1.3 Principles, " - a proposal of amendment..." I recall that<BR>we ran into a scope and 'business rules' problem with this phrase in<BR>Scandinavia (construction industry), where they insisted on the Order<BR>Response being a confirmation of an order or an order change, with Order<BR>Change going in either direction and being the only means of amending an<BR>order. The seller substituting an item would raise an Order Change, and<BR>the buyer would respond with the confirming order Response. <BR>The Order response is therefore a busin href="mailto:michael.adcock@apacs.org.uk";>michael.adcock@apacs.org.uk</A>< BR><BR></PRE> href="mailto:michael.adcock@apacs.org.uk";>michael.adcock@apacs.org.uk</A>< BR></PRE></BLOCKQUOTE><PRE wrap=""><!----><A class=moz-txt-link-rfc2396E href="mailto:michael.adcock@apacs.org.uk";><mailto:michael.adcock@apacs.org .uk></A><BR></PRE> wrap=""><BR><BR>********************************************************** ************<BR>The opinions expressed are those of the individual and not the<BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->company.<BR></PRE> you.<BR>****************************************************************** ****<BR><BR>Part 1.1<BR><BR>Content-Type:<BR><BR>text/plain<BR>Content-Encoding:<BR><BR>quo ted-printable<BR><BR><BR><BR></PRE></BLOCKQUOTE><PRE wrap=""><!---->----------------------------------------------------------- -------------<BR></PRE> wrap="">OrderResponse-Comment1.doc<BR><BR>Content-Type:<BR><BR>application /msword<BR>Content-Encoding:<BR><BR>base64<BR><BR><BR></PRE></BLOCKQUOTE>< PRE wrap=""><!----><BR></PRE></BLOCKQUOTE><BR><PRE class=moz-signature cols="$mailwrapcol">-- <BR>regards<BR>tim mcgrath<BR>fremantle western australia 6160<BR>phone: +618 93352228 fax: +618 93352142 </PRE><BR></BLOCKQUOTE> <TD>base64</TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></CENTER><BR ></BLOCKQUOTE><BR><PRE class=moz-signature cols="$mailwrapcol">--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC