draft srs document for great abyssinia plc

ERP System Requirement Specification Document for Great Abyssinia PLC.

2011

CNET SOFTWARE TECHNOLOGIES PLC Page 1

Chapter One

Introduction to the CNET_ERP Software System

CNET was established in 2000 and began operation in January 2001. Prior to the ERP system, the

company developed separate accounting and MIS software for six different organizations. Finally the

experts at CNET realized that the software which was developed had similar functionalities although

their domains were merely different. So, they have decided to develop the ERP system by integrating

the different systems developed earlier. However, due to various financial and time constraints, the

implementation of the existing ERP system didnt follow the accepted software development process.

1. ERP System

The term ERP originally implied systems designed to plan the use of enterprise-wide resources. It

incorporates all basic functions of an organization, regardless of the organization's business.

Merchandize organizations, non-profit organizations, governmental and nongovernmental

organizations, and other large entities utilize ERP systems. ERP's main goal is to integrate data and

processes from all areas of an organization and unify it for easy access and flow of work. It aims to

improve and streamline internal business processes, which typically requires reengineering of current

business processes.

The components of an ERP system are the common components of a Management Information System

(MIS). The boundary of an ERP system is usually smaller than the boundary of the organization that

implements the ERP system. Integration is an extremely important part to ERP. ERP usually

accomplishes integration by creating one single database that employs multiple software subsystems

providing different areas of an organization with various business functions.

In the absence of an ERP system, a large enterprise may find itself with many software applications that

do not communicate to each other and do not effectively interface with one another.

There are many advantages of implementing an EPR system; here are a few of them:

Improved efficiency and productivity levels

Better tracking and forecasting


2011


Lower costs

Improved customer service

reduced data entry resulting in fewer input errors,

Integration of production planning, material planning, and sales processing systems has allowed

for quicker conversion of customer orders into production schedules as well as material orders,

Customer service will be improved due to increased responsiveness resulting from the

integration of sales and production planning systems; total order visibility,

Increased visibility and understanding of future material requirements will provide suppliers

with more notice, thus improving their delivery performance.

While advantages usually outweigh disadvantages for most organizations implementing an ERP system,

here are some of the most common obstacles experienced:

The need to reengineer business processes

Technical support can be shoddy

Systems can be complex to be realized

Resistance in sharing sensitive internal information between departments can reduce the effectiveness of the software.

Usually many obstacles can be prevented if adequate investment is made and adequate training is

involved, however, success does depend on skills and the experience of the workforce to quickly adapt

to the new system.


2011


1.1 Purpose

The main purpose of this SRS document is to describe the functional and nonfunctional requirements of

Great Abyssinia P.L.C ERP software needs. This software is version 5 of the ERP. From now on it will be

called CNET_ERP v.5 Software. This documentation does not cover all subsystems implemented by CNET

software technologies where as it only focus on the four subsystems that are requested by the Great

Abyssinia P.L.C. The four Subsystems are Sales, Inventory, Accounting and Production.

1.2. Document Convention

This SRS is developed by adapting templates derived from IEEE Standard 830-1998B which is highly

recommended by IEEE to Practice software requirement specification document. The document follows

the following convention while it is being written.

The document is written in Calibri(Body), 12 Text Style

Every Document title is written in Bold letter, Times New Roman, 12 Style

Each and every release specified at this document will be incorporated by the System.

The following ID mechanisms are utilized through out the document

o BR- Business Rule

o FE Feature

o UC Use Case

o CO Design and Implementation Constraint

o UD- User Documentation

o AS Assumption

o DE- Dependency

o UI- User Interface

o HI Hardware Interface

o SI- Software Interface

o CI-Communication Interface

o PE- Performance Requirements

o SA- Safety Requirements

o SE- Security Requirement


2011


1.3. Intended Audience and Reading Suggestions

This document is divided into six chapters in a way that it can briefly state what will be implemented

while the software is developed. The SRS is developed to create a common understanding between all

stakeholders. Chapter one mainly focuses on creating a common understanding about a working

system (Software). The Requirement analyst believes this chapter shall be read by all stake holders. In

this chapter we will have an abstract view of the system so that we can imagine what is developed in the

SRS for the system. Chapter two is developed for technical personals specially developers to understand

what is going to be implemented. Also in this chapter the features, the assumptions and the

functionalities and design constraints of the system will be developed in the system. The consultant

advises the developers and designers to read this part for the well development of the ERP system.

Chapter three is developed for clearly specifying the functional requirements of the system. The

consultant advices the analyst, Designer and developer of the project to read this part to identify a way

of implementing all functionalities in a user friendly manner. Chapter four is developed for creating a

clear understanding about the external interfaces of the system. This chapter is described in a low level

technical language so that all stakeholders understand what kind of external interface needed for

implementing the aspired software. Chapter five is developed for the developer to understand what the

users really need in addition with the functional requirements. Chapter six is a reference chapter that

compromises other requirements that can not be described in the other chapters. Each chapter is

intended to following Stakeholders.

Intended Audience (Stakeholders) Reading Suggestion

System Owner(MGT of Abyssinia) Chapter 1,3,4,5

System Designers Chapter 1-4

System Developers All

Technical People of Abyssinia All

1.4. Project Scope

The scope of this project is limited to the following modules of the CNET_ERP Subsystems. Based on Great Abyssinia P.L.C business process the following modules of CNET ERP are found mandatory for facilitating the Enterprise Activities. The enterprise needs the following subsystem modules

1. Sales Subsystem

The sales subsystem will have two major modules. Sales management module (SMM) is responsible to keep track of information related with sales persons and sales transaction. This module is responsible for keeping rules related with sales transactions and make sure that the rules are applied properly. For example, once an invoice is created its content should never be modified. This module is also responsible for creating sales related vouchers and support all required operations on those vouchers. It is also responsible for the generation of reports.


2011


2. Inventory Subsystem

This subsystem will have two major modules Supplier Management Module (SMM) and Inventory Management Module (IMM). SMM is responsible for maintaining supplier information and handles reports that are related to suppliers or vendors. The module handles the purchase order, GRV, and suppliers return activities that are related to the supplier. It is also responsible to provide various reports related to the supplier. IMM is responsible to keep track of information related with inventory transaction. This module is responsible for keeping rules related to the inventory transactions and controls the proper implementation of the rules. This module is responsible for creating inventory related vouchers such as SIV, GRV, Disposal, Store Return, Items Transfer and Supplier Return and support all required operations on those vouchers.

3. Accounting Subsystem

