DEPARTMENTAL STORE MANAGEMENT SYSTEM

1. SYNOPSIS

1.1 Title of the Project:

Departmental Store Management System

A department store is a retail establishment which specializes in selling

a wide range of products without a single predominant merchandise line. Department
stores usually sell products including apparel, furniture, appliances, electronics, and
additionally select other lines of products such as paint, hardware, toiletries, cosmetics,
photographic equipment, jewellery, toys, and sporting goods. Certain department stores
are further classified as discount department stores. Discount department stores
commonly have central customer checkout areas, generally in the front area of the store.
Department stores are usually part of a retail chain of many stores situated around a
country or several Countries. In other words, a departmental store is a large retail store
suffering a variety of merchandise and services and organized in separate departments.

The Departmental Store Management System is based on the

departmental store, which keeps the track of Inventory, Sales, Purchase & personnel. The
system is Management Oriented.
This system gives the management an efficient way to handle their main
operational areas such as customer care, inventory control, point of sales & analysis,
Profits.

1.2 Problem:

In the departmental stores most of the work is done manually by

maintaining registers.
This involves many limitations such as:
 Increases the paper work
 The time to access the data increases
 Chances of Information Leakage or Loss of Information increases
 Maintaining records is not Integrated
 Duplication of data

They also use DOS based systems with monotonous Look & duplication of data
having many gaps & inefficiency in forecasting due to batch process or lack of
information due to either manual systems or old software. So, there is a Lack of
Tools for manipulation of data.

1
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

1.3 Purpose of the Project:

Departmental store is a place where we get all our daily use products.
These products are the basic requirements such as clothes, utensils, grocery, toys, watches
etc. From the administrator point of view, the management of these products is not an
easy job. Since they need to keep track of the products, their various suppliers, the
customer details, their employees etc. All these jobs are done mostly manually or using
some old software.

1.4 Scope & Objective of Project:

The project aims to develop software which will store data about their
different products, their manufactures, product’s Inventory status, customer records and
even the record of their employees. This system provides accounting, inventory,
invoicing information in integrated fashion, preferably with Graphics User Interface
(GUI).

The objective of the project is to create a system that:

 Provides Security to the data
 According to the user, provides the relevant data
 Handles the inventory, accounting & employee information
 Auto Checking the stocks, Performance of the Employee
 Less prone to errors
 Efficient data storage that will reduce the redundancy of data
 Less chances of information Leakage

1.5 System Architecture:

Fig 1.1

2
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

1.6 Hardware and Software to be used:

Front End: Visual Basics 6.0

Back End: MS Access

Hardware Requirement:
Minimum 10GB HDD
Processor Type P-II & onwards
Software:
Operating Systems Windows98 & onwards

1.7 Modules:

Inventory
Sales & purchase
Employee details

1.8 Conclusion:

Here we have tried to develop a software that will help the administrator
to have a quick access to all the information flow in the departmental store.

3
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

2. INTRODUCTION

2.1 Organization Profile

Apna Bazar is a reputed departmental store which specializes in selling a
wide range of products without a single predominant merchandise line. It sells a variety
of different products like appliances cosmetics, photographic equipment, jewellery, toys,
and sporting goods clothes, fashion accessories, cd’s, dvd’s, books, eatables, etc. Such a
market carries large number of transactions on a daily basis like sale of various products,
buying these products from suppliers, recognizing goods that are need to be ordered,
making payments to the supplier etc.

2.2 Introduction to the Project:

The main aim of developing departmental store management system is to

build a user friendly, efficient and robust system that will handle all transactions related
to the store. The DSMS i.e. Departmental Store Management System will record
details of all products and information relating sales and current stock of those products.
All the information will be stored in consistent and structured format which will allow
easier retrieval of data. . The system is Management Oriented. This system gives the
management an efficient way to handle their main operational areas such as customer
care, inventory control, point of sales & analysis, Profits.

4
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

3. SYSTEM STUDY & ANALYSIS

3.1 Problem Definition:

Development of user friendly departmental store database management

system that provides solution for storing product information, their sales, total stocks,
orders and delivery information, customer accounts information, payments etc.
Developing a software the will be useful to the store administrators.
Understanding the system properly so that all it’s problems are identified
correctly. Also, identifying all the alternatives that exists to achieve our objectives with
respect to modifying the system, even all the various way to implement the alternatives.

3.2 Feasibility Study

A feasibility study is the study of positive possibilities of the project. It is

also measure of how beneficial or practical development of information system would be
to an organization.
The different types of feasibility are as follows: -

 Economic feasibility
 Operational feasibility
 Technical feasibility
 Scheduled & Resource feasibility

3.2.1 Economic Feasibility

Higher level of automation most often requires more funds. Hence based
on the hardware and software specification a desirable alternative costs and benefits to
see if the investment made in creating / developing a new system is costlier or more
beneficial
Financial benefits must equal or exceed the costs. To assure this one mist
estimate following:
 If the Organization has adequate cash flow for funding the development
 The cost to conduct a full system investigation
 The cost of hardware and software for the class of application being considered.
 The benefits in the form of reduced costs or fewer costly errors.
 The cost if nothing changes (i.e. the proposed system is not developed) for a
project to be judged feasible, it must pass all these tests.
If any one of these issues appears infeasible the decision must be reconsidered.

5
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

3.2.2 Operational Feasibility

A system with an easy interface will always help the user to use the
system. The new system has completely user friendly interface. It has been designed to be
pretty intuitive, so that even an inexperienced person can easily handle the system.
Business functions are reengineered to achieve broader scope and higher level of
automation. Manual processes too are modified. Every company has its own culture and
new system should fit the company culture.
The issues to be taken into concern are:
 Corporate Culture.
 Level of computer competency.
 Loss of control on employee by staff/management.
 Change of job responsibility.
 Loss of employment due to increased automation.
 The nature & level of user involvement in the development & implementation of
system.
 Revisal of old, longstanding work procedures.
 It is usually a practice to include people trained in organizational behavior to
assist in managing these changes.

3.2.3 Technical feasibility

The necessary software required for the development of admission &
student profile systems were:
 Visual Basic 6.0
 Microsoft Access
The above as well as required hardware already available in the firm; also there is
required expertise for handling system. Thus in the presence of required hardware,
software the proposed system is technically feasible.

6
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

3.2.4 Scheduled & Resource feasibility

The Schedule of the project is actually the periodic progress of the project. This is
carefully monitored. Whenever the upper management indicates that their has to be a
change in the system then the schedule has to be adjusted again and the schedule is
revised.
It is the schedule makes to reach the prescribed deadline, which is
invariably revised to suit use requirements. In the resource feasibility, the primary
resource is the team member and their designation i.e. analysts, technician and user have
to be managed. Their skills have to be continuous & updated & revised.
A new system variably has less capability than the organization ultimately desires.

Schedule feasibility :
It is measure of how reasonable the project schedule is
Are the deadlines reasonable?
Can the deadline be extended?
Is the deadline desirable or compulsory if yes how much?

Resource Feasibility:

It is measure of availability of system resources

Availability of people
Do they have necessary skill?
Availability of computing facilities
Availability of support staff
Availability of physical worksite

For our system we discussed the schedule of the project it took 2 days for
arranging the schedule also we have made research on the user requirements and what is
the flow actually user wants.

7
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

3.3 SYSTEM ANALYSIS

The phase is detailed appraisal of existing system. This appraisal includes how the
system works & what it does. It also include finding out in more detail what are the
problems with system & what user requires from a new system or any new changes in
system. The output of this page results in model of system. The model describes the
system function & data & system information flow. The phase also contains the detail set
of user requirement & this requirement are used to set objectives for a new system.

3.3.1 SYSTEM STUDY:

It is always necessary to study & recognize the problem of existing, which

will help in finding out the requirements for the new system. System study helps in
finding different alternative for better solution. The project study basically deals with
different operation & steps:

 Data Gathering
 Study of Existing System
 Analyzing problem
 Studying various documents
 Feasibility study for further improvement

