Purpose: Arrange for a bank to transfer funds on a specified day to settle an invoice.

Actors: Buyer, Bank

Initiator: Buyer

Beneficiary: Buyer

Requires:

1. An invoice has been issued for the goods ordered.
2. The order for the invoice has been confirmed.
3. The invoice has not been scheduled.
4. The invoice has not been paid.

Results: The invoice has been scheduled.

1. The Buyer begins the use case by browsing the invoices for the Buyer's account in the system.
2. The system checks order confirmations previously received, and displays unpaid, unscheduled invoices for confirmed orders.
3. The Buyer schedules an invoice for payment by the Bank.
4. The system generates a Payment Request to the Bank for payment on the scheduled day.

• At step 3, if the Buyer asks that an invoice be rejected, the system records the request. This terminates the use case.

• Analysis class diagram

  

• Analysis collaboration diagram
  

  

• Analysis flow of events

Flow of events:

1. Using the Payment Request UI, the Buyer browses the received Invoices.
2. The Payment Request UI uses the Order Handler to check the Invoices.
3. The Order Handler uses the Business Rules to determine the checks to make on the Order Confirmation and Invoice objects.
4. The Payment Request UI displays Invoice status information.
5. The Buyer selects an Invoice via the Payment Request UI and schedules it for payment.
6. The Payment Request UI asks the Payment Scheduler to schedule the payment.
7. The Payment Scheduler creates a Payment Request.
8. The Payment Request notifies the Bank to make the payment on the scheduled day
9. The Payment Request UI asks the Order Handler to change the state of the Invoice to "scheduled".

Alternative paths:

• At steps 1 - 4, the Buyer may exit.
• At step 5, the Buyer may request via the Payment Request UI that an invoice be rejected rather than paid. This negates the remaining steps for that invoice.
• Description of nonfunctional requirements.