Fruit Store Management System For Jayani Fresh Fruits - RUP

Fruit Store Management System (FSMS)
Student Name: H H L Madusanka

Registration Number: R110738
Index Number: 1107382
Supervisor: Mr.Duminda Herath
2014/2015
This dissertation is submitted in partial fulfillment of the requirement of the

Degree of Bachelor of Information Technology (External) of the
University Of Colombo School Of Computing
DECLARATION
I certify that this dissertation does not incorporate, without acknowledgement, any
material previously submitted for a Degree or Diploma in any University and to the
best of my knowledge and belief, it does not contain any material previously published
or written by another person or myself except where due reference is made in the text.
I also hereby give consent for my dissertation, if accepted, to be made available for
photocopying and for interlibrary loans, and for the title and summary to be made
available to outside organizations.
…………………………………. Date: ....../….../......

H H L Madusanka.
(Name of Candidate)
Countersigned by:
…………………………………. Date: ....../….../......

Daminda Herath
(Name of Supervisor)
R110738 – Jayani Fruit Store Management System 2|Page

ABSTRACT
Jayani Fresh Fruits is a fruit store in Galle that having major trust with customers and
dealers with quality and freshness about their selling products for more than 15 years.
Drawback of this shop is they don’t having any kind of system for manage their Stock,
Sales, Cash flow and they just keeping track of their debtors with manually written
book. My target is to solve this problem with an automated, efficient and reliable
computerized system.
The proposed FSMS system consists of two main components. First is backend system
that employees use to do their day to day operations like selling, stock handling and
second one in static web page that customers can get information about the shop give a
feedback and so on.
FSMS can be used to store the details of Sales, Stock, and generate reports, keeping
information about debtors and creditors, keeping track of cash flow, Making employee
salaries as well. The most important task of the system is Managing Stock and Selling
goods.
The system coding was done using the PHP web programming language and MySQL
is used as the DBMS mainly. HTML, CSS, JavaScripts, Bootstrap Models, JQuery as
using technologies to the system. PhpStorm, MS Visio, MS Word, MySQL
Workbench, Photoshop CC, Google Chrome softwares that use for cording,
documentation, diagram drawing, image editing, database designing, and browsing
purposes.

ACKNOWLEDGEMENT
I owe my deep gratitude to the University Of Colombo School Of Computing for

offering us this valuable program and thanks to all the staff for guiding us to here.
There are number of persons who I want to thanks for helping and guiding me during
the period of the project and in the preparation of this dissertation, I hereby wish to
gratefully acknowledge their invaluable contribution. The compilation of this
dissertation could not have been possible without the help and support of them.
A very special recognition needs to be given to my project supervisor Mr.Daminda

Herath for his extensive assistance, without which the completion of this project would
have been extremely complicated. As the person who give me a chance to make this
system and guided me in requirement gathering and design phase of development my
next sincere gratitude goes to Mrs.Indrani Hewawasam owner of the Jayani Fresh
Friuts. Both of them provided the assistance to solve various problems I faced during
the analysis, design and development phases of JFSMS.
Finally but not least I offer my gratitude to all my friends who helped, my loving
mother and father and members of my family for their encouragement and assistance
given to me at all time.

TABLE OF CONTENTS
DECLARATION..........................................................................................................II
ABSTRACT.................................................................................................................III
ACKNOWLEDGEMENT..........................................................................................IV
TABLE OF CONTENTS..............................................................................................V
LIST OF FIGURES.................................................................................................VIII
LIST OF TABLES.......................................................................................................IX
LIST OF ACRONYMS.................................................................................................X
CHAPTER 1: INTRODUCTION................................................................................1
1.1 JAYANI FRESH FRUITS.............................................................................................1
1.2 PROBLEM DOMAIN AND NEED OF THE PROJECT...................................................1
1.3 MOTIVATION FOR THE PROJECT............................................................................2
1.4 GENERAL OBJECTIVES OF THE PROJECT............................................................2
1.5 SPECIFIC OBJECTIVE..............................................................................................2
1.6 SCOPE....................................................................................................................... 3
1.7 STRUCTURE OF THE DISSERTATION.....................................................................3
CHAPTER 2: ANALYSIS.............................................................................................5
2.1 FACT GATHERING TECHNIQUES............................................................................5
2.2 ANALYZING THE CURRENT MANUAL SYSTEM......................................................6
2.2.1 USE CASE DIAGRAM OF CURRENT MANUAL SYSTEM...........................................7
2.3 EXISTING SIMILAR SYSTEMS..................................................................................8
2.4 FUNCTIONAL REQUIREMENTS...............................................................................9
2.4.1 STOCK MODULE.................................................................................................... 9
2.4.2 SALES MODULE.................................................................................................... 9
2.4.3 ORDERS MODULE............................................................................................... 10
2.4.4 EMPLOYEES MODULE........................................................................................ 10
2.4.5 REPORTS MODULE.............................................................................................. 11
2.4.6 TRANSACTIONS MODULE..................................................................................12
2.4.7 SUPPLIERS MUDULE........................................................................................... 13
2.4.8 USERS MODULE.................................................................................................. 13
2.4.9 MASTER FILES AND OPTIONS MODULES..........................................................13
2.5 NON-FUNCTIONAL REQUIREMENTS....................................................................14
2.6 METHODOLOGY FOR THE PROPOSED SYSTEM................................................15

CHAPTER 3: DESIGN...............................................................................................17
3.1 ALTERNATE SOLUTION.......................................................................................... 17
3.1.1 STAND ALONE SOLUTION..................................................................................17
3.1.2 MOBILE APPLICATION........................................................................................ 18
3.1.3 WEB BASED SOLUTION......................................................................................18
3.2 DESIGN TECHNIQUES........................................................................................... 18
3.3 USE-CASE DIAGRAM OF STOCK MODULE..........................................................19
3.3.1 DESCRIPTION FOR REMOVE WASTAGES USE CASE.........................................20
3.3.2 DESCRIPTION FOR RECEIVE GOODS USE CASE................................................20
3.3.3 DESCRIPTION FOR RETURN GOODS USE CASE.................................................21
3.3.4 DESCRIPTION FOR MAKE PAYMENTS USE CASE..............................................21
3.4 CLASS DIAGRAM OF THE SYSTEM......................................................................22
3.5 ACTIVITY DIAGRAM OF PURCHASE.....................................................................24
3.6 DATABASE DESIGN................................................................................................ 25
3.6.1 DATA NORMALIZATION......................................................................................25
3.6.2 ENHANCED ENTITY RELATIONSHIP DIAGRAM OF JFSMS DATABASE............26
3.7 INTRODUCTION TO USER INTERFACES..............................................................27
3.8 MAIN INTERFACES................................................................................................. 29
3.8.1 LOGIN PAGE......................................................................................................... 29
3.8.2 HOME PAGE......................................................................................................... 30
3.8.3 MASTER FILES..................................................................................................... 31
3.8.4 GOODS RECEIVED NOTE....................................................................................31
3.8.5 REPORTS.............................................................................................................. 32
CHAPTER 4: IMPLEMENTATION.........................................................................34
4.1 IMPLEMENTATION ENVIRONMENT.......................................................................34
4.2 REUSED MODULES................................................................................................ 36
4.3 SECURITY............................................................................................................... 37
4.4 MAJOR CODE SEGMENTS.....................................................................................38
4.5 MODULES AND FOLDER STRUCTURE.................................................................41
CHAPTER 5: TESTING.............................................................................................42
5.1 TEST PLAN AND TEST CASES...............................................................................42
5.1.1 GOODS RECEVIED NOTE....................................................................................43
5.1.2 MAKE AN INVOICE.............................................................................................. 44
CHAPTER 6: EVALUATION....................................................................................46
6.1 RESULTS WITH RESPECT TO THE OBJECTIVE...................................................46
CHAPTER 7: CONCLUSION...................................................................................48
7.1 ACHIEVEMENTS..................................................................................................... 48
7.2 FUTUER IMPROVEMENTS.....................................................................................49
7.3 LESSONS LEARNT.................................................................................................. 50

REFERENCES............................................................................................................51
APPENDIX A: SYSTEM DOCUMENTATION.......................................................52
APPENDIX B: DESIGN DOCUMENTATION........................................................55
APPENDIX C: USER DOCUMENTATION............................................................64
APPENDIX D: MANAGEMENT REPORTS..........................................................70
APPENDIX E: TEST RESULTS................................................................................73
APPENDIX F: CODE LISTINGS.............................................................................80
APPENDIX G: CLIENT CERTIFICATE................................................................85
GLOSSARY.................................................................................................................86

