CSD Online Shopping & Inventory Management System

Project Report CSD Online Shopping and Inventory Management System
CSD Online Shopping &

Inventory Management System
Submitted By:
Mayank Jaglan DCE
Abhishek Rana KIIT
CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

1
INDEX
S.NO CONTENT PAGE NO.
1. INTRODUCTION 4
Acknowledgement 5
Objective 6
Project Development life Cycle 7
2. DESIGN OF PRESENT SYSTEM 8
Study of System 8
Hardwares Used 16
Softwares Used 17
Limitations 18
3. DESIGN OF PROPOSED SYSTEM 18
Melioration in present application software 18
Hardwares Used 18
Softwares Used 19
Methodology 20
Parts Of The System 21
PERT Chart 22

2
4. ANALYSIS 23
5. IMPLEMENTATION & CODING 26
Implementation Phase 26
Code Snippets 27
6. FLOW DIAGRAM 35
7. DATABASE 36
ER-Diagram 36
Tables 38
8. OUTPUT SNAPSHOTS 43
9. TESTING 53
10. MAINTENANCE 54
11. CONCLUSION 55
12. LIMITATIONS 56
13. FUTURE PROSPECTS 57

3
14. BIBLOGRAPHY 58

4
CSD ONLINE SHOPPING &

INVENTORY MANAGEMENT SYSTEM
DATE OF SUBMISSION:
30th July, 2010
SUBMITTED TO:
Mrs. Alka Diwan,
Scientist-F & Additional Director,
CFEES, DRDO,
Ministry of Defense,
Timarpur, Delhi

5
ACKNOWLEDGEMENT
I express my sincere gratitude and thanks to Mrs.Alka Diwan, Scientist-F, for providing me the
excellent opportunity to do a project on CSD Online Shopping & Inventory Management
System and providing me with all the essential elements required for the completion and
enhancement of this project.
I am also grateful to Mr. S D Gupta, Technical Officer-C, for his expert guidance and
cooperation in making my project a learning and worthwhile experience.
I would like to thanks those respondents who have taken pain in successful completion of my
project work.

6
OBJECTIVE
One will definitely prefer to lap up a system, which is cost effective yet highly efficient,
easy to install and operate. It is here that Canteen Inventory Management System (CIMS)
is fast gaining its foothold in companies as an easy cost saving tool for CSD Canteen
Management. The objective of the system is to reduce the work load of the operator right
from stocks to selling goods. The system should maintain a detailed account of all
provisions bought and goods sold at the canteen. In addition to this, it should also
maintain the daily report of canteen sales & shopping quota of registered members. The
system should provide an interface to payroll for deductions. Several inquiry facilities
should also be provided to view the expenses incurred/ planned menus/cash payment etc.
In short following are the list of facilities that should be provided with the system: list of
items available with rates, stock left, transactions’ summary, damages and demands,
purchases and issues, etc.
The objective of the project is to develop a CSD Online Shopping and Inventory
Management System meeting the needs of employees and reducing the rush at CSD
Canteen.

7
PROJECT DEVELOPMENT LIFE CYCLE
The computer application development life cycle can be thought of six main steps, which are:
1. System project selection
2. Study Phase
3. Feasibility phase
4. Definition phase
5. Design phase
6. Implementation phase
7. Maintenance phase

8
DESIGN OF PRESENT SYSTEM
v STUDY OF PRESENT SYSTEM:
• Total Modules (divisions):

I. System Administrator
II. Canteen manager
III. Liquor salesman
IV. Grocery – Salesman
V. Card Issuance
VI. OIC liquor
VII. Grocery – bulk
VIII. Grocery - shop/Bay in-charge
IX. Data transfer
X. Reports
XI. History
XII. Liquor bulk
XIII. Liquor shop In-charge
XIV. Grocery damage
XV. Liquor Damaged
XVI. Gift In-charge
XVII. Canteen summary
• Module under use in canteen under Salesman login (GROCERY BILLING

SELECTION):
I. Grocery Salesman: Tabs under use in this module are listed below.
(snapshot)
a. Sale Grocery
b. Stock Demand
c. Duplicate Bill
II. Reports (snapshot)
III. Canteen summary (snapshot)

9
• Module under use in canteen under Manager login:

I. System Administrator
II. Canteen manager
III. Grocery Salesman
IV. Card Issuance
V. Unlocking the smart card
VI. Grocery bulk
VII. Grocery shop in-charge
VIII. Data transfer
IX. Reports
X. Grocery damage
XI. Canteen summary
Brief explanation of modules under Manager Login:
i. System Administrator:
A. Master Maintenance:
Masters essential for running CIMS application are maintained. Masters like
Shops, Counters, Users, Inventory, Profit Percentage, and Sales Tax are stored in
the database.
B. Rate Revision:
Apart from invoice, Rate revision can take place through Circulars. Whole Sale /
Retail Rate can be revised. Whenever Rate Revision is done, system logs the
impact on Stock Value for Bulk and all Minibulks.
C. User Maintenance:
a. The CIMS Users are defined. Each User has a default LOGIN ID, Shop and
Counter. A Secondary Shop can also be defined. It is relevant only when
Grocery and Liquor Bills can be cut from the same counter.
b. CIMS users are of two types – Supervisor and Operator. Supervisor can
perform all roles. But Operator cannot perform roles of Canteen Manager,
administrator, Card Issuer, OIC Liquor and Data Transferer.
c. The Roles can be assigned and unassigned.

10
D. Canteen Card Management:

a. A Canteen Card can be updated for Rank, Date Of Retirement, Card Validity,
Address, Temporary Service number (in case of retirement)
b. Card can be Blocked or Un-Blocked.
c. If PIN has been blocked, it can be reset to default value.
E. Paper Card Management :

a. Paper Card is maintained for a canteen member till he is issued a Smart Card.
b. When Smart card is issued, the Paper Card is to be BLOCKED.
ii. Canteen Manager:

A. Open Canteen:
a. To commence sales, canteen has to be opened every morning.
b. If Backup has not been taken, System prompts to take Backup.
B. Close Canteen:
a. At the end of the day, canteen is closed so that NO un-authorized user can access the
system.
b. STB cannot be done if Canteen is not close.
c. Month Closing can be done only if Canteen is Close.
d. All the Draft Vouchers exceeding the grace period are deleted.
e. All Non-Finalized Sale / Refund Bills are deleted and its history maintained.
C. Finalize Invoices:
a. Material Inward, Receipts from Depot, is finalized by the Manager.
b. Price Variation can occur upon finalization.
c. Case Pack of an item can get changed.
d. Items not demanded can be received.
D. Month Closing:
a. When New Month starts, System forces for Month Closing.
b. It can be done only if Canteen is Close.
c. It cannot be proceeded, if any Non-Finalized STB exists.
d. The Ledger Balance becomes the New Month’s Opening.
e. If besides Month Closing, a New Year also is starting then the Voucher Numbers are
initialized.
11
E. Approve Refunds:
a. A Bill can be refunded from the respective shop by any salesman only if it has been
approved for Refund.
b. Bill can be refunded partly or wholly. That is, only one item or more than one item
can be refunded. The Original Quantity of item can be refunded fully or partly as
maybe the case.
c. Once a Bill has been refunded, its status is updated to ‘Close’. Salesman does not see
that Bill for refund. But, Manager can view the status of all the Bills approved for
Refunds.
F. Approve Duplicate Bill Printing:

A Duplicate Bill can be printed from respective Shop from any Salesman’s Counter
only if it has been approved by the Manager.
iii. OIC Liquor:

A. Defining Grocery and Liquor Entitlements for different categories.
B. Various Categories are:
a. Serving Personnel
1. Maximum can be 4 cards
2. Primary Liquor Card
3. Primary Grocery Card
b. Ex-Servicemen and their Widows:

1. Maximum can be 4 cards
2. Primary Liquor Card
c. Civilians:
Entitled only for Single Grocery Card
d. Silver Card, Issued to Canteen Manager for Preferred Guests:

Entitled only for Single Card having limited Grocery Entitlements.

12
e. Gold Card, Issued to Serving Generals and VIPs:

f. Bronze Card, Issued to Institutions, Mess, hospitals:

iv. Grocery Salesman:

A. Billing:
Before a new Bill is cut, Smart Canteen Card is inserted in the PIN PAD reader.
System prompts for 4 digit PIN. Three failed attempts for PIN, blocks the Card. It
can be Un-Blocked only by the Manager.
B. Liquor Billing:
a. There is Daily, Fortnightly and Monthly Quota. A member can buy liquor as per
the balance quota.
b. If a person has not availed fortnightly quota before 15th of the month then
remaining balance can be bought after 15th.
c. Monthly, Fortnightly, Daily consumption gets initialized every month
C. Grocery Billing:
a. Monthly NON AFD consumption gets initialized every month
b. Yearly AFD consumption gets initialized every year
D. Refund:
a. A refund can be made only if Manager approves the Bill for Refund
b. Refund of a Bill can be whole or in parts
E. Duplicate Bill Printing:

Duplicate Bill can be printed only if Manager approves the Bill
F. Summaries:
Three summaries can be generated:
a. General Sales
b. Refund Sales
c. Net Sale (General Sales – Refunds)
13
v. Shop/Bay Incharge:
A. Material Return from Minibulk to Bulk
B. Transfer Damage Stock from Minibulk to Damage Stores

The Material transferred to Damage Stores is reflected in ‘Condemn’ column of
STB.
C. STB:
a. STB can be done any day during the Month
b. The canteen has to be close
c. The Material transferred to Damage Stores is reflected in ‘Condemn’ column of STB.
d. On Finalization, the Ground Balance declared in STB becomes the Ledger Balance of
Minibulk Inventory Master
vi. Bulk Incharge:

A. Issue Material from Bulk to Minibulk:
a. Material from Bulk to Minibulk transferred through Issue Voucher
b. Bulk Incharge has to enter Index Number and Issue Quantity manually
B. Automated Issue Voucher Creation for Bulk to Minibulk Transfer

a. When there is Single Grocery / Liquor Shop and No Bulk existing then All
Stock of Bulk can be transferred to Minibulk using this option.
b. The system prepares Issue Voucher with Index Number and Issued Quantity
same as the Ledger Balance.
c. Bulk Incharge has to press the ‘Transfer’ button to transfer Stock from Bulk
to Minibulk
C. Automated Issue Voucher Creation with 0 Issue Quantity

a. Bulk Incharge selects Shop and the Group.
b. All items having Ledger Balance Greater Than 0 and present in the Group
are added in the Issue Voucher with Issue Quantity 0.
c. Only the Issue Quantity has to be entered
D. Raise Demand:
a. Demands are raised when Bulk needs to be replenished with Stock.
b. Bulk Incharge has to enter Index Number and Quantity demanded.
14
E. Automated Demand Generation:

a. Demands with quantity to order, can be generated automatically based on
following criteria:
1. Average Sale = Sale / (Opening Balance + Receipts ) of (Previous Two
Months and Current Month)
2. Stock in Hand
3. Reorder Level
4. Demand Quantity = Reorder Level – Closing Balance + Average Sale
F. STB:
a. STB can be done any day during the Month
b. The canteen has to be close
c. The Material transferred to Damage Stores is reflected in ‘Condemn’
column of STB.
d. On Finalization, the Ground Balance declared in STB becomes the Ledger
Balance of Bulk Inventory Master.
vii. Damage Store Incharge:

A. Replacement Vouchers:
a. The material is sent to Supplier to Replacement Voucher.
b. The damaged material from Extension Counter can be returned to Main
Canteen under the Vendor code ‘URC’
c. On Finalizing the Replacement Voucher, the Damage Stock is reduced.
d. Against a Replacement voucher, more than one Return Voucher can be
prepared till the Replacement Voucher is Close.
e. A Replacement Voucher is Close when no more Return Material is
expected.
B. Return Vouchers:
a. It is the Material returned by Supplier against Replacement Voucher
b. In Lieu of Item sent for Replacement - Equivalent Amount can be received,
another item can be received, and same item with same quantity of different
quantity can be received.

15
c. STB:
Two types of STB done –
1. Damage Stores STB
2. Reduce Item STB (Reduce Items are the items which are sold to the
customers at reduced rates)
viii. Card Issuer:

A. Smart Canteen Cards Registration:
a. The Card Issuer registers the cards in the system
b. Every Card is associated with a Card Location.
c. The Card location can be a composite location comprising of Box Number, Rack
number, Shelf Number.
d. Maximum length of Card location is 15
B. Issuance:
a. Search is made in the Database and corresponding records meeting the criteria are
retrieved
b. Depending on the default values pertaining to respective category, the Entitlements
are displayed
c. In case of dependent card, all dependents of the Primary Card Holder, have same
NON AFD grocery entitlement
d. Flexibility is given where the customer can define the Grocery Entitlement on Primary
and Dependent Cards. But the sum total can never exceed the monthly entitlement
e. On successful issuance, Two reports are generated-
1. Acknowledgment Receipt
2. Letter to Customer
f. If card is not issued then Rejection Note is printed
Card Issue Failure Note
ix. Gift Store In charge:

A. Maintain Gift Master:
a. CSD Items received with Gift schemes are maintained
b. The Gift Index Number is a system generated number. The Gift received is
associated with CSD Index Number.

16
B. Receipt Vouchers:
The gifts are received through Receipt Voucher
C. Issue Vouchers:
The gifts are issued to Customers through Issue Voucher
D. STB:
Gift STB is done to know the Gift Stock Position.
x. Data Transferer:
A. Data Transfer from Main Canteen to Extension Counter and vice versa
B. Data Transfer is required when Dependent Canteen has Extension Counter/s
C. From Extension Counter, data transferred to Main Canteen is

a. The gifts are issued to Customers through Issue Voucher
b. Bills Cut
c. Consolidated Stock Position
d. Consolidated STB
e. Price Revision
f. Stock Return to Main canteen
g. Bulk Grocery / Liquor Shop Master
h. Inventory Master having new Items only
D. From Main Canteen to Extension Counter, data transferred is

a. Issues to Extension Counter
b. Inventory Master having new Items only
v HARDWARES USED
• RAM: 1 GB
• Processor: Intel Pentium IV, 3 GHz

17
• Std. Smart Card reader (for customer’s account login) Std. Smart card reader (for
master key by cashier) Printer (for paper bill)
• A monitor
• A CPU
• Standard Key Board & Mouse
v SOFTWARES USED
• Front End Language: Visual Basic
• Database Used: DB2
• Architecture Employed: 1 tier Arch. OS: WIN XP (32 bit)
v Limitations of present system:

• Tier-I architecture: User, Administrator and Database are installed on the same
system.
• If system fails all canteen work may halt. Canteen would remain close until
system starts working normally.
• In case of disk failure, all data may lose and might not be recoverable.
• Inconvenience to customer:
Usually, long queues for billing as registered employees/members shall
be shopping in their free time which is common in an organization (here,
Ministry of defense). Members have to visit canteen for shopping.

18
DESIGN OF PROPOSED SYSTEM
v Melioration in present application software:

• Up gradation to online shopping for employees/members.
• Up gradation from Tier-I to Tier-II architecture.
• LAN connection of user (customer/cashier) to system database (on server).
• New Business logic for user login through LAN using unique user-ID &
password.
• Logic for shopping at canteen site would be same as before.
v HARDWARES USED
• RAM: 1 GB
• Processor: Intel Pentium IV, 3 GHz, 64 bit support
• Printer
• A CRT monitor
• A CPU
• Std. PS2 Key Board & Mouse

19
v SOFTWARES USED
• Front End Languages: JAVA server pages, HTML, JAVA script
• Database Used: ORACLE Architecture Employed: 2 tier Arch. OS: WIN Server
2003 (64 bit)

20
v METHODOLOGY
The project proceeded according to the steps of SDLC (Software Development Life
Cycle) that is in seven phases which include the following:-
1) Requirement Analysis: All the requirements are analyzed using verbal or written
questionnaires with CSD canteen shopkeeper & employees.
2) High-Level Design: The purpose of this phase is to design the overall functioning of the
proposed system and finalize the input and output format.
3) Low-Level Design: The purpose is to produce a detailed design of the Software

modules/units.
4) Construction: Actual coding will be done in this phase.
5) Testing: In this phase module level testing is performed with mock values.
6) Acceptance: At this time the software is actually provided to the company and checking
it according to need.
7) Warranty and Maintenance: No warranty and maintenance since the project is

developed as an enhanced beta product of current installed Canteen Inventory
Management System (CIMS).

21
v PARTS OF THE PROPOSED SYSTEM
The application has three parts:
• Front-end
• Back-end
• Connectivity
When we use JAVA as software development tool, connectivity code is written as a part of
front-end code itself.
FRONT-END
It has been coded so as to provide maximum user friendliness and ease. Stress is laid on the
point that the user should type as minimum as possible. Most of the work is done in few
clicks. From each page, jumps to the other pages are provided.
These event-linked functions contain connection string (which connects front-end with
applications) and queries, which are executed when the corresponding event occurs.
BACK-END
Database is designed using Oracle. Our main databases required for this application are: stock
item details, customer details, & username and password details of customers.
All tables are normalized and do not have redundant or unwanted records.
CONNECTIVITY
A connection string is used to connect the queries written in front-end codes with the
database.
Provider used—sun.jdbc.odbc.JdbcOdbcDriver ()
Driver used—ODBC ORACLE XE driver connecting to Oracle in windows OS.

22
PERT CHART
Activity Time
Preliminary Investigation & Study 6 days
Feasibility Study 1 day
Proposed System Design & Analysis 5 days
Development of Prototype 9 days
System Design 4 days
Study of Languages (JAVA Script & Java Server Pages) 7 days
Coding 14 days
System Testing & Bugs Adjudication 14 days
Implementation & Evaluation 3 days
Maintenance none
Total Days 63 days

23
ANALYSIS
Analysis can be referred to as study of a problem and its division into smaller modules so as
to solve particular problem. A complete understanding of software requirements is necessary to
help the new software being developed succeed. No matter how well designed or well coded, a
poorly analyzed and specified program will disappoint the user and will also be a burden to
the developer. At this stage comes Requirement analysis that is a process of discovery,
refinement, modeling and specification. Models of the required data, information and control
flow are created. It bridges together the gap between system-level software allocation and
software design.
Software Requirement A n a l y s i s is divided into the following areas:

1. Initial Investigation (Problem recognition):
The first step of the development of system is the need of a new system. This might be a user
request to change, improve or enhance an existing system. This step Determine whether the
request is valid and feasible or not before improving or modifying the current system or build a
new one.
2. Determining the user’s Information Requirement (Evaluation & Synthesis):
At this stage, the user’s requirements are determined with the help of prototyping, asking
question and obtaining information from the existing system.
3. Problem Definition & Project Initiation:
Once the problem is clearly determined, the problem is defined in terms as to what is required,
how etc.

24
4. Background Analysis:
Once the project is initiated, the analyst begins to learn about the setting, the existing system
and the physical processes related to the revised system. All the background information is
collected and thoroughly studied. After obtaining background knowledge, the analyst begins
to collect data on the existing system, output, input and costs with the help of written
documents, on site observations, interviews and questionnaires.
5. Fact Analysis:
After gathering data, they must be organized and evaluated and conclusions drawn for preparing
a report to the users for final review and approval. At this stage, some tools are used i.e. data
flow diagrams, decision tables, structure charts etc.

25
In this project the following analysis is done:
1. Initial Investigation:
We saw that there were very few sites that could give complete information about air
management system to the users. Also there was a need to automate the entire system
2. Determination of user Requirements:
We contacted a number of people about this Project who agreed with the idea that this system
will help a lot many people rather that entire nation.
3. Problem definition & project initiation:
Problem definition is an initial investigation, which defines the problem that led to the user
request. It states the objectives the user is trying to achieve and the user wants to see. It gives
more stress on logical requirements than the physical requirements.
4. Fact Analysis:
All the data and information collected was organized to show how information flows and at
what stage, exactly what happens? For this we tried to explain this with the help of Data Flow
diagrams.

26
IMPLEMENTATION & CODING
IMPLEMENTATION PHASE
The implementation phase is less creative than system design. It is primarily concerned with
user training, site preparation, and file conversion. When the candidate system is linked to
terminals or remote sites, telecommunication network and test of the network along with the
system are also included under implementation.
During the final testing, user acceptance is tested, followed by user training. Depending on the
nature of the system, extensive user training may be required. Conversion usually takes place
about the same time the user is being trained or late.
In the extreme, the programmer is viewed as someone who ought to be isolated from other
aspects of the system development. Programming is itself design work, however. The initial
parameters of the candidate system should be modified as a result of programming efforts.
Programming provides a ‘reality test’ for the assumptions made by the analyst. Therefore, it is a
mistake to exclude programmers from the initial system design.

27
CODE SNIPPETS: A few important highlights of the code are unveiled below.
Ø JAVA imports for establishing connection:

<%@ page import="java.sql.*" contentType="text/html"%>
<%@ page import="java.io.*"%>
Ø Variables declared for connection:

<%!
Connection con;
ResultSet rs;
PreparedStatement pst;
%>
Ø Creating connection using “JdbcOdbcDriver”:

<%
String aUserName = request.getParameter("userName");
String aPassword = request.getParameter("password");
try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
con = DriverManager.getConnection("jdbc:odbc:dsnCIMS");
} catch (Exception ex) {
out.println(“Connection Error: ”+ ex);
}
%>

28
Ø Code for validating user login:

<%
try {
pst = con.prepareStatement("Select * from logIn " +
" where type='user'");
rs = pst.executeQuery();
session.setAttribute("userName", cUserName);
session.setAttribute("password", cPassword);
while (rs.next()) {
session.setAttribute("scNo", rs.getInt("smart_cardNo"));
if (cUserName.equals(rs.getString("userName")) &&
cPassword.equals(rs.getString("password"))) {
response.sendRedirect("CustomerLoggedIn.jsp");
}
}
response.sendRedirect("Sorry.jsp");
out.println("\nERROR: PLEASE Look into UserCheck.jsp\n" + ex);
}
%>
Ø Code for fetching & displaying the details of logged in customer:

<%
try {
int temp = Integer.parseInt(session.getAttribute("scNo").toString());
pst = con.prepareStatement("Select * from CustomerLoggedIn
where smart_cardNo= ?");
pst.setInt(1, temp);
while (rs.next()) {
29
%>
<td>
<%=rs.getString("personnelNo")%>
</td>
<td>
<%=rs.getString("cardHolderName")%>
</td>
<td>
<%=rs.getString("rank")%>
</td>
<td>
<%=rs.getString("contactNo")%>
</td>
<td>
<%=rs.getString("smart_cardNo")%>
</td>
<td>
<%=rs.getString("department")%>
</td>
<td>
<%=rs.getString("maritalStatus")%>
</td>
<td>
<%=rs.getString("cardIssueDate")%>
</td>
30
<td>
<%=rs.getString("cardValidityDate")%>
</td>
<%
}
out.println("\nERROR: DATABASE NOT FOUND! \n
PLEASE Look into CustomerLoggedIn.jsp\n" + ex);
}
%>
Ø A few java script functions’ highlights used for searching Items:
<script language="JavaScript">
function cart() {
if (window.XMLHttpRequest) {
// // code for IE7+, Firefox, Chrome, Opera, Safari
xmlhttp=new XMLHttpRequest();
} else {
// code for IE6, IE5
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.onreadystatechange=function() {
if (xmlhttp.readyState==4 && xmlhttp.status==200) {
document.getElementById("daba_cart").innerHTML="";
document.getElementById("daba_cart").innerHTML =
xmlhttp.responseText;
31
}
}
xmlhttp.open("GET","FillAddToCart.jsp?index=" + radioSelect.value, true);

xmlhttp.send();
}
function chintu() {
if (window.XMLHttpRequest) {
// // code for IE7+, Firefox, Chrome, Opera, Safari
xmlhttp=new XMLHttpRequest();
} else {
// code for IE6, IE5
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.onreadystatechange=function() {
if (xmlhttp.readyState==4 && xmlhttp.status==200) {
document.getElementById("daba2").innerHTML="";
document.getElementById("daba").innerHTML=xmlhttp.responseText;
}
}
xmlhttp.open("GET","Search.jsp?index=" + index.value + "&item=" +
item.value + "&category=" + category.value, true);
xmlhttp.send();
}
</script>

32
Ø System search used to lookup desired “item” in stock’s database:
<%
try {
pst = con.prepareStatement("Select * from Item ");
while (rs.next()) {
%>
<hr>
<tr>
<td>
<%=rs.getString("SNo")%>
</td>
<td>
<a href="BillGeneration.jsp?index=<% out.print(temp); %>">
<%=rs.getString("indexNo")%>
</a>
</td>
<td>
<%=rs.getString("itemName")%>
</td>
<td>
<%=rs.getString("ratePerUnit")%>
</td>
<td>
<%=rs.getString("quantity")%>
</td>
33
<td>
<%=rs.getString("salesTax")%>
</td>
<td>
<%=rs.getString("category")%>
</td>
</tr>
<%
}
out.println("\nERROR: PLEASE Look into Search.jsp \n " + ex);
}
%>

34
FLOW DIAGRAM

35
DATABASE
ER-DIAGRAM: The entity relationship diagram is shown on the next page.
Some of the attributes’ names are explained below.
• tax: it is of type NUMBER. It stores the numerical value of percentage of tax on a

particular item.
• category: it specifies whether the item belongs AFD or NON-AFD category.
• quantity: it represents the number of units available in the stock of each item i.e.,
ledger balance.
• cardValidityDate: It represents the last date up to which an employee possessing

his/her smart card can use for shopping purpose.
• type: it represents whether an employee is assigned administrative rights of CSD

Inventory Management System or is a customer.
• address: it stores the residential address of employee.
• shopLimit: it stores the upper limit (in INR) of amount up to which an employee
could shop each month. Upper limit is set as per organization’s policy.
• contactNo: it stores only on contact number per employee record.
• rank: it is the present designation of an employee.
• department: it is the department of organization where an employee is presently

working.
Meaning of rest of the attributes, entity sets and relationship sets are understood as per their
names.

36

37
TABLES:
There are total of five tables used for maintaining records.
Ø DDL commands using SQL for creating the tables are:
v For table “LogIn”: This table is used to store login-ID, login-password,

smart card number, smart card number’s pin number and type of user
logging session.
CREATE TABLE "LogIn"

( "username" VARCHAR2(30) NOT NULL ENABLE,
"password" VARCHAR2(30) NOT NULL ENABLE,
"smart_cardNo" NUMBER NOT NULL ENABLE,
"pinNo" NUMBER,
"type" VARCHAR2(10) NOT NULL ENABLE,
PRIMARY KEY ("smart_cardNo") ENABLE
)
v For table “CustomerLoggedIn”: This table store basic details of employee

which is used for the purpose of transactions.
CREATE TABLE "CustomerLoggedIn"

( "personnelNo" VARCHAR2(40) NOT NULL ENABLE,
"cardHolderName" VARCHAR2(50),
"rank" VARCHAR2(30),
"smart_cardNo" NUMBER NOT NULL ENABLE,
"contactNo" NUMBER,
"address" VARCHAR2(100),
"maritalStatus" VARCHAR2(20),
"department" VARCHAR2(50),
"officeAddress" VARCHAR2(100),
"cardIssueDate" DATE,
"cardValidityDate" DATE,
"shopLimit" NUMBER,
PRIMARY KEY ("personnelNo") ENABLE
)

38
v Table “Item”: This table maintains the available stock’s records.
CREATE TABLE “Item"

( "indexNo" VARCHAR2(10) NOT NULL,
"itemName" VARCHAR2(100),
"ratePerUnit" NUMBER,
"quantity" NUMBER,
"tax" NUMBER,
"category" VARCHAR2(10),
PRIMARY KEY ("indexNo")
)
v Table “SalesSummary”: This table maintains the log of all the successfully
completed transactions.
CREATE TABLE "SalesSummary"

( "personnelNo" VARCHAR2(4000) NOT NULL ENABLE,
"date_and_time" DATE NOT NULL ENABLE,
"indexNo" VARCHAR2(40),
"ItemName" VARCHAR2(100),
"QuantityPurchased" NUMBER,
"RatePerUnit" NUMBER,
"Amount" NUMBER,
"tax" NUMBER,
"TotalTax" NUMBER,
"TotalAmount" NUMBER,
"Category" VARCHAR2(10),

39
PRIMARY KEY ("personnelNo", "date_and_time")

ENABLE,
FOREIGN KEY ("personnelNo")
REFERENCES "CustomerLoggedIn"
("personnelNo") ENABLE
)
v Table “Temporary”: This table keeps temporary records of the selection of

items made by different (logged-in) users until transaction commits or
aborts.
CREATE TABLE "Temporary"

( "IndexNumber" VARCHAR2(40),
"ItemName" VARCHAR2(40),
"QuantityPurchased" NUMBER,
"RatePerPiece" NUMBER,
"Amount" NUMBER,
"TaxPercent" NUMBER,
"TotalTax" NUMBER,
"TotalAmount" NUMBER,
"Category" NUMBER,
"Userid" VARCHAR2(40),
PRIMARY KEY ("Userid") ENABLE,
FOREIGN KEY ("Userid")
REFERENCES "CustomerLoggedIn"
("personnelNo") ENABLE
)

40
Ø Snapshots of the tables designed using Microsoft Access:
v Table “LogIn”:
v Table “CustomerLoggedIn”:
v Table “Item”:

41
v Table “SalesSummary”:
v Table: “Temporary”:

42
OUTPUT SNAPSHOTS
CIMS MAIN PAGE:
LogInPage

43
ADMINISRATOR LOG-IN PAGE:

LogInPage=>Administrator

44
ADMINISTRATOR LOGGED-IN PAGE:
LogInPage=>Administrator=>AdministratorLoggedIn

45
CARD ISSUANCE PAGE:

LogInPage=>Administrator=>AdministratorLoggedIn=>CardIssuance

46
STOCK ENTRY PAGE:

LogInPage=>Administrator=>AdministratorLoggedIn=>

47
STOCK EDITING PAGE:

LogInPage=>Administrator=>AdministratorLoggedIn=>

48
CUSTOMER LOG-IN:
LogInPage=>Customer

49
CUSTOMER LOGGED IN PAGE:

LogInPage=>Customer=>CustomerLoggedIn

50
BILL GENERATION PAGE:

LogInPage=>Customer=>CustomerLoggedIn=>BillGeneration

51
ITEMS’ LIST PAGE:

LogInPage=>Customer=>CustomerLoggedIn=>BillGeneration=>ItemList

52
TESTING PHASE
Testing is the process of making sure that the programs perform the intended tasks. Once the
system is designed it should be tested for validity. During system testing, the system is used
experimentally to insure that the software does not fail, that means it will run according to
its specification and in the way users expect it to. The system is tested with special test data and
the results are examined for their validity. Some of the users may be permitted to operate on
the system so that the analyst can ascertain that the system can work in the specified
environment.
Test Details:
ü User Login Page Working
ü Database connection working
ü Item selection page working
ü Bill generation working
ü Updation of sales summary in data-base working
ü Logout session working
ü Administrator Login Page working
ü Administrator module working (with a few tabs disabled)

53
MAINTENANCE PHASE
After the installation phase is completed and the user staff is adjusted to the changes created by
the candidate system, evaluation and maintenance begin. Like any system, there is an aging
process that requires periodic maintenance of hardware and software. If new information is
inconsistent with the design specification, then changes have to be made. Hardware also
required periodic maintenance to keep in tune with design specification. The importance of
maintenance is to continue to bring the new system to standers.
User priorities, changes in organization requirements, or environmental factors also call for the
system enhancements. To contrast maintenance is done with enhancement.

54
CONCLUSION
The efficiently performing running application for electronic information retrieval and
deposition has been developed, which achieves the following goals:
ü User can change his/her login password.
ü User can search & select the item(s) from the available lost of stock items.
ü Present mode of payment is via cash or cheque due unavailability of extensive special
devices required for other modes of payment.
ü The application data-base is protected by security code.
ü Error free and fast record processing is possible.
ü Manager is provided with rights to search, add, delete and modify stock items’ list.
ü Manager is provided with rights to add, search & delete user details and login
details.
ü User can print report from any form (provided printer should be available)

55
LIMITATIONS
As such every project has some limitations so this project does. Limitations are mentioned
below.
Ø For successful implementation of the project, we should have a proper network system
where every transaction made should be updated in the server database. Inaccessibility
of internet/intranet.
Ø As this project deals with personal and important data thus requires every security.
Ø This project is limited to an Intranet Application thus is bound to an organization’s

building possessing the same intranet connections.
Ø Data encryption needs to be implemented.
Ø More features could be incorporated to facilitate employees additional services and easy
modes of payments.
Ø More features and rights could be incorporated in administrator module for implementing
new services for employees.

56
FUTURE ENHANCEMENTS
The following additions can be made in future to improve or upgrade the performance of the
application.
Ø Enhancing the application to implement tier 3 architecture by hosting this web

application on internet under D.R.D.O.’s domain.
Ø Allowing multilevel selections by implementing advanced search.
Ø Adding limpid application usage & directions so as to make it easily understandable by

new users.
Ø Allowing multilevel selections.

57
BIBLIOGRAPHY
Web sites:
1. www.w3schools.com
2. www.centerkey.com
3. www.java.sun.com
4. www.javaranch.com
Other:
Analysis of on the job Inventory Management System at CSD shop along with
operating staff.
_____________________________________ J _____________________________________
58

CSD Online Shopping &amp; Inventory Management System

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CSD Online Shopping &amp; Inventory Management System

Enviado por

Direitos autorais:

Formatos disponíveis

Project Report CSD Online Shopping and Inventory Management System

CSD Online Shopping &

Mayank Jaglan DCE

Abhishek Rana KIIT

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

Project Development life Cycle 7

2. DESIGN OF PRESENT SYSTEM 8

3. DESIGN OF PROPOSED SYSTEM 18

Melioration in present application software 18

Parts Of The System 21

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

5. IMPLEMENTATION & CODING 26

13. FUTURE PROSPECTS 57

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

CSD ONLINE SHOPPING &

30th July, 2010

Mrs. Alka Diwan,

Scientist-F & Additional Director,

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

purchases and issues, etc.

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

PROJECT DEVELOPMENT LIFE CYCLE

1. System project selection

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

DESIGN OF PRESENT SYSTEM

v STUDY OF PRESENT SYSTEM:

• Total Modules (divisions):

• Module under use in canteen under Salesman login (GROCERY BILLING

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

• Module under use in canteen under Manager login:

Brief explanation of modules under Manager Login:

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

D. Canteen Card Management:

E. Paper Card Management :

ii. Canteen Manager:

F. Approve Duplicate Bill Printing:

iii. OIC Liquor:

b. Ex-Servicemen and their Widows:

d. Silver Card, Issued to Canteen Manager for Preferred Guests:

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

e. Gold Card, Issued to Serving Generals and VIPs:

f. Bronze Card, Issued to Institutions, Mess, hospitals:

iv. Grocery Salesman:

E. Duplicate Bill Printing:

B. Transfer Damage Stock from Minibulk to Damage Stores

vi. Bulk Incharge:

B. Automated Issue Voucher Creation for Bulk to Minibulk Transfer

C. Automated Issue Voucher Creation with 0 Issue Quantity

E. Automated Demand Generation:

vii. Damage Store Incharge:

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

viii. Card Issuer:

ix. Gift Store In charge:

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

B. Data Transfer is required when Dependent Canteen has Extension Counter/s

C. From Extension Counter, data transferred to Main Canteen is

D. From Main Canteen to Extension Counter, data transferred is

• Processor: Intel Pentium IV, 3 GHz

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

• Standard Key Board & Mouse

• Database Used: DB2

CSD Online Shopping & Inventory Management System

CSD Online Shopping & Inventory Management System