Re: quote use case

Robert wrote:

Len Greski posted the interesting Request Quote use case.
I have some questions and comments:

1. Is this use case based on actual practice?
It has a realistic air about it (unlike some use cases)
but are all the details from actual practice?
If so, then I find it even more interesting.
If not, does it represent something like
desired or to-be practice?

Yes, this use case is fairly close to actual current practice.

2. You wrote that in this use case,
"the contractual relationships between Supplier and Manufacturer roles
are already in place."
I assume that means the contractual relationships
between Supplier and Buyer are *not* in place,
and the use case is the opening of contract
formation between Supplier and Buyer?

Correct. The request for a quote begins the process of contract formation,
as the Supplier makes a commitment that the quote is valid for <n> days.
The fact that a quote is offered, however, does not obligate the Buyer to
purchase.

3. Jumping around a bit, you wrote,
"Need to distinguish the idea of a contract between services ... from a
legal contract."
Tony Fletcher and I collaborated on a paper about
a somewhat related use case in trying to harmonize
OASIS-Business Transaction Protocol and UN/CEFACT
Business Collaboration Protocol:
http://www.supplychainlinks.com/UNCEFACT-papers.htm
In that paper, we distinguised between:
* Economic Contracts, about commitments to exchange
economic resources, e.g. products and money; and
* Transaction Contracts, about the rules of engagement
for doing electronic commerce.
Whether you buy that terminology, the distinctions in the paper
might be useful.
Economic Commitments can be defined precisely.
Contracts can contain both Economic Commitments
as well as Transaction Contracts, which is where
the going gets muddy.

Thanks for the reference, I'll take a look at your paper. On the
teleconference last week, we had some discussion were we used the word
contract. The term means different things to different people, and we need
to distinguish what it means for the choreography specification, versus its
business meaning (a legal agreement between two parties blah blah blah...).
The distinction in your paper, economic vs. transaction, may be useful in
helping us clarify our use of the word.

4. Getting back to the scenario,
I don't see where the Buyer accepts the Quote.
In other words, I don't see where a contract between
Buyer and Supplier is legally bound.
The Quote appears to be binding on the Supplier for some timespan,
and presumably if the Buyer accepts it they have an Economic Contract.
But not until?

I specifically left out the activity where the Buyer and Supplier convert
the quote into a contract. In many situations the relationship between
Buyer and Supplier is relatively informal, i.e. the Buyer can buy off the
quote for a specified period of time without entering into a formal
contract. In other situations acceptance of the quote triggers more
elaborate contracts process.

5. Might the Buyer be getting quotes from many Suppliers,
and accepting the best one?

Yes, this is possible. I scoped the use case at a relationship between a
single Buyer and a single Supplier, because this is complex enough to cover
the key features that must be handled by the choreography specification
(contract provisions, service level agreements, security provisions,
privacy provisions, non-repudiation, escalation procedures, exception
handling), without being overly complex.

6. "The Supplier may reject one or more terms requested by the Buyer. To
handle the negotiation of terms, there may be multiple request /
response sequences between Buyer and Supplier."
Very difficult to present as a linear event sequence,
and I see that you did not try to do so.
How would you handle that negotiation?
If this use case is from actual practice,
how *do* you handle it?
There's a saying, "everything is negotiable".
I think that means in a business conversation,
every point of agreement may resolve into a negotiation.

I know how it happens in "meat space", but haven't figured out how to
handle this electronically. We'll have to think about this further because
most electronic negotiation models that I know about are require some kind
of human interaction (e.g. auction sites), or are very restricted in the
parameter(s) being negotiated (e.g bid/ask on securities). Hopefully one or
more of our erstwhile colleagues on the list will provide an answer to this
one...

regards,
__________________________________
Len Greski
Director
eBusiness Architecture & Development
W.W. Grainger
voice: (847) 793-5185
fax: (847) 793-5019
cell: (847) 366-1376
mailto:greski.l@grainger.com

Received on Thursday, 19 June 2003 00:29:14 UTC