Following are steps taken during the initial study:

 Initially, we collected all the information which they wanted to store .

 Then we studied the config of database we noted the difficulty of that system
which motivated them to have new system.
 Then we analyzed the format of the report generated by that system.

8
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

3.4 Current System:

A department store is a retail establishment which specializes in selling a

wide range of products without a single predominant merchandise line. A departmental
store is a store which sells a variety of different products like apparel, furniture,
appliances, electronics, and additionally select other lines of products such as paint,
hardware, toiletries, cosmetics, photographic equipment, jewellery, toys, and sporting
goods clothes, fashion accessories, cd’s, dvd’s, books, eatables, etc. Such a market
carries large number of transactions on a daily basis like sale of various products, buying
these products from suppliers, recognizing goods that are need to be ordered, making
payments to the supplier etc.
Till recently, all such information was stored in the form of paper. Hence it
becomes difficult to manage such vast amounts of information by the current manual
system. Also the information stored on paper is not reliable and retrieval of any data
becomes inconvenient and time consuming. This leads to wastage of a lot of time, effort
and space.

3.4.1 Limitations Of Current System:

In the departmental stores most of the work is done manually by

maintaining registers.
This involves many limitations such as:

 Unorganized data
 Error prone data
 Tedious calculation for user
 Time delay in calculating & generating reports
 Complications in analyzing stored data
 Poor report generation
 Increases the paper work
 Chances of Information Leakage or Loss of Information increases
 Maintaining records is not Integrated
 Duplication of data

They also use DOS based systems with monotonous Look & duplication of data
having many gaps & inefficiency in forecasting due to batch process or lack of
information due to either manual systems or old software. So, there is a Lack of Tools for
manipulation of data.

9
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

3.5 Proposed system:

The proposed system may include following features:

 Creating a database for the stores containing the information present with them on
the paper in the existing system.
 Access to database will be based on logon-id and password. Different person will
have different login-id and a distinct set of access rights.
 The developed system will also print bills and reports and maintain various
transactions of the super-market.
 It will have a comfortable and user friendly GUI.
 The user interface will be designed using VB 6.0 and database will be
implemented in MS-ACCESS.
 Also the system is intended to take very few inputs from the user.

3.5.1 Advantages of Proposed System:

 User friendly, accurate and robust system.

 Store various product information, it’s supplier information & their sales.
 Handle order placing and delivery.
 Store information about delivery of orders & their payments.
 Manage stock of all products.
 Production of bills.
 Security of data.
 Integration of all functions in to one system.
 Remove redundancy of data.
 Remove inconsistency of data.

10
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

4. SYSTEM DEVELOPMENT

We have used the waterfall model for developing the system.

4.1 WATERFALL MODEL

The WATERFALL MODEL demands a systematic, sequential approach to

software development that begins at the system level and progresses through analysis,
design, coding, testing, and maintenance. The Waterfall model flows from top to bottom.
It includes the following steps:

 Requirement Gathering
 Analysis
 Design
 Coding
 Testing
 Maintenance

Fig 4.1

11
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Requirement Gathering: The works begins with the information gathering. Developer
and customer meet and define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further definition is mandatory.
In our software development process, we gathered information from the various
developers and users to know about the existing system. This will help us to develop a
proposed system.

Analysis: After gathering all the requirements from the user, we need to distribute the
various requirements that we have already collected. We discard the unnecessary
requirements & only consider the relevant requirements. Also some requirements that
have not been considered but are very much needed also need to be discovered to avoid
changes in the project in the later stages.

Design: This step focuses on four distinct attributes of the program:

 Data Structure
 Software Architecture
 Procedural Detail
 Interface Characterization
The design process translates requirements into a representation of the
software that can be assessed for quality before coding begins. The design process is
documented and become a part of the software configuration. That means, in a design
process we designed the form layouts of the system, which in turn used for the coding
purposes.

Coding: In the coding process the design must be translated into a machine-readable
form. If design is performed in a detailed manner, coding can be accomplished
mechanistically. For coding purposes we used Visual Basic 6.0 language.

Testing: The testing process focuses on the logical internals of the software, ensuring
that all statements have been tested, and on the functional externals, that is, conducting
testes to uncover errors and ensure that defined input will produce actual results that
agree with required results.

Maintenance: After all of these processes, the maintenance of the system takes into
consideration. It is required because of the errors that have been encountered in the
system or because the customer requires functional or performance enhancements.

12
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

4.2 E-R Diagram

An ER-Diagram (Entity Relationship Diagram) is a graphical model of the data needed

by a system. This included the entities about which information is stored and the
relationship among them. It is produced in structured analysis methods.

On the Entity-Relationship Diagram:

 Rectangles represent data entities
 Lines connecting the rectangles show the relationships among data entities.
 Ellipse represents the attributes of the entity.

The traditional approach to system development places a great deal of

emphasis on data storage requirements for the new system. Data storage requirements
include the data entities, their attributes, and the relationships among the data entities.
The model used to define the data storage requirements is called the Entity-Relationship
Diagram.

For the Departmental Store:

DATA REQUIRQMENTS:

The data requirements process may be based on interviews with the database
users, and on the designer’s own analysis of the organization. The major characteristics of
the departmental stores are:
 The departmental store is organized into branches. Each branch is located in a
particular area and is identified by a unique name. The store monitors the assets
of each branch.
 Customers of the departmental store are identified by their customer-id values. It
stores each customer’s name and address where the customer lives. Customer
may have accounts with the store for their purchasing purposes.
 Employees of the departmental store are identified by their employee-id values.
The management stores the name, addresses, position, salary of each employee.
It also keeps track of the employee’s start date and, thus, length of employee.
 The departmental store also keeps the information of the suppliers. Each supplier
is identified by its supplier-id. It also stores the name, address and product-id
that the supplier can supply.
 The departmental store also keeps the information of all of the inventories. Each
product is identified by its product-id.

13
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

ENTITY_SET DESIGNATION:
From the characteristics of the data requirements we begin to identify
entity set and their attributes:

 The BRANCH entity set, with attributes branch no, location, manager, target and
sales.
 The STOCK entity set, with attributes supplier-id, product-id, category, quantity
and pay rate.
 The CUSTOMER entity set, with attributes Cust_Id, Cname, Address,
Phone_no, Total_Amt and Balance.
 The EMPLOYEE entity set, with attributes Emp_Id, Ename, Branch_Id, Gender,
Address, Phone_no, Date of Birth, Position, Hire_Date, Salary, Order_Id,
Purchase.
 The SUPPLIER entity set, with attributes supplier-id, supplier-name, product-id,
Address and Phone_no.
 The DAMAGES entity set, with attributes Emp_Id, supplier-id, product-id,
quantity, price and replaced. It is a weak entity set.

RELATIONSHIP SETS DESIGNATION:

The relationship sets designation defines the relationship among the

entity sets and mapping cardinalities:

 GIVES ORDER, a many-to-one relationship set between customer and

employee.
 WORK FOR, a one-to-one relationship set between employee and branch.
 CHECK FOR, a one-to-many relationship set between employee and stock.
 ORDER SUPPLIER, a many-to-one relationship set between supplier and
employee.
 CHECK TRANSACTION, a one-to-one relationship set between damages
and employee.

14
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

E-R Diagram

15
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

B rn o Loc M an
P a id E nam e
Cnam e P ty p
o r id A ddr P hno
w o rk s
O id E id
Sal fo r
B ranc h
c id Tam t B id
A ddr
D O B
G iv e s
Bal C u s to m e r
O rde r
E m p lo y e e S a le s
T a rg e t
P os
P hno

A vai
D am g or
R ep not

o rde r
supl g iv e s
o rd e r

P id
chk updt
fo r
del
C hk S u p p lie r A dd
tra n updt

S id S id Snam e
Snam e
P hno P id C a te

