[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comment about UBL 2 Ordering Process diagram
I was asked recently abbout the Ordering process of UBL and I mention a couple of comments since things are moving toward UBL 2.1 and maybe the speec could be improved with a little clarification on Ordering. I note first that we did of course agree that UBL 2.0 would not limit the schema uses regarding the processes outlined: To quote the UBL 2.0 spec Section 4: UBL 2.0 Context of Use http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html#CONTEXT "The processes described in this section, and the business rules associated with them, define a context for the use of UBL 2.0 business documents. They are normative insofar as they provide semantics for the UBL document schemas, but they should not be construed as limiting the application of those schemas." This means the Ordering process isn't described as a limitation on the processes used with any UBL Ordering schema. The spec does seem to be ambiguous about the Ordering process. [Below I refer to processes completing when I say 'completion' not to be confused with the order itself being 'completed' - the process could 'complete' even with a cancellation of the order.] According to the UBL 2.0 spec "Figure 8. Ordering Process" http://docs.oasis-open.org/ubl/os-UBL-2.0/art/UBL-2.0-OrderingProcess.jpg the ordering can complete in several ways which depend on which document is used to respond to the order. If an OrderResponse is the document sent in response then there are three ways to complete: 1. if the OrderResponse is sent without any modification then the order can be completed by Buyer doing nothing (except of course sending signals where appropriate e.g. with ebXML) 2. if the OrderResponse is sent with modification then there are two ways to complete the process 2a. Buyer send an OrderCancellation 2b. Buyer send an OrderChange An order rejection by the Seller is typically performed using the OrderResponseSimple. I'm not sure it *can* be done using the OrderResponse document schema without customizing the schema. What isn't clear from the diagram is how the different responses relate to the different paths to completion. The diagrams might be clearer and less ambiguous about paths to completion if the 'ReceiveResponse' box was split into two or more boxes showing how different kinds of response determine different process paths. The ReceiveReponse should only lead to the 'accept order?' gateway (yes/no) if the OrderResponse did *not* include any modifications otherwise how is the Seller to know whether the modifications were accepted? It isn't clear about this. Neither exit from the gateway requires any further message to the Seller. Really it only makes sense if the diagrammed Documents prior to the 'ReceiveResponse' task are more specific. An OrderResponse with modifications ('AddDetail' followed by OrderResponse document in diagram) has to be shown following a different path to an OrderResponse without modifications ('Accept Order' followed by OrderResponse) and different again from a rejected Order ('Reject Order' followed by OrderResponse). In the latter case I would suggest only OrderResponseSimple can follow the 'Reject Order' task, by the way, though I might be corrected on that. I don't think an OrderResponse can be used to reject an order outright can it? Not without customisation? Best regards -- Stephen D. Green Document Engineering Services Ltd http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]