Re: [ubl] How does anOrderResponse show order acceptance/rejection?

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

Monica (et al),

I think for the example business process in question we could have:

from the Seller's point of view, with the Order as the 'request', for the response:
      - if the order is rejected an OrderResponseSimple is sent (with AcceptedIndicator
= 'true' ) 
      - if the order is accepted an OrderResponse is sent

and so from the Buyer's/'requester's' point of view 

    - if the response is the OrderResponseSimple (with AcceptedIndicator
= 'true' ) then the order has been rejected
    - if the response is an OrderResponse then the order has been accepted

There is a slight glitch with the minutae in this in that it might be necessary 
to specifiy somehow (not in this example though I guess) that, in the Order,
AcknowledgementResponseCode should not be used in such a business
process as this or that care should be taken by the Seller (or 'Drop-Ship')
in how they interpret it.

I think this process could be 'good practise'. (I guess we can't say what 'best
practise' is.)

[Incidentally I quite like the idea of keeping the order part of the process as
optionally EITHER an Order document (UBL) OR an 'order' operation (to allow
for the type of 'punch-out' where the order can be placed by some special
technology such as on a Seller's website and not necessarily by an Order
message from the Buyer (or Buyer agent) to the Seller. The rest of the process
would be unaffected.]


All the best

Steve



>>> Monica J Martin <Monica.Martin@Sun.COM> 10/11/05 17:49:21 >>>

>green: Thanks Tim and Mark, I think you've got the issues well covered. I think
>what I'd suggest for the ebBP definition (having received a further
>comment from Denmark) is to just ignore the OrderResponse and
>stick to the OrderResponseSimple for the example (the OrderResponse
>business processing could be formidable to describe I guess so it would
>simplify things too). I guess the example needn't be comprehensive.
>
mm1: A simple yet relevant example is a good premise.  This should work 
fine with ebBP and the team can provide guidance and assistance as 
required. There are other aspects to consider, which touches on our 
previous discussion of a logical business document and what is being 
specified here.

>>>>Tim McGrath <tmcgrath@portcomm.com.au> 10/11/05 08:38:36 >>>
>>>>        
>>>>
>I agree this is a meaningful and beneficial issue to discuss, especially 
>at this stage in UBL 2.0 development.
>
>It does seem that allowing the Buyer Party to specify which type of 
>response they get is illogical.  But that isn't what we meant. What we 
>were trying to do was indicate what the Buyer Party was capable of 
>receiving automatically.  If they say Order Response Simple and they are 
>sent an Order Response they won't be able to process it.
>  
>
mm1: Inherent in the business process, the shared expectation between 
the parties (i.e. Buyer Party and Seller Party) would be whether or not 
a response was Order Response or Order Response Simple.

>It is (and should be) the Seller Party who will decide whether to reject 
>the Order, accept it as is or accept it with proposed changes.  But 
>currently, (in UBL 1.0) if the Buyer Party says they want an Order 
>Response document then the Seller Party cannot (easily) indicate they 
>reject the Order.
>
mm1: The UML models I have seen indicate that a Reject Order is 
possible. What is the limitation? Typically an Order Response could be 
complete or partial fulfillment of an order, or can't fulfill.

>  Likewise, if the Buyer requests an Order Response 
>Simple the Seller cannot (using UBL) propose modifications to the Order. 
>
mm1: See above. As long as we understand the limitation we can work to 
sufficiently model it in the business process. Whether or not changes 
are considered because of this in UBL is this team's department.

>They would have to do this using another form of document (eg paper or 
>fax) or even ring up.  The business process model needs to show this 
>(ie. revert to manual process).  
>
mm1: There are two separate aspects of this - the identification of 
functionality that may not be currently provided in UBL (whether v1.0 or 
v2.0) and then allowing this to be handled in the process model.  For 
example, the ebBP Specification element in complement with expressions 
(condition constraints and semantic variables), provide a hint whereby 
the decision is raised to a person (we added these changes because of 
earlier UBL inputs).

>So it isn't illogical - just incomplete 
>in terms of UBL documents.  I think the ebBP description should handle this.
>  
>
mm1: See above.

>When it comes to what to do with UBL 2.0 we could review this process.  
>When we added the Acknowledgement Response Code (and fixed it to the two 
>UBL document types) we hadn't thought through that they may are not 
>mutually exclusive and the process may need both (given the current 
>definitions).  We could consider extending the code list to allow 
>both(or either).  We have even discussed rationalizing these into one 
>document type thus fixing the issue entirely.  I felt this was radical 
>but maybe it would make our life simpler.  We could just add the 
>AcceptedIndicator to OrderResponse and make most of the other components 
>optional.  So we can support the 'simple' implementation and a more 
>complex one using the same document.
>  
>
mm1: This is indicative of the logical business document approach where 
it can serve many purposes. Only side comment is that the 
Acknowledgement and the business validation (Acceptance) signals are 
separate from the Order Response document itself. I understand this may 
not be exposed in UBL; however, it may be a point of confusion. The 
actual business document is the substantive response to an offer; the 
signals provide state alignment checks and balances to ensure the 
parties expectations are being met and the process is proceeding 
(regardless of what the outcome is).

>But if we want to keep both documents then as another approach we should 
>consider how we propose solving a similar issue with the Request for 
>Catalogue document.  This allows the Buyer to say whether they want a 
>Price Update or Item Update document in response.  But in that case we 
>have defined two Indicators (PricingUpdateRequestIndicator and 
>ItemUpdateRequestIndicator).  This seems a better solution.  Maybe for 
>UBL 2.0 we could just have an Indicator in the Order to say whether and 
>OrderResponseSimple and/or an OrderResponse can be accepted.  Then we 
>can drop the AcknowledgementResponseCode.
>  
>