E-Billing and Invoice System

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 61

A Project Report

On

“E-BILLING AND INVOICE SYSTEM”


Submitted to
JMJ COLLEGE (AUTONOMOUS) ,TENALI

In partial fulfillment for the Award of Degree Of

Bachelor of Sciences

In

Computer Science

Submitted By
D.Likhitha Sri(J18A31251)

CH.Manaswini(J18A31246)

Sk.Ashabhi(J18A31211)

K.Sai Deepika(J18A31178)

UNDER THE GUIDANCE OF

Mrs. A.REVATHI

Department of Computer Science

JESUS MARY JOSEPH COLLEGE FOR WOMEN

(Affiliated to Acharya Nagarjuna University), Tenali


DECLARATION

This is to declare that the project entitled “E-BILLING AND INVOICE


SYSTEM”is a bonafide work carried out in the department of computer
science ,JMJ COLLEGE FOR WOMEN(Autonomous),Tenali, during the
academic year 2020-2021, in partial fulfillment for the award of the Degree
of Bachelor of Sciences in computer science.

D.Likhitha Sri(J18A31251)

CH.Manaswini(J18A31246)

Sk.Ashabhi(J18A31211)

K.Sai Deepika(J18A31178)

Place :

Date :
Department of Computer Science

JESUS MARY JOSEPH COLLEGE FOR WOMEN

(Affiliated to AcharyaNagarjuna University)

TENALI

CERTIFICATE

This is to certify that the dissertation entitled "VOICE BASED EMAIL


SYSTEM FOR VISUALLY IMPAIRED" is bonafide project work carried out
by bearing Name and Regd. No.D.Likhitha Sri(J18A31251), Ch.Manaswini
(J18A31246), Sk.Ashabhi(J18A31211),K.Sai Deepika(J18A31178) worked
under my supervision and submitted in partial fulfillment of the requirements for
the award of the degree of Bachelor of Sciences in Computer Science during
the Academic year 2020-2021.

INTERNAL HEAD OF DEPARTMENT

Mrs.A.Revathi Mrs. M.Asha Priya Darshini

EXTERNAL EXAMINER
ACKNOWLEDGMENT
Firstly I would like to convey my heartfelt thanks to Almighty for the blessings
on me to carry out this project work without any disruption. I am thankful to our
principal Dr.Sr.Shiny K.P for fostering an excellent environment in my college and
helping me at all points for achieving my task.

I am very much grateful to Mrs.A.Revathi, Lecturer and Mrs. M.Asha Priya Darshini
,Lecturer and H.O.D Department of Computer science, for their valuable guidance
which helped me to bring out this project successfully. His wise approach made me
learn the minute details of the subject. His matured and patient guidance paved the
way for completing my project with the sense of satisfaction and pleasure.

I am thankful to my project coordinator Mrs.A.Revathi, Lecturer in the Department of


Computer science for his valuable guidance which helped me to bring this project
successfully.

Finally I would like to convey my heartfelt thanks to my technical staff, for their
guidance and support in every step of this project. I convey my sincere thanks to all
the faculty and friends who directly or indirectly helped me for the successful
completion of my project.

Project Associate

D.Likhitha Sri(J18A31251)

CH.Manaswini(J18A31246)

Sk.Ashabhi(J18A31211)

K.Sai Deepika(J18A31178)
Abstract

E-billing and Invoice System is a Web Application which makes the business work easy. The E-
Billing and Invoice system is an excellent way to record details of the Customer in an easy and
efficient manner. This system replaces the current system where customer details and product
details are written manually with a pen and is given to the customer in the form of a Receipt.
With the help of E-Billing System, the customer details are recorded in a Computer and the
Computer generates an Invoice which contains the Products which Customer has bought and the
Invoice includes everything like when the purchase is made, what products are bought, Billed
amount etc. This e-Billing system is easy to use and doesn’t require huge amount of money to
Maintain
INDEX
1. Introduction

2. System Analysis

3. System Requirements Specification

4. System Design

5. Implementation

6. Testing

7. Screen Shots

8. Conclusion and Future Enhancements

9. Bibliography
1. INTRODUCTION

E-billing is the delivery of electronic bills to end consumers (B2C) and providing a payment
option for them and it can simply be explained as a technology which enables the replacement of
paper with electronic documents delivered through email or a website.

Telecommunication Billing is a process of collecting credit usage, aggregating it, applying


required charges and finally generating invoices for the customers. Telecom Billing process also
includes receiving and recording payments from the customers. The billing process involves
receiving billing records from various networks, determining the billing rates associated with the
billing records, calculating the cost for each billing record, aggregating these records periodically
to generate invoices, sending invoices to the customer, and collecting payments received from
the customer

What is E-Billing?

E-Billing s a method of sending bills and collecting electronic payments in which invoice are
given over the Internet and customers can pay electronically. E-Billing involves integrating
multiple systems including a billing system, banking system, a customer’s bank bill pay system,
and an online interface for the billing system.

E-Billing is most helpful for businesses that send recurring bills to customers.

What is an E-Bill?

Electronic bills, or E-Bills, are a paperless option for delivering a bill. Bills can be presented
either on a website or as an electronic document, such as a PDF file. This gives customers the
ability to review proposals before sending payment. Alternately, customers can set up automated
payments to pay without even touching a button.

E-Bills offer benefits to both Client and customers. Some of the numerous advantages from E-
Billing include:

 Low cost to deliver bills to customers


 Better security than paper and snail mail
 Option for automatic payments
 Fast payment delivery via ACH

E-Bills offer a win-win for customers and businesses. Because they are faster, convenient, less
expensive, and more secure, everyone involved benefits from electronic billing.

What is an electronic billing system?

Electronic billing systems are computer systems that assist with generating and delivering
invoices and accepting customer payments. The flow of an invoice through an automated billing
system typically follows this path:

1. Customer billing data is aggregated in a billing system.


2. Billing system generates customer bill.
3. Billing is passed to electronic billing system.
4. Bills are totaled and sent to customer online.
5. Customer receives new bill notification email.

There are two main types of electronic billing systems used for billing: biller-direct systems and
bank-aggregator systems.

As already noted, most utility companies allow customers to log in to the utility website to view
and pay bills.

Some bills can be merged into a bank’s bill pay system. In this case, users can log in to their bank
website and pay bills for several billers through the same interface. This is an example of bank-
aggregator systems.

Biller-direct and bank-aggregator are also known as electronic billing formats.

What is the difference between E-Billing and E-Invoicing ?

E-Billing and E-Invoicing have many similar aspects but are not entirely the same thing. E-
Invoicing is just sending invoices digitally, but the payment feature is not integrated as it is with
E-Billing.
True E-Billing also includes the ability to pay as well. On a utility or bank website, you can both
view the invoice and submit an electronic payment.

Project Scope

From an end-user perspective, the E-Billing and Invoicing Project consists of two functional
elements: an enhanced searchable database for customer, products, billing generation system and
a report generation system.

Customer, Products, Billing Generation

 An enhanced atomized system is developed to maintain Customer, Product, order, order


details data and produce Bill and invoice with following features.
 The system operator will be able to Add, Edit and search the product. Also, the operator
can delete the product; update the cost of the product as per the rights are given to the
operator by the administrator.
 By using their account, sales staff will be able to place orders through the system. Also,
sales staff will be able to apply discounts in accord with the current sales policy.
 Improved search capabilities of product information will be available; It will display all
the details of the particular product with current stock quantity.
 Prices and order information will be expressible in international currency and date/time
formats.
 After placing the order system automatically print the invoice with per-printed stationary
with all the details.
 Searching of the previously generated invoice is also available; Operator can search the
already saved invoice by system generated unique invoice no.
 Importing the old stock into the system, it introduces the old stock from predefined MS
Excel file.
 Maintain the user master and security features.
Report Generation System

A Report Generation system will be developed for the user and management of billing and
Invoicing System. This MIS system will have both details, and summary type reports for analysis
the sales volume, sales trend, available stock, The Windows-based MIS application will include
the following features:

 Billing summary report, it has the selection criteria for the date range.

 Stock Details and stock summary reports, It shows every detail of the stock and can be
used to monitor the sales pattern.

 All reports can be exported in different format includes Text File, CSV File, MS Excel,
MS Word File.

 All report can be printed from any printer.

 Bill and invoice can be printed on per-printed stationery.

Modules:

1. Manager.

2. SalesStaff.

3. Accountant.

1. Manager:

Manager can add the staff (sales staff and accountant), Manager can view the staff details and
manager can view the top buyers after login process.

2. Sales Staff:

Sales staff is authorized to sell product. Sale staff can view the available product.

For validation purpose, whether sales staff is valid or not, he/she should login.
3. Accountant:

Accountant can do following after login:

Add the product,

Update the available quantity,

View sales details

View top buyers.


2.SYSTEM ANALYSIS

2.1 Systems Development Life Cycle :

Systems Development Life Cycle (SDLC) adheres to important phase that are essential
for developers, such as planning, analysis, design, and implementation.

SDLC Methodology :

Although SDLC has different forms and models, it follows certain steps. These steps
could have the same name in one methodology but they are treated in a different manner or
could lead to something different. We will take a look at some of the common steps that you
will find in most methodologies in SDLC. There are SDLC models that have been created by
different developers. Some of them follow the standard steps in a model however; there are
those that prefer to create their own type of model. But whatever their model is, they should go
through these stages as these determine the outcome of the any SDLC model.
1. Planning – Everything starts with a concept. It could be a concept of someone, or everyone.
However, there are those that do not start out with a concept but with a question, “What do you
want?” they ask thousands of people in a certain community or age group to know what they
want and decide to create an answer. Establishes a high-level view of the intended project and
determines its goals.

2. Design – Once planning and arguing with the manager or the owner about the plan and
somehow convincing them, it is time to design or create a rough plan regarding the software.
Developers will work together and decide the initial specifics of the software to be created. They
will decide what platform or programming language to use, which will take care the coding of
a certain part of the software and even the time frame.

3. Implementation – The first two stages are quite common in all SDLC models. However,
things change starting on this stage. When the design and all the things that you need have been
laid out, it is time to work on the plan. Some developers, especially those that follow the
standard plan of developing software will work on the plan and present them for approval.

4. Testing – This could mean two things depending on an SDLC model. The first type of testing
is the actual testing by users. This is usually done in models wherein implementation does not
go with pre-testing with users. On the other hand, there are also testing that uses professionals
in the field. This testing is aimed in cleaning the software of all the bugs altogether. For software
that are set for public release, the software is first tested by other developers who were not in
charge in creating the software. They will weed out the bugs and suggest fixes if every they find
one. Once this stage is completed, it is time to test the software not just to the developers but to
actual users

5. Acceptance – When the software is released to be used by a certain company, acceptance


means the software is implemented as an added tool or could be replacing another software that
has been found too wanting after years of use. On the other hand, when the software is
implemented to the public a new software could be an added software for use. So developers
will always have a fighting chance in the market as long as they implement good software for
public use.
6. Maintenance – When the software is implemented, it does not mean that the software is good
as it is. All SDLC models include maintenance since there are absolutely no way that a software
will be working perfectly. Someone has to stay in the present software to take a look and ensure
the program works perfectly. When the software is implemented in public. Software companies
either set up a call center or an e-mail service to address the concerns of the consumer. As we
have indicated in previous chapters, Maintenance is quiet an easy task as long as the right food
and product is serve in an expected time frame. However, it is always a challenge when
something goes wrong. The whole team might not be there to help the developer so addressing
a major concern could never be answered.

These are the common steps in SDLC. Although they might have different versions,
they all end up with one thing: creating a software to make the world a better place. These six
steps could be even bigger or expanded depending on the SDLC model that has been followed
by different developers. These strategies were created by the same programmers and they sure
know that something is needed to be done to create better software.

Requirements :

This document play a vital role in the development of life cycle (SDLC) as it describes
the complete requirement of the system. It means for use by developers and will be the basic
during testing phase. Any changes made to the requirements in the future will have to go
through formal change approval process.

SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of
Software Development and Enhancement. This model was not the first model to discuss
iterative development, but it was the first model to explain why the iteration models.

As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase
starts with a design goal and ends with a client reviewing the progress thus far. Analysis and
engineering efforts are applied at each phase of the project, with an eye toward the end goal of
the project.

The steps for Spiral Model can be generalized as follows:


 The new system requirements are defined in as much details as possible. This usually
involves interviewing a number of users representing all the external or internal users and
other aspects of the existing system.

 A preliminary design is created for the new system.

 A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics of the
final product.

 A second prototype is evolved by a fourfold procedure:

1. Evaluating the first prototype in terms of its strengths, weakness, and risks.

2. Defining the requirements of the second prototype.

3. Planning an designing the second prototype.

4. Constructing and testing the second prototype.

 At the customer option, the entire project can be aborted if the risk is deemed too great.
Risk factors might involved development cost overruns, operating-cost miscalculation, or
any other factor that could, in the customer’s judgment, result in a less-than-satisfactory
final product.

 The existing prototype is evaluated in the same manner as was the previous prototype, and
if necessary, another prototype is developed from it according to the fourfold procedure
outlined above.

 The preceding steps are iterated until the customer is satisfied that the refined prototype
represents the final product desired.

 The final system is constructed, based on the refined prototype.

 The final system is thoroughly evaluated and tested. Routine maintenance is carried on
a continuing basis to prevent large scale failures and to minimize down time.
The following diagram shows how a spiral model acts like:

Fig 1.0-Spiral Model

Advantages :

 Estimates(i.e. budget, schedule etc .) become more relistic as work progresses,


because important issues discoved earlier.

 It is more able to cope with the changes that are software development generally
entails.

 Software engineers can get their hands in and start woring on the core of a project
earlier.
2.2 Existing System:

The client uses a Receipt Book to record details of the customer and takes the details of the
items bought and Fills it manually using a pen. This is an old Technique and isn’t preferable
these days. Moreover the records cannot be saved for future and if owner needs to search for
Previous Records it takes much time to search for all records and Increases burden. Hence to
solve all these problems, the e-Billing and Invoice System is Preferable to use.

2.2.1 Drawbacks of Existing System

 More man power.


 Time consuming.
 Consumes large volume of pare work.
 Needs manual calculations.
 No direct role for the higher officials.
 Damage of machines due to lack of attention.
To avoid all these limitations and make the working more accurately the system needs to be
computerized.

2.3 Proposed System:


The e-Billing and Invoice System is easy to use and Maintain. Client enters all the details
of the customer in the Software and an Invoice is generated containing all the Details of the
Purchase. The records can be saved for future and previous records can be easily viewed using
this System. All the records are stored in a Database. This System records all the details like
Date & Time of Purchase, Total Amount Paid, and Warranty for the Product, Items Purchased
etc. Hence this system is an excellent way to record Customer Details.

2.3.1 Advantages:

 Provides efficient way of managing business.


 Saves the time of customer as well as business employee also.
 More customer services can be provided compare to existing.
2.4 FEASIBILITY STUDY :

Feasibility study is made to see if the project on completion will serve the purpose of the
organization for the amount of work, effort and the time that spend on it. Feasibility study lets
the developer foresee the future of the project and the usefulness. A feasibility study of a system
proposal is according to its workability, which is the impact on the organization, ability to meet
their user needs and effective use of resources. Thus when a new application is proposed it
normally goes through a feasibility study before it is approved for development.

The document provide the feasibility of the project that is being designed and lists various areas
that were considered very carefully during the feasibility study of this project such as Technical,
Economic and Operational feasibilities. The following are its features:

2.4.1 TECHNICAL FEASIBILITY:

The system must be evaluated from the technical point of view first. The assessment of this
feasibility must be based on an outline design of the system requirement in the terms of input,
output, programs and procedures. Having identified an outline system, the investigation must
go on to suggest the type of equipment, required method developing the system, of running the
system once it has been designed.

Technical issues raised during the investigation are:

 Does the existing technology sufficient for the suggested one?


 Can the system expand if developed?
The project should be developed such that the necessary functions and performance are
achieved within the constraints. The project is developed within latest technology. Through the
technology may become obsolete after some period of time, due to the fact that never version
of same software supports older versions, the system may still be used. So there are minimal
constraints involved with this project. The system has been developed using Java the project is
technically feasible for development.
2.4.2 ECONOMIC FEASIBILITY

The developing system must be justified by cost and benefit. Criteria to ensure that effort is
concentrated on project, which will give best, return at the earliest. One of the factors, which
affect the development of a new system, is the cost it would require.

The following are some of the important financial questions asked during preliminary
investigation:

 The costs conduct a full system investigation.


 The cost of the hardware and software.
 The benefits in the form of reduced costs or fewer costly errors.
Since the system is developed as part of project work, there is no manual cost to spend for
the proposed system. Also all the resources are already available, it give an indication of the
system is economically possible for development.

2.4.3 BEHAVIORAL FEASIBILITY

This includes the following questions:

 Is there sufficient support for the users?


 Will the proposed system cause harm?
The project would be beneficial because it satisfies the objectives when developed and
installed. All behavioral aspects are considered carefully and conclude that the project is
behaviorally feasible.
3. System Requirements Specification

3.1 Introduction

A Software Requirements Specification (SRS) – a requirements specification for a software


system – is a complete description of the behavior of a system to be developed. It includes a set
of use cases that describe all the interactions the users will have with the software. In addition
to use cases, the SRS also contains non-functional requirements. Non-functional requirements
are requirements which impose constraints on the design or implementation (such as
performance engineering requirements, quality standards, or design constraints).

System requirements specification: A structured collection of information that embodies the


requirements of a system. A business analyst, sometimes titled system analyst, is responsible
for analyzing the business needs of their clients and stakeholders to help identify business
problems and propose solutions. Within the systems development life cycle domain, the BA
typically performs a liaison function between the business side of an enterprise and the
information technology department or external service providers. Projects are subject to three
sorts of requirements:

 Business requirements describe in business terms what must be delivered or


accomplished to provide value.

 Product requirements describe properties of a system or product (which could be one


of several ways to accomplish a set of business requirements.)

 Process requirements describe activities performed by the developing organization.


For instance, process requirements could specify specific methodologies that must be
followed, and constraints that the organization must obey.

Product and process requirements are closely linked. Process requirements often specify the
activities that will be performed to satisfy a product requirement. For example, a maximum
development cost requirement (a process requirement) may be imposed to help achieve a
maximum sales price requirement (a product requirement); a requirement that the product be
maintainable (a Product requirement) often is addressed by imposing requirements to follow
particular development styles

3.2 Purpose

An systems engineering, a requirement can be a description of what a system must do, referred
to as a Functional Requirement. This type of requirement specifies something that the delivered
system must be able to do. Another type of requirement specifies something about the system
itself, and how well it performs its functions. Such requirements are often called Non-functional
requirements, or 'performance requirements' or 'quality of service requirements.' Examples of
such requirements include usability, availability, reliability, supportability, testability and
maintainability.

A collection of requirements define the characteristics or features of the desired system. A 'good'
list of requirements as far as possible avoids saying how the system should implement the
requirements, leaving such decisions to the system designer. Specifying how the system should
be implemented is called "implementation bias" or "solution engineering". However,
implementation constraints on the solution may validly be expressed by the future owner, for
example for required interfaces to external systems; for interoperability with other systems; and
for commonality (e.g. of user interfaces) with other owned products.

In software engineering, the same meanings of requirements apply, except that the focus of
interest is the software itself.

3.3 FUNCTIONAL REQUIREMENTS

 The system should be the user friendly.

 The system should give the perfect search results to the users with in a minimum time.

3.4 NON-FUNCTIONAL REQUIREMENTS

The major non-functional Requirements of the system are as follows

1. Usability
The system is designed with completely automated process hence there is no or less user
intervention.

2. Reliability

The system is more reliable because of the qualities that are inherited from the chosen platform
java. The code built by using java is more reliable.

3. Performance

This system is developing in the high level languages and using the advanced front-end and
back-end technologies it will give response to the end user on client system with in very less
time.

4. Supportability

The system is designed to be the cross platform supportable. The system is supported on a wide
range of hardware and any software platform, which is having JVM, built into the system.

5. Implementation

The system is implemented in web environment. The apache tomcat is used as the web server
and windows xp professional is used as the platform.

6. Interface The user interface is based on HTML and XHTML.

Software Requirements:
Operating System : Windows XP/7/8

Language : Java, HTML

Technology : JDBC, Servlet, JSP

Scripting Language : Java Script

Web Server : Apache Tomcat6 / 7

Database : MYSQL 6.0


Hardware Requirements:
Processor : Pentium
RAM : 1GB
Hard Disk : 20 GB
Key Board : Standard Windows Keyboard
Mouse : Two or Three Button Mouse
Monitor : SVGA
4. System Design

4.1 System Specifications

Objectives :

The objective of this sub-project is to develop tools and methods to support the earlier
phases of systems development; for implementation independent specification and
verification, and for subsequent synthesis of specifications into efficient implementations.

The sub-project is divided into four sub-tasks:

i) Adopt/further develop a model for formal, high-level system specification and verification.

ii) Demonstrate the efficacy of the developed model by applying it to a suitable part of the
consortium demonstrator, the network terminal for broadband access.

iii) Develop a systematic method to refine the specification into synthesizable code and a
prototype tool which supports the refinement process and links it to synthesis and compilation
tools.

4.2 System Components:

The diagram shows a general view of how desktop and workstation computers are organized.
Different systems have different details, but in general all computers consist of components
(processor, memory, controllers, video) connected together with a bus. Physically, a bus
consists of many parallel wires, usually printed (in copper) on the main circuit board of the
computer. Data signals, clock signals, and control signals are sent on the bus back and forth
between components. A particular type of bus follows a carefully written standard that describes
the signals that are carried on the wires and what the signals mean. The PCI standard (for
example) describes the PCI bus used on most current PCs.

 KEYBOARD

 MOUSE

 JOYSTICK
 SCANNER

 SCANNING DEVICE

 DIGITIZING TABLET

 TOUCH-SENSITIVE SCREEN

 MICROPHON

4.3 UML DIAGRAMS:

Class Diagram:

Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements such as
classes, packages and objects. Class diagrams describe three different perspectives when
designing a system, conceptual, specification, and implementation. These perspectives become
evident as the diagram is created and help solidify the design.
Sequence Diagram:

Sequence diagrams belong to a group of UML diagrams called Interaction


Diagrams. Sequence diagrams describe how objects interact over the course of time through an
exchange of messages. A single sequence diagram often represents the flow of events for a
single use case.

Instance : An instance of a class shows a sample configuration of an object. On the sequence


diagram, each instance has a lifeline box underneath it showing it's existence over a period of
time.

Actor : An actor is anything outside the system that interacts with the system. It could be a
user or another system.

Message : The message indicates communication between objects. The order of messages from
top to bottom on your diagram should be the order in which the messages occur.
Use Case Diagram:

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral
diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical
overview of the functionality provided by a system in terms of actors, their goals , and any
dependencies between those use cases.

Actor : You can picture an actor as a user of the IT system, for example Mr. Steel or Mrs. Smith
from check-in. Because individual persons are irrelevant for the model, they are abstracted. So
the actors are called “check-in employee” or “passenger”:

Use Case : Use cases describe the interactions that take place between actors and IT systems
during the execution of business processes:

Relationships:

Association : An association is a connection between an actor and a use case. An association


indicates that an actor can carry out a use case. Several actors at one use case mean that each
actor can carry out the use case on his or her own and not that the actors carry out the use
case together:

Include Relationships : An include relationship is a relationship between two use cases:


It indicates that the use case to which the arrow points is included in the use case on the
other side of the arrow. This makes it possible to reuse a use case in another use case

Data Flow Diagrams:

A graphical tool used to describe and analyze the moment of data through a system
manual or automated including the process, stores of data, and delays in the system. Data Flow
Diagrams are the central tool and the basis from which other components are developed. The
transformation of data from input to output, through processes, may be described logically and
independently of the physical components associated with the system. The DFD is also know
as a data flow graph or a bubble chart.

DFDs are the model of the proposed system. They clearly should show the requirements
on which the new system should be built. Later during design activity this is taken as the basis
for drawing the system’s structure charts. The Basic Notation used to create a DFD’s are as
follows:
1. Dataflow: Data move in a specific direction from an origin to a destination.

2. Process: People, procedures, or devices that use or produce (Transform) Data. The physical
component is not identified.

3. Source: External sources or destination of data, which may be People, programs,


organizations or other entities.

4. Data Store: Here data are stored or referenced by a process in the System.
0-LEVEL DFD

For The Admin:

Details
UserID, pwd

Payment billing
Accountant
Admin System

Add ,delete

For the Accountant :

Details
UserID, pwd

Payment billing
students
Accountant System

Add ,modify
Level 1 DFD- Administrator

Administrator Registration details

User name, Password


View user details

Login Payment
billing View details
System salary

Add Solutions

Feedback

Level 1 DFD- Accountant :

Registration
User Registration

Username/Password

Username/Password
Login

Verify
Login

modify
modified
Modify
details
E-R DIAGRAMS:

In software engineering, an entity-relationship model (ERM) is an abstract and


conceptual representation of data. Entity-relationship modeling is a database modeling method,
used to produce a type of conceptual schema or semantic data model of a system, often a relational
database, and its requirements in a top-down fashion. Diagrams created by this process are called
entity-relationship diagrams, ER diagrams, or ERDs. The definitive reference for entity-
relationship modeling is Peter Chen's 1976 paper. However, variants of the idea existed
previously, and have been devised subsequently.

An entity may be defined as a thing which is recognized as being capable of an independent


existence and which can be uniquely identified. An entity is an abstraction from the complexities
of some domain. When we speak of an entity we normally speak of some aspect of the real world
which can be distinguished from other aspects of the real world. [3]

An entity may be a physical object such as a house or a car, an event such as a house sale or a car
service, or a concept such as a customer transaction or order. Although the term entity is the one
most commonly used, following Chen we should really distinguish between an entity and an
entity-type. An entity-type is a category. An entity, strictly speaking, is an instance of a given
entity-type. There are usually many instances of an entity-type. Because the term entity-type is
somewhat cumbersome, most people tend to use the term entity as a synonym for this term.

Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical


theorem.

A relationship captures how two or more entities are related to one another. Relationships can be
thought of as verbs, linking two or more nouns. Examples: an owns relationship between a
company and a computer, a supervises relationship between an employee and a department, a
performs relationship between an artist and a song, a proved relationship between a
mathematician and a theorem.

The model's linguistic aspect described above is utilized in the declarative database query
language ERROL, which mimics natural language constructs.
Entities and relationships can both have attributes. Examples: an employee entity might have a
Social Security Number (SSN) attribute; the proved relationship may have a date attribute.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes,
which is called the entity's primary key.

Entity-relationship diagrams don't show single entities or single instances of relations. Rather,
they show entity sets and relationship sets. Example: a particular song is an entity. The collection
of all songs in a database is an entity set. The eaten relationship between a child and her lunch is
a single relationship. The set of all such child-lunch relationships in a database is a relationship
set. In other words, a relationship set corresponds to a relation in mathematics, while a
relationship corresponds to a member of the relation. Certain cardinality constraints on
relationship sets may be indicated as well.
5. Implementation

Installation Step:

Step 1: Jdk1.6 Installation:

Step2: my eclipse Installation

Step 3: Tomcat Installation

Deployment Step:

Step 1: Start the my eclipse

Step2: click on File Menu Button and Select the Import option

Step 3: After that select general option and Click on Existing Project into Workspace

Step4: After that select the Browse Button and option the project and click on Finish Button

Step 5: Right click on project and select the Run as option

5.1 Sample Code :

import java.awt.*;

import javax.swing.*;

import java.awt.event.*;

import java.sql.*;

import javax.swing.border.*;

public class SeniorManagerLogon extends JFrame implements ActionListener

JMenuBar mb;

JMenu file,ca,report,csd,cd,dmd,csh;
JMenuItem
user,cpwd,exit,tc,woa,addcon,cln,acdcln,acd,modifycon,clc,nc,vc,vb,mc,vd,dw,id,cdaj,acd
aj,adj,adv,DatEnt,DatView,acdrep,colln,sop14,sop141a,sop142,sop143,sop144,sop145,sop
146a,sop146b,sop146c,sop146d,sop147a,sop147b,sop147c,sop148;