Q ty
Addr
Snacks
S id P a yrt
Q ty W t
C id C a te E xp ry
Q ty
Snam e P ay rt C a te
Tam t
D am ages V e g_ F rut G ro ssary Snam e
S id
P ay rt U te n s ils S id
P a y rt P id
q ty P id C a te
R epl P id
P id
C a te
P a y rt Typ
T yp Snam e
P ri Q ty
Snam e
S id
Toys
S id S id
Snam e
M e d ic in e Q ty P id
P id
S id
C lo th e s
H o s ie ry Q ty
Q ty
W t P a y rt
P a y rt Snam e c o lo r
E x p ry S id P id
C a te Q ty
P id
Snam e C a te
P a y rt

Fig 4.2

4.3 Schema Diagram:

16
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Fig 4.3

4.4 Data Flow Diagram

17
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

4.4.1 Context Diagram

A DFD (Data Flow Diagram) that summarizes all processing activity

within the system in a single process symbol is called Context Diagram. A context
Diagram is a DFD that describes the highest-level view of a system are shown in own
diagram, with the whole system represented as one process.
The context diagram is useful for showing boundaries. The system scope
is defined by what is represented within single process and what is represented as an
external agent. External agents that supply or receive data from the system are outside of
the system scope. Everything else is inside the system scope. Data stores are not usually
shown on the context diagram because all of the system’s data stores are considered to be
within the system scope. The context diagram is simply the highest-level DFD.
The context diagram provides a good overview of the scope of the system,
showing the system in “context” but it does not show any detail about the processing that
takes place inside the system.
The context diagram for the departmental store is shown below. The inputs
& outputs of the store are shown in the fig. The diagram shows the external entities of the
system & how the data that flows through the system. This helps in determining the basic
functionalities.

Context Level Diagram

18
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

(Level 0)

S a le s R e p o r t

S e a r c h / M o d if y S u p p lie r S a le s M an a g e r

S e a r c h / M o d if y P r o d u c t s
P la c e o r d e r f o r C u s t o m e r

D e liv e r y R e p o r t P a y m e n t
C h e c k A v a ila b le S t o c k
D e p artm e n tal
R e c e p tio n is t S to re U n a v a ila b le S t o c k O r d e r
M anagem ent
S y s te m E m p lo y e e D e t a il
R e c e ip t f o r C u s t o m e r

P a y m e n t fo r C u s to m e r
A tte n d a n c e R e c o rd

P a y s lip

S e a r c h / A d d E m p lo y e e C le rk

Fig 4.4

4.4.2 Data Flow Diagram (DFD)

19
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

The traditional approach to information system development describes

activities as processes carried out by or computer. A graphical model that has proven to
be quite valuable for modeling processes dependency diagram used in the Information
Engineering approach and the workflow diagram used with business process
reengineering, but the data flow diagram is the most commonly used process model.
A data flow diagram (DFD) is a graphical system model that shows all of
the main requirements for an information system in one diagram: inputs and outputs,
processes, and data storage. Everyone working on a development project can see all
aspects of the system working together at once with DFD. That is one reason for its
popularity. The DFD is also easy to read because it is graphical model.
End Users, management, and all information systems workers typically
can read and interpret the DFD with minimal training.

4.4.3 Fragmented DFD

A DFD that represent the system response to one event within a single
process symbol is called DFD fragment. A DFD fragment is created for each event in the
event list (expanded into the event table). Each DFD fragment is a self-contained model
showing how the system responds to a single event. The analyst usually creates DFD
fragments on at a time, focusing attention on just part of the system.

Each DFD fragment represents all processing for an event within single process symbol.
But the fragments show details of interactions between the process, external agents, and
internal data stores. The data stores used on a DFD fragment represent entities on the
ERD. Each DFD fragment shows only those data stores that are actually needed to
respond to the event.

Data Flow Diagram

20
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

(Level-1)

Fig 4.5

Data Flow Diagram

21
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

(Level-2)

Fig 4.6

Data Flow Diagram

22
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

(Level 3)

Fig 4.7

23
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Data Flow Diagram

(Level 4)

Fig 4.8

24
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

4.5 Structure Chart

First Level Factoring:

M a in
B il
id l,P
ro d
Qt y ,P

Pa
y s
lip
G e t S to c k fro m P ay s lip to D e live ry to
T ran s ac tio n
S u p p lie r E m p lo y e e C u s to m e r

Fig 4.9

25
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Factoring of INPUT Module

G e t S to c k fro m
S u p p lie r

Q
l
ta i

ty
,P
e
k d

ro
d
c
S to

S u p p lie r O rd e r
U p d atin g S to re in S to c k
D e tail

Fig 4.10

26
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Factoring Of TRANSFORM Module:

T r a n s a c t io n

P ay
s lip

am e
B i ll
E id ,n

B il
P ay

l
s lip
S to c k B ill G e t E m p lo y e e S a la ry B ill to P ay s lip to
C alc u latio n In f o . C alc u latio n C u s to m e r E m p lo y e e

A tte n d a n c e
Q ty
d

R ec o rd
,P i
Q ty

,
P id

R e c o rd
O rde r A vailab ility
d e tail o f S to c k

Fig 4.11

4.6 FLOW CHARTS

27
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Flow Chart For LOGIN :

Fig 4.12

28
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Flow Chart for Add/Delete/Update Product Information:

Fig 4.13

Flow Chart for Add/Delete/Update Supplier Information:

29
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Start

Display Supplier Master

Form

Enter the Supplier to Add/Updat Enter New Supplier

Update/Delete e/Delete Details

Update/Delete from Add to Database

Database

Display Supplier Master

Form

Stop

Fig 4.14

30
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Flow Chart for Add/Delete/Update Employee Information:

Start

Display Employee Master

Form

Enter the Employee Add/Updat Enter New

to Update/Delete e/Delete Employee Details

Update/Delete from Add to Database

Database

Display Employee Master

Form

Stop

Fig 4.15

31
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Flow Chart for Add/Update/Delete Customer Master:

Start

Display Customer Master

Form

Add/Updat Enter New Customer

Enter the Customer
e/Delete Details
to Update/Delete

Add to Database
Update/Delete from
Database

Display Customer Master

Form

Stop

Fig 4.16

32
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Flowchart for Add/Update/Delete Damages:

Start

Display Damages
Form

Enter the Damages Add/Updat Enter New Damages

to Update/Delete e/Delete Details

Update/Delete from
Add to Database
Database

Display Damages Form

Stop

Fig 4.17

33
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

4.7 MENU TREE

Fig 4.18

34
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

4.8 GANTT CHART

Fig 4.19

35
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

4.9 Event Table:

NO EVENT TRIGGER EVENT ACTIVITY RESPONSE DESTINATION

TABLE
1. Add New Supplier Make new Confirmation Supplier
Supplier Supplier Supplier entry
Details Entry
2. Add New Customer Make new Confirmation Customer
Customer Customer Customer
Details Entry entry

3. Add New Employee Make new Confirmation Employee

Employee Employee Employee
Details Entry entry

4. Entry for New Order Order_Cust Update Confirm Order_Cust

Customer Entry Customer
Order Order
Entry
5. Entry for New Order_Supl Update Confirm Order_Supl
Supplier Supplier Supplier
Order Order entry Order Entry
6. Update Update Supplier Update Change Supplier
Supplier Supplier Supplier confirmation
Details
7. Update Update Customer Update Change Customer
Customer Customer Customer confirmation
Details
8. Update Update Products Update Change Products
Product Product Product confirmation
Details
9. Update Update Order_Supl Update Change Order-Supl
Supplier Supplier Supplier confirmation
Order Details Order Order

36
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

10. Update Update Order_Cust Update Change Order_Cust