This subsystem will have three major modules Account Receivable Management Module (ARMM), Account Payable Management Module (APMM), and Journal Management Module (JMM) ARMM is responsible for maintaining income related transactions that result for increasing in the proprietorship asset. It includes the account receivables, which are obtained mainly from sales revenue collection. It manages the preparation of credit sales invoice, cash sales invoice and cash receipts. It is also responsible to provide various reports related to the income transactions. APMM is responsible to keep track of information related with expense transactions. In addition to the documents it receives mainly from sales and inventory subsystem, this module prepares its own vouchers such as BPV, and PCPV. It is also responsible for the generation of various reports.JMM is responsible for posting journal voucher source documents to the appropriate journals. This module is also used to edit journals, to prepare journal reports, and to control whether accounting journal principles are respected or not.

4. Production Subsystem

This subsystem is developed for maintaining products, production process and Production voucher. The system will have a capacity for facilitating a production process from raw material to finished process.

References Taken:-

1. CNET_ERP System Architecture and Development Guide, November 2007, By Tamirat and

Seamen

2. A Briefing made by Ato Manager and Finance officer of Great Abyssinia P.L.C

3. CNET Staffs that have domain knowledge on the ERP utilization in different enterprises.

4. Literature reviews of different Documents.


2011


Chapter two

Overall Description of the System

2.1. Product Perspective

This software product is developed for facilitating and automating the business process of Great Abyssinia P.L.C. The System will be deployed in the Main Office, Sululta Branch and Egziharab Branch. This chapter tries to address the known constraints, assumptions and dependencies of the system. Some of the sections also show the technical details of static parts of the system. This system provides accounting and finance management, Sales Management, Warehouse management and Production Management. The system enables the owner to control all activities done by the marketing, sales, human resource, finance etc.

CNET ERP Back up Server

Main office Server

Egziaherab ware

house

Sululta

Warehouse

Mobile sales

Management, Marketing, Accountant

Store keeper ,Sales

Production department, Store keeper, Sales

Workstation

Workstation

Workstation

Context Diagram for Great Abyssinia P.L.C CNET_ERP Software System Version 5


2011


2.2. Business Rules

According to the Business Rules Group (1993), "A business rule is a statement that defines or constrains

some aspect of the business. It is intended to assert business structure or to control or influence the

behavior of the business." Whole methodologies have been developed based on the discovery and

documentation of business rules and their implementation in automated business rules systems (Ross

1997; von Halle 2002).

ID Rule Definition Types of rule Source

BR-1 Vouchers are sequentially Numbered Facts International

literatures

BR-2 Vouchers need a time stamp Facts International

Literatures

BR-3 Vouchers need one or more owner Facts International

Literatures

BR-4 Vouchers should be contained in one page Facts International

Literatures and

Abyssinia MGT

BR-5 Vouchers can not be modified after being

Issued

Facts Ministry of Trade

and international

literature

BR-6 Vouchers need a copy distribution

management system

Facts Abyssinia MGT

BR-7 Vouchers Can be void Facts Ministry of trade

BR-8 Vouchers must support multiple print size

and formats

Facts Abyssinia Mgt

BR-9 Vouchers have an execution Procedure. Facts CNET consultants

and international

literature


2011


BR-10 While sales invoice is issued sales journal

Should be generated

Constraint CNET consultants

and international

literature

BR-11 When ever consignment sales is issued the

balance of a stock shall not be affected

Fact International

Literature

BR-12 When ever sales return invoice is issued the

General ledger will be Generated

Constraint International

Literatures

BR-13 The purchase request quantity will be set according to the following rule: Quantity_requested + normal_stock_quantity (quantity_available_in_stock + quantity_available_in_consignment + quantity_ in_ transit)

Remark: The user can modify the default quantity

Computation International

literature

BR-14 Product doesnt need purchase request and item doesnt need job request

Fact International

literature and AAU

experts argument

BR-15 A purchase requests must be prepared per suppliers

Constraint International

literature and AAU

experts argument

BR-16 Purchase request must be Manually approved

Constraint CNET Staff and

Development team

BR-17 A given closing includes all matured transactions up to that point and beginning information

Fact CNET Development

team and

Consultants

argument

Br- 18 Source documents should not be modified after closing

Constraint And International


2011


Fact literatures

BR-19 Store return should always be approved. Constraint International

literatures

BR-20 Stock transfer does not affect the

companys capital.

fact International

literatures

BR-21 The classes of fixed assets are predefined. It will refer the ministry of finance asset definition document

Constraint Ethiopian

government law,

International

literatures

BR-22 Payment Request should always be approved

Constraint CNET Development

office

BR-23 Payment preparation always needs a reference document

Fact CNET Development

office

BR-24 There is always a threshold amount that is set by an organization for the preparation of check or to pay from the petty cash

Computation International

literatures

BR-25 The debit and credit information that is inserted should be balanced

Computation CNET development

office


2011


2.3. User Class and Characteristics

User classes are products users that differ, among other ways, in the following respects:

The frequency with which they use the product Their application domain experience and computer systems expertise The features they use The tasks they perform in support of their business processes Their access privilege or security levels.

The following user classes are identified by CNET requirement development team. The

system shall entertain the user classs requirement in order to be successfully utilized.

User Class Description

System Admin The role of the system admin is to control all the proper functionality of the software in each and every setting. Most settings and first time maintenance of the software is implemented by this system admin. An organization can have a system admin that is trained in CNET training center. But our enterprise gives a preventive and maintenance administration to all customers of its product by its system administrators.

1. Configure Accounting subsystem 2. Maintain Beginning Balance 3. Manage setting 4. Maintain Fixed asset 5. Manage incoming Check 6. Prepare payment voucher 7. Prepare bank deposit slip 8. Manage outgoing check 9. Approve payment request 10. Configure Inventory subsystem 11. Prepare store request 12. Generate report 13. Manage Stock transfer 14. Manage Disposal 15. Prepare purchase request 16. Manage Supplier return 17. Prepare GRV 18. Manage stock return 19. Close inventory 20. Prepare sales invoice 21. Define distribution target 22. Configure sales sub system 23. Prepare Performa 24. Prepare consignment note 25. Prepare Sales return invoice 26. Prepare production order


2011


Accountant The role of the accountant is to utilize the accounting subsystem according to his profession. An accountant can easily understand and utilize why each of the accounting forms and vouchers are prepared in the system. Each and every task in the accounting module shall be done by an accountant.

1. Maintain Chart of account 2. Manage Journal 3. Prepare payment request 4. Prepare receipt 5. Manage account Reconciliation 6. Maintain beginning Balance 7. Manage Budget 8. Manage Settings 9. Maintain fixed asset 10. Manage incoming check 11. Prepare payment voucher 12. Prepare Bank Deposit Slip 13. Manage outgoing Check 14. Approve payment Request 15. Close accounting period

Cashier The role of cashier in our system is to pay cashes for those stake holders that are going to be paid from the Great Abyssinia P.L.C.

1. Prepare Payment Request 2. Prepare receipt

Abyssinia Management The management shall play a role for controlling weather the system is used for the targeted goal or not. The management also has a responsibility for approving or rejecting main tasks in the enterprise

