3.  Specified Use Cases 

1.  AR/AP tasks:

a.  Use case: Create purchase order (PO) 

      Community:

Actor:  Company

Actor: Application

Actor: TP's BSP

as role:  customer

as role:  system

as role:  seller

Goal/Postcondition 
The goal of a PO is to initiate a purchase from a vendor, in this case the vendor is the Web-Storefront.

Roles 
Company as custommer
Application as system

Trading Partner as seller

Preconditions

The Application and TP's BSP  must be able to handle the whole business-process.
The PO contain rules for handling of the order if the TP's BSP can't deliver the requested products, or only parts of it.
The TP's BSP must have a globally visible namespace for parties and product catalogues.
Application must be able to access this namespace to complete the purchase.
The TP's BSP must be able to evaluate my credit.


Steps
The Company notifies the Application about a PO containing all the items that I want to buy.
The Application sends the PO to the desired TP's BSP.
The TP's BSP evaluate the PO against it's own CPP (Collaboration Process Protocoll).


Trigger 
The Company decides to purchase.

Main Success Scenario
The TP's BSP accepts the PO, or part of it.
The TP's sends an acknowledgement to the Application.
The TP delivers the product or service to the Company.



Extensions 
Test Specification 
Open Issues 

 

 

b.  Use case: Create acknowledgement (AM) 

      Community:

Actor:  Company

Actor: Application

Actor: TP's BSP

as role:  customer

as role:  system

as role:  seller

Goal/Postcondition 
The goal of a an acknowledgment is to notify the Application about the result for handling the PO.

Roles 
Company as customer
Application as system

Trading Partner as seller

Preconditions

The Application
must have sent a PO to the TP's BSP with the correct spesifications.


Steps
The TP's BSP verifies the PO, and handle it according to predefined rules (CPP).
If it is possible to make an agreement (CPA), the the Web-Storefront sends an acknowledgement to the Application.



Trigger 
The TP's BSP receives a PO from the Application.

Main Success Scenario
The TP's BSP accepts the PO, or part of it.
The TP's BSP sends an acknowledgement to the Application.
The TP delivers the product or service to the Company.



Extensions 
Test Specification 
Open Issues 

 

c.  Use case: Submit GL transactions 

      Community:

Actor: Application

Actor: TP's BSP

Actor: ARAP

Actor: BSP's ARAP

as role:  submitter

as role:  submitter

as role:  receiver

as role:  receiver

Goal/Postcondition 
The goal of a an acknowledgment to notify the Application about the result for handling the PO.

Roles 
Application as submitter.
Trading Partner as submitter.
ARAP as receiver.
BSP's ARAP as receiver.


Preconditions

The Application
must have received a valid acknowledgement (AM) from the TP's BSP.
The Application must be able to transmit the appropriate GL data.


Steps
The Application sends GL data to the ARAP.
The TP's BSP sends GL data to the BSP's ARAP.

The entries come forth from this operation (journal) are generated and organized as follows:

The entries to ARAP represents a purchase of goods or services like this:

The entries to the BSP's ARAP represents a sale of goods or services like this:

Trigger 
The application receives an AM from the TP's BSP.


Main Success Scenario
All necessary GL-data is stored in the ARAP and the BSP's ARAP in a proper way.

Extensions 

Test Specification 

Open Issues 

 

d.  Use case: Receive and accept goods and service when delivery is according to acknowledgement

      Community:

Actor: Company

Actor: TP

Actor: Application

Actor: ARAP

Actor: BSP's ARAP

as role:  approver

as role:  deliverer

as role:  submitter

as role:  receiver

as role:  receiver

Goal/Postcondition 
The goal of a an acknowledgment to notify the Application about the result for handling the PO.

Roles 
Company as approver.
TP as deliverer.
Application as submitter.

ARAP as receiver.
BSP's ARAP as receiver.


Preconditions

The product or service has been delivered.

Steps
The Company receives the goods
The Company checks if the delivered goods is according to the acknowledgement
The Company notifies the Application that the delivery is according to the acknowledgement
The notification revert the original submission and replaces it with a new posting.
The Application sends GL data to the ARAP.
The Application sends GL data to the BSP's ARAP.

The entries come forth from this operation (journal) are generated and organized as follows:

The new entries to ARAP.

The new entries to the BSP's ARAP.

Trigger 
The company receive goods from TP.


Main Success Scenario
All necessary GL-data is stored in the ARAP and the BSP's ARAP in a proper way.


Extensions 

Test Specification 

Open Issues 

 

 

e.  Use case: Receive and accept goods and service when delivery is NOT according to acknowledgement

      Community:

Actor: TP

Actor: Company

Actor: Application

Actor: TP's BSP

Actor: Application

Actor: ARAP

Actor: BSP's ARAP

as role:  deliverer

as role:  approver

as role:  system

as role:  approver

as role:  submitter

as role:  receiver

as role:  receiver

Goal/Postcondition 
The goal of a an acknowledgment to notify the Application about the result for handling the PO.

Roles 
TP as deliverer of goods.
Company as an approver of the delivery.
Application as system.
TP's BSP as an approver of the complaint from Application.
Application as submitter of the GL-data.
ARAP as receiver of GL data.
BSP's ARAP as receiver of GL data.


Preconditions

The product or service has been delivered and that the delivery is not according to the acnowledgement.

Steps
The Company receives the goods
The Company checks if the delivered goods is according to the acknowledgement
The Company notifies the Application that the delivery is not according to the acknowledgement
The Application makes a complaint to the BSP's about the unfulfilled delivery.
The TP's BSP accepts the complaint and issue a CreditMemo to the Application.
The Application .
The Application sends GL data to the ARAP, reverting the original submission and replaces it with a new posting.
The Application sends GL data to the ARAP about the CreditMemo.
The Application sends GL data to the BSP's ARAP, reverting the original submission and replaces it with a new posting.
The Application sends GL data to the BSP's ARAP about the CreditMemo.

The entries come forth from this operation (journal) are generated and organized as follows:

The new entries to ARAP: The original transaction.


ARAP transactions due to the creditmemo.

The new entries to BSP's ARAP after accepting the creditmemo.BSP's ARAP


Trigger 
The company receive goods from TP.

Main Success Scenario
All necessary GL-data is stored in the ARAP and the BSP's ARAP in a proper way.

Extensions 

Test Specification 

Open Issues