LIST OF FIGURES
Figure 1 - Overall Use-Case Diagram............................................................7
Figure 2 - An Interface of a QuickBooks Software.........................................8
Figure 3 - RUP Life Cycle............................................................................. 16
Figure 4 - Use-Case Diagram of Stock Module............................................19
Figure 5 - Class Diagram of the System (Association).................................22
Figure 6 - Class Diagram of the System (Detail).........................................23
Figure 7 - Activity Diagram of Purchase......................................................24
Figure 8 - EERD of the JFSMS Database......................................................26
Figure 9 - Successful Message....................................................................28
Figure 10 - Confirmation Message..............................................................29
Figure 11 - Login Page................................................................................ 29
Figure 12 - Home Page (Administrator).......................................................30
Figure 13 - Home Page (Store Manager).....................................................30
Figure 14 - Master Files Page......................................................................31
Figure 15 - Interface of GRN.......................................................................32
Figure 16 - Sales Ledger Report (Quick)......................................................32
Figure 17 - Option Menu View.....................................................................33
Figure 18 - Item Wise Sales Report (Advance)............................................33
Figure 19 - Folder Structure of the System.................................................41
Figure 20 - Use Case of Sales Module.........................................................54
Figure 21 - Employee Module Use Case Diagram.......................................58
Figure 22 - Orders Module Use Case Diagram............................................59
Figure 23 - Users Module Use Case Diagram..............................................60
Figure 24 - Activity Diagram of a Cash Sale................................................62
Figure 25 - Login Page................................................................................ 63
Figure 26 - Home Page................................................................................ 64
Figure 27 - User Module Interface...............................................................65
Figure 28 - Add User Interface....................................................................65
Figure 29 - Edit User Interface....................................................................66
Figure 30 - Module Common Structure.......................................................66
Figure 31 - Add GRN Interface....................................................................67
Figure 32 - Supplier Payments Interface.....................................................68
Figure 33 - Date Selection In Advance Report.............................................69
Figure 34 - Advance Sales Ledger Report...................................................70
Figure 35 - GRN Listing Date Selection Menu..............................................70
Figure 36 - GRN Listing Report....................................................................71
Figure 37 - Item Wise Sale (Quick) Report..................................................71
Figure 38 - Cancel Invoice Code Listing......................................................80
Figure 39 - Check in Code Listing................................................................81
Figure 40 - Save Invoice Code Listing.........................................................83

LIST OF TABLES
Table 1 - Remove Wastages Use Case........................................................20
Table 2 - Receive Goods Use Case..............................................................20
Table 3 - Return Goods Use Case................................................................21
Table 4 - Make Payments Use Case.............................................................21
Table 5 - Form Validation............................................................................. 28
Table 6 - Error Messages............................................................................. 28
Table 7 - Implementation Environment.......................................................34
Table 8 - Goods Received Note Test Cases..................................................44
Table 9 – Make an Invoice Test Cases..........................................................45
Table 10 - Evaluation Result of Sales & Stock Handler................................47
Table 11 - Hardware Requirements.............................................................51
Table 12 - Software Requirements..............................................................51
Table 13 - Sale Items Use Case...................................................................55
Table 14 - Collect Returned Goods Use Case..............................................56
Table 15 - Cancel Invoice Use Case.............................................................56
Table 16 - Check In/Out Use Case...............................................................57
Table 17 - Collect Payments Use Case........................................................57
Table 18 - Assign Salaries Use Case............................................................59
Table 19 - Add Orders Use Case..................................................................60
Table 20 - Manage Users Use Case.............................................................61
Table 21 - Manage User Roles Use Case.....................................................61
Table 22 - Common Functions Test Cases...................................................72
Table 23 - Add a Customer Test Case..........................................................74
Table 24 - Supplier Payment Test Case.......................................................75
Table 25 - Customer PRN Test Case............................................................76
Table 26 - Cash in Test Case........................................................................77
Table 27 - Cancel Invoice Test Case............................................................78
LIST OF ACRONYMS

SYSTEM RELATED
JFSMS : Jayani Fruits Store Management System

JFF : Jayani Fresh Fruits
GRN : Goods Received Note
PRN : Purchase Return Note
EPF : Employee Provident Fund
ETF : Employee Trust Fund
SOFTWARES RELATED & TECHNOLOGIES
SQL : Structured Query Language

DBMS : Database Management Systems
IDE : Integrated Development Environment
HTML : Hypertext Mark-up Language
PDF : Portable Document Format
PHP : Hypertext Pre-processor
SHA : Secure Hash Algorithm
URL : Uniform Resource Locator
JS : JavaScripts
AJAX : Asynchronous JavaScript and XML
CSS : Cascading Style Sheet
MS : Microsoft
OS : Operating System
HARDWARE RELATED
R110738 – Jayani Fruit Store Management System 10 | P a g e

DVD ROM : Digital Versatile Disc Read Only Memory
DDR : Double Data Rate
SATA : Serial AT Attachment
RAM : Random Access Memory
DIAGRAMS RELATED & METHODOLOGIES
UML : Unified Modeling Language

EERD : Enhanced Entity Relationship Diagram
RUP : Rational Unified Process
RBAC : Role Based Access Control
CRUD : Create Read Update Delete

CHAPTER 1: INTRODUCTION
1.1 JAYANI FRESH FRUITS
Jayani Fresh Fruits started in year 2000 and not take that much of time to become the
dominant fruit seller in Galle area. Mrs. Indrani Hewawasam the owner had that
abilities and ideas to get this shop this far and move forward in this competitive
market.
They have suppliers from island wide bring fruits to the JFF daily. Throughout past 15
years they build a strong customer base and earned their trust by providing fresh and
good quality fruits. Among those customers there are government suppliers, hotel
suppliers and small business owners in Galle district. The main store at Karapitiya is
open for 12 Hours and them planning on opening another 2 shops around Galle area.
Due to their defects in manual data entry system and increase in sales, purchases and
employee count during last decade make them feel the need of an automated system.
1.2 PROBLEM DOMAIN AND NEED OF THE PROJECT
JFF is a crowed place during their working 12 hours. There are hundreds of
transactions been done in those hours. Among those transactions there are Invoices,
GRNs, PRNs, Cash in, Cash out, Customer Payments, Supplier Payments, Taking
Orders, Completing Orders, Pay daily and monthly basis employee salaries and so on.
Hench they not using any automated system they doing that all thing by manually. In
one hand they having problems with paper wastage, inefficiency and wasting of time
for that kind of works. And the other hand they having problems on miss leadings,
stock availability, collecting customer payments on time, banking cheques on time,
getting ledger, count sales, count expenses, employee salary calculations, getting list of
customer and supplier outstanding and many of sales, stock and employee managing

issues. It is therefore essential to have a system to ensure that cover this issues while
reducing the cost involved.
1.3 MOTIVATION FOR THE PROJECT
As a candidate to BIT Degree Program I have to submit a final year individual project
for successful completion. And I wanted to create an opportunity to develop my skills
and gain experience in the software development field.
As the whole working process at JFF is handled through manual data entry system they
have to face many problems in ledger maintenance, accounts handling and stock
management secessions.
The proposed computerized system will give solutions to the most of above problems
by handling sales, stock and accounts modules.
1.4 GENERAL OBJECTIVES OF THE PROJECT
The main objective of this project is establish an efficient and reliable system that
handles stock with covering point of sales needs and manage employee salaries. Also
create reports that can easily read about sales, stock and outstanding details.
1.5 SPECIFIC OBJECTIVE
 To use the system to manage transactions in sales.

 To use the system to manage transaction in stock.
 To generate more than 15 reports those are consolidated manually at present
 Facilitate employee management and handle all expenditures and revenues of
the company.
 Maintaining proper records of the customer credit and purchasing.
 Maintaining records of daily, monthly and annual reports of revenues and
expenditures.
1.6 SCOPE

Customer requirements that satisfied by the proposed JFSMS is the scope of the
project. When satisfying the basic user requirements which means functional
requirements also non-functional requirements are being satisfied automatically. The
scope of the project is as follows,
 Authentication and Authorization for different User roles

 Employee Management
o Payroll
 Stock Management
 Sales Management
 Customer Management
 Supplier Management
 Generate Reports
1.7 STRUCTURE OF THE DISSERTATION
Dissertation chapters are focused on the work that carried out during the various
Stages of the project. Every chapter will consist of required details to understand the
project with the help of appropriate figures, graphs and reports.
Frist chapter (Introduction) is aiming to provide basic idea, the nature and the scope of
this project to the reader.
Second chapter (Analysis) will be based on the requirements analysis. It summarizes

all the techniques that used to identify the requirements and introduces all the system
requirements in detail.
Third chapter (Design) will be based on the System Design. Then the techniques and
tools that are used for system design will be introduced. All significant design
decisions will be discussed. In last part of this chapter about User Interfaces. It will
provide main user interfaces with appropriate screen shots.
Next the forth chapter (Implementation) will cover all the issues in implementation.
Here some of the codes are listed and explained. Also implementation environment,
and other related issues are summarized.

Fifth chapter (Testing) is based on testing. It provides testing approaches and methods
which were used in the project with all the major test cases and test results.
Last two chapters (Evaluation & Conclusion) deal with evaluation and conclusion.
There it will be discussed and assessed all the results of the project. And will outline
failures and problems came across during the project and will give suggestions of
future work.
In addition,
 Referred materials are properly listed in the References section.

 In appendices, Design Documentation, System Documentation, User
Documentation,
 Management Reports, Code Listing, Extra Tests and Client Certificate
will be provided.
 Finally, glossary of terms is provided.
CHAPTER 2: ANALYSIS
System analysis is one of the major phases in the software development life cycle.
System analysts will help to get an overall view of the system and will be able to
produce a high level description of the system through this phase. Main objectives of

this phase are what services system should provide, required performance of the
system. Before analysing the system, first the requirements should be gathered by
using the fact finding techniques, such as interviews, observations, sample
documentations etc.
Using relevant methods and techniques and giving a significant amount of time to
analyze manual system main segments, the functional and the non-functional
requirements of the system were discovered. Some of those are Authentication and
Authorization for the different user roles to the system, Employee Management, Stock
Management, Sales Management, Customer & Supplier Management and Generate
Reports.
After completing the initial stage, the requirements were validated, classified and
structured and listed in an order of priority.
2.1 FACT GATHERING TECHNIQUES
The main requirements were gathered by an interview held with the owner and got an
excellent knowledge of the problem domain and the discussion was recorded. Open-
ended and close-ended interviews were used. Sampling documents, bills, invoices
were gathered in order to get to know about of the business domain and procedures are
being performed in the manual system. Every process was observed by visiting the
site. Observation provided such informations which plays a critical role in the system.
The captured facts were represented as scenarios and Use-Case diagrams to give a
clear picture on basic requirements and interaction sessions of the system, which can
be understood by both technical and non-technical personnel.
2.2 ANALYZING THE CURRENT MANUAL SYSTEM
In the old system employees have different task to do and know.
Store keeper want to know,