Customer Customer Customer confirmation
Order Details Order Order
11. Update Update Employee Update Change Employee
Employee Employee Employee Confirmation
Detail
12. Delete Delete Customer Delete Delete Customer
Customer Customer Customer Confirmation
Detail
13. Delete Delete Supplier Delete Delete Supplier
Supplier Supplier Supplier Confirmation
Detail
14. Delete Delete Employee Delete Delete Employee
Employee Employee Employee Confirmation
Detail
15. Delete Delete Products Delete Delete Products
Products Products Products Confirmation
Detail
16. Generate Bill Produce bill Order_Cust Report Bill Reports Customer
Reports report Generation
17. Generate Produce Salary Sheet Pay slip Pay slip Salary Sheet
Salary Sheet Salary Generation
Sheet

37
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

5. Program List:

Sr.No. Program Caption Program Name Description

(.frm)
1. Departmental frmsplash.frm Displays the splash
Screen
2. Login frmlogin.frm Login the software by user id
& password
3 Welcome….. frmWelcomeMDI.frm Displays the MDI form with
different menus
4. Customer_Info frmcustinfo.frm Displays form with
customers information
5. Customer_Add frmcustadd.frm Displays form for adding the
customer information
6. Order_Customer frmordercust.frm Displays the form for adding
customers orders
7. Employee_Info frmemp.frm Displays forms with
employees information
8. Salary_Sheet frmsalary.frm Displays the salary
information for the employee
9. Search frmsearch.frm Search a specific employee

10. Products frmproductsclo.frm Contains the information

about various products
11. Glossary Information frmgross.frm Displays the information
about glossary
12. Hosiery Information frmhosiery.frm Displays the information
about hosiery
13. Medicine Information frmmedecine.frm Displays the information
about medicines
14. Snacks Information frmsnacks.frm Displays the information
about snacks
15. Toys Information frmtoys.frm Displays the information
about toys
16. Utensils Information frmutensils.frm Displays the information
about utensils
17. Fruits & Vegetables frmfruitveg.frm Displays the information
about fruits & vegetables
18. Damages frmdamages.frm Displays the information
about damaged products
19. Add_Damages frmadddamages.frm Displays the form for adding
damaged products

38
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

20. Supplier_Info frmsupl.frm Displays the form with

suppliers information
21. Supplier_Add frmsupl.frm Displays the form for adding
suppliers information
22. Order to Supplier frmaddsuporder.frm Displays the form for adding
orders given to the supplier
23. Purchases done by frmordersup.frm Displays the form for adding
Company supplier orders
24. Add a supplier payment frmpayadd.frm Displays the form for adding
suppliers payments
25. Order_Supplier frmpayment.frm Displays form with order
given to the supplier
26. About us frmabout.frm Displays the About Us form

39
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

6.TABLE STRUCTURE:

Branch Table:

Sr.No. Fields Required(Y/N) Type Key

1. Branch_No Yes Number Primary Key
2 Location Yes Text
3. Manager Yes Text
4. Emp_Id Yes Text
5. Target Yes Currency
6. Sales No Currency
Description:

 Branch_No: This field stores the IDs of the various branches located in different
areas. Branches have different branch ID.
 Location: This field stores the name of the locations of each branch.
 Manager: This field contains the name of the managers of the branch.
 Emp_Id: This field gives the ID of the Branch Manager.
 Target: This field gives the information about target sale of each branch.
 Sales: This field gives the information about the actual sales of each
Branch.

Customer:

Sr.No. Fields Required(Y/N) Type Key

1. Cust_Id Yes Text Primary Key
2. Cust_name Yes Text
3. Address Yes Text
4. Phone_no No Double
5. Total_amt No Currency
6. Balance No Currency
Description:

 Cust_Id: This field stores the Ids of each customer, which is unique to each
one.
 Cust_name: This field stores the name of each employee.
 Address: This field gives the addresses of each customer.
 Phone_No: This column stores the phone numbers of employees.
 Total_Amt: This column gives the total purchases of employees.
 Balance: This field stores the balances remaining for the customers , if any.

40
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Employee:

Sr.No. Fields Required(Y/N) Type Key

1. Emp_Id Yes Text Primary Key
2. Ename Yes Text
3. Branch_Id Yes Text Foreign Key
4. Gender Yes Text
5. Address Yes Text
6. Phone_No. No Double
7. Date of Birth Yes Date/Time
8. Position Yes Text
9. Hire_Date Yes Date/Time
10. Salary No Currency
11. Bill_No No Text
12. Purchases No Currency

Description:

 Emp_Id: This field stores the Ids of the each employee, which is also
unique to each other.
 Ename: This field stores the name of each employee.
 Branch_Id: This field stores the branch id of the employee.
 Address: This store the information of the employees addresses.
 Phone no: This field stores the phone numbers of the employees.
 Date of Birth: It stores the birthdates of each employee.
 Position: This column stores the positions of each employee.
 Hire Date: This field stores the hiring date of each employee.
 Salary: This column stores the salary of the employees.
 Bill_No: This field stores the order id of the employee.
 Purchases: This field gives the information about the total purchases of the
employee.

41
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Supplier:

Sr.No. Fields Required(Y/N) Type Key

1. Supp_Id Yes Text Primary Key
2. Sname Yes Text
3. Address Yes Text
4. Phone_No No Double
5. Reasonable Yes Text
Description:

 Supp_Id: This field stores the Ids of each supplier, which is unique to each
one.
 Sname: This field stores the name of each supplier.
 Address: This field gives the addresses of each supplier.
 Phone No: This column stores the phone numbers of supplier.
 Reasonable: This field just tells that whether the supplier provides us with
reasonable discounts, schemes, products in a profitable price.

Clothes:

Sr.No. Fields Required(Y/N) Type Key

1. Prod_Id Yes Text Primary Key
2. Sup_Id Yes Text Foreign Key
3. Sname No Text
4. Category Yes Text
5. Quantity No Double
6. PayRate No Currency
7. Size No Text
8. Color No Text
Description:

 Prod_Id: This field stores the product Ids of each product.

 Sup_Id: This field gives the supplier Ids of the product who took the order.
 Sname: This field stores the name of each supplier
 Category: This field stores the category of each clothes whether it is dress
materials, saris, shirts or anything else.
 Quantity: This field stores the total quantities of each clothes.
 PayRate: This field stores the price of each dress material.
 Size: This field gives the various sizes of clothes available.
 Color: This field gives the various of clothes available.

42
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Fruits_Veg:

Sr.No. Fields Required(Y/N) Type Key

1. Prod_Id Yes Text Primary Key
2. Sup_Id Yes Text Foreign Key
3. Sname No Text
4. Category Yes Text
5. Type No Text
6. Quantity No Double
7. PayRate No Currency
Description

 Prod_Id: This field stores the product Ids of each product.

 Sup_Id: This field gives the supplier Ids of the product who took the order.
 Sname: This field stores the name of each supplier
 Category: This field stores the category of each vegetable and fruits.
 Type: This field tells whether the product is fruit or vegetable.
 Quantity: This field stores the total quantities of each vegetable and fruits.
 PayRate: This field stores the price of each vegetable and fruits.

Grossary:

Sr.No. Fields Required(Y/N) Type Key

1. Prod_Id Yes Text Primary Key
2. Sup_Id Yes Text Foreign Key
3. Sname Yes Text
4. Category Yes Text
5. Quantity No Double
6. PayRate No Currency
7. Total_Amt No Currency
Description:

 Prod_Id: This field stores the product Ids of each product.

 Sup_Id: This field gives the supplier Ids of the product who took the order.
 Sname: This field stores the name of each supplier
 Category: This field stores the category of each glossary whether it is rice, dal
or anything else.
 Quantity: This field stores the total quantities of each glossary.
 PayRate: This field stores the price of each glossary.
 Total_Amt: This field contains the total amount of grossary available.

43
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Hosiery:

Sr.No. Fields Required(Y/N) Type Key

1. Prod_Id Yes Text Primary Key
2. Sup_Id Yes Text Foreign Key
3. Sname No Text
4. Category Yes Text
5. Quantity No Double
6. PayRate No Currency
Description:

 Prod_Id: This field stores the product Ids of each product.

 Sup_Id: This field gives the supplier Ids of the product who took the order.
 Sname: This field stores the name of each supplier
 Category: This field stores the category of each product whether it is soap,