1. Approve Payment Request 2. Production order 3. Prepare product release voucher

Store personnel 1. Prepare store request 2. Generate report 3. Manage Stock transfer 4. Manage Disposal 5. Prepare purchase request 6. Manage Supplier return 7. Prepare GRV 8. Manage stock return 9. Close inventory 10. Prepare production order 11. Prepare store transfer voucher 12.

Time 1. Close inventory

Sales person 1. Manage POS sales 2. Prepare Sales invoice


2011


3. Prepare Performa 4. Prepare consignment Note 5. Prepare sales return note

Input Device 1. Manage POS sales 2. Prepare sales invoice

Marketing Department 1. Check availability of product 2. Prepare production request 3. Prepare finished product release voucher

The above table might become vague for you but what is tried to address there is which part of the

stake holder will have connectivity with the system attributes. Each of the user class categories can be

divided into different personnel we illustrate this issue while describing the use cases.

2.3.1 Use case Diagram

A use case describes a sequence of interactions between a system and an external actor. An actor is a person, another software system, or a hardware device that interacts with the system to achieve a useful goal (Cockburn 2001). Another name for actor is user role, because actors are roles that the members of one or more user classes can perform with respect to the system (Constantine and Lockwood 1999). Use cases shift the perspective of requirements development to discussing what users need to accomplish. The objective of the use-case approach is to describe all tasks that users will need to perform with the system. The resulting set of use cases will encompass all the desired system functionality.

Use-case diagrams provide a high-level visual representation of the user requirements. The box represents the system boundary. Lines from each actor (stick figure) connect to the use cases (ovals) with which the actor interacts. Note the resemblance of this use-case diagram to the context diagram in Figure 1. In the use-case diagram, the box separates some top-level internals of the systemthe use casesfrom the external actors. The context diagram also depicts objects that lie outside the system, but it provides no visibility into the system internals.

We will see each of the subsystems use cases individually. But before that, let us see the flow diagram (Work flow) of Great Abyssinia P.L.C Production distribution and sales activity.


2011


Production

Request

Purchase Approve

Production order

Active , Batch number,

production, Expiration date

Start

Bill of QuantitySales issue Voucher

Work in ProcessWorking Process, Journal recipt

Product Release

Voucher

Finished Product

Receiving

Voucher(GRV)

Title

Production

z


2011


Title

Distribution

Goods Receiving

Voucher

Cash or Credit

invoice

Store Transfer

Voucher

Sales Post

(I Owe You

Voucher)

Cash receiving

Voucher


2011


Title

Dispersment and Payment Payment Type

Prepaid Purchase

(PO)

Post Paid

Purchase (CGRM)

Non stock

Payment (PAO)

Prepare

Approve

Bank Advice

Voucher

Pity Cash

Payment Voucher Bank Payment

Voucher

Cash Sales

Cash Recipt


2011


Sales Subsystem Use Case diagram

Sales Person

Manage POS Sales

Input Device

Prepare Sales Invoice

Configure Sales Subsystem

Prepare Consignment Note

System Admin.

Prepare Sales Return Invoice

Sales ERP System for

Abissinia


2011


Ware House Management System Use Case Diagram

Time

Authorized

Personnel

StorePersonnel

CloseInventory

ConfigureInventorySubsystemPrepareStoreRequest

GenerateReport

ManageStockTransfer

ManageDisposal

PreparePurchaseRequest

ManageSupplierReturn

PrepareGRV

ManageStockReturn

ApproveRequest

System Admin

(from Global Actors)

Warehouse Management System

for Abyssinia

Production Use case Diagram


2011


System Admin(From

Global Class)

Manage store request

Batch Voucher

Marketing Department

representative

Maintain Budget

Packing List

Production Planning

Production

department

Maintain Production

Configure production

Maintain Production Request

"include"

Production Order

Store Keeper

Production Transfer

Managment

Production Process

Production System For Abyssinia


2011


Accounting Use Case Diagram

Accounting system for Abyssinia


2011


Use case Documentation

At this stage of the exploration, the stakeholders should be thinking of essential use cases. Constantine

and Lockwood (1999) define an essential use case, which discuss specific actions the user takes to

interact with the system, as "a simplified, generalized, abstract, technology-free and implementation-

independent description of one task or interaction that embodies the purpose or intentions underlying

the interaction." That is, the focus should be on the goal the user is trying to accomplish and the

system's responsibilities in meeting that goal.

Based on the IEEE 1998b international Use Case description format, for all use cases we develop the

description in the following format.

Use Case ID: UC-1

Use Case Name:

Created By: Last Updated BY:

Date Created: Date last Updated

Actors:

Description:

Preconditions:

Post-conditions:

Normal Course:

Alternative Courses:

Exceptions:

Includes:

Priority:

Frequency of Use:

Special Requirements:

Assumptions:

2.3.2.1. Use Case description for sales system of Great Abyssinia P.L.C


2011


No Use Case Description

1. ConfigureSalesSubsystem This use case is used to change the way the sales

subsystem behaves.

2. PrepareSalesInvoice This use case is used to create Sales Invoice

3. PrepareSalesConsingmentNote This use case is used to create Sales Consignment

Note

4. ManagePOSSales This use case is used to make sales at Point of

Sales

5. PrepareSalesReturnInvoice This use case is used to create Sales Return Invoice


2011


Use Case ID: UC-1

Use Case Name: Configure Sales Subsystem

Created By: Fasil Solomon (System Analyst) Last Updated BY: Fasil Solomon

Date Created: Jan 10, 2011 Date last Updated Jan 10, 2011

Actors: System Admin

Description: This use case is used to manage the way the sales subsystem behaves

Preconditions: 1. The user is successfully logged in 2. The ERP Main Window is displayed

Post-conditions: The new sales setting will be saved and a printable report of the new setting will be displayed.

Normal Course:

1. The user chooses Sales Setting menu item from Setting menu

2. The system displays Sales Settings Form containing tabs for various types of sales settings such as POS setting, advanced setting , so on

3. The user selects one of the options and presses the required tab

4. The system displays the list of setting items in the selected category with their previous/default values

5. The user makes the changes and presses the Save button

6. The system displays confirmation message

7. Step 3- 6 may be repeated

8. The user press Ok button


9.4. 1. The user wants to reset to previous setting

1. The user selects the previous settings options

2. The system saves the existing setting and displays a confirmation message for the change

3. The user approve the confirmation

4. The system replaces the existing setting with the selected configuration settings

Exceptions: None

Includes: Login - in the case when the user configures after the installation is completed

Priority: High

Frequency of Use: Ones in three month


1. If invalid configurations are made, the system should display the summary of the invalid entries and should not move to the other page.

2. In each page the users should be allowed to reset the default setting after making configurations

3. The Configuration History Bin should contain the previous configuration history