o How many quantity is in hand for each product?
o Is there are enough quantities for upcoming orders?
o What are the available products in stock and what are not?
o What products to purchase and not?
Accountant want to know,
o Is there are due payments from customers?

o Is there are due payments to suppliers?
o What and when put cheques to bank and what are to not?
o When to put money to bank for cheques?
Sales person want to know,
o Is the product available that customer requesting?

o What is the selling price of each product?
o What is the dealer price of each product? Etc.
Likewise each and every employee has a unique process to be performed in the manual
system and these employees are demotivated by this manual system because it is an
inefficient time wasting thing.
2.2.1 USE CASE DIAGRAM OF CURRENT MANUAL SYSTEM
Diagram in Figure 1 depicts the overall Use-Case of the existing system.

Figure 1 - Overall Use-Case Diagram
2.3 EXISTING SIMILAR SYSTEMS
Considering the available open source and proprietary software such as QuickBooks
[9], Insightly [10], Marg [11] (which is packed with unnecessary features and lacks
some that are critical to the client), is way beyond the amount client is willing to spend
on a system.

Point of sale, Employee management, Customer & Supplier Management, Stock
Management are the need of the client and proposed system is full filling that all needs
of the client.
A user interface of QuickBooks is depicted in Figure 2.
Figure 2 - An Interface of a QuickBooks Software
2.4 FUNCTIONAL REQUIREMENTS
Functional Requirements is what the system want to archive. It can be a calculation, it

can be a data manipulation etc. Following are the JFSMS functional requirements that
gathered through system analysis phase. [2]

Within the help of User Case model major functionalities that system should be
provided are listed through 10 modules.Use case for each module is shown in
Appendix -B
2.4.1 STOCK MODULE
Since this System depends on products supplied from outside, there’s want to be a way
to Add products that supplied, Adjust product if wrong entry occurs and want to
Remove product if there are defects of damaged and quick look at current stock
balance.
The Stock Module covers that all stock needs by
 GRN – Add products that supplied.

 Stock Adjustment - Adjust product if wrong entry occurs.
 Wastage Note - Remove product if there are defects of damaged.
 Stock Balance - Quick look at current stock balance.
2.4.2 SALES MODULE
After the products in the stock are managed there has to be a way to sale them. In the
sales module focus on covering that part.
 Check In – Add how much float when starting the day.

 Invoice – Sale items in stock.
 Cancel Invoice – If a customer return all items in invoice that he bought.
 Current Balance – To check details about to day sales up to time that view.
 Check Out – Add how much float when finishing the day.
2.4.3 ORDERS MODULE
After that main two functions client needs a formal way to handle orders that coming
from hotel suppliers, government suppliers and many more. From that client need to
add and remove orders, view dates that orders are placed.
For that purpose I designed order module. In that,

 Add Order – To add order with wanted products.
 Cancel Order – Delete orders that have been cancelled.
 Order Calendar - This is an event calendar to show upcoming orders.
2.4.4 EMPLOYEES MODULE
Another major requirement of the client is that handle employee with keeping track of
employee details, Automate salary calculation process. In employee module we focus
on that requirement of the client.
 Employee Details – In here an authorized one can add, edit, and delete details
about employees.
 Employee Salaries – In here an authorized one can add basic salaries to
employees.
 Manage Salaries – An authorized one can add leaves, half days, shot leaves,
bonuses, allowances, mark advances taken by employees in this page.
 Salary Calculation - An authorized person can calculate final salaries to all
employees and it is one button click operation. It can be done once in a month.
 Pay Sheet – This is where one can view pay sheets of employees.
2.4.5 REPORTS MODULE
Reports are vital to almost any system. In my opinion reports must be easily readable
and if one can use charts or pictorials to represent data it is an advantage. So covering
this two recommendations we created a Reports Module.
In this module,
 Sales Reports – This page have reports like,

o Sales Ledger ( Quick / Advance )

o Item Wise Sales ( Quick / Advance )
o Cheque Sales Listing ( Quick / Advance )
o Credit Sales Listing ( Quick / Advance )
o Invoice Cancelation Report ( Quick / Advance )
 Transaction Reports – This page have reports like,
o Supplier Reports
 GRN Listing
 Item Wise Purchases
 Supplier PRN
 Paid Payments To Suppliers
 Not Paid Payments To Suppliers
o Customer Reports
 Customer PRN
 Customer Paid Payments
 Customer Outstanding
 Cheque Details – This page shows cheques transactions to be done today or
upcoming days.
2.4.6 TRANSACTIONS MODULE
Most of this kind of systems there are two features that must have and it is indeed a
client’s requirement. That is cash flow of in and out. JFSMS is have that two features
embedded in Transactions Module.
When I’m explaining invoice cancellation in discussing about the system with client
her ask me two questions,
 What if a customer returned one item on an invoice that he/she bought lot other
items?
 What if we want to return one product on a GRN that we bought from a
supplier have lot other items?
For the answer to that I introduced Purchase Return Notes (PRN). I included it in to
Transaction Module.
Transaction Module have another function that record Customer Payments.

With all of this features overall Transaction Module as follows.
 Customer Payments – Taking records about customer payments.

 Supplier PRN – As I mentioned this where we returns one product we bought
from suppliers with in a GRN that have many more products.
 Customer PRN - As I mentioned this where we collect one item from a
customer that he/she returns with in an invoice that have more items.
 Cash In – This is where system collecting cash that comes from without
invoices or customer payments.
 Cash Out – This is where system saving record about cash going out without
supplier payments. It could be an expense or any other.
2.4.7 SUPPLIERS MUDULE
In Supplier Module it have two tabs.
1. Supplier Payments
2. Supplier Details
In Supplier Payments tab we are showing an interface of payments that client needs to
pay for suppliers. An authorized person can settle payments from this tab.
In Supplier Details there is company or personal details about suppliers. That includes
Supplier Company or Persons Name, Address, Contact Number, Contact Person, and
Main Telephone Number.
2.4.8 USERS MODULE
On an every system authentication and authorization is vital. That two main things
handle by Users and User Roles. In JFSMS those things included in Users Module.
In Users Module,

 User Management – This is use to add, edit, and delete users by authorized
users.
 User Role Management - This is use to add, edit, and delete user roles by
authorized users.
2.4.9 MASTER FILES AND OPTIONS MODULES
This two modules use to enter data to the system like,
 Master Files
o Category
o Sub Category
o Product
o Suppliers
o Customers
 Options
o Payment Methods
o Unit Types
2.5 NON-FUNCTIONAL REQUIREMENTS
When developing a system non-functional requirements are too want to be considered.

Non-functional requirements describe the system properties and constraints of the
system and those requirements are applied to the whole system. Its goner be a useless
system if we do not consider about non-functional requirements. [3]
Non-functional requirements are vital same as functional requirements to success of

the system. When analyzing we found out there are many non-functional requirements
to be considered. Main non-functional requirements which need to be achieved are
described below.
 Accuracy and consistency
Some functionalities in proposed system is require accurate data especially like Stock
Module. When maintaining current quantity of product, maintaining stock history with
each stock transaction accuracy in vital.

 Security of the system
System should be only operated by authorized users and authorized modules. Any
change that made in the database must be able to track who made the change.
 User friendliness
User interfaces should have consistent look and feel and should design the manner that
user can navigate the system easily. User can be able to change their passwords if they
wish and error massages provided by system should be understandable and meaningful
that user can know directly what did he/she done wrong.
 Modifiability
In case of adding new functionalities, editing and maintaining existing functions

system should provide functionality to do it without affecting the core functions of the
implemented modules. And those changes should not affect majorly in designing and
coding segments.
2.6 METHODOLOGY FOR THE PROPOSED SYSTEM
For the above models Rational Unified Process (RUP) model were chosen. Where
elements of the process can be changed according to the user’s needs, called a
adaptable process framework. RUP is that kind of framework. Inception, Elaboration,
Construction and Transition are the main phases of RUP life cycle.
 Inception phase is where the business case is defined that includes the
business context of the project. Lifecycle Objective Milestone is achieved in
this phase.

 Elaboration phase is where problem domain analysis is take palce and
architecture of the project gets its basic form. Lifecycle Architecture Milestone
is reached in this phase.
 Construction phase mainly focuses on the development of components and

other features of the system. Initial Capability Milestone is achieved through
this phase.
 Transition phase is where the built system is transferred to the end users and
they are trained and beta testing and system validations are carried out. If all
the objectives are met, the Product release Milestone is met and the
development lifecycle ends [3]
The following Figure 3 illustrates the phases of the RUP life cycle,
Figure 3 - RUP Life Cycle

CHAPTER 3: DESIGN
Including component, interfaces, modules, architecture and data, designing phase

provide details and description of the system and in software designing, system should
have good design before implementing.
Requirements gathered in analysis phase were used to create detailed specification and
data model for the system. UML 2.0 diagrams such as Use-case, Class and Sequence
diagrams were created during this phase.
And also user interfaces were designed and created it in such a way that the users will
get motivated to use the system. The environment that system actually running and the
mind-set of the system users were analysed before the design of user interfaces.
3.1 ALTERNATE SOLUTION
3.1.1 STAND ALONE SOLUTION
Client having idea of expanding their market shear by opening another 2 show rooms
in Galle area. If so it is a standalone system, developer must visit each 3 branches for