brush, shampoo or anything else.
 Quantity: This field stores the total quantities of each product.
 PayRate: This field stores the price of each product.

Medicine:

Sr.No. Fields Required(Y/N) Type Key

1. Prod_Id Yes Text Primary Key
2. Sup_Id Yes Text Foreign Key
3. Sname No Text
4. Item_Name Yes Text
5. Quantity No Double
6. Weight Yes Text
7. PayRate No Currency
8. Expiry No Date/time
Description:

 Prodid: This field stores the product Ids of each product.

 Suplid: This field gives the supplier Ids of the product who took the order.
 Sname: This field stores the name of each supplier
 Item_Name: This field stores the category of each medicine, whether
 Quantity: This field stores the total quantities of each product.
 Weight: This field gives the net wt. of the product.
 PayRate: This field stores the price of each product.
 Expiry Date: This field gives the information about the expiry date of each
medicine.

44
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Snacks:

Sr.No. Fields Required(Y/N) Type Key

1. Prod_Id Yes Text Primary Key
2. Sup_Id Yes Text Foreign Key
3. Sname
4. Category Yes Text
5. Weight
6. Quantity No Double
7. PayRate No Currency
8. Expiry
Description:

 Prod_Id: This field stores the product Ids of each product.

 Sup_Id: This field gives the supplier Ids of the product who took the order.
 Sname: This field stores the name of each supplier
 Category: This field stores the category of each snacks product whether it is
wafer, chocolate, biscuits or anything else.
 Quantity: This field stores the total quantities of each snacks product.
 PayRate: This field stores the price of each product

Toys:

Sr.No. Fields Required(Y/N) Type Key

1. Prod_Id Yes Text Primary Key
2. Sup_Id Yes Text Foreign Key
3. Category Yes Text
4. Quantity No Double
5. PayRate No Currency
Description:

 Prod_Id: This field stores the product Ids of each product.

 Sup_Id: This field gives the supplier Ids of the product who took the order.
 Sname: This field stores the name of each supplier
 Category: This field stores the category of each toy.
 Quantity: This field stores the total quantities of each toy.
 PayRate: This field stores the price of each toy.

45
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Utensils:

Sr.No. Fields Required(Y/N) Type Key

1. Prod_Id Yes Text Primary Key
2. Sup_Id Yes Text Foreign Key
3. Category Yes Text
4. Quantity No Double
5. PayRate No Currency
Description:

 Prod_Id: This field stores the product Ids of each product.

 Sup_Id: This field gives the supplier Ids of the product who took the order.
 Sname: This field stores the name of each supplier
 Category: This field stores the category of each product whether it is spoon,
pan, plates or anything else.
 Quantity: This field stores the total quantities of each product.
 PayRate: This field stores the price of each product.

Order_Customer:

Sr.No. Fields Required(Y/N) Type Key

1. Orderid Yes Text Primary Key
2. Custid Yes Text Foreign Key
3. Order_dt Yes Date/Time
4. Paying_type No Text
5. Total_amt Yes Currency
6. Balance No Currency
7. Amt_paid No Currency
Description:

 Orderid: This field stores the order id for each customer.

 Custid: This field gives id of the customer who placed the order.
 Order_dt: This field stores the date of the order.
 Paying_Type: This column gives the information about the paying type of
each customer whether it is based on cash or cheque.
 Total Amt: This field stores the total amount of purchase of the customers.
 Balance: This field stores the balances remaining for the customers.
 Amt Paid: This field gives the amount paid by each customer.

46
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Order Customer Product:

Sr.No. Fields Required(Y/N) Type Key

1. Order_Id Yes Text Foreign Key
2. Prod_Id Yes Yes Foreign Key
3. Quantity Yes Double
4. PayRate Yes Currency
Description:

 Order_Id: This field stores the order id for each customer.

 Prod_Id: This field stores the information about those product ids for which
customer placed the order.
 Quantity: This column gives the information for the total quantity of
products of each customer.
 PayRate: This field stores the price of each product.

Order_supplier:

Sr.No. Fields Required(Y/N) Type Key

1. Order_Id Yes Text Primary Key
2. Sup_Id Yes Text Foreign Key
3. Order_dt No Date/Time
4. Paying_type Yes Text
5. Total_amt No Currency
6. Balance No Currency
7. Amt_paid No Currency
Description:

 Order_Id: This field stores the order id for each supplier.

 Sup_Id: This field gives id of the supplier to whom order is placed .
 Order_dt: This field stores the date of the order.
 Paying_type: This column gives the information about the paying type of each
customer whether it is based on cash or cheque.
 Total_Amt: This field stores the total amount of purchase of the customers.
 Balance: This field stores the balances remaining for the customers.
 Amt_Paid: This field gives the amount paid by each customer.

47
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Order Supplier Product:

Sr.No. Fields Required(Y/N) Type Key

1. Order_Id Yes Text Foreign Key
2. Prod_Id Yes Yes Foreign Key
3. Quantity Yes Double
4. PayRate Yes Currency
Description:

 Order_Id: This field stores the order id for each customer

 Prod_Id: This field stores the information about those product ids for which
customer placed the order.
 Quantity: This column gives the information for the total quantity of
products of each customer.
 PayRate: This field stores the price of each product.

Damages:

Sr.No. Fields Required(Y/N) Type Key

1. Cust_Id Yes Text Foreign Key
2. Sup_Id Yes Text Foreign Key
3. Prod_Id Yes Text Foreign Key
4. Quantity No Double
5. PayRate No Currency
6. Replaced Yes Text
Description:

 Cust_Id: This field gives id of the customer who have reported damages.
 Sup_Id: This field gives id of the supplier to whom we need to contact.
 Prod_Id: This field gives id of the damaged product
 Quantity: This column gives total quantity of the damaged products.
 PayRate: This field stores the price of each product.
 Replaced: This field gives whether the damaged products are replaced or not

48
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Salary Sheet:

Sr.No. Fields Required(Y/N) Type Key

1. Ename Yes Text
2. Emp_ID Yes Text Foreign Key
3. Basic _Salary No Currency
4. Dearness_Allowance No Currency
5. Travelling_Allowance No Currency
6. Medical_Allowance No Currency
7. Overtime No Currency
8. Bonus No Currency
9. Providend_Fund No Currency
10. Gross_Salary No Currency
11. Service_Charge No Currency
12. Income_Tax No Text
13. Net_Salary No Currency
Description:

 Emp_Id: This field stores the Ids of the each employee, which is
also unique to each other.
 Ename: This field stores the name of each employee.
 Basic_Salary: This field stores the basic salary given to all
employees.
 Dearness_Allowance: This field stores the dearness allowance decided for
the employees
 Travelling_Allowance: This field stores the traveling allowance decided for
the employees.
 Medical_Allowance: This field stores the medical allowance decided for
the employees.
 Overtime: This field stores the overtime given to employee, If
any.
 Bonus: This field stores the bonus given to employee, If any.
 Providend_Fund: This field stores the amount for the Providend Fund
decided for the employees.
 Gross_Salary: This field stores the Gross Salary given to the
employees.
 Service_Charge: This field store the charges for the various services
provided by the company.
 Income_Tax: This field stores the income tax paid by the employee.
 Net_Salary: This field store the Net Salary given to the employee.

49
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

7. REPORT LIST

The system includes the following reports:

 Sales Report
 Purchase Report
 Salary Sheet Report
 Customer Bill Report

50
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

8. SYSTEM TESTING

Testing plays a critical role in quality assurance for software. Due to the
limitations of the verification methods for the previous phases, design and
requirements faults also appear in the code. Testing is used to detect these errors, in
addition to the errors introduced during the coding phase.
Testing is a dynamic method for verification and validation, where the
system to be tested is executed and the behavior of the system is observed. Due to
This, testing observes the failure of the system, from which the presence of faults can
be deduced. However, separate activities have to be performed to identify the faults.