2011


Use Case ID: UC-2

Use Case Name: Prepare Sales invoice

Created By: Fasil Solomon Last Updated BY: Fasil Solomon

Date Created: Jan 10,2011 Date last Updated Jan 10,2011

Actors: Sales person, System Admin, Input Device

Description: This use case is used to create Sales Invoice for normal sales transaction


Post-conditions: 1. The system will save the new sales invoice and displays a printable document

2. The system will track and make changes on the quantity of the items

Normal Course:

1. The user chooses Cash Sales or Credit Sales menu item from the Invoice submenu of the Sales menu

2. The system displays the Sales Invoice Preparation Form having Direct, Previous Sales, Consignment tabs with an activated Direct tab and automatically generated sales invoice id

3. The user enters or selects the customer, list of items along with their quantity and presses Save button

4. The system checks the validity of the data and displays confirmation message


Prepare sales invoice from previous documents

1. The user selects one of the previous documents tab

2. The system starts Prepare Voucher From Existing Voucher use case with the selected document as a parameter

Exceptions: None

Includes: Login

Priority: High

Frequency of Use: Once in a minute


None

Assumptions: All the requested items are available in the database i.e. sales invoice will not be prepared for an item that is not yet registered


2011


Use Case ID: UC-3

Use Case Name: Manage POS sales



Actors: Sales Person, Input Device

Description: This use case is used to make sales at Point of Sales


Post-conditions: 1. The system will save the new sales invoice and displays a printable document 2. The system will track and make changes on the quantity of the items

Normal Course:

1. The user chooses specific POS menu item form POS submenu of the Sales menu or selects specific POS icon from the POS toolbar

2. The system displays the POS Form for the selected POS type with an automatically generated sales invoice id

3. The user selects items and specify their quantities

4. The system computes the total price

5. The user selects the sales option (credit/cash) and payment type (check, cash, credit card, debit card) and press Print button

6. The system checks the validity of the data and saves the invoice

Alternative Courses: Activating Held Invoices

1. The user presses Show hold button

2. The system displays all previously held invoices

3. The user selects the specific invoice and presses retrieve button

4. The system activates the selected invoice and populates all controls with the selected invoice information

5. The user makes modifications on the activated invoice and press Print button

Select the item from Touchpad

1. The user selects an item from the pad

2. The system displays the details of the item

3. The user enters the quantity


5. The user selects the sales option (credit/cash) and payment type (check, cash, credit card, debit card) and press Print button

6. The system checks the validity of the data and save the invoice

Postconditions: The system will display or print sales invoice

Select the item from Master record

1. The user selects the item from the master record

2. The system displays the details of the item


2011


3. The user enters the quantity


5. The user selects the sales option (credit/cash) and payment type (check, cash, credit card, debit card)

6. The system checks the validity of the data and Print the invoice

Postconditions: The invoice will be printed and transaction is recorded in the database

Hold an invoice

1. The user selects the sales option (credit/cash) and payment type (check, cash, credit card, debit card) and presses the Hold button

2. The system will put the item in its hold state

Order while in Held state

1. The user selects a specific held invoice and presses add additional order button

2. The system will display the list of orders made to that specific held invoice

3. The user enters additional order to the invoice in the held state and presses save.

4. The system will add the item in the held invoice with the same Reference number and displays a printable held invoice.

Postconditions: The order is added to the held state

Exceptions:

Includes: Login

Priority: High

Frequency of Use: Ones in a minute

Special Requirements: 1. The sales invoice may be suspended one or more times 2. When selecting an item, the system should automatically generate the necessary

detail information of the specific item with a default quantity of 1 3. Item should be selected using one of the following options:

By typing item id

By typing the description

By using barcode reader

By using touchpad

By using search criteria

By selecting line item 4. This use case generates SJ 5. POS configuration facility should be included in the Sales Settings menu item of the

settings menu and the POS interface should behave differently according to the settings

6. If a system is running on a POS terminal POS toolbar should be activated with appropriate POS type

Assumptions:


2011


Use Case ID: UC-4

Use Case Name: Prepare sales Consignment



Actors: Sales Person, System Admin

Description: This use case is used to create Sales Consignment note.


Post-conditions: The system will save the new Sales Consignment note and displays a printable document.

Normal Course:

1. The user chooses Consignment sales menu item from the Sales Menu

2. The system displays the Consignment Sales Preparation Form along with the system generated consignment sales id

3. The user enters the detail list of items along with their quantity, and presses Save button

4. The system checks the validity of the data and displays a confirmation message


Prepare Sales Consignment From Previously Prepared Consignment Sales note

1. The user selects Previous Consignment tabs from the Consignment Preparation Form

2. The system starts Prepare Voucher From Existing Voucher use case with previous Sales Consignment

Exceptions:

Includes: Login

Priority: High

Frequency of Use: Once in a day


Assumptions: All the requested items are available in the database i.e. consignment invoice will not be prepared for an item that is not yet registered


2011


Use Case ID: UC-5

Use Case Name: Prepare sales Return Invoice



Actors: Sales Person, System Admin

Description: This use case is used to create Sales Return Invoice


Post-conditions: 1. The system will save the new sales return invoice and displays a printable document

2. The system will track and make changes on the quantity of the items

Normal Course:

1. The user chooses Sales Return menu item from the Sales menu

2. The system displays the Sales Return Invoice Preparation Form having Direct, Cash Sales and Credit Sales tabs with an activated Cash Sales tab with an automatically generated sales return invoice id

3. The user selects invoice type and customer

4. The system displays the list of valid sales invoice for the selected customer

5. The user selects specific sales invoice

6. The system displays list of items sold in that specific sales invoice

7. The user selects items being returned and the corresponding quantities and enters the reason for sales return and presses Ok button.

8. The system checks the validity of the data and saves the sales return invoice


Prepare Sales Return invoice from previous documents

1. The user selects one of the previous documents tab

2. The system starts Prepare Voucher From Existing Voucher use case with the selected document as a parameter

Exceptions: None

Includes: Login

Priority: High

Frequency of Use: Once in three days


Sales return may have reference document

Assumptions:


2011


2.3.2.2. Use Case description for Warehouse management system

No Use Case Name Description

1 Configure Inventory Subsystem This use case is used to adjust the way the Inventory subsystem behaves. It configures auto notifications and other settings

2 Prepare Store Request This use case is used to prepare store request. It

may be triggered by dispensary store or by user.

3 Approve Request This use case is used to approve inventory

vouchers whenever required

4 PreparePurchaseRequest This use case is used to initiate the purchase

process. After a purchase request is approved it

will become purchase order.

6 Close Inventory This use case is used to register inventory balance

at specific time.

7 Prepare GRV This use case is used when an item is proved to be

received into a store

8 Manage Disposal This use case is used to prepare disposal invoice

when an item is consumed or disposed

9 Manage Supplier Return This use case is used to manage returns made to

the supplier

10 Manage Stock Return This use case is used to manage items/products

returned into a store

11 Manage Stock Transfer This use case is used to manage the transfer of

items from one dispensary store to another

dispensary store


2011


Use Case ID: UC-6

Use Case Name: Configure inventory Subsystem



Actors: System Admin.

Description: This use case is used to manage the way the inventory subsystem behaves.


Post-conditions: The new inventory setting will be saved and a printable report of the new setting will be displayed.

Normal Course:

1. The user chooses Inventory Setting menu item from Setting menu 2. The system displays Inventory Settings Form containing tabs for

various types of inventory settings such as Store settings, Approval Points setting, Notifications, advanced setting , so on

3. The user selects one of the options and presses the required tab 4. The system displays the list of setting items in the selected category

with their previous/default values 5. The user makes the changes and presses the Save button 6. The system displays confirmation message 7. Step 3- 6 may be repeated 8. The user press Ok button


The user wants to reset to previous setting

1. The user selects the previous settings options 2. The system saves the existing setting and displays a confirmation

message for the change 3. The user approve the confirmation 4. The system replaces the existing setting with the selected

configuration settings

Exceptions:

Includes: Login - in the case when the user configures after the installation is

completed

Priority: High

Frequency of Use: Once in three months


1. If invalid configurations are made, the system should display the summary of the invalid entries and should not move to the other page.


3. The Configuration History Bin should contain the previous configuration history


2011


Use Case ID: UC-7

Use Case Name: Prepare Store request


Date Created: Jan 10, 2011 Date last Updated Jan 10,2011

Actors: Store personnel, System Admin

Description: This use case is used to prepare store request. It may be triggered by

dispensary store or by user.


Post-conditions: New store request is registered to the Approval Waiting List and message will be transferred to the person responsible for approval

Normal Course:

1. The user chooses Store Request menu item from Inventory menu

2. The system displays Store Request Form

3. The user selects or enters items, set their quantity, set the level of urgency (urgent or top urgent) and press Ok button

4. The system validates the data and displays printable Store Request Voucher


Prepare Store Request From other documents

1. The user presses From Previous Voucher button

2. The system executes the Prepare Voucher From Existing Voucher use case

Exceptions:

Includes: Login, Prepare Voucher From Existing Voucher

Priority: High

Frequency of Use: Once in half a day


The system should automatically generate an id to newly generated store request vouchers

Assumptions:


2011


Use Case ID: UC-8

Use Case Name: Approve Store Request


Date Created: Jan 10,2011 Date last Updated Jan 10, 2011

Actors: Authorized personnel, System Admin

Description: This use case is used to approve store request

Preconditions: 1. The user is successfully logged in

2. The ERP Main Window is displayed

Post-conditions: 1. The document will be approved and passed to the next state. 2. Those Store Requests that are suspended will not be removed from

the Approval Waiting List along with their suspended items only 3. One or more SIVs may be created 4. One or more Purchase Request Vouchers may be created

Normal Course:

1. The user chooses Store Request Approval menu item from the Inventory Menu or press the Ok button when the approval request message is displayed

2. The system displays the list of store request documents in the Store Request Approval Form

3. The user selects a store request from Approval Waiting List

4. The system displays the detail line item

5. While the user selects an item from the line item, the system displays Availability Information

6. The user chooses either From Stock or From Consignment option depending on the Availability Information and presses Ok button

7. The system will put available items in the Temporary SIV with respective requester

8. The system removes the item from the Store Request Vouchers in line item list

9. The user repeats step 3 8 until exhausting the Approval Waiting List

10. The user press the Approve Button


3.6.1 The request is for an item and the item is not available in the stock

and it is not in transit with the requested quantity

1. The system chooses Purchase Request option

2. The user presses Ok button

3. The system puts the item to the respective suppliers Temporary Purchase Request Documents

Exception: If the suppliers Temporary Purchase Request Document is not yet created the system will create a new Temporary Purchase Request Document for the supplier

3.6.2 The request is for an item and the item is not available in the stock


2011


with the requested quantity but it is in transit

1. The system selects Suspend Request option


3. The system keeps the Store Request Voucher along with the suspended item

3.6.1 The request is for a product and the product is not available

1. The system chooses Job Request option


3. The system puts the item in the Job Request Voucher

3.6.1 The item is not registered in the database

1. The system displays a item not registered message and prompt the user for registration

2. The user confirms the registration 3. The MaintainItem use case from the Global Package will be triggered 4. The system will prepare Temporary Purchase Request Voucher for the

supplier that is registered along with the item. Post condition: A new item is added to the stock items list.

Exceptions:

Includes: Login, PrepareSIV, MaintainItem, PrepareJobRequest,

PreparePurchaseRequest

Priority: High

Frequency of Use: Once in an hour


1. When the user press the Ok button from the new approval request message, the system should display Store Request Approval Form with the list of store request documents that needs approval

2. It should be possible to stop live messaging when the authorized personnel do not want it.

Assumptions: 1. The person who approves requests is also responsible for the registration of new items

2. There is always a default supplier for each item


2011


Use Case ID: UC-9

Use Case Name: Prepare purchase request




Description: This use case is used to initiate the purchase process. After a purchase

request is approved it will become purchase order.


Post-conditions: The Purchase Request is saved and the document becomes ready for manual approval

Normal Course:

1. The user chooses Purchase Request menu item from the Inventory menu

2. The system displays the Purchase Request Form

3. The user selects items along with their quantity and press the Ok Button

4. The system saves and/or displays and/or print (with unapproved flag) the purchase request


4.3.1 Purchase Request preparation from previous document

1. The user presses From Previous Voucher button

2. The system executes the Prepare Voucher From Existing Voucher use case with previous purchase request as parameter

4.1.1 Purchase Request preparation when store request is approved

1. The system selects Prepare Purchase Request option and saves the request in the temporary Purchase Request voucher

Postcondition: The system collects all items to the supplier and save the purchase request for the next operation

4.1.1 Purchase Request preparation from the system notification

1. The system displays a popup notice for items below the reorder level

2. The user selects auto PR preparation button

3. The system displays the list of a temporary purchase request items with checkbox categorized by the supplier

4. The user selects some or all items that need purchase request and press Prepare Purchase Request button

5. The system creates one or more purchase request

Postcondition: The system saves the purchase requests for next operation

Exceptions:


2011


Includes: Login, Prepare Voucher From Existing Voucher

Priority: High



The system should automatically generate an id for the Purchase Request voucher

Assumptions: None

Use Case ID: UC-10

Use Case Name: Close inventory




Description: This use case is used to register inventory balance at specific time.


Post-conditions: The stock balance at time of closing is viewed, saved or printed

Normal Course:

1. The user chooses Close Inventory menu item from the Inventory menu 2. The system displays the on-hand, on-consignment, in-process and on-