installations and every time is there are goner be a system update or upgrade that done
by manually developer must visit each and every show room for that purposes. If it is a
standalone system, client should buy recommended computer hardware to all
showrooms separately and it is an extra expense considering other solutions.
3.1.2 MOBILE APPLICATION
Developing a mobile application for this requirements and implementation

environment is a hard work. Because there is more than hundreds of products/Items,
more than 50 suppliers, more than hundreds of customers including hotel suppliers,
government suppliers, shop owners, and loyal customers, more than 10 employees, so
the question about how mobile display view or mange to done this kind of data
processing and most of system users want to be trained basic of using smart phones if
comes to that.
3.1.3 WEB BASED SOLUTION
There are several reasons to select the web based solution.
 No need to install it to every computer.

 No need to visiting every branch if it is a system update or upgrade.
 In case of system update or upgrade changes may done only to central server
and because of that each and every time when user logging in he/her log in to
latest version of the software.
 The main expense is for central server. All the clients are thin clients and for
that expenditure is less.
3.2 DESIGN TECHNIQUES

In order to get better understanding and to do comprehensive design, static and
dynamic behaviours of the system are provided. For notations UML were used and
system modelled using Use-case diagram, Class diagrams and Activity diagrams.
To design the static behaviour of the system class diagrams are used. Using identified
set of candidate classes, set of classes was filtered. After that attributes and the main
method was identified. To provide pictorial view of all classes in the system diagrams
were drawn.
Attributes and methods of the classes are not displayed in the class diagrams and all of
that are listed in the Design Documentation section (Appendix - B) of this dissertation.
Activity diagrams are used to show the workflow of the system and it also providing a
way to model the workflow of the system.
3.3 USE-CASE DIAGRAM OF STOCK MODULE
Diagram in Figure 4 depicts the overall high level Use-Case of Stock Module.

Figure 4 - Use-Case Diagram of Stock Module
3.3.1 DESCRIPTION FOR REMOVE WASTAGES USE CASE
Use Case Remove Wastages Use Case

Actors Stock Keeper
Overview
Remove wastages from the stock that can’t be returned to supplier.
Preconditions
None.
Flow of Events
i. Select damaged items from stock that can’t be returned.
ii. Add that items to wastage note and save.

iii. Remove those items from stock
Post Condition
In stock those item quantities must be decreased.
Table 1 - Remove Wastages Use Case
3.3.2 DESCRIPTION FOR RECEIVE GOODS USE CASE
Use Case Receive Goods Use Case

Actors Stock Keeper
Overview
Receive goods from supplier that deliver according to order.
Preconditions
There should be ordered supplier or have store manager approval.
Flow of Events
i. Check received goods for damages.
ii. Enter all items in goods receive note.
iii. Receive goods.
iv. Print GRN.
Post Condition
In stock relevant item quantities must be increased.
Table 2 - Receive Goods Use Case
3.3.3 DESCRIPTION FOR RETURN GOODS USE CASE
Use Case Return Goods Use Case

Actors Stock Keeper
Overview
Return goods that entered by GRN to supplier.
Preconditions
None.
Flow of Events
i. Select items that need to be returned.
ii. Add items to PRN.
iii. Return goods.
iv. Print PRN.

Post Condition
In stock those item quantities must be decreased.
Table 3 - Return Goods Use Case
3.3.4 DESCRIPTION FOR MAKE PAYMENTS USE CASE
Use Case Make Payments Use Case

Actors Accountant
Overview
Pay suppliers according to goods received note.
Preconditions
There should be due balance to pay for specific supplier that comes from GRN total.
Flow of Events
i. Select supplier from Supplier Payments.
ii. Select what GRN to pay or Settle All.
iii. Make payment.
iv. Print Invoice.
Post Condition
Supplier due payments must be reduced by paid amount.
Table 4 - Make Payments Use Case
3.4 CLASS DIAGRAM OF THE SYSTEM
The following Class diagrams in Figure 5 and Figure 6 depicts the overall classes of
the system. Please refer to Figure 6 for the methods and attributes of each class in
Figure 5.

Figure 5 - Class Diagram of the System (Association)

Figure 6 - Class Diagram of the System (Detail)

3.5 ACTIVITY DIAGRAM OF PURCHASE
Diagram in Figure 7 depicts the Activity Diagram of a purchase.
Figure 7 - Activity Diagram of Purchase
3.6 DATABASE DESIGN

A good database design is,
 Divides information into subject-based tables to reduce redundant data.
 Provides Access with the information it requires to join the information in the
tables together as needed.
 Helps support and ensure the accuracy and integrity of your information.
 Accommodates your data processing and reporting needs.
3.6.1 DATA NORMALIZATION
“Normalization [4] is the process of organizing data in a database. This includes

creating tables and establishing relationships between those tables according to rules
designed both to protect the data and to make the database more flexible by
eliminating redundancy and inconsistent dependency.”
The database design of the system is in the third normalization form (3NF)
3.6.2 ENHANCED ENTITY RELATIONSHIP DIAGRAM OF JFSMS

DATABASE

Diagram in Figure 8 depicts the EERD of the database.
Figure 8 - EERD of the JFSMS Database
3.7 INTRODUCTION TO USER INTERFACES
Interface design goner make major impact on system success. Due to poor interface
designing, many user errors can be occurred. User expectations should be matched by

good interface designing. Physical and mental capabilities of users who use the system
should be considered when designing interfaces.
To make sure that system interfaces well throughout the system, some major facts are
considered. Those are as follows,
 Consistent – Views and actions should be consistent each and every interface.
 Provide Feedback – There should be meaningful error messages and
confirmation massages.
 For easy understanding, more meaningful headings and buttons were used.
 To make interfaces pleasant to view appropriate background and text colors,
well aligned fields and tables were used.
 Users can navigate through pages easily.
 Avoiding situations that wrong entries can happen by HTML 5 or JavaScripts
validation. Table 5 shows some example of this error messages.
 According to different user privileges interfaces are rendered.
 After every saving, updating or deleting a record, every form should show the
successful message. Figure 9 shows the example of that messages.
 System goner provide meaningful error messages when fields are empty or a
user enter an invalid value. Table 6 shows some of them.
 Before deleting a record, system should take permission from the user. Figure
10 show confirmation message that appear when deleting a record.
Situation Message
When submit the form with

empty fields.
When submit the form with

invalid email address.

When type an invalid letters
in NIC text field.
When type letters in
telephone number text field.
Table 5 - Form Validation
Figure 9 - Successful Message
Situation Message
When trying to start an invoice without

check in for the day.
When trying to save an invoice without

adding any item.
When trying to add items to wastage

note without starting note.
Table 6 - Error Messages
Figure 10 - Confirmation Message
3.8 MAIN INTERFACES

This section only provide a few of user interfaces in the system to show system’s
interface structure. For rest of the interfaces please refer Appendix C – User
Documentation.
3.8.1 LOGIN PAGE
Following Figure 11 illustrate the login page that is initial interface of the system.
This is a common interface for all the users to login to the system. Only authorized
users can access to the system.
Figure 11 - Login Page
3.8.2 HOME PAGE
The Figure 12 illustrate the home page of the administrator. Due to privileges
defined to each user role, home page render the modules according to user role of the
logged in user. User can navigate easily through modules that he/her have privileged
and each module have reference to home page.

Figure 12 - Home Page (Administrator)
Figure 13 - Home Page (Store Manager)
3.8.3 MASTER FILES
In this page a privileged user can add, edit or delete Categories, Sub Categories,
Products, Suppliers and Customers. Also user can search Categories, Sub Categories,
Products, Suppliers and Customers by its name. Figure 14 illustrates Master Files
interface.

Figure 14 - Master Files Page
3.8.4 GOODS RECEIVED NOTE
This is the interface used to receive goods that supplier deliver. This interface is get
information about products like Cost Price, Received Quantity to the system. When
Save GRN button were pressed stock update by received quantity. Figure 15
illustrates GRN interface.
Figure 15 - Interface of GRN

3.8.5 REPORTS
There are more than 15 reports generated in this system. Following two figures
illustrates some sales related reports that this system generating. Most of other reports
are shown in Appendix-D.
SALES LEDGER (QUICK)
This report used to get ledger of sales done in current day and up to that particular
time.
Figure 16 - Sales Ledger Report (Quick)
ITEM WISE SALES (ADVANCE)
This report is used to get sales report in item wise. Since this is an advance report user
can select date range that he/her want to see and possible to select sold item quantity
wise or sold amount wise two option as they desire. Figure 17 and Figure 18
shows date and options selecting view and the report respectively.

Figure 17 - Option Menu View
Figure 18 - Item Wise Sales Report (Advance)
CHAPTER 4: IMPLEMENTATION
Process of converting the system specification into an executable system in called

Implementation process. As explained in the analysis and design chapters, the
specifications transform by design and implementation processes to an executable
program.

