1. Invoice Number
  2. Unique PO#
  3. Product Information (i.e. titles, quantity, version/edition, etc.)
  4. Suppliers Name
  5. Suppliers Location
  6. Purchase Order Date
  7. Shipping Date
  8. Expected Receiving Date
  9. Actual Arrival Date at Store
  10. Name of Carrier/Transport
  11. Mode of Carrier/Transport
  12. Destination Location
  13. Store #
    14.
Rationale: Generation of PO’s is a vital business control as well as a critical process
Importance: 5

 
        1. Requirements: Purchase orders need to be transmitted through electronic data interchange (EDI).
Rationale: Process is needed to communicate orders to suppliers efficently and accurately.

Importance: 5

 
1.1.3 Requirements: Purchase orders need to be "live" documents that can be changed and updated by purchaser as information becomes more current.

Rationale: This is vital to an accurate information system as not all product or delivery information is known at time of purchaser order generation.

Importance: 5

 

 
1.1.4 Requirements: Purchase orders need to be printed.

Rationale: Necessary to order from smaller suppliers that do not have the means to order through the EDI also provides a manual audit trail.

Importance: 4

 
1.1.5 Requirements: The system needs to be able to run queries and generate open order reports at both the headquarters and local stores, based on information contained in the purchase order fields.

Rationale: This is important for tracking incoming orders and to allow for the forecasting, scheduling, and allocating of resources.

Importance: 4

 
1.1.6 Requirements: Purchase orders need to be accessible in read-only format at the local store prior to ship date.

Rationale: Purchase orders can be changed only at the headquarters to allow for management control and information integrity.

Importance: 4

 
1.1.7 Requirements: The system needs to allow for communication between all the local stores and the purchasing agent.

Rationale: The local stores need to be able to communicate with purchasing managers if it is needed to request changes in purchase orders.

Importance: 4
      1. Receiving

        2. 1.2.1 Requirements: At the shipping date, the purchase order becomes a "live" document and no longer in read only format so that it may be received at the local store.

        Rationale: Local stores need to update and receive the purchase orders. To do so the local store must be able to enter actual received quantities and arrival date.

        Importance: 5

         

        1.2.2 Requirements: After arrival update, the purchase order needs to be processed so it can become a "receiver" which will update the stores’ physical inventory and render the books sellable.

        Rationale: This is critical to enable the books to turn into sellable goods.

        Importance: 5

         
        1.2.3 Requirements: Upon the receipt of the purchase order, the system needs to generate a report with price stickers that have independent UPC bar codes and prices for each individual book.

        Rationale: This is critical for the maintenance of inventory and sales figures.

        Importance: 5

         

         

         

        Financial Processes
      2. Accounts Payable
2.1.1 Requirements: System must be able to monitor and control payments of all accounts by linking it to payment account history and vendor, wholesaler, and distributor records.

Rationale: Essential to the proper maintenance and tracking of all accounts payable.

Importance: 5
2.1.2 Requirements: Payment transactions will be made to distributors and/or shippers through the system via EDI (or in the case of smaller companies, a check will be printed and mailed) once authorization is granted.

Rationale: Payments need to be authorized by the headquarters or store manager.

Importance: 5
 
 

 2.2 Accounts Payable – Reports 2.2.1 Requirements: System must have the ability to generate accounts payable reports such as:
  1. Purchase Orders generated by Borders
  2. Bill of Lading to verify the receipt of the goods
  3. Invoice prepared by the supplier/shipper
    4.
Rationale: Essential for headquarters and store management, buyers, and purchasers to control payments.

Importance: 5

  2.2.2 Requirements: An accounts payable discrepancy report.

Rationale: Necessary to verify that all products ordered were delivered.

Importance: 5

 

 
INVENTORY PROCESSES

 

3.1 Inventory Requirements

 
3.1.1 Requirements: Master inventory repository.
 