8.1Approaches:

Black-Box Testing:

In the black-box testing, the internal logic of the system under testing is not
considered and the test cases are decided from the specification or the requirements. It is
often called functional testing. Equivalence class partitioning, boundary value analysis,
and cause effecting graphing are examples of methods for selecting test cases for black-
box testing. State–based testing is another approach in which the system is modeled as a
state machine and then this model is used to select test cases using some transition or path
based coverage criteria. State–based testing can also be viewed as grey-box testing in that
it often requires more information than just the requirements.

White-Box Testing:
In white-box testing, the test cases are decided entirely on the internal
logic of the program or module being tested. The external specifications are not
considered. Often a criterion is specified, but the procedure for selecting test case is left
to the tester. The most common control flow-based criteria are statement coverage and
branch coverage, and the common data flow-based criteria are all-defs and all-uses.
Mutation testing is another approach for the white-box testing that creates mutants of the
original program by changing the original program. The testing criterion is to kill all the
mutants by having the mutant generate a different output from the original program.

51
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

8.2 System Test Document (STD)

System Overview:
The software system consists of a desktop application in which the local machine
maintains various databases. The system consists of various interrelated pages. The
interconnections of the pages and the links on the pages have to be tested for proper
interfaces between them. The databases on the server system have to be checked for
consistency on different input values entered at the client system. The two versions
released have to be checked separately.

Test Approach:

 The model used to develop the software is the waterfall model. So the testing
phase comes only once in the entire lifetime of the project. Therefore it has to be
intensive and as thorough as possible.
 First and foremost we have to check the hardware interfaces. While checking the
visual interface the interconnection and the links have to be checked. This will be
done by going through various links and checking if the desired pages open up.
 This will be followed by testing the database business layer interface. Here the
interactions between the validation and query scripts and the database have to be
checked.
 Next we check the GUI and business layer interfaces. Here the form validation
and scripts acting on the form come into the picture.
 The inventory triggers have to be checked for. This includes testing whether the
triggers are activated on reaching minimum levels or not.
 This will be succeeded by integration testing. The individual models are
integrated and tested for proper interface. This will require 3 days.
 System testing will focus on system integration.
 User acceptance will focus on the testing by the user and then giving an approval
of the system.

52
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Features to be tested:

 The hardware has to be tested to check whether the standard output values
expected are satisfied or not. The test cases involved in this are as follows
 To check the machine speed.
 The software interface testing is to be done next in this section. Here we have to
test the various links which provide the interfaces between different pages. The
test cases involved in this are as follows:
 To check links which are independent of the data entered.
 To check the links which are dependent on the data entered.
 The input fields have to be checked whether only valid values are being accepted
i.e. the form validation is done without any bugs in it. The various test case
involved are
 By entering wrong and invalid values
 By entering values on the boundary.
 By entering skeptical data.

 The database on the server side should be checked for any inconsistencies.
 The various test cases involved are as follows:
 By entering values which are repeated to make the database inconsistent.
 The database also has to be checked for maximum possible entries which it can
accept and handle.
 The entered values are not allowed and are out of bounds

Features not to be tested:

 The data inputs on the screen in the different forms are the sole interest and
information only known to the customer. So it need not be checked by the
developers and testers.
 The machine speeds of the client machine, which may result into better speed of
the software, is the lookout of the customer and is not an element to be considered
for testing.

53
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

8.3 TEST CASES:

Case 1 (Interface):

Purpose:

To check links which are independent of the data entered and to check the links
which are dependent on the data entered.

Inputs:

In case of independent links there would not be any inputs whereas in case of
dependent links the fields, the value of which decides the links are to be entered.
Example of dependent links is the form entered which is to be validated before accepting
the information into the database. The data entered will be valid and invalid as well as on
the boundary. Independent links are the ones in which the links are given on the screen
and the pages to which they jump is prefixed and does not change based on any input.

Expected Outputs & Pass/Fail criteria:

In case of independent links the prefixed pages to which the links are pointing
should be checked. If the links are functioning properly then the test is passed. In case of
dependent links on entering the valid input the output should be generated. In case of
invalid input an error message should be displayed. This will indicate whether the test has
been passed or failed.

Test Procedure:

The required fields are entered and the links are clicked on and the results are
observed and noted down. The valid input is entered and the results are verified. The
invalid input is entered and the results are verified. The boundary conditions are also
checked and verified.

54
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Case 2 (Database):

Purpose:

The purpose of this test case is to check the capability of the database. It
will verify the amount of data that can be handled as well as determine the dependability
of the data.

Inputs:

The inputs to the software will be data which can prove to be inconsistent
and can damage the dependability of the software. The data entered will be in voluminous
quantities so that the capability of the database can be tested.

Expected Outputs & Pass/Fail criteria:

In case of skeptical data, if the inputs given cause inconsistency to the

database, the system will fail this test case. Even if 1 out of 100 inputs cause
inconsistency then the system will fail to clear the test. In case of stressing the system, if
the system is able to handle the number of entries as specified in the requirement
document then the test will be passed by the system.

Test Procedure:

Enter the data in such a way that the inputs have same time slots allotted
or same usernames allotted. If the database accepts those then the system fails there itself.
The same process will be carried out in case of each input field to check for
consistencies. The data will be then entered in large quantities. If the database is capable
of handling it without losing any access time then the database will pass the test. 5%
level of tolerance is acceptable.

55
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

9. CONCLUSION

Here we have tried to develop a system that will synchronize the data
stored at various places to be maintained at a single location with proper accessibility and
security. The system will store the various records of different products, distributors and
various transactions in a uniform format. Effective management will be done to maintain
minimum inventory levels of food and other essential commodities. The user will get
critical information as unavailability of a certain product or expiry of some goods
beforehand. User can also make any updates to previously entered information and also
delete any obsolete data which is not required anymore. Thus, we tried to provide the
store administrator with an easy way to access his data.

56
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

10. CODING CONVENTION

Variable Name Convention:

Every variable has being named according standard convention. There is no number
allowed at the beginning of each variable.

Table Naming Convention:

Every table has being named with underscore sign in between two words.

Function Naming Convention:

Every function has been named starting with corresponding name with underscore sign
separating two records to maintain consistency.

57
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

11. FORM LAYOUTS

The Splash Screen (frmSplash.frm)

58
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

The LOGIN Form (frmLogin.frm):

59
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Main Form (frmWelcomeMDI.frm)

60
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Customer Master Form (frmcustinfo.frm)

61
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Form that Add A New Customer (frmcustadd.frm)

The Text Boxes Checks for validation of the value that is entered
Here it checks whether the entered number is character or not

62
DEPARTMENTAL STORE MANAGEMENT SYSTEM

63
DEPARTMENTAL STORE MANAGEMENT SYSTEM

64
DEPARTMENTAL STORE MANAGEMENT SYSTEM

65
DEPARTMENTAL STORE MANAGEMENT SYSTEM

66
DEPARTMENTAL STORE MANAGEMENT SYSTEM

67
DEPARTMENTAL STORE MANAGEMENT SYSTEM

68
DEPARTMENTAL STORE MANAGEMENT SYSTEM

69
DEPARTMENTAL STORE MANAGEMENT SYSTEM

70
DEPARTMENTAL STORE MANAGEMENT SYSTEM

71
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

About Us Form

72
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Data Report For Employees Salary sheet

73
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

12. CODE:

FORM : frmSplash.frm

Dim inti As Integer

‘***********************************************************************

Private Sub Form_KeyPress(KeyAscii As Integer)

Unload Me
End Sub

'********** SETS THE TIMER EVENT FOR THE PROGRESSBAR **************

Private Sub Timer1_Timer()

ProgressBar1.Value = ProgressBar1.Value + 1

If ProgressBar1.Value = 100 Then

Timer1.Enabled = False
frmLogin.Show

End If

inti = inti + 1
lblno.Caption = inti & "%"

End Sub

74
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

FORM: frmLogin.frm