In development process a familiarized language and appropriate tools was used.
Readability and understandability is most important thing when comes to software
maintenance. Hench the code were written and arranged in such manner that it can be
maintainable in the future.
4.1 IMPLEMENTATION ENVIRONMENT
When finalizing the implementation environment, important aspects were taken into
consideration. To get copyrights for the system, it is wise to use free and open source
softwares when developing.
Hardware Software
i. Intel(R) i3 5th Generation i. Microsoft Windows 8.1
2.4 GHz ii. XAMPP 3.2.1
ii. 4 GB DDR III RAM o PHP 5.6.8
iii. 500 GB SATA HDD o Apache 2.4.12
o phpMyAdmin 4.3.11
o MySQL 5.6.24
iii. HTML 5 compatible web
browser
Table 7 - Implementation Environment
The JFSMS developed under MS Windows 8.1 OS. Since it is a web based system all
it need is HTML 5 compatible browser only.
Also JFSMS can run following resolutions,
 1366 x 768 px (Recommended)

 1280 x 768 px
 1024 x 768 px
DEVELOPMENT TOOLS USED,
 MySQL Workbench 6.0 CE – For database handling.

 PHP Storm – For coding.

 Adobe Photoshop CC – For image retouching.
 http://creately.com/ and MS Visio – For diagram drawings.
TECHNOLOGIES USED,
 PHP (Hypertext Pre Processor) were used as main development language to

develop main system and its logics.
 MySQL is the DBMS used for database developments.
 CSS is the main styling language used to style whole JFSMS.
 Bootstrap JS, CSS and Components was used for some styling purposes.
 JavaScripts used to validations and calculations in client side.
 AJAX is used to get data from the database without refreshing the page. (AJAX
is based on JavaScripts) [5]
 JQuery were used for some transition effects. (JQuery also based on
JavaScripts). [6]
4.2 REUSED MODULES
Followings are open source and free modules that used in when developing the
JFSMS.
GOOGLE CHARTS
This is a free API developed by Google Corporation and it used to generate reports in
JFSMS with purpose of displaying reports as visually pleasing, interactive and easily
understandable reports.

BOOTSTRAP PAGINATION
There is lot of details to show in some pages of JFSMS. Sometimes it will slow the
system because of large amount of data to be load in those pages. By using bootstrap
pagination we managed that.
BOOTSTRAP TABS
In JFSMS bootstrap tabs are used to make the system more user friendly and
understandable. Because of using bootstrap tabs user can easily navigate pages inside
module at ease.
FACEBOX
Facebox is a JQuery-based, Facebook-style light box which can display images, divs,
or entire remote pages. The reason to use facebox is, it’s simple to use and easy on the
eyes. In JFSMS we used facebox in most of Adding, Editing and Options selecting
views.
4.3 SECURITY
Since this is a web base system, the database is available on a hosted environment,
security is a major feature that want to be considered. To be ensure that data is not
compromised or misused access methods and other security measures are
implemented.
USING SESSIONS

When a user logging in to the system some user related information like User’s Role,
User Role Id, Username and User Id were stored in sessions. From those information
we can prevent unauthorized access and redirect user to where he/her authorized to
view.
ROLE BASED ACCESS CONTROL (RBAC)
When a user been logged in system automatically render his/hers privilege level using
user role and automatically redirect to the home page with only authorized modules
enabled to that user. Also if a user try to access unauthorized pages by typing those
address in address bar or something else user will be automatically redirect to home
page with an error “YOU ARE NOT AUTHORIZED TO ACCESS THAT PAGE” by
help of sessions and RBAC.
DOUBLE CHECK USER
When a user trying to do a critical calculation or a critical process in the system (e.g.:
Calculate Salaries or Assign Salary) even though he/her using the system as logged in
user he/her have to enter username and password again to confirm that he/her
authorized to do that process. We can prevent some issues like,
“If an authorized user forget to log out when he is leaving or something like that and
any other user can take advantage or misuse that account.”
4.4 MAJOR CODE SEGMENTS
USER VALIDATION
<?php
//Start a session
if (!isset($_SESSION)) {
session_start();
}

//DB Connection
require_once '../Common/dbconnection_inc.php';
$username = $_POST['username']; //To get user name

$password = sha1($_POST['password']); //To get password
//To check the username and password in the table (sql query)
$sql = "SELECT * FROM user WHERE User_name='$username' &&
password='$password'";
//To execute the query

$result = mysqli_query($conn, $sql)
or die("Query did not work" . mysqli_error($conn));
//To count the records