Connection con;

PreparedStatement stat;

JDesktopPane desktop;

public SeniorManagerLogon(String title)

super(" L T BILLING ");

try{

UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFe
el");

SwingUtilities.updateComponentTreeUI(this);

}catch(Exception ex)

System.out.println("Exception in LookAnd Feel");

String category=title;

desktop = new JDesktopPane();

mb = new JMenuBar();

file = new JMenu("OfficeAdministraton ");


user = new JMenuItem("Add User");

cpwd = new JMenuItem("Change Password");

exit = new JMenuItem("Exit");

file.add(user);

file.add(cpwd);

file.addSeparator();

file.add(exit);

ca = new JMenu(" ConsumerAdministration ");

nc = new JMenuItem("Add / Edit Consumer");

//addcon = new JMenuItem("Add New Consumer");

//nc.add(addcon);

vc = new JMenuItem("View Consumer Status");

vb = new JMenuItem("View Bill details");

//csd.add(modifycon);

//mc = new JMenuItem("MeterChange");

tc = new JMenuItem("Change Tariff");

clc = new JMenuItem("Connected Load Change");

cd = new JMenu("Cash Deposit ");

cdaj=new JMenuItem("C D adjustment");

acdaj=new JMenuItem("A C D");

id = new JMenuItem("Intrest on deposit");


cd.add(cdaj);

cd.add(acdaj);

cd.add(id);

woa = new JMenuItem("WalkOrderAssignment");

// DatEnt=new JMenuItem("Entering new consuer");

// DatView=new JMenuItem("View a consuer");

ca.add(nc);

ca.add(vc);

ca.add(vb);

// ca.add(mc);

ca.add(tc);

ca.add(clc);

ca.add(cd);

ca.add(woa);

//ca.add(DatEnt);

//ca.add(DatView);

dmd=new JMenu(" Demand ");

vd = new JMenuItem("Generate/edit Demand ");

dw = new JMenuItem("Demand Withdrawal");

adj = new JMenuItem("Demand Adjustments");

adv = new JMenuItem("Advance payment");


dmd.add(vd);

dmd.add(dw);

dmd.add(adj);

dmd.add(adv);

csh=new JMenu(" CASH ");

cln = new JMenuItem("Spot Bill Collection ");

csh.add(cln);

acdcln=new JMenuItem("ACD Collection ");

csh.add(acdcln);

report = new JMenu(" Report ");

acdrep=new JMenuItem("ACD Collection Report");

colln=new JMenuItem("Spot Bill Collecton Report");

sop14=new JMenu("Spot Bill Collecton Report");

sop141a=new JMenuItem("SOP 14 - IA");

sop142=new JMenuItem("SOP 14 - II");

sop143=new JMenuItem("SOP 14 - III");

sop144=new JMenuItem("SOP 14 - IV");

sop145=new JMenuItem("SOP 14 - V");

sop146a=new JMenuItem("SOP 14 - VI A");

sop146b=new JMenuItem("SOP 14 - VI B");

sop146c=new JMenuItem("SOP 14 - VI C");


sop146d=new JMenuItem("SOP 14 - VI D");

sop147a=new JMenuItem("SOP 14 - VII A");

sop147b=new JMenuItem("SOP 14 - VII B");

sop147c=new JMenuItem("SOP 14 - VII C");

sop148=new JMenuItem("SOP 14 - VIII ");

sop14.add(sop141a);

sop14.add(sop142);

sop14.add(sop143);

sop14.add(sop144);

sop14.add(sop145);

sop14.add(sop146b);

sop14.add(sop146a);

sop14.add(sop146c);

sop14.add(sop146d);

sop14.add(sop147a);

sop14.add(sop147b);

sop14.add(sop147c);

sop14.add(sop148);

mb.add(file);

mb.add(ca);

mb.add(dmd);
mb.add(csh);

mb.add(report);

report.add(acdrep);

report.add(colln);

report.add(sop14);

setJMenuBar(mb);

desktop.setBorder(BorderFactory.createCompoundBorder(BorderFactory.createMatte
Border(700,0,0,0,new
ImageIcon("pictures/peace.jpg")),BorderFactory.createBevelBorder(BevelBorder.LOWER
ED)));

getContentPane().add(desktop,BorderLayout.CENTER);

user.addActionListener(this);

cpwd.addActionListener(this);

nc.addActionListener(this);

vc.addActionListener(this);

vb.addActionListener(this);

// mc.addActionListener(this);

tc.addActionListener(this);

clc.addActionListener(this);

/*---*/ cdaj.addActionListener(this);

acdaj.addActionListener(this);

id.addActionListener(this);
vd.addActionListener(this);

dw.addActionListener(this);

adj.addActionListener(this);

adv.addActionListener(this);

cln.addActionListener(this);

acdcln.addActionListener(this);

acdrep.addActionListener(this);

colln.addActionListener(this);

sop141a.addActionListener(this);

sop142.addActionListener(this);

sop143.addActionListener(this);

sop144.addActionListener(this);

sop145.addActionListener(this);

sop146a.addActionListener(this);

sop146b.addActionListener(this);

sop146c.addActionListener(this);

sop146d.addActionListener(this);

sop147a.addActionListener(this);

sop147b.addActionListener(this);

sop147c.addActionListener(this);

sop148.addActionListener(this);
addWindowListener(new WindowAdapter(){

public void windowClosing(WindowEvent e)

System.exit(0);

});

if(category.equals(""))

