DISTRIBUTOR MANAGEMENT SYSTEM PROJECT REPORT
PROJECT REPORT
PROJECT SOURCE CODE
FREE DOWNLOAD ALL THE PROJECT REPORTS WITH SOURCE CODE FROM HERE
A 1.2 ABOUT THE PROJECT
DISTRIBUTOR
MANAGEMENT SYSTEM is a web based application, which is
developed for a particular company for maintaining and analyzing the sales of
the product. This project is a module under website development for a
particular computer hardware company. Here all communications held through
internet and its database has all the updated information of the sales details.
The
main objective of the project is to analyze the sales of the products by a
manager through the details supplied by the distributors, sales managers and
representatives. It is very useful for the distributors, sales managers to know
about the sales of the products done by them and by others in particular
area/zone.
This system gives complete analysis
about the moving of the product in the market and the person responsible for
selling the product in that area. It is computerized to improve the efficiency
of the organization by reducing the cost of marinating data and minimizing the
time involved in handling the data.
Depending
on the access rights given the users can process different modules.
The modules are as follows
Ø Administrative
department
Ø Manager
department
Ø Distributors
department
Ø Sales
Managers department &
Ø Representatives
department
2. ABSTRACT/SYNOPSIS
DISTRIBUTOR
MANAGEMENT SYSTEM is a web based application, which is
developed for a particular company for maintaining and analyzing the sales of
the product. This project is a module under website development for a
particular computer hardware company. Here all communications held through
internet and its database has all the updated information of the sales details.
Depending on the access rights given the users can process different modules.
The
modules are as follows
Ø Administrative
department
Ø Manager
department
Ø Distributors
department
Ø Sales
Managers department &
Ø Representatives
department
Each module controls the lower modules with their given
rights.
The
main objective of the project is to analyze the sales of the products by a
manager through the details supplied by the distributors, sales managers and
representatives. It is very useful for the distributors, sales managers to know
about the sales of the products done by them and by others in particular
area/zone.
This system gives complete analysis
about the moving of the product in the market and the person responsible for
selling the product in that area. It is computerized to improve the efficiency
of the organization by reducing the cost of maintaining data and minimizing the
time involved in handling the data.
Administrative
department is the department which has veto rights in this project. This department
has the right to remove/add any persons from/to the system or can change any
product details from the database and can send mail to any person in the
system.
Managers department is the department
made to assist and to reduce the work load to the administrative department.
This department has no rights to change product details or add/remove persons
to/from the system. This department sets the targets to the distributors
department in monthly basics and to evaluate the distributors.
Distributors department has
distributors as its members. Each distributor has to submit their sales daily
via, a sales form. The distributor’s sets the target to the sales managers, in
weekly basics and evaluates their progress daily. The distributors cannot send
mail to the administrative department.
Sales Managers department has sales
managers as its members. Each sales manager has to submit their sales daily
via, a sales form. The sales manager sets the target to the sales
representative’s, in daily basics and evaluates their progress daily. The sales
managers cannot send mail to the administrative department nor to Managers
department.
Sales Representative’s department has
sales representative’s as its members. Each sales representative’s, has to
submit their sales daily via, a sales form. The sales representative’s, can
send mail only to the Sales Managers department.
3.
SYSTEM ANALYSIS - DISTRIBUTOR MANAGEMENT SYSTEM
System
analysis focuses on specifying what the system or application required to
do. It allows individuals see logical
elements (what the system should do) apart from the physical component it uses
(computers, terminals and storage system).
It is the process of gathering and interpreting facts, diagnosing
problem and using the information to recommend improvements to the system.
3.1 Existing System:
The existing system is the manual
system. The manual system is error
prone. It is time consuming. It is very difficult for a person to produce
report. There are chances for
manipulating the sales reports and changing it.
This system involves a lot of manual entries with the applications to
perform the desired task.
Limitations:
Ø Data
maintenance adopted by the present system is not accurate.
Ø Inaccurate
result in case of duplicating, delay and inconsistency in reporting.
Ø Generating
consolidated reports is more difficult in manual system and it may not be
consistent.
Ø The
transactions are very time consuming.
Ø There
is no facility for the users to know whether the data is entered is valid or
not. This disadvantage is the major
cause of errors in transaction.
Ø There
is inconsistency in maintaining data’s.
Ø No
global view ability of data’s.
Ø No
chance of knowing other members sales daily.
Ø It
is not user friendly.
3.2 Proposed System:
The proposed system is designed to
eliminate the drawbacks of the existing system.
It is designed by keeping in mind all the drawbacks of the present
system in order to provide a permanent solution to the problems. The primary aim of the new system is to
speedup transactions. The report is
prepared for the sales done by the representative and the distributor.
The representative code and
distributor code are validated. Accuracy for all the data entered is maintained
in the proposed system through validation and verification from all the
files. Verification of representative
code, distributor code, validation of records, etc., are performed with maximum
accuracy. In short, efficiency is
established. The advantages of this
system are
Ø User
friendliness is the keyword for all the new software in the market. The proposed system incorporates this concept
into itself to guide the user.
Ø At
every stage of data entry necessary comments and validation messages are
provided to the user.
Ø The
proposed system is also expected to reduce the amount of paper work
involved. The hard copies of only
necessary documents need to be taken
the rest can be avoided.
Ø Competitive
environment is developed with the publications of other members of same level.
Ø Good
communication is being held via mail options.
Ø Data’s
are maintained accurately via daily submission of sales details.
3.3
Need
For Computerization:
The
Project entitled “Distributor management System” was not computerized
previously. In this system, the information
about the sales and the progress of sales and the movement of the products in
the market cannot be noted easily. If these information’s are needed we need to
spend lot of time, money and energy.
If the company’s turn over has to be increased
then there is some need for experts ideas for that up to date information has
to supplied this is quite impossible in the present system.
If the
company wants to inform some important meeting/decisions, this process should
start before sometime before the actual happening. If some products are added
this too has to be informed individually for that quite some money has to be
spent.
Reports
cannot be created easily with much flexibility and with limited amount of time.
The head of the company cannot sit at a place and maintain the sales records
without much assistance.
Data
maintenance is quite tough when maintained manually. High level of data
redundancy exists.
3.4 Packages Selected:
Front End : Java Servlets
Web
Tools :
HTML
Web
Server : Java Web Server2.0
Validation : JavaScripts
Backend :MS-Access
3.5 Resource Required:
Processor : Pentium-s II
300 mhz
RAM : 64 MB
HARDDISK : 6 GB
KEYBOARD : 108
MOUSE : LOGITECH
FLOPPY DISK : 1.44MB
DISPLAY TYPE : EGA/VGA
SERIAL PORTS : 2F8/3F8
PARALLEL
PORTS : 15 (if need)
CACHE MEMORY : 512K
BASE MEMORY : 640K
EXTENDED
MEMORY :31744K
L2 CACHE TYPE :PIPELINE
3.6 Feasibility Study
Feasibility study is
the measure of how beneficial, the development of information system would be
to an organization, and it is mainly
Conducted
·
To determine whether
this is a new and better way to do the job thatwill be benefiting the end user.
·
To ascertain the cost
and savings of alternatives.
·
To recommend the best
of alternatives.
Unfortunately
the development of a computer-based system more likely to be plagued by a
scarcity of resources difficulty delivery dates. It is both necessary and prudent to evaluate
the feasibility of a project at the earliest possible time. When we talk about feasibility study we
concentrate our attention on four primary areas of interest:
1. Economic Feasibility
Economic
feasibility means an evaluation of development cost weighed against the
ultimate income or benefit from the developed system. The benefits of the system to users outweigh
the costs incurred during the system development. In addition, flexibility of
the system to incorporate further enhancements improves the performance to suit
the future needs of the user.
2.
Technical Feasibility
The
technical feasibility involves the study of the Hardware and software
requirements and if it is feasible to obtain the required parameters.
3.
Operational Feasibility
The
Proposed project is beneficial because it can be turned into a website that
will meet the user’s requirements. Since the request has been from the
administrator As well as from the users, it does not have any operational
barriers. So it is operationally
feasible.
3.7
Analysis of proposed system:
While analyzing the
proposed system, we should know the users recruitments and whether the system
needs these recruitments. The user can easily enter and retrieve the
all-available details. The system was developed by the user interaction manner.
The calculation and validation should be free from error and reports.
Advantage
over existing system:
This system provides
advantage like:
·
Data redundancy is
avoided
·
Data integrity is
maintained
·
Security is ensured
·
Report can be easily
generated so this system feasibility.
3.8 Normalization:
Normalization is nothing but in the database system we
have tables we may have to delete a record from the tables or update or modify
from the tables. But some times when we are trying to do those operations we
may get the incorrect answer or result or some error. The main reason for that
table is not normalized. Therefore Normalization is very important to develop
the software. Every software engineer must do the normalization before developing
the software. Therefore in this developed software the normalization is done in
order to avoid such a problem and redundancy of the records.
First
Normal Form
A
repeating group that is the reoccurrence of data item or group of record is
actually another relation. This can be removed from the record an treated as an
additional record structure or relation. A relational model does not permit or
support unnormalized tables.A relation scheme is said to be first normal (1NF)
if the values in the domain of attribute of the relation are atomic.
Second
Normal Form
The
second Normal form is achieved whenever the data item in record that is not
dependent on the primary key of the record should be removed from the table and
used in a separate table. A relation scheme
is said to be second normal form (2NF) if it is in the 1NF and if all nonprime
attributes are fully functionally dependent on the relation keys. A database
scheme is in second normal form if every relation scheme included in the
database scheme is in second normal form.
Third
Normal Form
A relation Scheme Ris in third
normal form(3NF) if for all nontrivial
functional dependencies in F+ of the form X->A(X is Super Key). A table is
said to be in third normal form if, it is in second normal form and every
non-key attribute is functionally dependent o just the primary key.
4. PROJECT DESCRIPTION
The project ”Distributor management system” deals with the process of managing
the distributors of a company. This
project consists of many modules like Administrative department, Manager
department, Distributor department, Sales manager department and Representative
department with their access rights as sub modules.
ADMINISTRATIVE
DEPARTMENT:
Administrative
department module is mainly for the administrator. The administrator monitors the whole sales
activities. The administrator is the one with veto rights. The administrator
has special rights to dismiss/add any person in this system, to remove/modify
the products details, to give target values, to change any ones addresses and
to view various reports for monitoring purpose.
Add Distributor/Sales
manager/Representative:
The
administrator gets the details of the persons to be added via mails from other
major modules. The details of Distributor, Sales manager, Representative are added in disp, smp, repp tables
respectively with correct userid and position ids.
Removal Distributor/Sales
manager/Representative:
The administrator removes
Distributor/Sales manager/Representative the system according to their
performance. The details of Distributor, Sales manager, Representative are deleted from disp, smp, repp
tables respectively by supplying their user ids.
Product details modification:
In
this sub module the product detail is modified via the product keys, if the
product key has to be changed the product key is send as session value. The
products can be added by specifying the required data’s. These data’s are
updated in the protab table according to the process for which it is called.
Mail Options:
In
this, the administrator can send mails to any person in the system. The subject
of the mails can be memo, target value, incentives, any advice or any required
subject. These data’s are stored in mop table with from, to, subject, date as
the fields.
MANAGER DEPARTMENT:
Manager
department is the module developed for assisting the
administrative department. This module has no veto rights, it just evaluates
the distributors and send details to the administrative module. The evaluation
is stored in the sales, reppo tables for report generation.
DISTRIBUTORS DEPARTMENT:
Distributors department has
distributors as its members. This module has the following as the sub modules
Mail options, Evaluation and User input form. Each distributor has to submit
their sales daily via, a sales form. The distributor’s sets the target to the
SALES MANAGERs., in weekly basics and evaluates their progress daily. The
distributors cannot send mail to the administrative department.
Mail options:
The
difference between the administrative department mail options and this mail
options is the distributor cannot send mail to the administrative department
but mails can be send to other persons in the system.
Evaluation:
This sub module is used for evaluating
the sales manger of a distributor on daily basis. This evaluation is done on
the comparison of target achieved and the target to be achieved. The
distributor supplies the current position of the sales manager and gives
comment on the performances; the comment may include incentives also. These
evaluations will be stored in the reppo table, since it will be displayed for
other sales mangers.
SALES MANAGERS DEPARTMENT:
Sales
Managers department has sales managers as its members. This module has the
following as the sub modules Mail options, Evaluation and User input form. Each
sales manager has to submit their sales daily via, a sales form. The sales
managers sets the target to the sales representative’s., in daily basics and
evaluates their progress daily. The sales managers cannot send mail to the
administrative department nor to Managers department.
Mail options:
The
difference between the distributors department mail options and this mail options
is the sales manager cannot send mail to the administrative department and to
manager department but mails can be send to other persons in the system.
Evaluation:
This sub module is used for evaluating
the representatives of a sales manger on daily basis. This evaluation is done
on the comparison of target achieved and the target to be achieved. The sales
manger supplies the current position of the sales manager and gives comment on
the performances; the comment may include incentives also. These evaluations
will be stored in the reppo table, since it will be displayed for other sales
mangers.
REPRESENTATIVE’S DEPARTMENT:
Representative’s
department has sales representative’s as its members. Each sales
representative’s., has to submit their sales daily via, a sales form. The sales
representative’s., can send mail only to the Sales Managers department.
5. DATABASE
DESCRIPTION - DISTRIBUTOR MANAGEMENT SYSTEM
Table Name:
logs
Field Name
|
Type
|
Constraint
|
usnm
|
Text
|
Unique
|
pass
|
Text
|
Not
null
|
cod
|
Text
|
Primary
key
|
pos
|
Text
|
Not
null
|
Table Name: protab
Field Name
|
Type
|
Constraint
|
pcod
|
Integer(11)
|
Primary
key
|
pnm
|
Integer(11)
|
Unique
|
pcost
|
Number
|
Not
null
|
Table Name:
disp
Field Name
|
Type
|
Constraint
|
dcod
|
Text
|
Primary
key
|
usnm
|
Text
|
Unique
|
pass
|
Text
|
Not
null
|
nm
|
Text
|
Not
null
|
add1
|
Number
|
Not
null
|
cit
|
Text
|
Not
null
|
sat
|
Text
|
Not
null
|
pin
|
Text
|
Not
null
|
email
|
Text
|
Not
null
|
smcod1
|
Number
|
Not
null
|
smcod2
|
Text
|
Not
null
|
area
|
Text
|
Unique
|
target
|
Text
|
Not
null
|
Table Name: smp
Field Name
|
Type
|
Constraint
|
dcod
|
Text
|
Foreign
key
|
smcod
|
Text
|
Primary
key
|
usnm
|
Text
|
Unique
|
pass
|
Text
|
Not
null
|
nm
|
Text
|
Not
null
|
add1
|
Text
|
Not
null
|
cit
|
Text
|
Not
null
|
sat
|
Text
|
Not
null
|
pin
|
Number
|
Not
null
|
email
|
Text
|
Not
null
|
r1
|
Text
|
Unique
|
r2
|
Text
|
Unique
|
area
|
Text
|
Unique
|
target
|
Number
|
Not
null
|
Table Name: repp
Field Name
|
Type
|
Constraint
|
dcod
|
Text
|
Foreign
key
|
smcod
|
Text
|
Foreign
key
|
rcod
|
Text
|
Primary
key
|
usnm
|
Text
|
Not
null
|
pass
|
Text
|
Not
null
|
rnm
|
Text
|
Not
null
|
dob
|
Text
|
Not
null
|
qua
|
Text
|
Not
null
|
add
|
Text
|
Not
null
|
cit
|
Text
|
Not
null
|
sat
|
Text
|
Not
null
|
pin
|
Number
|
Not
null
|
phn
|
Number
|
Not
null
|
email
|
Text
|
Not
null
|
area
|
Text
|
Unique
|
target
|
Number
|
Not
null
|
Table Name: sales
Field Name
|
Type
|
Constraint
|
cod
|
Text
|
Primary
key
|
dat
|
Text
|
Not
null
|
pos
|
Text
|
Not
null
|
ps1
|
Number
|
Not
null
|
ps2
|
Number
|
Not
null
|
ps3
|
Number
|
Not
null
|
Table Name: mop
Field Name
|
Type
|
Constraint
|
cod
|
Text
|
Primary key
|
from
|
Text
|
Not
null
|
to
|
Text
|
Not
null
|
sub
|
Text
|
Not
null
|
mes
|
Text
|
Not
null
|
dat
|
Date
|
Not
null
|
Table Name:
repo
Field Name
|
Type
|
Constraint
|
cod
|
Text
|
Primarykey
|
totsalpr
|
Text
|
Not
null
|
posi
|
Text
|
Not
null
|
pos
|
Text
|
Not
null
|
comt
|
Text
|
Not
null
|
dat
|
Date
|
Not
null
|
6. SOFTWARE DESCRIPTION
Overview of Servlets
Servlets
are modules that extend request/response-oriented servers, such as Java-enabled
web servers. For example, a servlet might be responsible for taking data in an
HTML order-entry form and applying the business logic used to update a
company's order database.
Servlets
are to servers what applets are to browsers. Unlike applets, however, servlets
have no graphical user interface.
Servlets
can be embedded in many different servers because the servlet API, which you
use to write servlets, assumes nothing about the server's environment or
protocol. Servlets have become most widely used within HTTP servers; many web
servers support Java Servlet technology.
Use Servlets instead of CGI Scripts!
Servlets
are an effective replacement for CGI scripts. They provide a way to generate
dynamic documents that is both easier to write and faster to run. Servlets also
address the problem of doing server-side programming with platform-specific
APIs: they are developed with the Java Servlet API, a standard Java extension.
So
use servlets to handle HTTP client requests. For example, have servlets process
data POSTed over HTTPS using an HTML form, including purchase order or credit
card data. A servlet like this could be part of an order-entry and processing
system, working with product and inventory databases, and perhaps an on-line
payment system.
Other Uses for Servlets
Here are a few of the many
applications for servlets:
Ø Allowing
collaboration between people. A servlet can handle multiple requests
concurrently, and can synchronize requests. This allows servlets to support
systems such as on-line conferencing.
Ø Forwarding
requests. Servlets can forward requests to other servers and servlets. Thus
servlets can be used to balance load among several servers that mirror the same
content, and to partition a single logical service over several servers, according
to task type or organizational boundaries.
The Servlet Life Cycle
Each servlet has the same
life cycle:
Ø A
server loads and initializes the servlet
Ø The
servlet handles zero or more client requests
Ø The
server removes the servlet
(some servers do this step only when they shut down)
(some servers do this step only when they shut down)
Initializing a Servlet
When
a server loads a servlet, the server runs the servlet's
init
method. Initialization completes
before client requests are handled and before the servlet is destroyed.
Even
though most servlets are run in multi-threaded servers, servlets have no
concurrency issues during servlet initialization. The server calls the
init
method once, when the
server loads the servlet, and will not call the init method again unless the
server is reloading the servlet. The server can not reload a servlet until after the
server has destroyed the servlet by running the destroy
method.
Destroying a Servlet
Servlets
run until the server destroys them, for example, at the request of a system
administrator. When a server destroys a servlet, the server runs the servlet's
destroy
method. The method is
run once; the server will not run the destroy
method again until after the server reloads and reinitializes the servlet.
When
the server calls the
destroy
method, another thread might be running a service request. The Handling Service
Threads at Servlet Termination lesson shows you how to provide a clean shutdown
when there could be long-running threads still running service requests.
Saving Client State:
Saving
Client State shows you how to use session tracking and cookies.
The Servlet API provides two ways to track
client state:
Session Tracking
Session
tracking is a mechanism that servlets use to maintain state about a series of
requests from the same user (that is, requests originating from the same
browser) across some period of time.
Sessions
are shared among the servlets accessed by a client. This is convenient for
applications made up of multiple All the servlets in the example have access to
the user's session.
To use
session tracking,
Ø Get
a session (an
Http Session
object) for
a user.
Ø Store
or get data from the
HttpSession
object.
Ø Invalidate
the session (optional).
Cookies
Cookies are a way for a
server (or a servlet, as part of a server) to send some information to a client
to store, and for the server to later retrieve its data from that client.
Servlets send cookies to clients by adding fields to HTTP response headers.
Clients automatically return cookies by adding fields to HTTP request headers.
Each HTTP request and
response header is named and has a single value. For example, a cookie could be
a header named
BookToBuy
with a value 304qty1
,
indicating to the calling application that the user wants to buy one copy of
the book with stock number 304. (Cookies and their values are
application-specific.)
Multiple cookies can have
the same name. In addition to a name and a value, you can also provide optional
attributes such as comments. Current web browsers do not always treat the
optional attributes correctly, so you should not rely on them.
A server can provide one or
more cookies to a client. Client software, such as a web browser, is expected
to support twenty cookies per host, of at least four kilobytes each
When you send a cookie to a
client, standard HTTP/1.0 caches will not cache the page. Currently, the
javax.servlet.http.Cookie
does
not support HTTP/1.1 cache control models.
To send a cookie,
1.
Instantiate a
Cookie
object
2.
Set any attributes
3.
Send the cookie
To get information from a cookie,
1.
Retrieve all the
cookies from the user's request
2.
Find the cookie or
cookies with the name that you are interested in, using standard programming
techniques
3.
Get the values of the
cookies that you found
JDBC
JDBCTM was
designed to keep simple things simple. This means that the JDBC API makes
everyday database tasks, like simple
SELECT
statements, very easy.
Establishing a
Connection
The
first thing you need to do is establish a connection with the DBMS you want to
use. This involves two steps: (1) loading the driver and (2) making the
connection.
Loading
Drivers
Loading the driver or drivers you want to use
is very simple and involves just one line of code. If, for example, you want to
use the JDBC-ODBC Bridge driver, the following code will load it:
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Your driver documentation will give you the
class name to use. For instance, if the class name is
jdbc.DriverXYZ
, you would load
the driver with the following line of code: Class.forName("jdbc.DriverXYZ");
You do not need to create an instance of a
driver and register it with the
DriverManager
because calling Class.forName
will do that for you automatically. If you were to create your own instance,
you would be creating an unnecessary duplicate, but it would do no harm.
Making
the Connection
The second step in establishing a connection
is to have the appropriate driver connect to the DBMS. The following line of
code illustrates the general idea:
Connection con = DriverManager.getConnection(url,
"myLogin", "myPassword");
This step is also simple, with the hardest
thing being what to supply for
url
. If you are using the JDBC-ODBC Bridge driver, the JDBC URL will start with jdbc:odbc:
. The rest of the
URL is generally your data source name or database system. So, if you are using
ODBC to access an ODBC data source called "
Fred,
" for example, your JDBC URL could be jdbc:odbc:Fred
. In place of
" myLogin
" you put the name you use to log in to the DBMS; in place of " myPassword
" you put your
password for the DBMS. So if you log in to your DBMS with a login name of
" Fernanda
" and a password of "
J8,
" just these two lines of code will establish a
connection:String url = "jdbc:odbc:Fred";
Connection con = DriverManager.getConnection(url, "Fernanda", "J8");
If you are using a JDBC driver developed by a
third party, the documentation will tell you what subprotocol to use, that is,
what to put after
jdbc:
in the JDBC URL. For example, if the driver developer has registered the name
acme as the subprotocol, the first and second parts of the JDBC URL will be jdbc:acme:
. The driver
documentation will also give you guidelines for the rest of the JDBC URL. This
last part of the JDBC URL supplies information for identifying the data source.
If one of the drivers you loaded recognizes
the JDBC URL supplied to the method
DriverManager.getConnection
,
that driver will establish a connection to the DBMS specified in the JDBC URL.
The DriverManager
class, true to its name, manages all of the details of establishing the
connection for you behind the scenes. Unless you are writing a driver, you will
probably never use any of the methods in the interface Driver
, and the only DriverManager
method you really
need to know is DriverManager.getConnection
.
The connection returned by the method
DriverManager.getConnection
is
an open connection you can use to create JDBC statements that pass your SQL
statements to the DBMS. In the previous example, con
is an open connection.
JavaScript:
JavaScript is an open scripting language that
anyone can use without purchasing a license developed by Netscape. JavaScript
may be considered a derivative of the programming language Java. Both are tools
for providing interactivity into web pages.
Ø A JavaScript is lines of executable
computer code.
Ø A JavaScript can be inserted into an
HTML page.
Ø JavaScript is supported by all major
browsers like Netscape and Internet Explorer.
Ø JavaScript can be used to validate data.
Ø JavaScript is a set of programming
commands and instructions that can be used to enhance the way the page looks, insert
or delete parts of a page's contents depending on system requirements, control
the operation of Web Server, communicate with a online database or perform any
task previously associated with CGI communications.
MICROSOFT
ACCESS
Using Microsoft Access, we can manage
all user information from a single database file. Within the file, divide the data into
separate storage containers called tables, view, add and update table using
online forms, find and retrieve just the data we want using queries, and analyze
or print data in a specific order using reports.
To want where data, create one table
for each type of information we track.
To bring the data from multiple tables
together in a query, form, or, a report, we define relationship between the
tables.
To find and retrieve just the data
that meets conditions we specify, including data from multiple tables, create a
query. A query can also update or delete
multiple records at the same time, and perform built-in or custom calculation
on data.
To easily view, enter and change data
directly in a table, create a form. When
we open a form, Microsoft access retrieves the data from one or more tables and
displays it on the screen using the layout we choose in the form wizard or
using a layout that we created from scratch.
The following drag-drop functionality
is now available in Microsoft Access:
Ø We
can drag and drop database objects between open Microsoft Access databases.
Ø We
can drag and drop Microsoft Access tables and queries into other applications,
such as Microsoft word and Excel.
Ø We
can create a table by dragging and dropping a range of cells from Microsoft
Access Excel Spreadsheet into Database window.
Microsoft
Access provides extensive features designed to help easily the Internet and
develop a World Web Application. You
need a web browser, such as Microsoft Internet Explorer, modem, Internet
connection or other network connection to access the Internet and take
advantage of some of these new features.
Ø Securing
and administering a database.
Ø Hide
database objects that you don’t want other user to see or open database window.
Ø Assign
a single password to control that can open a database instead of or in addition
to implementing user level security.
Ø Create
a query.
Microsoft Access can often create a
query for you so you don’t have to design one from search.
Ø To
create a query use the basis of a form or report, try the form or report
wizards. They create the form or
reports, and if it’s based on more than one table; they also create its
underlying SQL statements as a query.
Ø To
easily create queries that you want to run independently based on multiple
forms and reports, try one on query wizards.
Query wizard do all the basic work for you after you provide answers to
a series of questions. Even if you have
created many queries you may want to use a wizard to quickly design the
query. Then you can switch to design
view to customize it.
Ø To
create queries from filters you created using filter by form, Filter by
selection or filter for input, save filter as a query.
If none of these methods satisfies your
needs, you can create the query from scratch in query design view.
Java Web Server
Sun’s Java Web Server(JWS) was the
first commercial HTTP server to support servlets and should receive strong
consideration when selecting a Java-enabled Web Server.It is used to register
and invoke servlets using JWS.
ARCHITECTURAL
DESIGN
Dynamic
web applications are presented as a three-tier architecture, in which the Java
servlets play a key role in the business logic layer of the architecture.
Designing the application in layers, or tiers, is useful for many different
reasons. In a multiple tier design, each tier can be run a separate machine, or
machines, allowing for improved processing performance. Depending on the
design, multiprocessor machines, or many different independent computers can be
used to improve performance. Efficient layering can give structure to you
application, promote scalability, and ease long-term maintenance requirements for
your code.
First-Tier: Persistent Data Storage – The underlying
technology to implement this layer could be a variety of things including
cookies, server side files or databases.
Second-Tier: Business Logic Layer – This is where one
code any rules regarding the data stored and generally is the bulk of the
application.
Third-Tier: Presentation – Enables the user to see
the results of the business logic applied to the data stored.
HTML
HTML developed a few years ago as a
subset of SGML (Standard Generalized Mark-up Language) which is a higher-level
mark-up language that has long been a favorite of the Department of Defense.
Like HTML, it describes formatting and hypertext links, and it defines
different components of a document. HTML is definitely the simpler of the two,
and although they are related, there are few browsers that support both.
Because
HTML was conceived for transmission over the Internet (in the form of Web
pages), it is much simpler than SGML, which is more of an application-oriented
document format.
While it's true that many programs can
load, edit, create, and save files in the SGML format (just as many programs
can create and save programs in the Microsoft Word format), SGML is not exactly
ideal for transmission across the Internet to many different types of
computers, users, and browser applications. HTML is more suited to this task.
Designed with these considerations in mind, HTML lets you, the designer, create
pages that you are reasonably sure can be read by the entire population of the
Web. Even users who are unable to view your graphics, for instance, can
experience the bulk of what you're communicating if you design your HTML pages
properly.
At the same time, HTML is a simple
enough format (at least currently) that typical computer users can generate
HTML documents without the benefit of a special application. Creating a
WordPerfect-format document would be rather difficult by hand (including all of
the required text size, fonts, page breaks, columns, margins, and other
information), even if it weren't a "proprietary"-that is,
nonpublic-document format.
HTML is a public standard,
and simple enough that you can get through a book like this one and have a very
strong ability to create HTML documents from scratch. This simplicity is part
of a trade-off, as HTML-format documents don't offer nearly the precision of
control or depth of formatting options that a WordPerfect- or Adobe
PageMaker-formatted document would.
7. DATA
DICTIONARY - DISTRIBUTOR MANAGEMENT SYSTEM
The
data dictionary is an organized listing of all data elements that are pertinent
to the system, with precise, rigorous definitions so that both user and system
analyst will have a common understanding of inputs, outputs, components of
stores and even intermediate calculations.
Name
The
primary name of the data or control item, the data store or an external entity.
Alias--other names used for the first entry.
Where-used/how-used
A
listing of the processes that use the data or control item and how it is used
(e.g., input to the process, output from the process, as a store, as an
external entity).
Content-description
A
notation for representing content. Supplementary information--other information
about data-types, preset values (if known), restrictions or limitations and so
forth.
This system uses several data
elements for identifying the users. Here the user name and password is the
primary aspect such that each user is identified, beyond that his email-id,
address, phone no etc are used for future reference.
Importances of data
dictionary are as follows:
Ø To manage the details
Ø Communicate meaning
Ø Document System features
Ø Facilitate analysis
Ø Locate errors and omissions
logs
USNM :
user name
PASS :
user password
COD :
user identity
POS
: group identity
protab
PCOD : product code
PNM
: product name
PCOST
: product cost
disp
DCOD : distributor’s code
USNM : distributor’s name
PASS : password
NM : distributor’s name
ADD1 : distributor’s address
CIT : distributor’s city
SAT : distributor’s state
PIN : pin code of user
EMAIL : email-id of user
SMCOD1 : distributor’s sales manger code
SMCOD2 : distributor’s sales manger code
AREA : distributor’s area of
control
TARGET : distributor’s monthly target
smp
DCOD : distributor’s code
SMCOD : sales manager’s code
USNM : sales managers name
PASS : sales manager’s password
NM : sales managers name
ADD1 :
sales managers address
CIT : sales manager’s city
SAT : sales manager’s state
PIN : sales manager’s pin
code
EMAIL : sales manager’s email-id
R1 : sales manager’s sales
representatives
R2 : sales manager’s sales
representatives
AREA : sales manager’s area of
control
TARGET : sales manager’s weekly target
repp
DCOD : distributor’s code
SMCOD : sales manager’s code
RCOD : sales representative’s
code
USNM : sales representative’s name
PASS : sales representative’s
password
RNM : sales representative’s
name
DOB : sales representative’s
date of birth
QUA : sales representative’s
qualification
ADD : sales representative’s
address
CIT : sales representative’s
city
SAT : sales representative’s
state
PIN : sales representative’s
pin code
EMAIL : sales representative’s
email-id
AREA : sales representative’s
area of control
TARGET : sales representative’s daily
target
sales
COD : user’s code
DAT : sales date
POS : user’s position
PS1 : number of product of
first product sold
PS2 : number of product of
second product sold
PS3 : number of product of
third product sold
mop
COD : user’s code
FROM : mail sender’s name
TO : mail receiver’s name
SUB : subject of the mail
MES : message of the mail
DAT : date of the mail
repo
COD : user’s code
TOTSALPR : total sales by the user current day
POSI : position of the users
POS : group identity
COMT : comments of higher
authorities
DAT : date of report
9. DATA FLOW DIAGRAM - DISTRIBUTOR MANAGEMENT SYSTEM
A data flow diagram is a graphical
representation that depicts information flow and the transforms that are
applied as data move from input to output. The data flow diagram may be used to
represent a system or software at any level of abstraction.
In fact, DFD's may be partioned into
levels that represent increasing information flow and functional detail.
Therefore DFD provides a mechanism for functional modeling as well as
information flow modeling.
A level 0 DFD also called a fundamental system model or a
context model, representing the entire software element as a single bubble with
input and output data indicated by incoming and outgoing arrows, respectively.
Additional processes and information flow paths are represented as the level 0
DFD is partioned to reveal more detail. For example, a level 1 DFD might
contain five or six bubbles with interconnecting arrows. Each of the processes
represented at level 1 is a sub function of the overall system depicted in the
context model.
A DFD has the purpose of clarifying system requirements
and identifying major transformation that will become programs in system
design.
DFD Symbols:
In the DFD
there are four symbols.
1)
A square defines a source or destination of system data.
2)
An arrow identifies data-flow data in motion. It is a pipeline
through which information flow.
3)
A Circle represents a process that transforms incoming data
flows into outgoing data flow(s).
4)
An open rectangle is a data store — data at resent or a
temporary repository of data.
10. TESTING
Testing
is a process of verifying whether the system developed satisfies the
requirement specification given by the user.
Testing is essential at each and every step of software
development. The following are the important
steps in testing
1.
Construction of test data for the program
2.
Analysis of results to detect program errors.
3. Localization of errors and modification of
program to eliminate them i.e. debugging)
Types of Testing Done :
Unit
Testing :
Unit testing focuses verification
effort on the smallest unit of software design – the module. Using the design
description as a guide, important control paths are tested to uncover errors
within the boundary of the module . The relative complexity of tests and the
errors detected as a result is limited by the constrained scope established for
unit testing. The unit test is always white box –oriented, and the step can be
conducted in parallel for multiple modules.
Unit Test Considerations
The tests that occur as part of unit
testing are illustrated schematically in figure below. The module interface is tested to ensure that
information properly flows and out of the program unit under tests. The local
data structure is examined to ensure
that data stored temporarily maintains its integrity during all steps in an
algorithm’s execution. Boundary conditions are tested to ensure that all
modules operate properly at boundaries established to limit or restrict
processing. All independent paths
(basis paths) through the control structure are exercised to ensure that all
statements in a module have been executed at least once. And finally, all error – handling paths are tested.
Tests of data flow across a module
interface are required before any other test is initiated. If data do not enter
and exit properly, all other tests are moot. In this text on software testing,
Myers [MYE79] proposes a checklist for interface tests:
1. Numbering
of input parameters equal to number of arguments?
2. Parameters
and argument attributes match?
3. Parameter
and arguments units’ system match?
4. Number
of arguments transmitted to called modules equal to number of parameters?
5. Attributes
of arguments transmitted to called modules equal to attributes of parameters?
6. Units
system of arguments to call modules equal to units systems of parameters.
7. Number
attributes and order of arguments to built-in functions correct?
8. Any
references to parameters not associated with current point of entry?
9. Input
– only arguments altered?
10. Global
variable definitions considerations across modules?
11. Constraints
passed as arguments?
When
a module performs external I/O, additional interface tests must are conducted.
Again,
from Myers [MYE79].
1. File
attributes correct?
2. OPEN/CLOSE
statements correct?
3. Format
specification matches I/O statements?
4. Buffer
size matches record size?
5. Files
opened before use?
6. End
– of – line conditions handled?
7. I/O
errors handled?
8. Any
textual errors in output information?
The local data structure for a
module is a common source of errors. Test cases should be designed to uncover
errors in the following categories:
1. Improper
or inconsistent typing
2. Erroneous
initialization or default values
3. Incorrect
(misspelled or truncated ) values names
4. Inconsistent
data types Underflow, overflow, and addressing exceptions.
In
addition to local data structures, the impact of global data (e.g., FORTRAN
COMMON) on a module should be ascertained (if possible) during unit testing.
Selective
testing of execution paths is an essential task during the unit test. Test
cases should be designed to uncover errors due to erroneous computations,
incorrect comparisons, or improper control flow. Basis path and loop testing
are effective techniques for uncovering a broad array of path errors.
Among the more common errors in
computations are (1) misunderstood or in
correct arithmetic precedence, (2) mixed- mode operations, (3) incorrect
initialization, (4) precision inaccuracy, and (5) incorrect symbolic
representation of an expression. Comparison and control flow are closely
coupled to one another (i.e., change of flow frequently occurs after a
comparison). Test cases should uncover error such as (1) comparison of
different data types, (2) incorrect logical operators or precedence, (3)
expectation equality when precision error makes equality unlikely, (4) incorrect
comparison or variables, (5) improper or nonexistent loop termination, (6) failure to exit when
divergent iteration is encountered, and (7) improper modified loop variables.
Good design dictates that error conditions
be anticipated and error handling paths set up reroute or cleanly terminate
processing when an error occurs. Yourdon (YOU 75) calls this approach antibugging.
Unfortunately, there is a tendency to
incorporate error handling into software and then never test it.
Among the potential error that should be
tested when error handling is evaluated are:
1. Error
description is unintelligible.
2. Error
noted does not correspond to error handling.
3. Error
condition causes system intervention prior to error handling.
4. Exception
– condition processing is incorrect.
5. Error
description does not provide enough information to assist in the location of
the cause of the error.
Boundary testing is the last (and
probably most important) task of the unit test step. Software often fails at
its boundaries. That is, error often occurs when the nth element an
n-dimensional array is processed. When the ith repetition of a loop with I
passes is invoked; when the maximum or minimum allowable value is encountered.
Test cases that exercise data structure, control flow, and data values just
below, at, and just above maxima and minima are very likely to uncover errors.
Integration
Testing :
Integration testing involves
Bottom-up integration, Top-down integration and sandwich integration strategy.
Bottom-up integrations the traditional
strategy used to integrate the components of a software system into a
functioning whole. Bottom – up integration consist of unit testing followed b
subsystem testing, followed by testing the entire system. A subsystem consists
of several modules that communicate with each other through well-defined
interfaces. The primary goal of subsystem testing is to verify operations of
the interfaces between modules in a subsystem.
Top-down integration starts with the
main routine and one or two immediate subroutines in the system structure.
Sandwich integration is predominantly
top-down, but bottom up techniques are used on some modules and subsystems.
These alleviate many of the problems encountered in pure top-down integration
at the subsystem and system level. In this system sandwich integration testing
is carried out for its validation of the program units.
Acceptance
Testing :
Acceptance testing
involves planning and execution of functional tests, performance tests and
stress tests in order to demonstrate that the implemented system satisfies its
requirements.
Functional test causes involve
exercising the code with nominal input values for which expected results are
known. It is tested by giving different input values.
Performance testing determines the
amount of executing time spend in various paths of the program unit, program
throughput, the response time and device utilization by the program unit. With
respect to the system performance testing is based on the maximum volume of
existing data which the system can handle with an effective throughput and
efficient utilization of the system resources.
Software system is developed in the
above manner is one that satisfied the user needs, confirms to its requirements
and design specifications, and exhibits an absence of errors.
User Interface Testing :
At
the culmination of integration testing, software is completely assembled as a
package, interfacing errors have been uncovered and corrected, and a final
series of software tests – Validation testing – may begin. Validation succeeds
when the software functions in a manner that can reasonably expected by the
customer.
Validation
Test Criteria :
Software
validation is achieved through a series of black box tests that demonstrate
conformity with requirements. A test plan outline the classes of test to be
conducted and a test procedure defines specific test will be used to
demonstrate conformity with requirements.
After each validation test case been
conducted, one of two possible conditions exist (1). The function or
performance characteristics confirm to specification and or expected or (2) A
deviation form specification is and covered and deficiency list is created.
Deviation or error discovered at this stage in a project can rarely be
corrected prior to scheduled completion. It is often necessary to negotiate
with the customer to establish a method for resolving deficiencies.
ERROR MESSGAGES
Error Messages and warnings are “bad News” delivered to the
user’s iterative systems when something has gone away or wrong. Therefore in this developed software there
are some messages which will be displaying while using this developed software
if the user goes wrong. These messages are used to help the use for the better
use.
When the user enters the wrong password the
displayed message would be “Invalid Password ! Please try again. “. While
adding information for various modules no field should be empty when saving the information in the database
otherwise corresponding error messages are given immediately. While updating
the information if any field is left empty then the messages are displayed
accordingly like “Select the Task Title”, “Please Enter Numeric Values” etc.
Thus
these error messages are displayed in simple language in order to understanding
of the user not to increase the frustration.
Like this for all the modules in the project has been
tested by giving different input values and which has been compared with the
expected results with success.
In this project the
various types of testing are conducted as follows.
Performance
Testing
In this
testing, the amount of executing time is very less because, the coding has been
done in a java servlets and HTML has been used for the front end designing. So
that the execution time is less and the hit rate will be faster.
Validation testing
The
validation testing has been given wherever it is necessary and the appropriate
error message has been given. The example part is given below for both the
Client-side validation and Server-side validation.
11. IMPLEMENTATION PHASE
After testing
the system and find it successful to put the new system into operation. There are different techniques that can be
used to replace an existing system with the new system.
·
Direct Change Over
In this
technique the existing system is replaced by the proposed system after ensuring
that the system objectives are met. For
this application this method is adopted.
This software is successfully demonstrated to HSL organization.
·
Parallel run
The Proposed
system is put into operation in parallel to monitor the performance. The system has produced the expected results.
·
Pilot
In pilot run,
the system is tested with available results. The performance of the system is
studied with the latest data.
·
Staged change over
In this
technique, the proposed system is implemented in several stages. The existing system becomes unoperational if
all stages are successfully implemented.
13. CONCLUSION
The
system is developed for automating the activities involved in the sales done by
the company. The data maintenance and reports generated are compatible with the
daily activities of the department.
The main advantage of the system over
the existing system is the increase in the speed of information retrieval since
that data is maintained systematically and any type of information required for
the end user of the system can be generated easily.
This system is of vital use to the
sales incharge, to the distributor and to the representative also. They can very well know about the sales done
by them on a particular day or a month, between dates, in an area,…
Though
“Distributor Information System” is
so designed that not much amendment is required. This system has provisions for adapting to
future enhancements.
2 comments:
Thank you for this informative blog. We provide what is inventory management which helps you streamline and automate your distribution network, making the process more efficient and helps you in tracking the Goods Inventory and increasing visibility over the complete Supply Chain cycle right from the stage of receiving Sales Order to delivering the ordered goods and Payment Receipts.
This Distributor Management System (DMS) project report is a comprehensive and insightful exploration into an essential aspect of business operations. The systematic breakdown of the project highlights the dedication and expertise poured into its development.
The detailed analysis of the features and functionalities provides a clear picture of how the DMS contributes to effective distributor management. It's evident that careful consideration has been given to the challenges faced by distributors and how this system addresses them.
Moreover, the inclusion of real-world use cases and practical implementations adds immense value to the report. It not only validates the effectiveness of the DMS but also serves as a practical guide for businesses considering similar solutions.
I appreciate the effort put into this report, and it serves as a valuable resource for anyone interested in understanding the dynamics of distributor management in a digital age. Looking forward to more insightful content like this!
Post a Comment