$count = mysqli_num_rows($result);
if ($count != 0) {
$sqluser = "SELECT * FROM user u,employee e,
user_role ur WHERE u.User_name = '$username' AND u.password
= '$password' AND u.Employee_emp_id = e.emp_id AND
u.User_Role_User_Role_id = ur.User_Role_id";
$resultuser = mysqli_query($conn, $sqluser) or die("Query
having an error" . mysqli_error($conn));
//To get a record into an array

$rowuser = mysqli_fetch_assoc($resultuser);
$_SESSION['emp_fname'] = $rowuser['emp_fname'];
$_SESSION['emp_lname'] = $rowuser['emp_lname'];
$_SESSION['emp_email'] = $rowuser['emp_email'];
$_SESSION['User_Role_id'] = $rowuser['User_Role_id'];
$_SESSION['User_Role_name'] = $rowuser['User_Role_name'];
$_SESSION['User_id'] = $rowuser['User_id'];
$_SESSION['password'] = $rowuser['password'];
$_SESSION['User_name'] = $rowuser['User_name'];
//To redirect to user privileged page

header("Location:userMenu.php");
} else {
//Invalid user name or password
$msg = base64_encode("INVALID USER NAME OR PASSWORD");
header("Location:index.php?msg=$msg");
}
?>
This code is in the validate.php file. When a user entered his/hers username and
password and submit, the form is pass that username and password to this page.
(validate.php) what this page doing is fist check whether is there a user in the database
having this username and password. Then if there is a user some of that user’s

information store in sessions and redirect user to home page that only have enabled
modules to that user role. If there is no user validate page redirect the user to login
page (index.php) with an error string “INVALID USER NAME OR PASSWORD”.
ONE HOME PAGE TO DIFFERENT USER ROLES
<?php if($User_Role_id==4){ ?>
<div class="data_operator_btns">
<a href="../modules/master_files/category_view.php"
id="remove_undln" >
<button name="Master_Files" class="hm_btn" type="button"
>
<div class="Master_Files_btn"></div>
<span class="home_btn_fonts">Master Files</span>
</button>
</a>
<a href="../modules/sales/check_in_view.php"
id="remove_undln" >
<button name="Sales" class="hm_btn " type="button" >
<div class="Sales_btn"></div>
<span class="home_btn_fonts">Sales</span>
</button>
</a>
<a href="../modules/options/payment_method_view.php"
id="remove_undln" >
<button name="Options" class="hm_btn" type="button" >
<div class="Options_btn"></div>
<span class="home_btn_fonts">Options</span>
</button>
</a>
</div>
<?php } ?>
Above code is a segment of userMenu.php file. As you can see this code segment is
shows what modules are enabled to the users of having user role id 4. In JFSMS there
are 5 user roles having 5 different working scopes. And for all of that user roles there
are code segments in userMenu.php like above with privileged modules enabled for
that specific user role.
USER LOGOUT

<?php
if(!isset($_SESSION)) { //If the session not start

session_start(); //start the session
}
session_unset(); // Free all session variables

session_destroy(); // Destroy all sessions
header("refresh:0;url=index.php");
?>
Above code segment is in logout.php file. If a user clicked logout button from
anywhere in the system it will process to this page and free all session variables and
after closing all sessions logout.php file will redirect user to index.php file.
For more codes please refer Appendix E: Code Listing section.
4.5 MODULES AND FOLDER STRUCTURE
Figure 19 illustrate modules and folder structure of the system.

Figure 19 - Folder Structure of the System
CHAPTER 5: TESTING
To evaluate the system or its components to see whether it satisfies the specific
requirements, the testing process were done. Also testing is take part of identifying any
errors or missing requirements, bugs or gaps in the system. [7]

Verification is the process that we make sure is the product behaves the way we want it
to. It says that is the product satisfy the requirements that we decided when starting
development phase. [8]
One can say software testing is a verification and validation process and it should be
done during the development process.
5.1 TEST PLAN AND TEST CASES
As a guide for all testing processes and cover all types and phases, the test plan were
used. The test plan were designed before implementation phase.
Once the test plan was design test cases were created. Test cases include,
 Data
 Procedure
 Expected Result
Following Table 8 and Table 9 shows two of test cases used to testing with test
result. To reduce complexity test cases was designed separately module by module.
5.1.1 GOODS RECEVIED NOTE
No Test Description Expected Result Screen Shot or Status
1 Clicking “Start Starting GRN not

GRN” button without allowed. Error
selecting supplier. message will appear.

2 Trying to start a Not allowed. Error
GRN without saving message will appear.
last one.
3 Clicking “Add Item” Not allowed. Error
button without filling message will appear.
Product, Qty or Cost
Price.
4 Clicking “Add Item” Not allowed. Error
button without message will appear.
starting a GRN
5 Clicking “Refresh” Not allowed. Error
button in start form message will appear.
without starting a
GRN.
6 Clicking “Refresh” Not allowed. Error
button in start form message will appear.
after adding items to
GRN.
7 Clicking “Cancel” Not allowed. Error
button without message will appear.
starting a GRN.
8 Clicking “Save Not allowed. Error

GRN” without message will appear.
adding items.
9 For all successful Success message will
processes. display.
Table 8 - Goods Received Note Test Cases
Note that same testing procedure like Goods Received Note was applied for Wastage
Notes, and Add Order functions because interfaces are above mention are relatively
same as those.
5.1.2 MAKE AN INVOICE

No Test Description Expected Result Status or Screen Shot
1 Try to start an Not allowed. Error
invoice without message appears.
check in for the
day.
2 Try to start invoice Not allowed. Error
without selecting a message appears.
customer.
3 Try to start invoice Not allowed. Error
without saving last message appears.
one.
4 Try to refresh Not allowed. Error
without starting an message appears.
invoice.
5 Press “Add Item” Not allowed. Error

button without fill message appears.
any of Product,
Quantity, Selling
Price, and Amount
fields.
6 Try to add an item Not allowed. Error
that not have message appears.
enough quantity in
hand.
7 Try to save invoice Not allowed. Error
without adding any message appears.
items.
8 Try to add a item Not allowed. Error

without starting an message appears.
invoice.
9 Try to cancel an Not allowed. Error

invoice without message appears.
starting one.
10 Try to refresh Not allowed. Error
invoice after adding message appears.
items.
11 Try to save an Not allowed. Error
invoice after message appears.
checked out for the
day.
12 After any After process
successful process. carried out
successful message
appears.
Table 9 – Make an Invoice Test Cases

Data that gathered from document sampling technique in analysis phase were used to
test functions of the system. Each data field in every form were tested using sample
data to ensure each elements are working.
The rest of test cases can be found in Appendix E – Test Results.
CHAPTER 6: EVALUATION
6.1 RESULTS WITH RESPECT TO THE OBJECTIVE
To manage Stock and Sales is the main functionality required from the system. To
provide better working hand environment, it was decided to get helping hand from the
Information Technology. The objectives of the system were achieved as we decided
and proposed.

As we described in chapter one, the aims and objectives of proposed system were
satisfactorily achieved. Many non-functional requirements fulfilled with them some
are not requested by client.
Feedbacks from the client, end users and other related persons was positive and
encouraging. Although JFSMS satisfy the client’s requirements, to consider the
project’s success it should be accepted by end users. For that a questionnaire were
created to capture end users feedback clearly. Table 10 shows a sample result of a
questionnaire.
Ratings A-Very Good B-Good C-Acceptable D-Low
EVALUATION RESULT OF SALES & STOCK HANDLER
No Questions A B C D
1 Ease of understanding. X
2 Look and feel of interfaces. X
3 Completeness of required functionalities. X
4 Consistency of navigation menus and command buttons X
5 Ability to find a way to perform transactions rollback X
any action (cancellation)
6 Speed of transactions per minute. X

7 Ability to understand error messages. X
8 Degree of information provided in reports. X
9 Benefits gained through the system. X
10 Ability to maintain data, to keep it up-to date. X
11 The advantage span between old manual system and X
new system.
Table 10 - Evaluation Result of Sales & Stock Handler
CHAPTER 7: CONCLUSION
This project covers stock handling section, point of sale section, employee details and
salary management and also orders management. System also provide interactive
reports to accountant or privileged uses. Users can easily view stock details, sales
details and other related information using this system while increasing efficiency of
the whole system.
Before the implementation of this system they not have a formal method to keeping
track of sales and stock in hand. Therefore they faced some issues. After the system
were implemented it was a huge impact in their day to day transactions. Users got
ability to see how much exact quantity they have in hand in specific product, easy view
of payables and collectables, view sales ledger at ease.

When looking into feedbacks of client’s and system users, we can say the project is
successful. Also it achieved all the functionalities that proposed and non-functionalities
as well. However system can improve further and suggestions are given below in this
chapter.
7.1 ACHIEVEMENTS
I earned huge knowledge and experience during this project process. I gained better
ideas about how to apply theories and techniques to practical scenarios. Also project
management and software engineering skills were polished vastly. The most important
achievement is experience that taken from information gathering, requirement
analysing activities and skills like communication, planning and scheduling the tasks.
Also huge level of technical knowledge were improved during this process of the
project. In areas such as
 PHP
 MySQL
 CSS
 JavaScripts, etc.
And thanks to this dissertation report writing skills were also vastly improved. As a
summary not only my knowledge also my other skills are improved equally.
7.2 FUTUER IMPROVEMENTS
Customer feedback on customer acceptance testing carried out in evaluation phase is

pretty convincing. Though JFSMS we managed to overcome most of the problems that
they having from their manual system.
However we can improve some of critical functionalities and add some new
functionalities to JFSMS. Some of those are listed below.

 At the moment I only managed to build a static web site that shows details
about the store and branches. We can develop that site to dynamic level by
providing customers to,
o Order Online.
o Collect Money from customers online.
 And the meanwhile we can develop this main system to pay suppliers online
For that kind of purposes we need to obtain a SSL certificate for all transactions
through a secure channel with HTTPS. And when comes to payments we need to
obtain secure channel for the payment gateway such as pay pal. It is a reliable way to
deal with currency.
 After implementation user asked for change a function that print every invoice
with use of a POS printer. Since that’s not client ask before and time
manageable issues I’m goner do that change in upcoming months after this
exams.
7.3 LESSONS LEARNT
When I starting the project I have no good experience or skills to develop such a
project. I have to go through tutorials, internet and that sort of things to update my
developing knowledge and skills.
Involved in a complete software development lifecycle, starting from the planning

stage to maintaining stage is a huge lesson that make me more experienced person
about how to apply certain theories and methods in variety of situations.
Although this project helped me to applying theories and methods it also improved my
developing knowledge with new technologies like AJAX, JQuery, PHP, and MySQL.

Furthermore working with people in different social levels and different educational
levels is a huge lesson. Thanks to this project process I got a chance to take that
experience.
REFERENCES
WORLD WIDE WEB
[1] Functional Requirement,

http://en.wikipedia.org/wiki/Functional_requirement
[2] Non Functional Requirements,

http://en.wikipedia.org/wiki/Non-functional_requirement
[3] IBM Rational Unified Process,

http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
[4] Database Normalization

http://support.microsoft.com/kb/283878
[5] AJAX
http://www.w3schools.com/ajax/

[6] JQuery
http://www.w3schools.com/jquery/default.asp
[7] Software Testing,

http://www.tutorialspoint.com/software_testing
[8] Software testing types,

http://www.codeproject.com/Tips/351122/What-is-software-testing-What-are-the-different-ty
[9] Quick Books

http://quickbooks.intuit.com/
[10] Insightly
https://www.insightly.com/
[11] Marg
http://www.margcompusoft.com/
APPENDIX A: SYSTEM
DOCUMENTATION
To assist the software engineers, managers and administrators to install servers, refer if
there are any changes to be made in the system and to install the system, the system
documentation were created.
The server that this system might installing should meet following hardware
requirements.
HARDWARE REQUIREMENTS
Hardware Recommended Minimum Requirements

Processor Intel(R) Core 2 Dou 1.8 GHz or higher.
Memory 2 GB RAM or higher.
Hard Disk Minimum 1 GB free space or higher.
Display 1366x768 Resolution is highly recommended.
Internet Minimum 512kbps ADSL connection
Table 11 - Hardware Requirements
SOFTWARE REQUIREMENTS
Software Recommended Minimum Requirements

Operating System MS Windows XP / Vista / 7 / 8 / 8.1
Linux Ubuntu 9.0 or above.
Bundle Packages Apache tomcat 7.0.56
PHP Complier 5.6
MySQL 5.6
MYSQL Work Bench 6.0CE
Code Editor PHP Storm 8.0.2
Web Browser HTML 5 Compatible – Google Chrome v43 or higher
Recommended / Firefox v35 or higher
Table 12 - Software Requirements
HOW TO SETUP
DATABASE SETUP
1. Download MySQL installer from:

http://dev.mysql.com/downloads/windows/installer/ or get it from the CD that
provided (Letter of the DVD Drive: /Dependencies/mysql-installer-web-
community-5.6.25.0.msi).
2. Install the setup ‘mysql-installer-web-community-5.x.msi’.
3. Download MySQL Workbech installer from:
http://dev.mysql.com/downloads/workbench/ or get it from the CD that
provided (Letter of the DVD Drive: /Dependencies/ mysql-workbench-
community-6.3.4-winx64.exe)
4. Install the setup ‘mysql-workbench-community-6.x-winx64.exe’.
5. Open MySQL Workbench.
6. Login by giving the username and password.
7. Create a blank database named JFSMS.

8. Click the Import tab and browse through the provided CD’s database folder and
it should be (Letter of the DVD Drive: /Database/jfsms.sql) and select jfsms.sql
file.
9. Click the “Execute” button to import the database to newly created system
database.
INSTALLING SERVER (APACHE TOMCAT)
1. Download a binary distribution of Tomcat from: http://tomcat.apache.org/ or

get it from the CD that provided (Letter of the DVD Drive: \Dependencies\
apache-tomcat-7.0.62-windows-x64.zip).
2. Unpack the binary distribution so that it resides in its own directory to partition
D:\ in case of failure. (Conventionally named "apache-tomcat-[version]").
3. Go to unpacked folder and inside of that go to bin folder and double click on
startup.bat (apache-tomcat-[version]\bin\startup.bat) then tomcat domain will
start.
 For more instructions please refer RUNNING.txt file on apache extracted
folder. (apache-tomcat-[version]\RUNNING.txt)
JFSMS SETUP
1. Copy the “JFSMS” folder from supplementary CD that given and paste it
webapps folder in extracted apache folder (apache-tomcat-[version]\webapps).
2. Go to “System\Common” folder inside “JFSMS” folder
(JFSMS\System\Common) that copied and open dbconnection_inc.php file and
configure the database connection with giving the username and password.
SYSTEM USAGE
From a preferred web browser you can open the system by typing following URL in
the address bar:
http://localhost/JFSMS/System/Login
http://127.0.0.1/ JFSMS/System/Login

From the login page you can gain access by providing correct username and password.
APPENDIX B: DESIGN
DOCUMENTATION
B: 1 USE CASES
B: 1.1 SALES MODULE

Figure 20 - Use Case of Sales Module
B: 1.1.2 DESCRIPTION FOR SALE ITEMS USE CASE
Use Case Sale Items Use Case

Actors Sales Handler
Overview
Sale goods to customers.
Preconditions
Items must be added to the stock before sale them.

Flow of Events
i. Start an invoice with appropriate payment method.
ii. Add items that customer buying.
iii. Collect money if it is a cash payment.
iv. Save invoice.
Post Condition
In stock relevant item quantities must be decreased and sales ledger must be updated
according to payment method.
Table 13 - Sale Items Use Case
B: 1.1.3 DESCRIPTION FOR COLLECT RETURNED GOODS
Use Case Collect Returned Goods Use Case

Overview
Collect an item that customer returned due to damages or any other issue.
Preconditions
None
Flow of Events
i. Add item and its quantity to Customer PRN.
ii. Select customer from that list.
iii. Collect returned good.
iv. Save Customer PRN.
Post Condition
In stock relevant item quantities must be increased and sales ledger must be updated
Table 14 - Collect Returned Goods Use Case
B: 1.1.4 DESCRIPTION FOR CANCEL INVOICES
Use Case Cancel Invoices Use Case

Overview
If a customer returned all items in an invoice sales handler can cancel the invoice
Preconditions

Customer must return all the items in the invoice
Flow of Events
i. Check whether all items are in there comparing with invoice.
ii. Collect all items.
iii. Cancel invoice using Invoice Cancelation menu.
Post Condition
In stock relevant item quantities must be increased and sales ledger must be updated
Table 15 - Cancel Invoice Use Case
B: 1.1.5 DESCRIPTION FOR CHECK IN/OUT
Use Case Collect Returned Goods Use Case

Actors Sales Handler Or Store Manager
Overview
Before any transaction user must check in for the day and when closing the system finishing
sales user must check out for the day.
Preconditions
None
Flow of Events
i. Enter how much money in the cash box when starting the day and check in.
ii. Enter how much money in the cash box when closing the store and check out.
Post Condition
Cash in the hand must be update.
Table 16 - Check In/Out Use Case
B: 1.1.6 DESCRIPTION FOR COLLECT PAYMENTS
Use Case Collect Payments Use Case

Actors Accountant
Overview
Collect customer outstanding payments.
Preconditions
There should be due payments to collect from customers

Flow of Events
i. Select customer from customer payments.
ii. With amount he paying accountant can select either payment to specific invoice or
settle all customer payments.
iii. Settle payments.
iv. Print invoice.
Post Condition
Cash in the hand must be update.
Table 17 - Collect Payments Use Case
B: 1.2 EMPLOYEE MODULE

Figure 21 - Employee Module Use Case Diagram
B: 1.2.1 DESCRIPTION FOR ASSIGN SALARIES
Use Case Assign Salaries Use Case

Actors Accountant
Overview
Assign salaries to new employees
Preconditions
Employee must be working for the store more than 6 month
Flow of Events
i. Select employee.
ii. Enter basic salary amount.(When entering basic salary ETF, EPF are automatically
assigned according to basic salary)
iii. Assign salary.
Post Condition

Salary table must be updated.
Table 18 - Assign Salaries Use Case
B: 1.3 ORDER MODULE
Figure 22 - Orders Module Use Case Diagram
B: 1.3.1 DESCRIPTION FOR ADD ORDERS
Use Case Add Orders Use Case

Actors Sale & Stock Handler
Overview
Add orders to customer requests.
Preconditions
None
Flow of Events
i. Start an order.
ii. Add items that customer requesting.
iii. Save Order.
iv. Print invoice.
Post Condition

Orders table must be updated.
Table 19 - Add Orders Use Case
B: 1.4 USERS MODULE
Figure 23 - Users Module Use Case Diagram
B: 1.4.1 DESCRIPTION FOR MANAGE USERS
Use Case Manage Users Use Case

Actors Administrator

Overview
Add, Edit and Delete users.
Preconditions
Must be an employee that added to the system.
Flow of Events
i. Fill details.
ii. Save
Post Condition
User table must be updated according to the changes.
Table 20 - Manage Users Use Case
B: 1.4.2 DESCRIPTION FOR MANAGE USER ROLES
Use Case Manage User Roles Use Case

Actors Administrator
Overview
Add, Edit and Delete user roles.
Preconditions
None
Flow of Events
i. Fill new details.
ii. Save
Post Condition
User Roles table must be updated according to the changes.
Table 21 - Manage User Roles Use Case
B: 2 ACTIVITY DIAGRAMS

Figure 24 - Activity Diagram of a Cash Sale
APPENDIX C: USER
DOCUMENTATION

This is a reference document for the users of JFSMS. Every user can log in to the
system that have a user account and according to their privileges they will redirect to
enabled modules. Since the Administrator have the rights to work on every module
documentation were created as an Administrator privileged user.
Note that only a few of main modules with selected interfaces of the system were
covered from this documentation.
LOGIN
By typing the URL in browsers address bar user can view the Login page Figure 25.
Then user can log in to the JFSMS by providing valid username and password. After
authorized access system will redirect user to Home page Figure 26.
Figure 25 - Login Page
HOME

Figure 26 - Home Page
An authorized user can browsed through the modules and user can log out from the
button on the top right corner.
ADD, EDIT OR DELETE A USER
Go to Users module.
Browse - Home Page > Users
After that user will direct to Users module Figure 27. An authorized user can add a
user by clicking and getting Add User interface Figure 28, edit a user (With
password changing) by clicking Edit button in front of every specific user and getting
Edit User interface Figure 29 or Delete a user by clicking Delete button in front of
every specific user from that interface.

Figure 27 - User Module Interface
Figure 28 - Add User Interface

Figure 29 - Edit User Interface
DATA MANUPULATION IN MODULES
Inside every module I followed a common interface structure. In the figure shows that
common structure of module. Please refer Legends to what in those numbers.
Figure 30 - Module Common Structure

LEGENDS
(1) Navigation Buttons – A user can use those to Go Back, Go to Home Page,
Reload or Go Forward.
(2) Sub Modules – This are the modules that inside a main module.
(3) Log Out Button – User can log out from this system using that button.
(4) Search Bar – It is a live search that users can search things based on the sub
module.
(5) Add Button – Authorized user can add things unique to that sub module.
(6) Edit Button – User can edit specific thing that previously added.
(7) Delete Button – User can delete specific thing that previously added.
GOODS RECEIVED NOTE
Go to Stock module and click on Goods Received Note sub module.
Browse - Home Page > Stock > Goods Received Note
After the user click Goods Received Note sub module interface in Figure 31 appears.
Figure 31 - Add GRN Interface
To add a GRN user must follow this steps,
1. Select the supplier with the live search provided.

2. Select the payment method from the drop down menu.
3. Click “Start GRN” button.
4. Select product one at a time by provided live search.
5. Type quantity of receiving product that selected before.
6. Type cost price per a unit that we are buying.
7. Note that “Amount” field will automatically fill according to quantity and cost
price.
8. Then click “Add Items” button.
9. Go through last 4 processes (4, 5, 6, and 7) till all the product that receive are
entered.
10. Finally click on “Save GRN” button to save the Goods Received Note.
SUPPLIER PAYMENTS
Go to Suppliers module.
Browse - Home Page > Suppliers
When a user click on Suppliers module interface in Figure 32 appears. From this
interface an authorized user can settle payments to suppliers for a specific GRN or user
can use “Settle All” button to settle all payables to a specific supplier.
Figure 32 - Supplier Payments Interface
APPENDIX D: MANAGEMENT
REPORTS

The System “JFSMS” is generate reports Yearly, Monthly and Daily to help
management to easily understand and get summary of situations that going on the
stores.
In JFSMS there are 18 reports that covering Stock, Sales, Customers and Suppliers
modules.
Note that in here I’m going to demonstrate few of those 18 reports.
SALES LADGER (ADVANCE)
Since this is an advance report user having the privilege of select the date range as in
Figure 33 that report want to be generated. And after user select the date range and
press “View Report” button Advance Sales Ledger report appears as in Figure 34.
Figure 33 - Date Selection In Advance Report

Figure 34 - Advance Sales Ledger Report
GRN LISTING
This is also an advance report. Because of that user have that privilege to select the
date range. Figure 35 illustrate that. After date selection and press “View Report”
button user will get the report as in Figure 36.
Figure 35 - GRN Listing Date Selection Menu

Figure 36 - GRN Listing Report
ITEM WISE SALES (QUICK)
This report may give management about what items are sold today and how much
earned by them.
Figure 37 - Item Wise Sale (Quick) Report

APPENDIX E: TEST RESULTS
COMMON FUNCTIONS TEST
No Test Description Expected Result Status or Screen Shot

1 Enter an invalid Login failed. Error
username or a password message appears.
when login to the
system.
2 When successfully Redirect user to home

logged in. page after validation.
Successful message
appears.
3 Try to access restricted Not allowed. Error
interface. message appears.
4 Change passwords of Not allowed if user

users. entered a wrong old √
password.
5 Logout. Logout user and redirect
user to the login page. √
Table 22 - Common Functions Test Cases
ADD A CUSTOMER TEST CASE
1 Clicking “Add Not allowed. Error

Customer” button message will appear.
without filling
Customer Name.
without filling

Customer Address.
without filling
Customer Tel.
4 When entering Not allowed. Error
“Customer Tel” if message will appear.
user tried to enter a
character.
without filling
Customer NIC.
“Customer NIC” if message will appear.
not allowed
character.
“Customer Email” message will appear.
if user tried to enter
an invalid email.
without filling
Credit Period.
“Credit Period” ” if message will appear.
character.
without filling
Credit Limit.
“Credit Limit” ” if message will appear.
character.

12 If a user tried to add Not allowed. Error
a customer already message will appear.
exist.
13 If a user entered and Success message
added a customer will display.
successfully.
Table 23 - Add a Customer Test Case
Note that same testing procedure like Add a Customer was applied to Add Category,
Edit Category, Add Sub Category, Edit Sub Category, Add Product, Edit Product, Add
Supplier, Edit Supplier and Edit Customer because interfaces are above mention
relatively same as those.
SUPPLIER PAYMENTS
1 Select supplier. Not paid GRN bills are √

listed.
2 Payment method If user select cash as √
selection. method cash in hand
must be deducted. If
user select cheque it
may update cheque
table in database.
3 Settle one bill or If user click settle √
settle all. button it may update
according to that
specific GRN amount.
If user click settle all it
may deduct all payables
for that specific
supplier.

4 Press “Settle Not allowed. Error
All” button in message will appears.
settle all menu
without selecting
Supplier.
5 After successful Database may updated
payment. and successful message
appear.
Table 24 - Supplier Payment Test Case
Note that same testing like supplier payments was applied for customer payments
because all interfaces are above mention relatively same as those.
CUSTOMER PURCHES RETURN NOTE
1 Try to save PRN Not allowed. Error

without selecting message appear.
customer.
without selecting message appear.
product.
without adding message appear.
return quantity.
cost price.
return amount.

6 After successful Database may updated
process. and successful message
appear.
Table 25 - Customer PRN Test Case
Note that same testing like Customer PRN was applied for Supplier PRN because all
interfaces are above mention relatively same as those.
CASH IN
No Test Expected Result Screen Shot or Status

Description
1 Try to in cash Not allowed. Error
amount.
2 Try to in cash Not allowed. Error
reason.
3 Try to add cash Not allowed. Error
with wrong message appear.
username or
password
without check message appear.
in for the day.
after checked message appear.
out for the day.
6 After Database may
successful updated and
process. successful message
appear.
Table 26 - Cash in Test Case

Note that same testing like Cash In was applied for Cash Out because all interfaces are
above mention relatively same as those.
CANCEL INVOICE
1 Pressing “Cancel Not allowed. Error

Invoice” button message appear.
without adding
invoice number.
without adding
reason.
with wrong
invoice number.
with wrong
username or
password
without check in
for the day.
after checked out
for the day.
7 After successful Database may
process. updated and

successful
message appear.
Table 27 - Cancel Invoice Test Case
Few of test results were shown because of adherence to page limit.
APPENDIX F: CODE LISTINGS

This section shows some of major code segments apart from the codes that included in
implementation chapter. Because of very lengthy codes only selected and important
code segments are listed below.
CANCEL INVOICE FUNCTION
Figure 38 shows the code segment in canceling an invoice. The overview of this
code is when a user entered a valid invoice number and entered correct username
password if the invoice is made today delete that items and update stock and or if
invoice is made before update stock and update the cash in hand by min the amount of
this invoice with cash in hand. In the code,
 1st If condition check whether user check in for the day before canceling an
invoice.
 After that elseif condition look for whether user is checked out for the day and
if not user will proceed to the body. If user checked out system will redirect
user to the cancel invoice page with an error.

 Next code will check that given username and password are valid. If not system
will redirect user to the cancel invoice page with an error.
 Then system will check whether given invoice number is a valid one. If not
user will be redirected to cancel invoice interface with an error.
 After that invoice table will updated.
 Then the system will collect all items in that invoice and update stock.
 Then system will check whether this invoice is made today or before and if it is
today delete the entry in payment details table or if it is not today add an entry
to payment details with a minus amount of invoice total.
 Then system will redirect to cancel invoice interface with successful message.

Figure 38 - Cancel Invoice Code Listing

CHECK IN
Figure 39 shows the code segment of check in process. Check in process want to be
done as a rooting in every day before other stuff. Without check in for the day user will
not allowed to make invoices, make PRNs, do Cash in or out and most of things in
JFSMS.
Figure 39 - Check in Code Listing

SAVE INVOICE
Figure 40 shows the code behind the save invoice function.
 This code first check whether items are added to the invoice.
 Then calculate the total amount.
 Then update the invoice table.
 Then check the payment method and if a credit it will update customer table
and if it is a cheque it will update cheque_details table.
 Then system will redirect user to invoice interface with successful message.

Figure 40 - Save Invoice Code Listing

APPENDIX G: CLIENT
CERTIFICATE

GLOSSARY
 Black-box testing is a method of software testing that examines the

functionality of an application without peering into its internal structures or
workings. This method of test can be applied to virtually every level of
software testing: unit, integration, system and acceptance.
 Encryption Algorithm is a mathematical procedure for performing encryption
on data. Through the use of an algorithm, information is made into meaningless
cipher text and requires the use of a key to transform the data back into its
original form. Blowfish, AES RC4, RC5, and RC6 are examples of encryption
algorithms.
 A database is a collection of information that is organized so that it can easily
be accessed, managed, and updated. In one view, databases can be classified
according to types of content: bibliographic, full-text, numeric, and images.
 Graphical User Interfaces Abbreviated GUI (pronounced GOO-ee). A
program interface that takes advantage of the computer's graphics capabilities
to make the program easier to use. Well-designed graphical user interfaces can
free the user from learning complex command languages.
 Cascading Style Sheets (CSS) is a style sheet language used for describing the
look and formatting of a document written in a markup language.
 Iterative and Incremental development is any combination of
both iterative design or iterative method and incremental build model for
software development. The combination is of long standing and has been
widely suggested for large development efforts.
 Internet is a global system of interconnected computer networks that use the
standard Internet Protocol Suite (TCP/IP) to serve billions of users worldwide.

Fruit Store Management System For Jayani Fresh Fruits - RUP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fruit Store Management System For Jayani Fresh Fruits - RUP

Uploaded by

Copyright:

Available Formats

Fruit Store Management System (FSMS)

Student Name: H H L Madusanka

Supervisor: Mr.Duminda Herath

This dissertation is submitted in partial fulfillment of the requirement of the

…………………………………. Date: ....../….../......

…………………………………. Date: ....../….../......

R110738 – Jayani Fruit Store Management System 2|Page

R110738 – Jayani Fruit Store Management System 3|Page

I owe my deep gratitude to the University Of Colombo School Of Computing for

A very special recognition needs to be given to my project supervisor Mr.Daminda

R110738 – Jayani Fruit Store Management System 4|Page

R110738 – Jayani Fruit Store Management System 5|Page

R110738 – Jayani Fruit Store Management System 6|Page

APPENDIX A: SYSTEM DOCUMENTATION.......................................................52

APPENDIX B: DESIGN DOCUMENTATION........................................................55

APPENDIX C: USER DOCUMENTATION............................................................64

APPENDIX D: MANAGEMENT REPORTS..........................................................70

APPENDIX E: TEST RESULTS................................................................................73

APPENDIX F: CODE LISTINGS.............................................................................80

APPENDIX G: CLIENT CERTIFICATE................................................................85

R110738 – Jayani Fruit Store Management System 7|Page

R110738 – Jayani Fruit Store Management System 8|Page

R110738 – Jayani Fruit Store Management System 9|Page

JFSMS : Jayani Fruits Store Management System

SOFTWARES RELATED & TECHNOLOGIES

SQL : Structured Query Language

R110738 – Jayani Fruit Store Management System 10 | P a g e

DIAGRAMS RELATED & METHODOLOGIES

UML : Unified Modeling Language

R110738 – Jayani Fruit Store Management System 11 | P a g e

1.1 JAYANI FRESH FRUITS

1.2 PROBLEM DOMAIN AND NEED OF THE PROJECT

R110738 – Jayani Fruit Store Management System 1|Page

1.3 MOTIVATION FOR THE PROJECT

1.4 GENERAL OBJECTIVES OF THE PROJECT

1.5 SPECIFIC OBJECTIVE

 To use the system to manage transactions in sales.

R110738 – Jayani Fruit Store Management System 2|Page

 Authentication and Authorization for different User roles

1.7 STRUCTURE OF THE DISSERTATION

Second chapter (Analysis) will be based on the requirements analysis. It summarizes

R110738 – Jayani Fruit Store Management System 3|Page

 Referred materials are properly listed in the References section.

R110738 – Jayani Fruit Store Management System 4|Page

2.1 FACT GATHERING TECHNIQUES

2.2 ANALYZING THE CURRENT MANUAL SYSTEM

In the old system employees have different task to do and know.

Store keeper want to know,

R110738 – Jayani Fruit Store Management System 5|Page

Accountant want to know,

o Is there are due payments from customers?

Sales person want to know,

o Is the product available that customer requesting?

2.2.1 USE CASE DIAGRAM OF CURRENT MANUAL SYSTEM

Diagram in Figure 1 depicts the overall Use-Case of the existing system.

R110738 – Jayani Fruit Store Management System 6|Page

2.3 EXISTING SIMILAR SYSTEMS

R110738 – Jayani Fruit Store Management System 7|Page

A user interface of QuickBooks is depicted in Figure 2.

Figure 2 - An Interface of a QuickBooks Software

2.4 FUNCTIONAL REQUIREMENTS

Functional Requirements is what the system want to archive. It can be a calculation, it

R110738 – Jayani Fruit Store Management System 8|Page