[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: UBL 5/22/2002: [ubl-lcsc] [Order Response] Order Response in theBusiness Process
Thanks for taking time to examine my proposal Monica. I'll start w/ a blurb on how to read the diagram, then I'll address your first two points. Those rounded boxes are "states" -- each denotes when an object satisfies some condition. The "flags" denote document transmission. The "outie" flag is the send side, and the "innie" flag is the receive side. Dashed lines denote object/document flow and solid lines denote control flow. Time flows from top to bottom. Start states are solid circles, end states are solid circles ringed in another circle. To the first question: "Seller Requested Revision" is a state entered after the Seller transmits an OrderException to the Buyer. "Seller Requested Revision" is not a process -- it's a state reached by the Seller process after transmission of the OrderException. The realization (by the Seller) that revision was required was made in the decision diamond (on Seller) labeled "Revision Required?". To the second question: same idea... "Buyer Requested Rev" is not a process, but a state achieved by the Buyer after transmission (see the previous "outie" flag) of the OrderChange document to the Seller. Does that make sense? I haven't addressed your points about parallelizing buyer and seller order change since I think we're still pretty far off a common understanding of what the model says. Once we close that gap, I'd be happy to give opinions about the substance of the model from a business perspective. Regards, Bill -----Original Message----- From: Monica Martin [mailto:mmartin@certivo.net] Sent: Wednesday, May 22, 2002 2:16 PM To: Burcham, Bill; tmcgrath@portcomm.com.au; Chan, Sally M Cc: Michael Adcock; ubl-lcsc@lists.oasis-open.org; Monica Martin Subject: UBL 5/22/2002: [ubl-lcsc] [Order Response] Order Response in the Business Process Importance: High Thanks for the activity diagram, Bill. I have two questions: * On Seller, Seller Requested Revision process occurs after an Order Exception? Would not an Order Exception be sent after a revision is identified by the seller? * On Buyer for a Seller Accepted Order, the buyer identifies if revisions are required. The Order Change occurs before the Buyer Requested Revision occurs. I could see that the Order Change could occur from both points: (1) after a seller provides a change and the buyer evaluates it, and (2) then by another buyer driven Order Change. In the interim Order Responses could be received. Can you please advise on your thoughts on this, as well as the LCSC team? If I am reading this incorrectly, please let me know. Thank you. Monica J. Martin Program Manager Drake Certivo, Inc. 208.585.5946 -----Original Message----- From: Burcham, Bill Sent: Tue 5/21/2002 9:32 AM To: 'tmcgrath@portcomm.com.au'; Chan, Sally M Cc: 'Michael Adcock'; ubl-lcsc@lists.oasis-open.org Subject: RE: [ubl-lcsc] [Order Response] Order Response in the business pr ocess I move that we discontinue the use of UML Sequence Diagrams in favor of UML Activity Diagrams for communicating process specifications. I've attached an activity diagram corresponding to Tim's sequence diagram for ordering. The activity diagram lets us formally express and tie together state transitions, conditional logic, and alternatives. A positive outcome of this increased fidelity is that the modeling process itself drives out more ambiguities. Evidence of this can be seen in the attached diagram. This modeling process drove out three situations where the sequence diagram was ambiguous or downright misleading: 1. Order change and order cancellation can happen in any order or not at all. In the sequence diagram it appears that order change must happen and then order change must happen, whereas in the activity diagram it's clear that either or neither may happen in any order. 2. when the Seller generates an Order Exception, what happens if the Buyer cannot abide the Exception? 3. when the Buyer generates an Order Change, what happens if the Seller cannot abide the requested revision? 4. when the Buyer generates an Order Cancel, what happens if the Seller is too far along in its process to allow the cancellation? I fixed the first problem in the activity diagram. I have ideas about the other three but purposely left them as TBD and flagged in red to highlight the applicability of the proposed approach. In particular #3 and #4 are answered in Tim's email (if not in his diagram) -- the Seller should generate an OrderResponse that contains the status: "order change not accepted" or "cancellation not accepted". I think #2 is still an issue though. Regards, Bill Burcham -----Original Message----- From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] Sent: Tuesday, May 21, 2002 3:45 AM To: Chan, Sally M Cc: 'Michael Adcock'; ubl-lcsc@lists.oasis-open.org Subject: [ubl-lcsc] [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] 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] 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 <tmcgrath@portcomm.com.au> <mailto: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 purpo ...< 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC