CSD Online Shopping & Inventory Management System

Project Report CSD Online Shopping and Inventory Management System

CFEES, DRDO, Ministry of Defense, Timarpur, Delhi

1

CSD Online Shopping &

Inventory Management System

Submitted By:

Mayank Jaglan DCE

Abhishek Rana KIIT



2

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



3

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



4

14. BIBLOGRAPHY 58



5

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



6

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.



7

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.



8

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



9

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)



10

• 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.



11

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.



12

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.



13

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)



14

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.



15

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.



16

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.



17

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



18

• 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.



19

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



20

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)



21

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).



22

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.



23

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



24

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 Analysis 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.



25

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.



26

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.



27

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.



28

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);

}

%>



29

Ø 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()) {



30

%>

<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>



31

<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;



32

}

}

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>



33

Ø 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>



34

<td>

<%=rs.getString("salesTax")%>

</td>

<td>

<%=rs.getString("category")%>

</td>

</tr>

<%

}


out.println("\nERROR: PLEASE Look into Search.jsp \n " + ex);

}

%>



35

FLOW DIAGRAM



36

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.



37



38

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 )



39

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),



40

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

)



41

Ø Snapshots of the tables designed using Microsoft Access:

v Table “LogIn”:

v Table “CustomerLoggedIn”:

v Table “Item”:



42

v Table “SalesSummary”:

v Table: “Temporary”:



43

OUTPUT SNAPSHOTS

CIMS MAIN PAGE:

LogInPage



44

ADMINISRATOR LOG-IN PAGE:

LogInPage=>Administrator



45

ADMINISTRATOR LOGGED-IN PAGE:

LogInPage=>Administrator=>AdministratorLoggedIn



46

CARD ISSUANCE PAGE:

LogInPage=>Administrator=>AdministratorLoggedIn=>CardIssuance



47

STOCK ENTRY PAGE:

LogInPage=>Administrator=>AdministratorLoggedIn=>



48

STOCK EDITING PAGE:

LogInPage=>Administrator=>AdministratorLoggedIn=>



49

CUSTOMER LOG-IN:

LogInPage=>Customer



50

CUSTOMER LOGGED IN PAGE:

LogInPage=>Customer=>CustomerLoggedIn



51

BILL GENERATION PAGE:

LogInPage=>Customer=>CustomerLoggedIn=>BillGeneration



52

ITEMS’ LIST PAGE: LogInPage=>Customer=>CustomerLoggedIn=>BillGeneration=>ItemList



53

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)



54

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.



55

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)



56

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.



57

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.



58

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 _____________________________________

Documents

CSD Online Shopping & Inventory Management System