Re: [ubl] How does an OrderResponse showorder acceptance/rejection?

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Hi Tim

Yes, in UBL 2, and RejectionReasonNote (if that's what OrderResponseSimple has)
but my main point is to seek detail about the rules or implementation guidance for
UBL 1.0 such as can be used to improve the example ebBP definition (aware that
folk may try to base implementations on the example despite ernest warnings that
it is purely illustrative). Any suggestions? I guess we might want to be forwards
compatible with UBL 2 too as much as possible so maybe Denmark folk have suggestions
too (Mikkel offered in the call yesterday). I think this would be an excellent exercise
in any case and the outcome might be very useful to UBL implementers and designers,
let alone good for marketing - in mutual interest with ebBP of course.

All the best

Steve

>>> Tim McGrath <tmcgrath@portcomm.com.au> 10/11/05 00:15:43 >>>
is your proposal that Order Response also should have an AcceptedIndicator?

Stephen Green wrote:

>Greetings UBL TC
>
>This issue arises because the ebBP TC are seeking
>to improve their 'drop-ship' example of a business
>process definition for use of UBL 1.0 documents in
>a drop-ship or marketplace environment and I have
>pointed out the need to correct some of the details
>of the process's 'condition expressions'
>
>http://lists.oasis-open.org/archives/ebxml-bp/200511/msg00024.html 
>
>The condition expressions denote the conditions
>which act as the basis for decisions at forks in the
>process and acceptance or rejection of the order
>is a key one of these.
>
>The ebBP TC would welcome any help from the UBL 
>TC in advising on these conditions. I would like to help
>pin down exactly how a UBL 1.0 Order, OrderResponse 
>and OrderResponseSimple relate to each other in a 
>typical process, for instance:
>
>Since the UBL 1.0 documentation states that the
>OrderResponseSimple is the document to use by
>the Seller to show rejection or acceptance of the 
>order whereas it states that the OrderResponse is
>to be used to alter the line of the order (with no
>mention of using it to show acceptance or rejection
>and no apparent way in the document or lines of
>an OrderResponse to cater for this), I'd like to
>understand whether there is therefore a logical 
>weakness, with 1.0, in using the OrderResponse 
>enumeration of the AcknowledgementResponseCode 
>in an Order. The latter would have the weakness,
>it seems, in limiting the response to just OrderResponse
>so that there is then no way to properly signal
>acceptance or rejection of the Order (in the business
>document layer).
>
>If this is a weakness, then this ebBP exercise, I think,
>is providing a good opportunity for UBL to receive
>valuable implementation feedback of sorts and it might
>be that it leads to improvements in 2.0 (for the second
>committee draft, at this stage, I suppose) and this particular
>case shows that we may need to question whether the
>2.0 process should emphasise the possibility of using
>the OrderResponse to show rejection/acceptance of an
>Order - the OrderResponseSimple does provide for this
>functionality but does the OrderResponse?. Alternatively
>we might want to ensure that OrderResponse has this
>functionailty and if not then, besides changing the 
>documentation of the process, we might want to
>reconsider the inclusion in the Order, etc of the 
>AcknowledgementResponseCode or reconsider its
>enumerations.
>
>All the best
>
>Stephen Green
>
>
>
>  
>
>>>>"Stephen Green" <stephen_green@bristol-city.gov.uk> 09/11/05 11:18:24 >>>
>>>>        
>>>>
>Looking at how all the documents of UBL 1.0 might
>be used together in a business process, I come across
>a problem: if the Order has its 
>AcknowledgementResponseCode set to "OrderResponse" 
>by the Buyer, how would the OrderResponse indicate
>whether the Order has been accepted or rejected?
>(OrderResponseSimple has AcceptedIndicator)
>
>Thanks for any light anyone can shed on this.
>
>All the best
>
>Stephen Green
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://www.docengineering.com/