Payment and Cashiering System

3.1 Software Requirements Specification Document

Project Study

Page 35

Payment and Cashiering System 1. Introduction 1.1 Goals and objectives The purpose of this document is to describe requirements for the Payment and Cashiering System (PACS) software application that will serve as a base for the final output. It is essential that the arrangement of these requirements be reached on every user of the software application so that everyones expectation will be met. This document uses written explanations as well as various types of modeling diagrams to illustrate the high level construction of the application. This gives different stakeholders and users a view of the requirements that is better suited to their area of responsibility. A Web based solution will be made on this project so that users can access the system on their desired computer web browsers. By designing and making a standardized web page using Java programming language, the software application will run on most computer web browsers. In addition, a centralized database will be connected to the Internet that will allow the employees to easily share more information over the Internet. The Payment and Cashiering System application software is intended to provide a computer based application software that will be used in the Local Government Units. Many of the typical operations and functions involving operations on the treasurers office will be automated through software to improve the operational workflow of the office. All the processes on the treasurers office will be automated such as accepting of payments and processing of payments. The Requirements Specification will describe these as well as many other features of the software in greater detail. 1.2 Statement of Scope This section contains a general description of the software functionality followed by detailed requirements that will be traced throughout the project. Taxpayers have to comply with all the necessary requirements to get an order of payment. Completion of requirements and order of payment will be coming from different departments depending on taxes and fees.

Project Study

Page 36

Payment and Cashiering System To gain access on PACS (Payment and Cashiering System) an employee will be required to enter their username and password. Their position will determined their access privileges on the system. The administrators will have all the privileges in accessing the system, while the teller and other employees will have their own specific access. The administrators are allowed in viewing and updating of the information on miscellaneous fees. Payer will have to complete the necessary requirements such as filling up form on miscellaneous fees. Payer will go to assigned window in the city treasurers office together with the order of payment. The teller will verify the payers record by entering their PIN/billing number. The cashier will accept the payment and payers record will be updated. The system will create a receipt of payment for the payer. Administrators and managers can access reports generated by the system such as delinquency report, daily collection report and monthly collection report over a specific period of time. Such as, they can also view those payers who have unsettled accounts like real property and business tax. The features of PACS includes the issuance of electronic official receipt for regulatory fees and LGU charges, accepts various modes of payment (cash and managers check) and accepts quarter, partial and full payments. The following tables are requirements needed with indication whether it must have a high and low priority. High priority indicates that the requirement must be implemented and low priority can be eliminated. Table 1.2.2 User Requirements for Payment and Cashiering System Req. No Priority Reference Description

Access Privileges R1 High Customer There will be three levels of access; one for tellers and other employees, one for manager and one for administrator

Project Study

Page 37

Payment and Cashiering System R2 High Customer Teller can only be allowed to update a payers record when payment is received. R3 High Customer The administrators are allowed to enter and edit all the needed data. R4 Medium Customer Only the administrators and manager are allowed to view and print reports. Security R5 High Customer Each user will be required to enter a unique user name and password to access the system. R6 Low Customer Password shall have at least six alpha numeric characters. R7 Medium Code Works A user will be locked out of the system after having more than five unsuccessful attempts in entering a username and password. R8 High Customer A new password will be created if a user forgets the password. R9 Low Customer The user shall be logged off the system if there is no activity for 10 minutes. Accepting Payment R10 High Customer Taxpayer shall have the order of payment from designated department. R11 R12 High High Customer Customer Only the teller is allowed to accept payment. The teller shall input the right amount given by the payer. R13 High Code Works The exact amount of change shall be given in every transaction. Issuance of Receipt R14 High Code Works Receipts shall include relevant information from transaction such as date, the type of fee/tax, amount paid, balance (if not fully paid) and the name of the

Project Study

Page 38

Payment and Cashiering System cashier who process the transaction. Reports R15 Customer Delinquents for Real Property Tax reports shall list all the taxpayer that is not paid for a selected period of time including their property and the amount not paid. R16 Customer Delinquents for business permit and licenses reports shall list all the taxpayer that is not paid for a selected period of time including their business and the amount not paid. R17 Customer Top taxpayers report for real property tax and business permit shall list taxpayers starting from those who paid biggest amount. R18 Customer Daily collection report shall include the total amount of cash and managers check collected by a particular cashier. Account Information R19 High Customer When the teller settles the taxpayer account, audit trail must contain the date, time and the changes done and shall be recorded on the database. R20 High Customer The payers account shall contain the following information: 1. taxpayer_id 2. firstname 3. middlename 4. lastname 5. gender 6. height 7. status 8. date_of_birth 9. place_of_birth Project Study Page 39

Payment and Cashiering System 10. contact no 11. TIN_no 12. occupation 13. citizenship 14. street 15. purok 16. municipality 17. barangay R21 High Customer User shall contain the following information: 1. User name 2. Password 3. Usertype 4. Status R22 High Customer The system shall support the ability to enter, store and update the employee and payers information. User Interface R23 High Customer The system shall respond to all user requests within 20 seconds.

1.3 Software Context The iTAX system is used as a model in this document. iTAX stands for integrated tax administration software for assessment and collection. It is an integrated system that allows the administration of all taxes, on a national as well as a local level. iTAX has been initially developed in a cooperation project between the Tanzanian Revenue Authority (TRA) and Deutsche Gesellschaft fr Technische Zusammenarbeit. (GTZ) GmbH. Tanzania by now has introduced iTAX nationwide and starting in 2007, iTAX has been adapted to the needs of local government units in the Philippines.

Project Study

Page 40

Payment and Cashiering System iTAX is therefore a software solution specifically designed for a developing country context. It is constantly improved, notably through South-South cooperation between the Philippines and Tanzania. Governments and public authorities in general have to act on behalf of society at large, notably in providing key public services. These include education, roads, health and social security, defense, and civil order forces. Public services are primarily financed through tax revenue, especially where a country does not have major natural resources at its disposal.

The responsibility of the government to finance public services lies therefore at the heart of taxation. Applying criteria of efficiency, fairness, and transparency to tax systems and the spending of government resources creates a virtuous circle of improving fiscal performance, good governance, fair distribution of public goods and services, and ultimately strengthens state legitimacy.

Indeed, understanding user demand is important to finding an adequate technical solution. Top-down approaches in iTAX strategies were frequently resulting in early failures. Resistance from civil servants is probably the biggest challenge to successful iTAXimplementations. High involvement of public authority staff will ensure a sustained administration effort for modernization. Hence, capacity development within the government is an important step for eGovernment and its effective implementation. With the establishment of well-structured plans that embrace employee participation throughout all stages of the process, civil servants will become key stakeholders of the reform.

There is no one-size-fits-all model for e-Government development. Each country needs to devise its own e-Government strategy and program, taking into consideration its political, economic and social priorities and its financial, human and technological capacities. The key to effective e-Government implementation is a multi-pronged approach based on technology as well as human development. The price for existing commercial tax administration software is based almost exclusively on IC price levels. Such solutions are too costly for most governments in DCs. As a consequence, most tax computation, assessment, and accounting in DCs is still Project Study Page 41

Payment and Cashiering System done manually, using various loose leaf systems, index cards or folios. This neither enhances administrative transparency nor does it promote tax payer compliance.

An IT system has the potential to help modernize the administrative processes. For example, in the Philippines, it may take up to four hours to inform a (waiting) tax payer about his tax bill. With the new IT system, this waiting period is reduced to 3 minutes, including issuing a proper tax or payment receipt.

Additionally, iTAX offers opportunities for the development of local ICT capacities that will in turn ensure the sustainability of the system. In order to comply with the need for cost effective solutions, the GTZ product predominantly uses open source software and focuses on their appropriate adaptation and implementation on the national and on the local community level.

The objective of the program is to transform the real property tax system in every province into an equitable, revenue-productive and cost-effective system through process innovation. It is basically an organizational development program that seeks to use behavioral knowledge to change beliefs, attitudes, values, strategies, structures and practices so that the organization can better adapt to changing environment. The participatory approach utilized by the program was intended to influence a paradigm shift not only for treasury and assessment personnel, but most especially to elective officials and other major stakeholders like barangays and teachers including the public in general. This program is the first of its kind among the various interventions in the past on real property tax administration. 1.4 Major Constraints The Payment and Cashiering System will use JAVA programming language The Payment and Cashiering System will use MySQL for the database

2. Usage Scenario 2.1 User Profiles The following definitions describe the actors in the system. Project Study Page 42

Payment and Cashiering System Table 2.1.1 Payment and Cashiering System User Profiles Administrator An Administrator is responsible for adding, viewing and editing all forms of the system setup and has the privilege to view all the reports of the system. Manager Teller A Manager views all the reports of the system. A Teller accepts the payment of the tax payer and updates the info of the payee in the system. System The System refers to the computer hardware and software that controls the application. It accepts user input, displays user output, and interfaces to the Web Server through the Internet. Web Server The Web server is a remote computer that maintains the database and serves Web pages to the system.

2.2 Use-cases The following use-cases are typical interactions between the external and the internal software system. Each use-case is described in section 2.2. 1. Log onto system 2. View billing information 3. Accept payment 4. Update accounts to be settled 5. View report

2.2.1 Use-Case Diagram The use-case diagram in Figure 1 shows three actors that were described in section 2.1. Figure 1: Use-case diagram of Payment and Cashiering System

Project Study

Page 43

Payment and Cashiering System

2.2.2 Use-Case Descriptions Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario: Log on to System Employee To gain access to the System The employee has a valid user name and password An Employee needs to access the system to perform their job. 1. The System prompts the employee for their user name and password. 2. The employee enters their user name and password. 3. The system sends the user name to the web server. 4. The system verifies the password and sets the users authorization. 5. The employee is given access to the system to perform their job. Exceptions: The user name and password cannot be verified.

Project Study

Page 44

Payment and Cashiering System Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario: View account information Teller To verify the account of payer. The payer has a pin number. The teller needs to verify if the payers account exist. 1. The teller will search the payers account by entering the pin number. 2. The system requests the record from the web server. 3. A report of the record is displayed on the screen. Exceptions: The account does not exist.

Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario:

Accept Payment Teller To settle the account of payer. The payer has the order of payment. A Payer needs to pay for the fee/taxes. 1. The payer renders to teller the order of payment which comes from the appropriate department. 2. The teller will verify the payers account information. 3. The teller will accept the payment when the account is verified. 4. The teller will update the payers account information. 5. The system will create an official receipt for the payer. The payers account information cannot be verified.

Exceptions:

Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario:

Update account to be settled Teller Settle the payers account. The payer has paid. The teller accepts the payment. 1. The teller input to system the amount paid by the payer.

Project Study

Page 45

Payment and Cashiering System 2. The system will compute if there is a change. 3. The system update the payers account and save to database. 4. The system will display the updated account. Exceptions: The account does not exist.

Use-case: Primary actor: Goal in context: Preconditions: Trigger: Scenario:

View Report Administrator/Manager To view a report. Information required for the report has previously been entered. The administrator decided to view a summary of collected taxes and fees. 1. The Administrator logs on to the system. 2. The administrator selects Report from the main menu. 3. The administrator selects the name of the report from the report menu. 4. The report is displayed on the screen. 5. The administrator is given the option to close or print the report. 6. The report is closed or printed.

Exceptions:

The account does not exist.

2.3 Special Usage Considerations Order of payment fees and cost cannot be changed.

Project Study

Page 46

Payment and Cashiering System 2.4 Activity Diagrams Figure 2 shows the steps taken as user logs on to the computer system. Access is only granted if the correct user ID / password combination is entered within the first five attempts. After the fifth attempt the user ID will be locked out and an administrator will need to issue new password. Once access is granted the user can use the system according to their level of authorization.

Figure 2 Activity Diagram for logging on to the system

Project Study

Page 47

Payment and Cashiering System In Figure 3 the employee has contacted an administrator to make a new employee account. The administrator will first check the employee number. If the given employee number has already the account, the process will end. If the given employee number doesnt have any account, the system will create a record for them and then saves their information. Figure 3 Activity Diagram for New Account of Employee

Project Study

Page 48

Payment and Cashiering System Figure 4 is the viewing and updating account information was depicted in Figure 6. As shown in the diagram all employees will be able to view account information but only administrators will be allowed to edit the information. Figure 4 Activity Diagram to View / Update Account Information

Project Study

Page 49

Payment and Cashiering System

Project Study

Page 50

Payment and Cashiering System Figure 5 shows that only administrators and managers have access in viewing and printing reports. After the report is displayed on the screen it can be sent to a printer. Figure 5 Activity Diagram for Viewing and Printing Reports

Project Study

Page 51

Payment and Cashiering System 3. Data Model and Description 3.1 Data objects Taxpayer Data Object taxpayer_id firstname middlename lastname gender height civil status date of birth place of birth contact no TIN no occupation citizenship street purok municipality barangay A unique identifier assigned to a taxpayer. The first name of the taxpayer. The middle name of the taxpayer. The last name of the taxpayer. The gender of the taxpayer. The height of the taxpayer. The civil status of the taxpayer. The date when the taxpayer is born. The place where the taxpayer is born. The contact number of the taxpayer. The tax identification no released by BIR The occupation and source of income of taxpayer. The nationality of the taxpayer. The street where the taxpayer currently reside. The purok where the taxpayer currently reside. The municipality where the taxpayer lives. The barangay where the taxpayer is residing.

User Data Object userid username password usertype status A unique identifier assigned to a user. The name of the user. The password of the user to be used in logging on the system. The type or position of the user. Describes whether the user is active or inactive.

Project Study

Page 52

Payment and Cashiering System Fee Data Object fee _id fee _name cost status validity created updated purpose The unique identifier assigned to fee. The name of the fee. The cost of the fee. Indicates whether the fee is active or not. The time span of the fee. The date when the fee is created. The date when the fee is updated. Indicates where the certificate is to be used.

Payment Details Data Object transaction_id taxpayer_id date mode_of_payment The unique identifier assigned to a business. The identifier of a taxpayer account information. The date when the transaction is processed. Indicates whether the payment is annually, quarterly or biannual. mode_of_payment amount_paid userid Indicates whether the taxpayer pay cash and managers check. The amount paid by the taxpayer. The identifier of the user who processed the payment.

Order of Payment Data Object bill_no taxpayer_id date amount fee_id type_of_payment The unique identifier assigned to a payment. The unique identifier assigned to a taxpayer. The date of payment. Total amount of payment. The unique identifier assigned to fee. Indicates whether the payment is full, partial or quarterly.

Project Study

Page 53

Payment and Cashiering System 3.2 Relationships When a taxpayer apply for a new business, register a property or pay for miscellaneous fees, a department responsible for the processing of these will create an account. An account made by these departments can be viewed in Payment and Cashiering System. A taxpayer can have one or more transaction and order of payment which is a one-tomany relationship. A taxpayer can have many transactions depending on the fees to be paid. One user can process many transactions and a particular transaction is processed by only one user. This is a one-to-many relationship. A particular fee can be included or not in one order of payment. An order of payment must have at least one type of fee. And a fee can have one or more order of payment. This relationship is optional-many. 3.3 Complete data model The figure below show the relationships between the data objects describe in section 3.2. Figure 6 - Relationship Diagram of PAC System

Project Study

Page 54

Payment and Cashiering System 4. Functional Model and Description 4.1 Class Diagram Figure 7 - Payments and Cashiering System Class Diagram

4.2 Software Interface Description 4.2.1 External Machine Interfaces The software will be capable of printing receipts and reports on a local or a network printer. 4.2.2 External System Interfaces The PACS system will communicate with a Web server on the internet through a high speed network connection such as DSL, cable, or a T1 line. Project Study Page 55

Payment and Cashiering System 4.2.3 Human Interface

The web pages shall permit complete navigation using he keyboard alone, in addition to using mouse and keyboard combinations. 4.2.4 Reports

Inventory of Generated Reports Form Fields Description

Delinquents of Real Property Tax Report

Delinquency no. PIN Lot Block Brgy Kind Cls Tax Dec No. Declared Owner Years Amount Tct No.

Contains the tax payers who are overdue on payment regarding their properties.

Delinquents of Business Permit Report

Delinquency no. Tax Dec No. Declared Owner Business Name Years Amount

Contains the tax payers who are overdue on payment regarding their business tax.

Daily Collection Report

Date Username

Contains the summary of collection on a Page 56

Project Study

Payment and Cashiering System Bill no Mode of Payment Total Cash Total Check Total Amount specific day.

Top Tax Payers of Real Property Tax Report

Tax Payer ID PIN Lot Block Area Brgy Kind Cls Tax Dec No. Declared Owner Years Amount

Contains the tax payers with the highest amount of tax paid.

Top Tax Payers of Business Permit Report

Taxpayer ID Tax Dec No. Declared Owner Business Name Years Amount

Contains the tax payers with the highest amount of tax paid.

Project Study

Page 57

Payment and Cashiering System Reports Layout Table for Delinquents of Real Property Tax Report No . PIN Lot Block Brgy. Kind Cls Tax Decl. No. 1 98346 10 106 Central Condo Res. 7069264657 2 65736 5 14 Central Condo Res. 7069264655 KAREN YU 1985-2013 300,436.65 LEA LOO 2008-2013 18.643.80 Declared Owner Years Amount

Table for Delinquents of Business Permit Report No. 1 2 Tax Decl. No. 1769-264-657 1869-264-655 Business Name LOO PET SHOP YU NA YU SALON Declared Owner LEA LOO KAREN YU Years 2008-2013 1985-2013 Amount 18.643.80 300,436.65

Project Study

Page 58

Payment and Cashiering System