'***THIS FORM RELATES TO THE AUTHORISED USER ONLY***

'*********IT PROVIDES SECURITY TO THE USER**********

Private Sub cmdcancel_Click()

Unload Me
End
End Sub

‘***********************************************************************
Private Sub cmdOk_Click()

If cbouser.ListIndex = 0 And txtPwd.Text = "gudiya" Then

frmWelcomeMDI.Show
ElseIf cbouser.ListIndex = 1 And txtPwd.Text = "rose" Then
frmWelcomeMDI.Show
Else
MsgBox "Incorrect Password"
End If

End Sub

75
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

FORM : frmcustinfo.frm

'****** THIS FORM DISPLAYS ALL THE RECORDS ************

'******* PRESENT IN THE CUSTOMER DATABASE *********

'******* ALSO ALLOWS VARIOUS OPERATIONS TO BE *********

'********** PERFORMED ON THE RECORDS *****************

Dim r1 As Integer, X As Integer

Dim cnn1 As Connection
Dim rs As New ADODB.Recordset
Dim FLAG1 As Boolean
Dim cnt As Integer
Dim cur_record As Integer
Dim r As String

‘***********************************************************************
Public Sub moves()
txtcname = MSFlexGrid1.TextMatrix(X, 2)
txtcid = MSFlexGrid1.TextMatrix(X, 1)
txtaddr = MSFlexGrid1.TextMatrix(X, 3)
txtph = MSFlexGrid1.TextMatrix(X, 4)
txtpur = MSFlexGrid1.TextMatrix(X, 5)
txtbalance = MSFlexGrid1.TextMatrix(X, 6)

End Sub

‘***********************************************************************
‘** LOCKS ALL THE TEXTS BOXES SO THAT NO EDITION CAN BE DONE **

Public Sub locked()

txtaddr.locked = True
txtbalance.locked = True
txtcid.locked = True
txtcname.locked = True
txtph.locked = True
txtpur.locked = True
End Sub

76
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

'******** UNLOCKS ALL THE BOXES FOR FURTHER EDITION ***********

Public Sub unlocked()

txtaddr.locked = False
txtbalance.locked = False
txtcid.locked = False
txtcname.locked = False
txtph.locked = False
txtpur.locked = False
End Sub

‘***********************************************************************
Public Sub setrecordcount()

j = MSFlexGrid1.Rows - 2
txtrecord.Text = " Record " & X & " Of " & j

End Sub

*'****** DISPLAY RECORDS IN THE APPROPRIATE BOXES****************

Public Sub display()

txtaddr.Text = rs!Address
txtbalance.Text = FormatCurrency(rs!Balance)
txtcid.Text = rs!Cust_Id
txtcname.Text = rs!Cname
txtph.Text = rs!Phone_no
txtpur.Text = FormatCurrency(rs!Total_Purchase)

End Sub

‘***********************************************************************
Private Sub cmdadd_Click()
On Error GoTo SaveErr:

Unload Me
frmcustadd.Show
frmcustadd.Caption = "Customer Add"

77
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Exit Sub
SaveErr:
MsgBox Err.Description
End Sub

Private Sub cmdback_Click()

Unload Me
frmWelcomeMDI.Show
End Sub

Private Sub cmdcancel_Click()

locked
rs.Open

' **** THINGS NOT TO BE DISPLAYED IN THE LAYOUT ****

cmdupdate.Visible = False
cmdcancel.Visible = False

' **** THINGS TO BE DISPLAYED IN THE LAYOUT *****

cmddelete.Visible = True
cmdadd.Visible = True
cmdsearch.Visible = True
cmdback.Visible = True
cmdedit.Visible = True
cmdrefresh.Visible = True

rs.Close

End Sub

‘***********************************************************************
Private Sub cmdclose_Click()
End
End Sub

78
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Private Sub cmddelete_Click()

On Error GoTo DeleteErr

rs.Open
With rs
If .RecordCount = 1 Then
FLAG1 = True
MsgBox "This Is Last Record. You Can't Delete This Record.", _
vbCritical, "DELETE RECORD"
Else
FLAG1 = False
End If

If FLAG1 = False Then

s1 = MsgBox("Are You Sure You Want To Delete Record", vbQuestion + vbYesNo,
_
"DELETE RECORD")
If s1 = vbYes Then
i = MSFlexGrid1.RowSel
Do While i > 1
If Not .EOF Then .MoveNext
i=i-1
Loop
i = MSFlexGrid1.RowSel
.Delete
MsgBox "Record Is Successfully Deleted."
.MoveNext

If .EOF Then
.MovePrevious
End If
End If
End If
End With

rs.Close
Exit Sub

79
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

DeleteErr:
MsgBox Err.Description
End Sub

Private Sub cmdedit_Click()

unlocked
rs.Open

'**** THINGS TO BE DISPLAYED IN THE LAYOUT ****

cmdupdate.Visible = True
cmdcancel.Visible = True

' **** THINGS NOT TO BE DISPLAYED IN THE LAYOUT ****

cmddelete.Visible = False
cmdadd.Visible = False
cmdback.Visible = False
cmdedit.Visible = False
cmdrefresh.Visible = False
cmdsearch.Visible = False

rs.Close

End Sub

‘***********************************************************************
Private Sub cmdfirst_Click()
On Error GoTo FirstErr

X=1
moves
setrecordcount

Exit Sub
FirstErr:
MsgBox Err.Description
End Sub

80
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Private Sub cmdLast_Click()

On Error GoTo LastErr

X = r1
moves
setrecordcount

Exit Sub
LastErr:
MsgBox Err.Description

End Sub

‘***********************************************************************
Private Sub cmdnext_Click()
On Error GoTo NextErr

If (r1 > X) Then

X=X+1
moves
setrecordcount
Else
X=1
moves
setrecordcount
End If

Exit Sub
NextErr:
MsgBox Err.Description

End Sub

‘***********************************************************************
Private Sub cmdrefresh_Click()
rs.Open
MSFlexGrid1.Refresh
rs.Requery

81
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

rs.Close
End Sub

Private Sub cmdprevious_Click()

On Error GoTo PreviousErr

If (r1 >= X) Then

X=X-1
moves
setrecordcount
If X = 0 Then
X = r1
moves
setrecordcount
End If
End If

Exit Sub
PreviousErr:
MsgBox Err.Description

End Sub

‘***********************************************************************
Private Sub cmdsearch_Click()
On Error GoTo SearchErr
rs.Open
r = InputBox("Enter Customer's ID Or Customer's Name You Want To Search...?", _
"Get Information")
rs.MoveFirst
While Not rs.EOF

If rs.Fields(0) = r Or rs.Fields(1) = r Then

MsgBox "Record Found"
Call display
End If
rs.MoveNext

Wend
rs.Close

Exit Sub
SearchErr:

82
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

MsgBox Err.Description

End Sub

Private Sub cmdupdate_Click()

On Error GoTo UpdateErr
locked
If txtcid.Text = "" Then
MsgBox "There is no current record ", vbInformation
Else
r = MsgBox("Do YOU Want To Edit The Current Record?", _
vbQuestion + vbYesNo, "Data Edition")
If r = vbYes Then
cnn1.Execute ("Delete from Customer where Cust_Id='" & txtcid & "'")
cnn1.Execute ("Insert into Customer values('" & txtcid.Text & "','" & _
txtcname.Text & "','" & txtaddr.Text & "','" & _
txtph.Text & "','" & FormatCurrency(txtpur.Text) & "','" & _
FormatCurrency(txtbalance.Text) & "')")

ElseIf r = vbNo Then

MsgBox "Modification Cancel"
End If
End If
Exit Sub
UpdateErr:
MsgBox Err.Description
End Sub

Private Sub MSFlexGrid1_Click()

'THE SELECTED RECORD IS DISPLAYED

rs.Open
i = MSFlexGrid1.RowSel
Do While i > 1
If Not rs.EOF Then rs.MoveNext
i=i-1
Loop
i = MSFlexGrid1.RowSel
X=i
setrecordcount
Call display
rs.Close
End Sub