transit balances and requests the user to close the inventory 3. The user presses the Yes button 4. The system saves and/or print the report


6.1.1 Automatic closing

1. The prescheduled closing task is fired and the system displays inventory closing alert message

2. The user presses Yes button

3. The system computes the on-hand, on-consignment, on-transit and on-request balances, displays a printable summary and saves the result in the database

Exceptions:

Includes: Login

Priority: High

Frequency of Use: Once in a month


Assumptions:


2011


Use Case ID: UC-11

Use Case Name: Prepare GRV




Description: This use case is used to prepare Goods Receiving Voucher


Post-conditions: The GRV is saved, a printable GRV is displayed and the document moves to the next state

Normal Course:

1. The user chooses Good Receiving Voucher option from the Inventory menu 2. The system displays the GRV Preparation Form 3. The user selects or enters supplier information and other necessary

information along with all the voucher line items and press Save 4. The system checks the validity of the document then saves and/or displays

and/or print the GRV


7.3. 1. GRV preparation from previous document

1. The user presses From Previous Voucher tab

2. The system executes the Prepare Voucher From Existing Voucher use case with Purchase Order and Consignment Note as parameters

Exceptions:

Includes: Login, Prepare Voucher From Existing Voucher, MaintainItem

Priority: High



This use case generates PJ

Assumptions: All GRV line items are already registered by the system.


2011


use Case ID: UC-12

Use Case Name: Manage disposal




Description: This use case is used to prepare disposal invoice when an item is consumed or

disposed


Post-conditions: The Disposal Voucher is saved, a printable (with unapproved flag) Disposal Voucher is displayed and the document moves to the next state

Normal Course:

1. The user chooses Disposal Voucher menu item from the Inventory menu 2. The system displays the Disposal Preparation Form with automatically

generated disposal id 3. The user enters items to dispose, reason for disposal (expired, damaged,

defective, consumption) and press Ok button 4. The system checks the validity of the data and displays a confirmation

message


8.3. 1. Disposal Voucher Preparation from previous document

1. The user presses From Previous Voucher tab 2. The system executes the Prepare Voucher From Existing Voucher use case

with Direct and Store Return parameters

Exceptions:

Includes: Login

Priority: High



1. This use case generates GJ

2. Disposal Voucher should always be approved

Assumptions:


2011


Use Case ID: UC-13

Use Case Name: Manage Supplier Return




Description: This use case is used to prepare supplier return invoice


Post-conditions: The new Supplier Return Voucher is saved, a printable (with unapproved flag) Supplier Return Voucher is displayed and the document moves to the next state

Normal Course:

1. The user chooses Supplier Return Voucher option from the Inventory menu 2. The system displays the Supplier return Preparation Form with an

automatically generated Supplier Return Voucher id 3. The user selects supplier, items and their quantity, reason for return

(normal, expired, defective, damaged), remark and presses Ok button 4. The system checks the validity of the data and displays a confirmation

message


9.3. 1. Prepare Supplier From Previous Voucher


2. The system executes the Prepare Voucher From Existing Voucher use case with GRV and Stock Return parameters

Exceptions:

Includes: Login

Priority: High

Frequency of Use: Once in a week


Assumptions:


2011


Use Case ID: UC-14

Use Case Name: Manage Store Return




Description: This use case is used to manage items returned into a store usually by

consumers or dispensary stores


Post-conditions: The new Store Return Voucher is saved, a printable Store Return Voucher is displayed and the document moves to the next state

Normal Course:

1. The user chooses Store return menu item from the Inventory menu

2. The system displays the Store Return Preparation Form with automatically generated store return id

3. The user selects or enters items to be returned and their quantity, reason for return (normal, expired, defective, damage), remark and presses Ok button



10.3. 1. Prepare Store Return from Previous Document


2. The system executes the Prepare Voucher From Existing Voucher use case with sales return, SIV and other store return as parameter

Exceptions:

Includes: Login

Priority: High

Frequency of Use: Once in a week


3.

Assumptions:


2011


Use Case ID: UC-15

Use Case Name: Manage Stock Transfer




Description: This use case is used to manage the transfer of items from one dispensary store

to another dispensary store


Post-conditions: The new Stock Transfer Voucher is saved, a printable (with unapproved flag) Stock Transfer Voucher is displayed and the document moves to the next state

Normal Course:

1. The user chooses Store Transfer Voucher menu item from the Inventory menu

2. The system displays the Store Transfer Voucher Form with an automatically generated store transfer voucher id

3. The user enters or selects the source store, destination store, reason for transfer and items list with their respective quantities and press Ok button.



11.3. 1. Prepare Item Transfer from Previous Document


2. The system executes the Prepare Voucher From Existing Voucher use case with store transfer parameter

Remark: Stock Transfer is commonly prepared from GRV, Sales Return, Consignment Note, or Store Request

Exceptions:

Includes: Login

Priority: Moderate



4.

Assumptions:


2011


Use Case ID: UC-16

Use Case Name: Prepare Voucher from existing Voucher




Description: This use case is used to prepare a voucher from previously prepared voucher. It

is introduced to minimize the amount of time required to prepare a new

voucher from line items. It is used when the new voucher continent is very

similar to previously prepared voucher.

Preconditions: 1. The user is successfully logged in 2. A new voucher is created with its own id 3. The user presses one of the tabs on the new voucher creation form

Post-conditions: The voucher line items grid of the caller will be populated with the selected voucher line items from the documents

Normal Course:

1. The system displays the list of documents in the selected category along with the modification controls required for the specific document category

2. The user searches a document from the Documents List pane

3. The system displays all the voucher line items in the Detail Content pane

4. The user can add all the voucher line items in a document together or can modify and add each item one by one into a voucher line item pane

5. The user press the Ok button

6. The system populates the voucher line item grid of the caller with voucher line items that are selected on the Document Selection Form


3.4.1 Searching a document with criteria

1. The user enters search criteria (date, line item, etc) and press Filter button 2. The system displays all the documents that satisfy the criteria in the

Documents List pane.

Exceptions:

Includes: Login

Priority: Moderate



1. The user should also be allowed to add items that are not in any previous document

2. The user should be allowed to add items from one or more documents

Assumptions: Users will use this use case when they want to prepare a voucher that has

similar content as voucher that is prepared previously.


2011


2.3.2.3. Use Case description for the Accounting System

In the Accounting subsystem sixteen use cases are identified. The following list describes each of the use

cases briefly:


1 ConfigureAccountingSubsystem This use case is used to adjust the way the

accounting subsystem behaves. It configures

accounting methods, posting methods, accounts,

periods, and etc.

2 MaintainChartOfAccont This use case is used to create control accounts,

subsidiary accounts, set default accounts and

maintain beginning balances

3 MaintainBegnningBalance This use case is used set the beginning balance of