{ // button enable

// button disable

else if(category.equals(""))

public void actionPerformed(ActionEvent e)

if(e.getSource() == nc)

DatEnt de=new DatEnt("Add / Edit Consumer");

desktop.add(de);
de.setVisible(true);

de.setSize(750,500);

else if(e.getSource() == user)

AddUser au = new AddUser("ADD USER");

desktop.add(au);

au.setSize(400,250);

//setLocation(400,400);

au.setVisible(true);

else if(e.getSource() == cpwd)

Chpwd chp= new Chpwd("CHANGE PASSWORD");

desktop.add(chp);

chp.setSize(420,270);

chp.setVisible(true);

else if(e.getSource() == vc)

DatView dv=new DatView("View Consumer Status");


desktop.add(dv);

dv.setVisible(true);

dv.setSize(750,500);

else if(e.getSource() == vb)

Billdetails bd = new Billdetails("BILL DETAILS");

desktop.add(bd);

bd.setVisible(true);

bd.setSize(900,550);

/*else if(e.getSource() == mc)

MeterChange mch = new MeterChange("Meter


Change");

desktop.add(mch);

mch.setSize(550,550);

mch.setVisible(true);

}*/

else if(e.getSource() == tc)

{
TariffChange w = new TariffChange("Tariff Change");

desktop.add(w);

w.setVisible(true);

w.setSize(600,550);

else if(e.getSource() == clc)

ConnectedLoadChange clch = new


ConnectedLoadChange("ConnectedLoadChange");

desktop.add(clch);

clch.setSize(550,550);

clch.setVisible(true);

else if(e.getSource() == cdaj)

Cdadj cdad = new Cdadj("C D Adjustment");

desktop.add(cdad);

cdad.setSize(600,550);

cdad.setVisible(true);

else if(e.getSource() == acdaj)


{

Acd acd = new Acd("Addl: C.D");

desktop.add(acd);

acd.setSize(400,550);

acd.setVisible(true);

else if(e.getSource()==id)

IntrestonDeposit id = new IntrestonDeposit("Intrest on Deposit");

desktop.add(id);

id.setSize(550,550);

id.setVisible(true);

else if(e.getSource() == vd)

Demand d = new Demand("DEMAND");

desktop.add(d);

d.setSize(880,550);

d.setVisible(true);

else if(e.getSource() == dw)


{

DemandWithdrawal wid = new


DemandWithdrawal("Demand Withdrawal");

desktop.add(wid);

wid.setSize(550,550);

wid.setVisible(true);

else if(e.getSource()==adj)

Ccadj cadj = new Ccadj("Current Charge Adjustment");

desktop.add(cadj);

cadj.setSize(600,550);

cadj.setVisible(true);

else if(e.getSource()==adv)

Ccadv ccad = new Ccadv("ADVANCE PAYMENT");

desktop.add(ccad);

ccad.setSize(400,550);

ccad.setVisible(true);

}
else if(e.getSource()==cln)

Collection c = new Collection("COLLECTION");

desktop.add(c);

c.setSize(400,550);

c.setVisible(true);

else if (e.getSource()==acdcln)

System.out.println("Entered ACDC");

AcdCollection acdc = new AcdCollection(" ACD COLLECTION


WINDOW");

desktop.add(acdc);

acdc.setSize(450,550);

acdc.setVisible(true);

else if (e.getSource()==acdrep)

System.out.println("Entered ACDreport");
ACDReport acdr= new ACDReport();

desktop.add(acdr);

acdr.setSize(600,550);

acdr.setVisible(true);

else if (e.getSource()==colln)

System.out.println("Entered collection report");

SBcollection sb = new SBcollection();

desktop.add(sb);

sb.setSize(600,550);

sb.setVisible(true);

else if (e.getSource()==sop141a)

System.out.println("Entered sop141a report");

SOPforteen sop14a= new SOPforteen();

desktop.add(sop14a);

//sop14a.setSize(600,550);

sop14a.setVisible(true);

}
else if (e.getSource()==sop142)

System.out.println("Entered sop142 report");

SOPforteen2a sop142= new SOPforteen2a();

desktop.add(sop142);

//sop14a.setSize(600,550);

sop142.setVisible(true);

else if (e.getSource()==sop143)

System.out.println("Entered sop143 report");

SOPforteen3 sop143= new SOPforteen3();

desktop.add(sop143);

//sop14a.setSize(600,550);

sop143.setVisible(true);

else if (e.getSource()==sop144)

System.out.println("Entered sop144 report");

SOPforteen4 a= new SOPforteen4();

desktop.add(a);
//sop14a.setSize(600,550);

a.setVisible(true);

else if (e.getSource()==sop145)

System.out.println("Entered sop145 report");

SOPforteen5 a= new SOPforteen5();

desktop.add(a);

//sop14a.setSize(600,550);

a.setVisible(true);

else if (e.getSource()==sop146a)

System.out.println("Entered sop146a report");

SOPforteen6a a= new SOPforteen6a();

desktop.add(a);

//sop14a.setSize(600,550);

a.setVisible(true);

else if (e.getSource()==sop146b)

{
System.out.println("Entered sop146b report");

SOPforteen6b a= new SOPforteen6b();

desktop.add(a);

//sop14a.setSize(600,550);

a.setVisible(true);

public static void main(String arg[])

{ SeniorManagerLogon ss = new SeniorManagerLogon("gf");

Toolkit tool = Toolkit.getDefaultToolkit();

Dimension d = tool.getScreenSize();

ss.setSize((int)d.getWidth(),(int)d.getHeight());

ss.setBackground(Color.white);

ss.setVisible(true);

//.setVisible(false);

}
6. SYSTEM TESTING

TESTING:

 The process of executing a system with the intent of finding an error.


 Testing is defined as the process in which defects are identified, isolated, subjected for
rectification and ensured that product is defect free in order to produce the quality
product and hence customer satisfaction.
 Quality is defined as justification of the requirements
 Defect is nothing but deviation from the requirements
 Defect is nothing but bug.
 Testing --- The presence of bugs
 Testing can demonstrate the presence of bugs, but not their absence
 Debugging and Testing are not the same thing!
 Testing is a systematic attempt to break a program or the AUT
 Debugging is the art or method of uncovering why the script /program did not execute
properly.

6.1 Testing Methodologies

 Black box Testing: is the testing process in which tester can perform testing on an
application without having any internal structural knowledge of application.
Usually Test Engineers are involved in the black box testing.
 White box Testing: is the testing process in which tester can perform testing on an
application with having internal structural knowledge.
Usually The Developers are involved in white box testing.
 Gray Box Testing: is the process in which the combination of black box and white box
tonics’ are used.
Levels of Testing:

Module1 Module2 Module3


Units Units Units

i/p Integration o/p i/p Integration o/p

System Testing: Presentation + business +Databases


UAT: user acceptance testing

Fig 11 STLC (SOFTWARE TESTING LIFE CYCLE)

Test Planning:
1. Test Plan is defined as a strategic document which describes
the procedure how to perform various testing on the total application in the most efficient
way.
2. This document involves the scope of testing,
3. Objective of testing,
4. Areas that need to be tested,
5. Areas that should not be tested,
6. Scheduling Resource Planning,
7. Areas to be automated, various testing tools used….
Test Development:
1. Test case Development (check list)
2. Test Procedure preparation (Description of the Test cases).
1. Implementation of test cases. Observing the result.
Result Analysis:
1. Expected value: is nothing but expected behavior Of application.
2. Actual value: is nothing but actual behavior of application
Bug Tracing: Collect all the failed cases, prepare documents.
Reporting: Prepare document (status of the application)

Types of Testing:
Smoke Testing: is the process of initial testing in which tester looks for the availability
of all the functionality of the application in order to perform detailed testing on them. (Main
check is for available forms)
Sanity Testing: is a type of testing that is conducted on an application initially to check
for the proper behavior of an application that is to check all the functionality are available before
the detailed testing is conducted by on them.
Regression Testing: is one of the best and important testing. Regression testing is the
process in which the functionality, which is already tested before, is once again tested whenever
some new change is added in order to check whether the existing functionality remains same.
Re-Testing: is the process in which testing is performed on some functionality which is
already tested before to make sure that the defects are reproducible and to rule out the
environments issues if at all any defects are there.
Static Testing: is the testing, which is performed on an application when it is not been
executed. Ex: GUI, Document Testing
Dynamic Testing: is the testing which is performed on an application when it is being
executed. Ex: Functional testing.
Alpha Testing: it is a type of user acceptance testing, which is conducted on an
application when it is just before released to the customer.
Beta-Testing: it is a type of UAT that is conducted on an application when it is released
to the customer, when deployed in to the real time environment and being accessed by the real
time users.
Monkey Testing: is the process in which abnormal operations, beyond capacity
operations are done on the application to check the stability of it in spite of the users abnormal
behavior.
Compatibility testing: it is the testing process in which usually the products are tested
on the environments with different combinations of databases (application servers,
browsers…etc) In order to check how far the product is compatible with all these environments
platform combination.
Installation Testing: it is the process of testing in which the tester try to install or try to
deploy the module into the corresponding environment by following the guidelines produced in
the deployment document and check whether the installation is successful or not.
Adhoc Testing: Adhoc Testing is the process of testing in which unlike the formal
testing where in test case document is used, with out that test case document testing can be
done of an application, to cover that testing of the future which are not covered in that test case
document. Also it is intended to perform GUI testing which may involve the cosmetic issues.

7. SCREEN SHOTS
Home Page:

Admin Login:

On Filling Incorrect Details:


On Filling Correct Details:

Create new accountant page :


8. Conclusion

The project titled as “E-Billing and invoice System” is a web based application. This software
provides facility for, create ,update and delete accountants details after login . it can search
branch wise accountant. And also search all candidates studying in the various branches and
can update and delete them The software is developed with modular approach. All modules in
the system have been tested with valid data and invalid data and everything work successfully.
Thus the system has fulfilled all the objectives identified and is able to replace the existing
system.

The project has been completed successfully with the maximum satisfaction of the
organization. The constraints are met and overcome successfully. The system is designed as like
it was decided in the design phase. The project gives good idea on developing a full-fledged
application satisfying the user requirements.

The system is very flexible and versatile. This software has a user-friendly screen that
enables the user to use without any inconvenience. Validation checks induced have greatly
reduced errors. Provisions have been made to upgrade the software.

10.1 Future Enhancement:

In future we can use photo reorganization instead of using heterogeneous database more over
High speed, accuracy and non-redundant data are the main advantages of the proposed system.
In the proposed system the user is provided with a choice of data screen, which are similar in
formats to the source documents. Data entry errors can be minimized through validity checks.
After the verification only the data are placed the permanent database. The software can be
developed further to include a lot of modules because the proposed system is developed on the
view of future, for example we should develop the system as a database independent using
JDBC so we can connect it to any other database, Now the proposed system is based on PC and
intranet but in the future if we need to convert it into internet then we need to change the front
end only because we are developing this on the basis of OOP technology and most of the
business logic’s are bounded in the class files and module like reusable components.
9. BIBLIOGRAPHY

BOOKS:
 Charles Hampfed (2000) ‘Instant Java Server Pages’ University of Toronto
 Herbert Schildt (2000) ‘Java Complete Reference’ Tata McGraw Hill
 John Zukowski (2000) ‘Mastering Java2’ BPB Publications
 Jamie Jaworsky ‘J2EE Bible’ Techmedia
 Stefen Denninger ‘Enterprise Java Beans-2.1’ Author’s Press
 Ian Somerville ‘Software engineering’
 Rajeev mall ‘Software engineering’
 Elmasri Navathe ‘Fundamentals of database systems’
ONLINE REFERENCE:

 www.java.sun.com
 www.w3schools.com
 www.wikipedia.com

You might also like