83
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Private Sub Form_Load()

On Error GoTo FormErr
locked
Set cnn1 = New ADODB.Connection
With cnn1
.ConnectionString = "Provider=MSDASQL.1;Persist Security Info=False; _
Data Source=supriya1"
.Open
End With
Call rs.Open("select * from Customer", cnn1, adOpenDynamic, adLockOptimistic)
i=1

'*** INCREASES THE COLUMN WIDTH ***

For j = 1 To 6 Step 1
MSFlexGrid1.ColWidth(j) = 2000
Next j

'*** COLUMN NAME IS DISPLAYED ***

MSFlexGrid1.TextMatrix(0, 1) = "Cust_Id"
MSFlexGrid1.TextMatrix(0, 2) = "Cust_name"
MSFlexGrid1.TextMatrix(0, 3) = "Address"
MSFlexGrid1.TextMatrix(0, 4) = "Phone_no"
MSFlexGrid1.TextMatrix(0, 5) = "Total_Purchase"
MSFlexGrid1.TextMatrix(0, 6) = "Balance"

'*** RECORDS ARE DISPLAYED IN THE GRID ****

If Not rs.EOF Then rs.MoveFirst

Do While Not rs.EOF
MSFlexGrid1.TextMatrix(i, 1) = rs!Cust_Id
MSFlexGrid1.TextMatrix(i, 2) = rs!Cname
MSFlexGrid1.TextMatrix(i, 3) = rs!Address
MSFlexGrid1.TextMatrix(i, 4) = rs!Phone_no
MSFlexGrid1.TextMatrix(i, 5) = FormatCurrency(rs!Total_Purchase)
MSFlexGrid1.TextMatrix(i, 6) = FormatCurrency(rs!Balance)
i=i+1
MSFlexGrid1.Rows = MSFlexGrid1.Rows + 1
If Not rs.EOF Then rs.MoveNext

84
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Loop
rs.Close

r1 = MSFlexGrid1.Rows - 2
X=1
Exit Sub
FormErr:
MsgBox Err.Description
End Sub

FORM: frmcustadd.frm

'****** THIS FORM DEALS WITH ADDING A NEW CUSTOMER ****

'*** IT ALSO CHECKS WHERTHER THE ENTERED *************
'************** VALUE IS VALID OR NOT ****************

‘*********************************************************************
Private Sub cmdback_Click()
Unload Me
frmcustinfo.Show
End Sub

‘*********************************************************************
Private Sub cmdclose_Click()
Unload Me
End Sub

‘********************************************************************
Private Sub Form_Load()
Set cnn1 = New ADODB.Connection
With cnn1
.ConnectionString = "Provider=MSDASQL.1;Persist Security Info=False;Data
Source=supriya1"
.Open
End With
Call rs.Open("select * from Customer", cnn1, adOpenDynamic, adLockOptimistic)
rs.Close

85
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

End Sub

Private Sub cmdsave_Click()

On Error GoTo SaveErr
rs.Open
rs.AddNew
r = MsgBox("Do You Want To SAVE The Changes To The Customer Database", _
vbYesNo + vbQuestion)
If r = vbYes Then
rs!Address = txtaddr.Text
rs!Balance = FormatCurrency(txtbalance.Text)
rs!Cust_Id = txtcid.Text
rs!Cname = txtcname.Text
rs!Phone_no = txtph.Text
rs!Total_Purchase = FormatCurrency(txtpur.Text)
MsgBox "Update Successfully"
rs.Update
Else
rs.CancelUpdate
End If

rs.Close
Exit Sub
SaveErr:
MsgBox Err.Description

End Sub

‘***********************************************************************
Private Sub txtbalance_KeyPress(KeyAscii As Integer)

If Not (KeyAscii >= 48 And KeyAscii <= 57 Or KeyAscii = 8) Then

MsgBox "Please Enter The Numbers"
KeyAscii = 0
End If

End Sub

86
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

Private Sub txtcname_KeyPress(KeyAscii As Integer)

If Not ((KeyAscii >= 97 And KeyAscii <= 122) Or (KeyAscii >= 65 And KeyAscii <=
91) Or KeyAscii = 8 Or KeyAscii = 32) Then
MsgBox "Please Enter The Characters"
KeyAscii = 0
End If

End Sub

‘***********************************************************************
Private Sub txtph_KeyPress(KeyAscii As Integer)

If Not (KeyAscii >= 48 And KeyAscii <= 57 Or KeyAscii = 8) Then

MsgBox "Please Enter The Numbers"
KeyAscii = 0
End If
End Sub

‘***********************************************************************
Private Sub txttotal_KeyPress(KeyAscii As Integer)

If Not (KeyAscii >= 48 And KeyAscii <= 57 Or KeyAscii = 8) Then

MsgBox "Please Enter The Numbers"
KeyAscii = 0
End If

End Sub

87
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

13. Implementation Procedure

After the completion of each module, a small working model with the required
database was created and Installed on the Work Area for the respective Module. The
Users were trained to use the system and their responses and suggestions for updations
were noted. The same were implemented wherever possible and the updated copy of the
Model was once again Installed and the same above procedure was repeated till the end
user was satisfied sufficiently with the system.
The same procedure was repeated with the full system fill the end users were fully
satisfied with the System.

For making an exe file select make project name.exe under the File menu.
Once the user has completed with the coding the application, and tested on multiple
machines, it is ready to be deployed. In order to deploy any application, the user can use
the Package and Deployment Wizard Provided by Microsoft. The prerequisite of
deploying an application is packaging.

To Package your application perform the following steps:

1) Start the Package and Deployment Wizard.

2) After selecting the administration module project, click on the Package button.

3) As per the requirements, select the type of packaging as Standard Setup Package.

The Wizard will then take over and perform the rest of the packaging steps for you. You
will see all the required files, including the runtime files, automatically being included.

To deploy your application, perform the following steps:-

1) Select the package you want to deploy, and click on the Deploy button.

2) Select the Deployment method. In this case, it will be Folder.

The wizard will then take over and perform the rest of the deployment steps for you.

88
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

14. Limitations of System:

Any project development is always a little less well than what the user had
on his mind. Every project that has been developed till date has never been a perfect one
because as the user gains more acknowledge about the system, he accepts that the system
perform a little more than it is developed with requirement in the mind.

Support for Networking in case of communication and data transfer

between Front End is not included yet.
This system is designed in SDI [Single Document Interface] user interface
i.e. user can work with only one window at the same time.
This system does not keep the details about customer’s discount & commission
rate.
The System may not function properly under Lower Versions of Oracle 8.0
Database Management System of Departmental Store Management System does
not support the networking environment and hence, there can be no centralization.
Power failures and any hardware problem cause the system fail and you cannot
keep any record of the transactions.
Because of hardware problem there is possibility of losing data.

89
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

15. Scope of Future Enhancement

For any system that is developing, there is always room for more
development.
Whenever a change in existing software system is include and then release, it
is said that the latest release is an advanced version of the software system.

Following are some of the feature that can be enhanced or include in

the result generation system.

 The system can be made compatible with different data base such as access.

General additions to the software

a) Data backup and recovery option,
b) More networking features,
c) Making the software platform independent,
d) Making the software version independent,

90
 DEPARTMENTAL STORE MANAGEMENT SYSTEM

16. Bibliography

References
Mastering VB 6.0.
Programming in Visual Basic By Julia Case Bradley, Anita C. Millspaugh
An Integrated Approach to Software Engineering By Pankaj Jalote.
Software Engineering By Pressman
DataBase System Concepts By Silberschatz, Korth, Sudarshan
SQL the Complete Reference By Groff Weinberg

Softwares

Visual Basic 6.0 Enterprise Edition.

Microsoft Access.
MicroSoft Developer’s Network April 99 Edition (MSDN).

91
DEPARTMENTAL STORE MANAGEMENT SYSTEM

92