each of the accounts

4 ManageBudget This use case is used to set budget for expense

accounts

6 MaintainFixedAsset This use case is used to record a new fixed asset

and/or to modify an existing one

7 PreparePaymentRequest This use case is used to prepare payment request

8 ApprovePaymentRequest This use case is used to approve payment requests

waiting for approval

9 PreparePaymentVoucher This use case is used to prepare payment voucher

(PCPV or BPV) for purchase order, purchased items,

payment order or sales return

10 ManageOutgoingCheck This use case is used to manage the checks

prepared for employee, supplier or any other

payee. It defines number of payments, starting

date, check payment interval.


2011



11 PrepareReceipt This use case is used to prepare receipt when

receiving cash, check or credit card for credit

settlement or deposit

12 PrepareBankDepositSlip This use case is used to prepare deposit slips for

cashes received through cash sales invoice and

receipts

13 ManageIncomingCheck This use case is used to manage checks coming

from into an organization.

14 ManageAccountReconciliation This use case is used to check that the amounts of

liquid assets you show in the checkbook are

identical to the account balance shown on your

bank statement as of the same date.

15 ManageJournal This use case is used to generate, modify or post

any one of the five journals (GJ, DJ, SJ, RJ, and PJ)

16 CloseAccountingPeriod This use case is used to know the exact balance of

an account at the end of a given period

3.

4. Table 1: Use Cases List in the Accounting Subsystem

se Case ID: UC-17

Use Case Name: Configure Accounting Subsystem



Actors: System Admin

Description: This use case is used to adjust the way the accounting subsystem behaves. It

configures posting methods, accounts, periods, and etc.

Preconditions: 1. Installation of the Accounting subsystem is completed 2. The user wants to configure the Accounting subsystem

Post-conditions: 1. The settings of the system will be changed and the system will display a printable configuration information


2011


2. The system will keep the previous configuration information in a Configuration History Bin

Normal Course:

1. The user chooses Accounting Settings menu item from the Settings menu or the system displays a message that requests the user to configure the accounting subsystem

2. The system starts the Accounting Configuration Form with brief description of the configuration tabs and an option to take the system to previous configuration

3. The user selects any one of the tabs (fixed assets rate, check print setting, payment setting, period setting, Default Account, Account Integration, Posting Method, Advanced Setting, and etc)

4. The system displays the list of setting items in the selected category with their previous/default values

5. The user modifies the default values and presses the Apply button

6. The system will validate the data and display confirmation message


1.3. 1. The user wants to reset to previous setting

1. The user selects one of the previous settings options from the past three settings

2. The system saves the existing setting and displays a confirmation message for the change

3. The user approves the confirmation

4. The system replaces the existing setting with the selected configuration settings

Exceptions:

Includes: Login - in the case when the user configures after the installation is completed

Priority: High

Frequency of Use: Once in six months



2. The Configuration History Bin should contain the last three configuration history

3. All the setting pages must be separated by tab on the Accounting Configuration Form

Assumptions: Acceptable default values will be set for each configuration items.


2011


Use Case ID: UC-18

Use Case Name: Maintain Chart of Account



Actors: Accountant

Description: This use case is used to create control accounts, subsidiary accounts


Post-conditions: The chart of account is created and a printable account tree is displayed

Normal Course:

1. The user chooses Chart Of Account menu item from Accounting menu 2. The system displays Chart of Account Form 3. The user selects or enters a control account from/to a tree or a combo 4. The system shows subsidiary accounts( if there are any) of the selected

control account 5. The user creates new accounts or modifies existing accounts and presses

the Save button 6. The system checks the validity of the data and displays a confirmation

message 7. Step 3 - 6 may be repeated until all the entries of the chart of account are

made


2.3.1 Automatically creating accounts for employees, items, suppliers, and

customer

1. The user checks one or more checkboxes to the left of each of the entities (employee, item, supplier, and/or customer) along with detail/category options for which the accounts should be created and presses Generate Accounts button

2. The system displays the automatically created accounts

3. The user reviews the accounts and presses the Save button

The system displays a confirmation message

Exceptions:

Includes: Login

Priority: High

Frequency of Use: Once in three months


Assumptions:


2011


Use Case ID: UC-19

Use Case Name: Maintain Beginning Balance



Actors: Accountant , System Admin

Description: This use case is used to maintain the beginning balance of each of the accounts


Post-conditions: The beginning balance of each of the accounts will be set and a printable beginning balance report will be displayed

Normal Course:

1. The user chooses Beginning Balance menu item from Accounting menu

2. The system displays Beginning Balance Form containing all the accounts in the chart of account

3. The user enters the beginning values and press the Save button



Exceptions: If the user does not set any value for an account the system will take a valued of 0 as its beginning balance

Includes: Login

Priority: High

Frequency of Use: Once in a year


1. The system should allow the maintenance of beginning balance at any time

The system should determine and enable the appropriate debit or credit side entry option automatically

Assumptions:


2011


Use Case ID: UC-20

Use Case Name: Maintain Budget




Description: This use case is used to set budget for expense accounts


Post-conditions: The budget amount of each of the expense accounts will be set and a printable budget report will be displayed

Normal Course:

1. The user chooses Budget menu item from Accounting menu

2. The system displays the Budget Maintenance Form with the list of expense accounts from the chart of account

3. The user enters the budget values and press Save button



Exceptions:

Includes: Login

Priority: High

Frequency of Use: Once in a year


1. The system should allow the maintenance of budget at any time

2. A facility to view previous budget values for an account must be implemented

Assumptions:


2011


Use Case ID: UC-21

Use Case Name: Maintain Fixed asset




Description: This use case is used to record a new fixed asset and/or to modify an existing

one

Preconditions: 1. The user is successfully logged in 2. The Accounting Main Window is displayed

Post-conditions: The new fixed asset is saved into the fixed assets file

Normal Course:

1. The user chooses Fixed Asset menu item from Maintain menu

2. The system displays Fixed Asset Maintenance Form along with automatically generated asset id.

3. The user enters/selects asset information such as the location of asset (where it physically located), asset group(class) information, Account information such as asset account, account depreciation, depreciation rate, depreciation expiration account, and selects fixed asset depreciation methods, and depreciation period information and presses Save button

4. The system validates the data and saves the fixed asset


6.3.2 Modify the record of existing Fixed Asset

1. The user presses Edit tab from the Fixed Asset Maintenance Form

2. The system displays a combo box for selecting the asset

3. The user selects a specific fixed asset item

4. The system populates the Fixed Asset Maintenance Form with the data of the selected fixed asset

5. The user performs the required modification and presses the Save button

6. The system validates the data and displays confirmation message

Postconditions: The record of fixed asset is modified

Exceptions: If the user has no modify access privilege, the Edit tab will be disabled

Exceptions:

Includes: Login

