CNC Project High Level Contracts
Date Updated: 2007-11-17
Context of Use: This is a high level Business Use Case (BUC) for Contracts process within the CNC Project. The Seller initiate this Contract process.
Scope: The process of sending and receiving the Contract
Primary Actor: Seller
Stakeholders and Interests- Buyer:
Buyer of product
- Seller:
Seller of product
Success Guarantees: Contract has been sent and a response is sent that all that had been negotiated has been accurately recorded in the contract.
Trigger: Buyer and Seller wish to complete the contract documentation.
Preconditions- Buyer's and Seller's relationship has been previously established and any legal aspects required have been completed outside the eContract.
- Negotiation of contract details (such as pricing, volume, terms etc.) has been agreed to either verbally or in email.
Main Success Scenario
| 1. | Seller sends the Buyer a Contract message with details of contract negotiations. This would be the "Offer" type of Contract.
Related Message (v4.0):
Contract
Business Guidelines:
- Trading partners need to establish what the acceptable timeframe should be from the time the contract has been verbally or email agreed to the transmission of the Contract is sent.
|
| 2. | Buyer receives Contract from Seller.
Business Guidelines:
- Trading partners need to establish what an acceptable timeframe should be from the time the Contract is sent/received until a ContractResponse is sent back.
|
| 3. | Buyer validates the information.
Related Message (v4.0):
ContractResponse
Business Guidelines:
- Trading partners need to determine what are acceptable "reject" scenarios and what scenarios are manually rejected (via phone or email).
|
| 4. | Buyer sends to Seller an "accepted" ContractResponse
Related Message (v4.0):
ContractResponse |
| 5. | Contract is open and available for orders to be placed against it. |
Extensions
Extensions for Step 1
- Extension # 1: Seller server is down and transmission can't be sent.
| 1. | Seller will notify Buyer of issue with server and determine resolution steps. |
- Extension # 2: Seller recognizes a human error (keying error, database synchronization error etc.). Prior to Buyer rejecting or notifying Seller of error.
| 1. | Seller to contact Buyer and determine resolution. |
Extensions for Step 2
- Extension # 1: Buyer's server is down and unable to receive ContractCreate.
| 1. | Buyer or Seller should contact trading partner to determine resolution. |
Extensions for Step 3
- Extension # 1: Information in Contract is not able to be validated - some of the information is incorrect as to what was anticipated as being negotiated (such as timing not met, pricing, terms, misunderstanding, etc.)
| 1. | Buyer send to Seller a "reject" in the ContractResponse message. |
| 2. | Buyer to contact Seller to resolve differences |
| 3. | Seller sends a modified ContractCreate with a type code "Modified" to Buyer. |
| 4. | Buyer receives modified ContractCreate. |
| 5. | Buyer validates ContractCreate information. |
Extensions for Step 4
- Extension # 1: Buyer's ContractResponse is not received by Seller
| 1. | Buyer contacts Seller to determine resolution. |
Postconditions- Contract has been sent and received and orders will be placed against contract for shipment/pickups.
Notes| 1. | There are a number of "different" types of contracts, but the process seems to be the same at this level. Such as block, pricing |
Author: CNC B/T Team
Date Created: 2006-08-30This document generated using UseCase.xsl version 2004-09-13