Re: [ubl] Comment about UBL 2 Ordering Process diagram

[Tim McGrath <tim.mcgrath@documentengineeringservices.com>]

on closer inspection I agree with Stephen. his revision does remove some 
ambiguity (by making it clear when to use Order Response and when to use 
Order response Simple) and removes some flows which are not very logical 
(such as adding details to the order and then accepting it yourself).

Therefore I think we should consider this as a Issue for 2.1 and revise 
it using Stephen's diagram in the next version.

Stephen Green wrote:
> Greetings UBL TC
>
> RE: Order Process Diagram
>
> Prior to UBL TC discussion of this, I thought I'd better add my own two cents
> worth: I realise the ordering process doesn't attempt or claim to show all the
> aspects of real-life use of the UBL ordering documents (e.g. no attempt to
> show that an order can be cancelled prior to order response). I agree my
> diagram version does seem to remove some possibilities but does this matter
> if it is a clarification? Maybe the things it removes can be added back in
> without obscuring anything. At the same time it should be considered
> 1. include a cancellation before the order response
> 2. there is a cycle (pointed out as we tried to use this diagram in TAG TC)
> which might need consideration - going from order 'modified' to order
> change and back to possible modification and so on - is this realistic?
> The aim with my modified diagram is only to improve the clarity (with paths
> through the process not sharing so many steps - different paths having their
> own steps , even if those steps have the same names). I didn't attend to create
> a profile as such. Nothing should be missing that is in the original,
> just clearer
> paths. Maybe add order cancellation prior to response and qualify the loop(s).
>
> Best regards
>
> Steve
>
>
> 2009/1/14 Stephen Green <stephen.green@documentengineeringservices.com>:
>   
>> Hi Tim
>>
>> Maybe this diagram isn't much use without me say re-doing all
>> the activity diagrams with the tool I use to make them consistent
>> in formatting. I've included an XMI file as well as jpeg, in case
>> you have the tool used for the original diagrams with the ability
>> to import XMI into it without losing too much - to make the diagram
>> consistent with the others.
>>
>> Let me know if there's more I can do to help. I hope this diagram
>> is clearer in terms of the paths through it not having ambiguities.
>> I notice a few minor issues still but it is just a diagram, no more.
>>
>> Best regards
>>
>> Steve
>>
>> 2009/1/6 Stephen Green <stephen.green@documentengineeringservices.com>:
>>     
>>> Yes, of course, I should produce another diagram. Won't look like
>>> format of existing one so needs another edit pass at least to bring
>>> format in line with other diagrams.
>>>
>>> 2009/1/6 Tim McGrath <tim.mcgrath@documentengineeringservices.com>:
>>>       
>>>> I think i agree with you but are your proposing updating the diagram?  i
>>>> would like to see your version of the process diagram.
>>>> Stephen Green wrote:
>>>>         
>>>>> 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
>>>
>>>       
>>
>> --
>> Stephen D. Green
>>
>> Document Engineering Services Ltd
>>
>>
>>
>> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>>
>>     
>
>
>
>   
begin:vcard
fn:Tim McGrath
n:McGrath;Tim
org:Document Engineering Services Ltd.
email;internet:tim.mcgrath@documentengineeringservices.com
title:Managing Director
tel;work:+61 893352228
tel;cell:+61 438 352228
url:www.documentengineeringservices.com
version:2.1
end:vcard