Priority: High



The system should automatically generate an id to newly registered fixed asset


2011


Use Case ID: UC-21

Use Case Name: Prepare Payment Request



Actors: Accountant , Cashier, System Admin

Description: This use case is used to prepare payment request


Post-conditions: 1. The system saves the request, the Payment Request will be added to the Approval Waiting Queue of the authorized personnel and a printable payment request document will be displayed

2. An approval request message will be sent to the authorized personnel

Normal Course:

1. The user selects Payment Request menu item from the Accounting menu

2. The system displays the Payment Request Form

3. The user selects or enters the payee, the amount, reason for payment, task/project and presses Prepare button

4. The system will validate and generate a confirmation message


Exceptions:

Includes: Login

Priority: High



Assumptions:


2011


Use Case ID: UC-22

Use Case Name: Approve Payment Request



Actors: Authorized Personnel, Accountant

Description: This use case is used to approve payment requests waiting for approval


Post-conditions: The payment request will be changed to payment order and wait for the preparation of BPV or PCPV preparation and a printable payment order document will be displayed

Normal Course:

1. The user chooses Payment Approval menu item from the Accounting menu or presses the Ok button when the approval request message is displayed

2. The system displays the list of payment request documents in the Payment Approval Form

3. While the user selects an item from Approval Waiting List, the system displays the request detail (requester, amount, task and reason)

4. The user sets account number and deduction requirement (Add VAT, VAT included, Apply Withhold, None) and presses Approve button

5. The system will prepare Payment Order and make it ready for the preparation of BPV or PCPV

6. The user repeats step 3 4 until exhausting the Approval Waiting List


Exceptions:

Includes: Login, Manage Journal

Priority: High



The user may check budget before approving payment request.

Assumptions:


2011


Use Case ID: UC-23

Use Case Name: Prepare Payment Voucher



Actors: System Admin, Accountant

Description:

Preconditions: 1. The user is successfully logged in 2. The ERP Main Window is displayed 3. Reference payment document (PO, GRV, Store Return Voucher, Payment

Order) is already prepared

Post-conditions: The system saves the new payment voucher BPV will be displayed

Normal Course:

1. The user selects the Payment Voucher menu item from the Accounting menu

2. The system displays the Payment Voucher Preparation Form along with unsettled GRV, PO, Sales Return, Payment Order tabs that displays the list of the required reference documents that are prepared same day

3. The user selects specific tab

4. The system displays the list of unsettled documents in the selected category along with a checkbox to their left and an editable text box containing the remaining amount to their right

5. The user selects or modifies one of the documents in the reference documents list

6. The system will filter unpaid or unsettled documents that are going to be paid for the selected reference document payee

7. The user checks all or some of the documents from the filtered list of reference documents and modify the amount they carry

8. The system displays the payee, the total amount, and default cash account that will be affected

9. The user may modify the cash account and presses Prepare button

10. The system prepares BPV


8.6.1 The user wants to prepare a payment document for several payees on a

single payment document

1. The user uncheck the Per Payee checkbox

2. The system displays all unsettled reference documents

3. The user checks two or more references documents that belong to different payees

4. The system displays the total amount referenced to the selected payee and prepares BPV

8.10.1 The user wants to prepare a PCPV


2011


1. user select petty cash account from the cash account and presses the Save button

The system generates and saves PCPV and displays a printable PCPV

Exceptions: If the user wants to prepare a PCPV or BPV irrespective of the rule set by the company, the system will provide the facility to the user to do so

Includes: Login, ManageJournal

Priority: High



1. The user can Refresh button if the he/she wants to see all the payment documents after processing for a single payee

2. The user should be able to see or modify the affected journal while preparing payment

Assumptions:


2011


Use Case ID: UC-24

Use Case Name: Manage Outgoing Check



Actors: Accountant, System Admin

Description: This use case is used to manage the checks prepared for employee, supplier or

any other payee. It defines number of payments, starting date, check, payment

interval, check no, and due date.

Preconditions: 1. The user is successfully logged in 2. The ERP Main Window is displayed 3. The BPV is prepared

Post-conditions: The check schedule along with the amount is saved and become ready for printing

Normal Course:

1. The user chooses Prepare Check submenu of the Accounting menu and presses Outgoing Check menu item

2. The system displays accounting document form with BPV tab activated

3. The user enters filter criteria and presses Show button

4. The system displays BPVs that satisfies the filter criteria

5. The user selects a BPV and selects prepare check menu from a contextual menu

6. The system displays check preparation form

7. The user enters number of payments, starting date, and date interval, check no information and presses Ok button

8. The system saves the outgoing check information and displays printable BPV


Exceptions:

Includes: Login

Priority: High



1. The checks will be printed from Accounting document outgoing check tab 2. Each time the check is prepared the system checks the payment limit per

day

Assumptions:


2011


Use Case ID: UC-25

Use Case Name: Prepare Receipt



Actors: Accountant, Cashier, System Admin

Description: This use case is used to prepare receipt when receiving cash, check or credit card for

credit settlement or advance deposit


Post-conditions: The system saves and displays a printable receipt voucher

Normal Course:

1. The user selects Receipt Voucher menu item from the Accounting menu 2. The system displays Receipt Preparation Form with direct and credit settlement

tabs 3. The user selects the direct tab 4. The system displays direct receipt preparation controls 5. The user selects or enters payer, reason for payment, and cash account that will

be affected and presses Prepare button 6. The system will prepare the receipt

Alternative Courses: 11.5.1. The payment is with check or Credit card

1. The user selects Check option

2. The system triggers the ManageIncomingCheck use case

11.3.1. The Payment is from Credit settlement

1. The user selects the Credit settlement tab

2. The system displays unsettled Credit sales invoice along with a checkbox to their left and an editable text box containing the remaining amount to their right

3. The user selects or modifies one of the documents in the reference documents list

4. The system will filter unpaid or unsettled documents that are going to be paid for the selected reference payer

5. The user checks all or some of the documents from the filtered list of reference documents and modify the amount they carry

6. The system displays the payer, the total amount, and default cash account that will be affected

7. The user may modify the cash account and presses Prepare button

8. The system prepares cash receipt

Exceptions:

Includes: Login, ManageIncomingCheck

Priority: High


2011




The journal that is passed is the receipt journal (RJ)

Assumptions: Customers have their own accounts

Use Case ID: UC-26

Use Case Name: Prepare Bank Deposit slip



Actors: Accountant, System Admin

Description: This use case is used to prepare bank deposit slips for cashes received through

cash sales invoice and receipts


Post-conditions: The system saves and displays a printable deposit slip

Normal Course:

1. The user selects Prepare Deposit Slip menu item from Accounting menu

2. The system displays the Deposit Slip Preparation Form along with the automatically generated id

3. The user sets filter criteria and presses the Show button

4. The system displays all cash sales