Table for Top Tax Payers of Real Property Tax Report

Tax Payer ID

PIN

Lot

Block

Brgy.

Kind

Cls

Tax Decl. No.

Declared Owner

Years

Amount

34

78976

20

10

Central

Condo

Res.

3456434901

ENE MAE

2008-2013

4,423,654

40

24325

30

Central

Condo

Res.

2306434941

DIANNE Y CO

1985-2013

3,000,436

Project Study

Page 59

Payment and Cashiering System Table for Top Tax Payers of Business Permit Report

No. 1 2

Tax Decl. No. 1769-264-657 1869-264-655

Business Name LOO PET SHOP YU NA YU SALON

Declared Owner LEA LOO KAREN YU

Years 2008-2013 1985-2013

Amount 18.643.80 300,436.65

Table for Daily Collection Report Date: 10/03/13 Username: Kayla Babes Bill No. 435 440 Mode of Payment Cash Check Amount 2,341.50 4,326.75

Total Check: 4,326.75 Total Cash: 2,341.50 TOTAL AMOUNT: 6668.25

Project Study

Page 60

Payment and Cashiering System Data Dictionary for each report Table name: tbl_t_order_of_payment Table description: Table for bill Column_name bill_no taxpayer_id date amount fee_id type_of_payment Type int int date float int varchar Description identity of bill identity of taxpayer date of order of people amount of bill identity of fee type of payment Remarks Not null, Primary Key Not null, Foreign Key Not null Not null Not null, Foreign Key Not null

Table name: tbl_t_paymentDetails Table description: Table for payment details Column_name transaction_id user_id mode_of_payment amount_paid bill_no Type int int varchar float int Description identity of transaction identity of user mode of payment amount paid identity of bill Remarks Not null, Primary Key Not null, Foreign Key Not null Not null Not null, Foreign Key

5 Behavioral Models and Description 5.1 Description for Software behavior 5.1.1 Events Taxpayer Class Events Taxpayer present order of Payment Taxpayer pay Taxpayer receives official receipt

Project Study

Page 61

Payment and Cashiering System User Class Events User logs on to the system User logs off to the system User is no longer active

5.1.2 States Taxpayer States Fully paid Partially paid Description The taxpayer has paid all the balances due on their account. The taxpayer has partially paid the balances due on their account. Unpaid The taxpayer has a balance due on their account.

User States Online Offline Terminated

Description The employee has logged on to the system. The employee has logged off the system. The employee has been terminated and must be blocked from using the system.

5.1 Statechart Diagram

A statechart diagram for the entire system is shown in Figure 8. After a user logs on, the system will validate the bill number and update account records as needed. Figure 9 contains statecharts for the user and taxpayer classes.

Project Study

Page 62

Payment and Cashiering System Figure 8 Overall system statechart diagram

Project Study

Page 63

Payment and Cashiering System Figure 9 Statechart diagrams

6 Restrictions, Limitations, and Constraints The system shall integrate within the existing LAN structure and with the existing systems, such as the database management systems. All HTML code shall conform to the HTML 4.0 standard. All server side code shall be written in JAVA. Any other browsers can be used.

7 Validation Criteria Software validation will ensure that the system responds according to the users expectations; therefore it is important that the end users shall be involved in some phases of the test procedure. All tests will be traced back to the requirements in section 1.2. 7.1 Classes of tests Unit testing will be conducted on all of software subsystems including 1. Viewing and editing information 2. Viewing and printing reports 3. Logging on to the system 4. Updating accounts settled Project Study Page 64

Payment and Cashiering System Acceptance testing will be conducted at the administrators side.

7.2 Expected software response The software should display an appropriate error message when a value outside the accepted limits is entered. The software should not be capable of deleting a taxpayer record with any other reasons that can lead to their extinction or unreliable consistency of transaction. The software should not be capable of deleting a type of fee whether it is categorized as an inactive transaction.

7.3 Performance Bounds The system shall support up to 100 simultaneous users against the Website/Web Server at any given time. The system will provide access to the database management.

Glossary Account Administrator Browser HTML A reference for all of the information related to tax payer. A person on the administrative staff of Treasurers Office. A software application used to locate and display Web pages. Short for Hyper Text Mark-up Language, the authoring language used to create documents on the World Wide Web. Manager Official Receipt Paid Teller Web Server A person that managers the department. The receipt given to tax payers given after the payment. The tax payer having settled payments. A person accepting payment from the tax payers. A remote computer connected to the internet that stores and delivers Web pages.

Project Study

Page 65