Rationale: A master set of all books sold by all Borders stores needs to be kept and maintained at HQ. Each book needs to be a separate entity containing at least these key fields:- independent and unique item number- supplier- on-hand- active flag- title- category- type- size- weight- units per case- cases per pallet- cost- freight cost- tax cost- description- Author- Subject- stores approved to sell book- price- discount periods- discount regions- post-offs- rebates- advertising unit cost- other specific fields used for report generation.

Importance: 5

 

 
        1. Requirement: Link between Purchase Orders and item numbers
Rationale: When in purchase order entering function all product entries need to be done with item number, for speed and accuracy

Importance: 5

  3.1.3 Requirement: Maintenance of master product file must be done at HQ
  Rationale: Integrity of this information is essential for maintaining proper margins and generation accurate sales reports.

Importance: 4
 

 3.1.4 Requirement: Master supplier repository
  Rationale: A master set of all suppliers must be stored. Each supplier needs to be a separate entity containing at least these key fields. Supplier may be Border’s owned distributor.
      1. independent and unique supplier number
      2. address and billing info
      3. credit terms
      4. freight terms
      5. contacts
      6. lead times
      7. account numbers
Importance: 5

 

 3.2 Inventory Reports
  3.2.1 Requirement: Stock status reports
  Rationale: Essential for buyers, purchasers and unit managers to control the flow of product. Available to HQ and Local managers.

Importance: 4
 

 3.2.2 Requirement: Inventory flow reports

Rationale: Essential for buyers, purchasers and unit managers to control the flow of product. Available to HQ and Local managers.

Importance: 4

 
 

 3.2.3 Requirements: Out of stock reports

Rationale: Essential for buyers, purchasers and unit managers to control the flow of product and reduce out of stock situations. Available to HQ and Local managers.

  Importance: 4   3.2.4 Requirements: System must be able to handle stock on hand, in transit, on order, in-store transfer and distributions, and physical inventory. System must be able to report any discrepancies between the physical count and recorded inventory on hand.   Rationale: To prevent internal or external theft, detect pricing errors, mis-ticketing, and missing merchandize.

Importance: 5

 

 
Point-of-Sale System Processes
 
      1. Order Processing
 4.1.1 Requirements: System must be able to process orders, receiving, ticketing, and selling to keep the database current through EDI exchange. In addition, the system must be capable of multi-store management and facilitation of new store additions.   Rationale: To manage order-processing communication between HQ and independent stores. Provide continuous update of on-hand inventories in order to ensure information confidence.

Importance: 5

 

 
Use Case Definitions
Version Number 2
Frozen as of 2/23/99

 

Background:

This is a set of graphical, base and extended use case models designed to show the required and interrelated components of the Border’s information system. The use case models address only those requirements within scope for our project. The inclusion of critically dependant but technically out of scope models have been include to maintain the real world integrity of our system’s design.

 

Key to Rank Order Importance of Requirements:

(Applies to Expanded Use Cases)

  • Possible addition some time in the future
  • Needed for growth, but will not hamper current productivity
  • Important for the system to be a highly productive tool now
  • Necessary for the system to perform base business processes
  • Critical for the operation of the system
    •       
      Use Case Name:
      Purchase Order Generation
      ID# 1.1.1
      Actors:
      Purchaser
      Description:
      The Purchaser wishes to generate a unique purchase order (PO) from the enterprise wide information system (EWIS). The purchaser selects the purchase generation option from which he/she can input all the required fields. The EWIS returns a unique PO # and leaves the information for further processing.
      Use Case Name:
      Transmission of PO to Supplier
      ID# 1.1.2
      Actors:
      Purchaser, Supplier.
      Description:
      The Purchaser initiates the transmission of PO’s to the supplier(s) via the EWIS. The EWIS compiles the data for transmission and transmits it according to the supplier protocols..
      Use Case Name:
      Validating and Revising of PO
      ID# 1.1.3
      Actors:
      Purchaser, Store Manager
      Description:
      The Purchaser needs to edit, update and validate the PO’s after the Store manager approves it. Also as new information becomes available. The EWIS allows for revising of all fields for information accuracy.
      Use Case Name:
      Confirmation and Updates of PO Status
      ID# 1.1.4
      Actors:
      Purchaser, Store Manager, Receiving Manager
      Description:
      The Purchaser prepares summary reports of pending PO’s via the EWIS. The EWIS sends the reports in file format to the local in-store system. The store manager receives and receiving manager these reports to make vital business process decisions.
      Use Case Name:
      Receiving of POs
      ID# 1.2.1
      Actors:
      Store Receiving Manager (SRM)
      Description:
      SRM after verifying contents must receive the goods into the existing purchaser order on the EWIS. Receiving of this PO involves updating the fields with actual quantities and dates. Upon completion, the EWIS processes this information, turns the PO into a receiver and makes the newly received inventory live and available and for resale.
      Use Case Name:
      Generation of Price Stickers
      ID# 1.2.2
      Actors:
      Store Receiving Manager
      Description:
      SRM initiates the output of price stickers containing individual UPC bar codes and prices for each book. The EWIS pulls this information from the master product data file and prints the stickers on a standard laser printer.
      Use Case Name:
      Accounts Payable Processing
      ID# 2.1.1
      Actors:
      Accounting Staff Member (ASM)
      Description:
      The ASM must be linked the EWIS in order to have access to payment account history for vendors, wholesalers, and distributors. The EWIS returns the requested data and allows for general ledger (GL) maintenance.
      Use Case Name:
      Funds Disbursement
      ID# 2.1.2
      Actors:
      Accounting Staff Member (ASM), Supplier
      Description:
      ASM initiates EFT or physical check generation after verification of current bills. The EWIS allows for electronic funds transfer (EFT) or physical check generation and concurrently updates the GL.
      Use Case Name:
      Generation of Accounts Payable Discrepancy Reports
      ID# 2.2.1
      Actors:
      Accounting Staff Member (ASM)
      Description:
      The ASM initiates the generation of AP reports. The EWIS returns these reports via physical output and computer file.
      Use Case Name:
      Accounts Receivable Processing
      ID# 2.3.1
      Actors:
      Accounting Staff Member (ASM)
      Description:
      The ASM must be linked the EWIS in order to have access to the receivable account history for vendors, wholesalers, distributors, and local stores. The EWIS returns the requested data and allows for general ledger (GL) maintenance.
      Use Case Name:
      Generation of Accounts Receivable Reports
      ID# 2.4.1
      Actors:
      Accounting Staff Member (ASM)
      Description:
      The ASM initiates the generation of delinquency reports. The EWIS returns these reports via physical output and computer file.
      Use Case Name:
      Master Inventory Repository
      ID# 3.1.1
      Actors:
      System Administrator (SA)
      Description:
      The SA acts as a data manager and maintains the master file data containing information on all the products. The EWIS contains a relational database housing multiple levels of information of each product. It is also linked to all the other applications in the EWIS.
      Use Case Name:
      Master Supplier Repository
      ID# 3.1.2
      Actors:
      System Administrator (SA)
      Description:
      The SA acts as data manager and maintains the master file containing all the supplier information. The EWIS contains a relational database housing multiple levels of information of each supplier. It is also linked to all the other applications in the EWIS.
      Use Case Name:
      Sales Transaction
      ID# 4.1.1
      Actors:
      Local Store Manager, Booksellers (Cashiers), ASM, Purchaser
      Description:
      A sale is initiated with the bookseller. At completion of the transaction the EWIS updates inventory, account receivables, accounts payable, employee records, general ledgers, cash-on-hand. The store manager can review this data through the EWIS. At headquarters an ASM reviews this data daily. The purchaser’s report registers are also updated.
       

      Use Case Name:
      Purchase Order Generation
      ID# 1.1.1.X
      Actors:
      Purchaser, Store Manager
      Description:
      The Purchaser wishes to generate a unique purchase order (PO) from the enterprise wide information system (EWIS). The purchaser selects the purchase generation option from which he/she can input all the required fields. The EWIS returns a unique PO # and leaves the information for further processing.
      Pre-Conditions:
      The purchaser has to have the capability to access the purchase order generation screen/application.
      Event Course:

       

       

       

       

       
      1. Purchaser assembles order.
    2. Purchaser accesses the PO generation application within EWIS.

    3. The PO is entered into the system for processing. Entry is through keyboard.

     4. In preparation for the purchase order generation:
  • The EWIS validates that the information on the purchase order is both accurate and complete. (required fields)
  • Transportation requirements are considered and delivery instructions are assigned, (e.g. third-party, UPS, next-day, courier, dedicated freight, P/U)
  • Purchaser calculates delivery dates and ship dates
    •      5. Transmits electronic copy of live PO to store manager for review.

    6. Store Manager returns corrections and approval to the purchaser.

    7. Purchaser updates and enters corrections.

     8. PO is transmitted to suppliers to initiate product order.
      Post-Conditions:
      The supplier has all details to begin filling order and contacts specified shipper.
      External Server

      Actor(s):
      WWW

      Supplier IS
       
      Page 1 of 2 
      External Receiver Actors(s):
      Supplier

      Transport Carriers
      Assumptions:
      Relationship exists with Suppliers.

      Books are in print.
      Associated Non-Behavioral Requirements:
      Performance:

      Orders are processed within 24 hours of receipt of buyer.

      PO’s are reviewed within 3 hours of receipt.

      PO’s are processed immediately after review.

      Supplier initiates fulfillment within 12 hours of receipt.

      Capacity:

      The system should have no limitation on the number of orders processed.

      Security:

      WWW communication is secure.

      Access to various functions should be controlled by multiple level passwords.
      Use Case Priority
      High ( 5)
      Source of Use Case
      Interview with Borders employees, operational observations and related operational experience.
      List of Exceptions Alternatives
      Buyers purchase request is incomplete. Order lead-time is insufficient. Transportation is unavailable. Credit terms with suppliers are in bad standings.
       
      Page 2 of 2
      Use Case Name:
      Receiving of POs
      ID# 1.2.1.X
      Actors:
      Receiving manager (RM)
      Description:
      The receiving manager wishes to update the information contained in the PO so that it mirrors that of the Bill of Lading. The RM also wishes to turn the live PO into a closed receiver. Upon doing so the EWIS needs to update the local inventory making the books available for sale.
      Pre-Conditions:
      The receiving manager has to have the capacity to process a PO.

      The books must have arrived and been verified against a summary bill of lading.
      Event Course:

       

       

       

       

       
      1. Receiving manager has a signed and delivered bill of lading.
      2. RM accesses receiving function of EWIS.
      3. RM enters via keyboard the actual date of arrival
      4. RM enters via keyboard the actual description and the confirmed count of books delivered.
      5. EWIS updates inventory fields, effectively adding the product to inventory, rendering it available for sale.
      6. EWIS updates the discrepancy report fields with any differences for what was on the PO to what arrived. 
      7. Accounts Payable will need to access this to cross reference it with the suppliers invoice.
      Post-Conditions:
      Accounts Payable now may access the information to begin their processes.
      External Server

      Actor(s):
      Some suppliers may transmit the bills of lading electronically.
      External Receiver Actors(s):
      Accounting Staff Member will initiate their own access of this information.
       
      Page 1 of 2
      Assumptions:
      Bills of Lading are in summary form or packing lists are included.
      Associated Non-Behavioral Requirements:
      Performance:

      Receivers are entered within 2 hours of receipt by local store.

      PO’s are processed immediately after entry.

      Supplier has provisions for delivering back up if common carrier loses paperwork.

      Capacity:

      The system should have no limitation on the number of orders processed.

      Security:

      WWW communication is secure.

      Access to various functions should be controlled by multiple level passwords.
      Use Case Priority
      High (5)
      Source of Use Case
      Interview with Borders employees, operational observations and related operational experience
      List of Exceptions Alternatives
      Rush deliveries, transfers and specials may not have a PO created in the system so a function to "Receive without PO" must be available to the RM on the EWIS.
       
      Page 2 of 2