Sales (Final RPT)

TABLE OF CONTENTS
SECTIONS
• Introduction.
o Objectives of the Project.
• System Analysis
o Identification Of The Need
o Preliminary Investigation
o Feasibility Study
 Technical Feasibility
 Economical Feasibility
 Operational Feasibility
• Software Requirement Specification
• Design
o Data Flow Diagram (DFD)
o Menu Flow Diagram
o Database Design
• Screens & Validation Checks
• Reports
• Coding
• Limitations
• Bibliography
SECTION 1
INTRODUCTION
1.1 Objectives OF the Project

OBJECTIVES OF THE PROJECT
SALES MONITORING
Introduction:
There is a company manufacturing electronic items for selling. Very frequently they have
to do sales analysis, product analysis and salesman analysis.
Objective:
This project does the complete automation of sales monitoring

system .It Maintain Item Detail ie. Which Items are available and in
how much Quantity . The Salesman Records are maintained and their
performance is measured . Reports generated shows clewr picture of
ongoing business , the reports shows analysis of Sales and analysis of
Salesman Performance .
Key feature of the System : -
Software keeps track of :-
0 First block keeps a track of all the Sales Man and Items
1 Second block keeps a track of all the Sales Order and Item Details
2 Third block keeps a track of Report generation
SECTION 2
SYSTEM ANALYSIS
2.1 Identification Of The Need
2.2 Preliminary Investigation
2.3 Feasibility Study
2.3.1 Technical Feasibility
2.3.2 Economical Feasibility
2.3.3 Operational Feasibility
SYSTEM ANALYSIS
Identification of Need:
This step is initiation of System Analysis. An overview of the client’s requirement has
been done. The basic need of the client to opt for such kind of project is analyzed.
As per current marketing scenario, an entire system was required to track day-to-day
transactions, alarming for stock and defaulters, and timely generation of reports is the
basic features of this project.
Preliminary Investigation:
The have to keep records of their employee details, their payment details, advance
payment details.
Different Modules In Computerized System:
Module 1: Item Module

In this module, Member enters a password and the software checks its
validity. If the password is valid then he is allowed to enter, otherwise “Invalid
User/Password” message is displayed. Different data access rights are
assigned to different users. A new member can also be registered in this
module. Proper database of all the Items Available is maintained including
their Name, Rate and quantity in hand.
Module 2 Sales Man Module

In this module database of all the Salesman of companies, their joining date
is maintained
Module 3 Sales Module

This module takes care of Sales Order generation of each sale, the
salesman which has done the sale and the Item sold is recorded.
Module 4 Report Generation

In this section administrator can view all the reports related to sales
analysis and Salesman analysis.
Feasibility Study:
Depending on the results of the initial investigation, the survey is expanded to a

more detailed feasibility study. Feasibility study is a test of system proposal
according to its workability, impact on the organization, ability to meet user
needs, and effective use of resources.
The objective of the feasibility study is not to solve the problem but to acquire
a sense of its scope . During the study, the problem definition is crystallized and
aspects of the problem to be included in the system are determined.
Consequently, costs and benefits are described with greater accuracy at this
stage.
It consists of the following:
1. Statement of the problem: A carefully worded statement of the

problem that led to analysis.
2. Summary of finding and recommendations: A list of the major

findings and recommendations of the study. It is ideal for the user who requires
quick access to the results of the analysis of the system under study.
Conclusion are stated , followed by a list of the recommendation and a
justification for them .
3. Details of findings : An outline of the methods and procedures under-

taken by the existing system, followed by coverage of the objectives and
procedures of the candidate system. Included are also discussions of output
reports, file structures, and costs and benefits of the candidate system.
4. Recommendations and conclusions: Specific recommendations

regarding the candidate system, including personnel assignments, costs, project
schedules, and target dates.
1) Technical Feasibility:
This involves financial considerations to accomodate technical enhancements. If
the budget is a serious constraint, then the project is judged not feasible. In the
proposed system only the cost of developing and maintaining the application will
be taken into consideration by the company. There is no need for any special
hardware.
2) Economical Feasibility:
With the help of this application it will lead to decrease in cost of opening and
maintaining offices which will be more than the cost of developing and
maintaining the Application . Lesser manpower is needed to maintain a
application than a branch office which will again lead to decrease in cost.
3) Operational Feseability:
This Application is very easy to operate as it is made user friendly . Main consideration
is user’s easy access to all the functionality of the Application.
SECTION 3
SOFTWARE REQUIREMENT SPECIFICATION

PROJECT PLANNING
I was assigned the duty for developing a computerized system known as “Sales Order
System”. Working in team reinstates the team for some common guidelines and
standard to be followed by all the team members across all team. For the optimum use
of practical time it is necessary that every session is planned. Planning of this project will
include the following things:
0 Topic Understanding.
1 Modular Break –Up Of The System.
2 Processor Logic For Each Module.
3 Database Requirements.
Topic Understanding:
It is vital that the field of application as introduced in the project may be totally a new
field. So as soon as the project was allocated to me, I carefully went through the project
to identify the requirements of the project.
Modular Break –Up Of The System:

Identify The Various Modules In The System.
List Them In The Right Hierarchy.
Identify Their Priority Of Development.
Description Of The Modules:
Modules – This project consists of different interfaces which will be accessed through
a MDI (Multiple Document Interface) window. Different modules that
makeup this system are briefly described below:
Module 1: Item Module

In this module, Member enters a password and the software checks its
validity. If the password is valid then he is allowed to enter, otherwise “Invalid
User/Password” message is displayed. Different data access rights are
assigned to different users. A new member can also be registered in this
module. proper database of all the Items Available is maintained including
their Name, Rate and quantity in hand .
Module 2 Sales Man Module

In this module database of all the Salesman of companies, their joining date
is maintained
Module 3 Sales Module

This module take care of Sales Order generation of each sale, the
salesman which has done the sale and the Item sold is recorded .
Module 4 Report Generation

In this section administrator can view all the reports related to sales
analysis and Salesman analysis.
Database Requirements:
 Identify The Various Tables Required.

 Fields For These Tables.
 The Various Key Fields (for example Primary key and Foreign key).
 Identify The Various Constraints like Not Null, Unique etc.
Software/Compilers Required Developing This

System:
Software means a collection of program where the objective is to enhance the

capabilities of the hardware machine.
The following paragraph defines the software of the proposed system
development.
Operating System : Win 98
Front end Tool : MS VB 6.0 (Enterprise
Edition)
Data Access Technology : ADO 2.1 (ActiveX Data
Object)
Reports : Data Report
Back end : MS-Access
Hardware Environment
Hardware is the term given to machinery itself and to various individual pieces of
equipment. It refers to the physical devices of a computer system. Thus the input,
storage, processing control and output devices are hardware.
Processor : Pentium-IV
RAM : 128 MB
HDD : 40 GB
FDD : 1.44 MB
CD-ROM : 52 X
Monitor : 14 inches Color Monitor
Keyboard : 104 Keys Keyboards
Printer : HP DeskJet 670 C
SECTION 4
DESIGN
4.1 Data Flow Diagram (DFD)
4.2 E-R Diagram
4.3 Menu Flow Diagram
4.4 Database Design

Analysis and Design:
Menu Flow Diagram
Main
Menu
Master Report Exit

s s
Clos
e
Sales SalesM
Salesm Ite Sale Analysis an
an Analysi
m s
The Entity-Relationship Approach

The entity-relationship approach consists of an analytical method and a modeling
technique. The entity-relationship (ER) approach was first described by Dr. Peter Chen
in a paper which appeared in the first issue of the ACM publication, Transactions on
Database Systems in 1976. It is now recognized as one of the most important tools in
the data administration tool kit. It is incorporated in various forms, into all major CASE
tools, and is supported by all dictionaries, repositories and encyclopedias. Properly
understood and used, the ER approach can greatly reduce the time needed during the
analysis phase of the development cycle and at the same time greatly increase both the
accuracy and completeness of that analysis. With only a few exceptions all popular
development methodologies use the ER approach to model data.
Most popular analytical approaches, or methodologies, focus either on the processes
being performed or on data elements presumed to be needed by the user. Some
concentrate on trying to fit lists of data elements into one of the data structure models
which can be implemented by a DBMS, others on designing reports, screens, and files,
and still others on following trails of transactions through the various processing stages.
From these processes, flows, data elements, and/or outputs, they attempt to re-create
the real world. Many attempt to recreate the processes from the desired results.
Each method approaches the data problem differently, and their results, many times,
resemble the results of the blind men who examined the elephant: the one examining
the tail thought it felt like a rope, the one examining the sides thought it felt like a wall,
the one examining its legs thought it felt like a tree, and the one examining its trunk
thought it felt like a snake. In a sense they were all right, but, at the same time, none
was right.
In the business environment, examining only transactions, processes, outputs, or data
flows, or even a combination of all four, produces a picture which is correct as far as it
goes, but which is not a true or complete picture of the environment. The business
environment is also populated by people using things, and both people and things are
located in places. Any business description must not only include these people, places,
and things, but it must also start with them. These people, places, and things are called
entities. These entities interact with each other in various ways, and those interactions
are called relationships.
People, either individually or in groups, work with things or provide services for other
people. Since both the people and the things are real (they physically exist), they must
be described and they must be located somewhere (in some place). Additionally,
relationships which exist between people and things, people and places, things and
places, different types of things, different types of places, and different types of people
themselves must be described.
These entities may be well defined, in that the firm may know a great deal about them,
or they may be vaguely defined, in that the firm may know very little about them. In
some cases, such as with either prospective customers or employees, the firm may only
know or suspect that they exist, but not who or where they are.
These entities may exist in large homogeneous groups where all members are capable
of being described in the same manner, or they may be fragmented into many different
subtypes, each with descriptions which are either slightly different, or in some cases
radically different, from other members of the same group.

Just as entities are real so are the relationships that exist between them. And as with
entities, the relationships may be well defined in that the firm may know a great deal
about them, or vaguely defined in that the firm may know very little about them, as little
as first knowing or suspecting that they exist.
The power of the ER approach lies in its ability to focus on describing entities of the real
world of the business and the relationships between them. By describing real world
entities through the identification and assignment of attributes to them and their
relationships, the analyst is describing how and why the business operates.
Although the business itself may change, sometimes dramatically, these types of
changes occur much less frequently than changes in the routine processes and
activities. Regardless of how the business changes, the entities of the business rarely
change. What may change, however, is the firm's perception of which attributes of those
entities are currently of interest. Some relationships between these business entities
may also change, but even these relationship changes occur infrequently. Thus by
understanding and properly describing these entities and the relationships between
them, the analyst can form a very stable foundation for understanding and analyzing the
business itself, and for properly recording the results of, or changes caused by, the
processes of the business.
As with any analytical method, the effectiveness of the ER approach is limited, or
constrained, by three factors, all of which have to do with the analyst's understanding of
the business environment. These closely related factors are (1) entity identification, (2)
entity definition, and (3) business context.

Entity identification consists of recognizing the various entities, determining why they are
of interest to the firm, and naming them. The identification process must specify the
entity at the precise level of specificity which ensures that it is not so general as to be
meaningless, and yet not so specific that it fragments into too many subsets. For
example, people as an entity would be too general since it includes both customers and
employees, among others. On the other hand, full-time employees and part-time
employees would be too specific since both are employees and "full-time" and "part-
time" are attributes of employee.
Entity definition consists of identifying which attributes of the identified entities are
needed by the firm and why those attributes are of interest. For example, is the firm
interested in the attribute "hobbies" or "clothing sizes" for the employees? If the firm
deals in sporting goods, the answer to the former might be yes. If the firm provides
uniforms for its employees, the answer to the latter might also be yes.
Business context involves identifying and defining the relationships which exist between
the identified and defined entities, and their relative importance to the firm as a whole
and to each of its specific parts. Business context also involves identifying and defining
the use or role of each entity within the firm. An entity's appearance, role, or use in one
firm may be entirely different in another firm; yet the entity itself is the same.
Just as an entity may have different roles or uses between firms, so also, each part of
the firm may have a different perspective on the business, and, consequently a different
perspective on the entities of the firm. This perspective does not change the fact of the
entity's existence, only the attributes and relationships of those entities which are of
interest to individual portions of the firm and their role or use in that firm.
The specific definitions of these entities and their relationships with other entities within
the firm are relevant only within the context of that firm and are totally dependent upon
the attributes of the entities which are of interest to the firm. An entity within one firm
may be only an attribute of an entity within another firm, and vice versa.
The importance of identification, definition, and context can be seen when one looks at
the formal definitions of the three key elements which form the heart of the ER
approach. These definitions form the basis for both the data analysis method and the
data modeling technique of the entity-relationship approach.
A definition
An entity is defined as a person, place, or thing which (a) is of interest to the corporation,
(b) is capable of being described in real terms, and (c) is relevant within the context of
the specific environment of the firm.
A definition
An attribute is any aspect, quality, characteristic, or descriptor of either an entity or a
relationship. An attribute must also be (a) of interest to the corporation, (b) describable
in real terms, and (c) relevant within the context of the specific environment of the firm.
An attribute must be definable in terms of words or numbers. That is, the attribute must
have one or more data elements associated with it, one of which may be the name of the
entity or relationship. An attribute may describe what the entity looks like, where it is
located, how old it is, how much it weighs, etc. It may describe why a relationship exists,
how long it has existed, how long it will exist, or under what conditions it exists.
A definition
A relationship is any association, linkage, or connection between the entities of interest
to the corporation. These relationships must also be (a) of interest to the corporation, (b)
describable in real terms, and (c) relevant within the context of the specific environment
of the firm.
It is important to note at this point that relationships exist only between entities, not
between attributes of entities. To illustrate,
The entity "person" could be anyone.
When the attributes name, age, and sex are added, we can distinguish men from
women, adults from children, and one person from another.
When the relationships are added, we know whether we are talking about a group of
unrelated people, a family, or a corporation.
Entities and their attributes
To describe an entity, we must describe it in terms of its attributes and its relationships
with other entities. An entity description consists of a series of statements which
complete a phrase such as "the entity is...," "the entity has...," "the entity contains...," or
"the entity does ...."
Each attribute relates to the entity in hierarchic terms, that is, all attributes of the entity
are fully dependent upon the entity itself because individually and together they are the
entity. The question can still be asked, however, "How can we begin to identify these
entities?" Is, for example, the entity identified as customer (representing all customers),
or is it the specific type of customer (such as mail order or retail), or is it a single
customer? The answer is that it can be all of these, none of these, or more than these.
The specific identification of the entity has meaning only within the context of that firm.
However, most businesses can be described using a fairly restricted set of generic entity
types such as customer, product, machine, employee, location, organizational unit, etc.
An entity is whatever the business defines it to be, and that definition must make sense
within the context of the firm. Thus, an entity in one firm may be a subset of entities
included in the entity definition of another firm, or may be the global definition of the
entity used within another firm. These differences in identification can be illustrated by
the following example.
An illustration:
A town planning board, with responsibility for community planning and zoning, would
describe that community in terms of its buildings, and further define those buildings into
residences, offices, stores, warehouses, and factories.
It might be interested in which people or firms occupy or own those buildings, but for
their purposes that information would be an attribute of the building, just as the size of
the building, the number of floors, the number of windows and doors, and the cost of the
building are attributes.
On the other hand, the local tax assessor doing a census or community directory would
be interested in the people who live and work in the community and firms located there.
The assessor would be interested in the names of the people, their incomes, length of
residence, amount of taxes paid, and where they live or are located (the buildings) within
the community. In this case the buildings become attributes of the people.
Neither the buildings nor the people have changed. They both still exist. The
perspective, however, has changed; the things of interest about those buildings and
people have changed.
The town council, would need to know all the information about both the people and the
buildings, along with information about roads, utilities, etc. In this case, both the
buildings and the people become entities in their own right, along with the relationships
between them (who lives or works where, who owns what, and so on).
This need for both attributes and relationships is consistent with the accepted dictionary
definition of an entity: "the fact of existence; being. The existence of something
considered apart from its properties." Thus although the entity exists, its true form and
role are only apparent after its attributes are added.
Without attributes all that is known about the entity is that it exists. The distinction
between an entity and its attributes, and the relationship between an entity and its
attributes, is so important that the ER diagram distinguishes between an entity and its
attributes by using different symbols for each.
The entity-relationship model
The entity-relationship model represents a conceptual view of the world; as such it is
independent of any DBMS or data processing considerations. It is a creature not of data
processing but of the business environment.
Although we speak of an entity as if it were singular, in reality it is that set of persons,
places, or things which have a common name, a common definition, and a common set
of descriptors (properties or attributes).

The entity representation in the model, while it may represent a single instance, usually
represents numerous people, places, or things which have a common name and
common descriptors and thus can be treated as a set. These entities interact (relate)
with other entities. These interactions form a complex set of relationships.
An entity, although it exists physically, only has physical substance when it is described
in terms of what it looks like, where it is, what it does, and how it relates to other entities.
Each component of that description is a property or an attribute of the entity. The sum
of the properties is the entity.
These entities are physically real and their real properties can be described; these
people perform actions, using and transforming both things and information (which is
contained on things as data). The common characteristic of all entities is that we can
describe them, and we use words and numbers for that description. Collectively these
words and numbers are data; individually they are data elements.
The fact that entities, especially in the data processing environment, are described by
data, does not make them data objects nor is every collection of data elements an entity.
Some writers have suggested that data entities are built from collections of data
elements in the same manner that a car is built from a collection of parts. In fact, an ER
model can be complete and meaningful with no traditional data elements at all. The
parts of a car were specifically chosen because each contributes something to the
overall design of the vehicle. Any number of different sets of parts could be assembled
and would result in a car, but a specific car can only be built from a specific set of parts.
A car is a thing. It is a subtype of the larger group of things called vehicles, and part of
another subtype called self-powered vehicles which transport people and things. Just
as there are many different types of vehicles, not all of which are cars (some may be
boats, planes, or trains), so too there are many different types of entities.
A final type of attribute needs to be discussed: attributes which do not describe the thing
itself, but what it does, how it is used, or why it is used. Those things that an entity does
are called activities; collectively they are called processes. The attributes which
describe these entity activities are called processing-related attributes.
The processes, or activities, of the business are in reality the actions that people take
with respect to things, places, or other people. These actions usually result in some
change in the physical appearance, state, or condition of one or more entities, or
sometimes in the creation of a new entity.
E-R Diagram for Sales Monitoring

System
Sales Monitoring
System
H salesman_code
a
s
salesman_name
d_o_j
SalesMan
year_sales
Sells
item_rate
item_code
Item QOH
item_name
Has Has
Item_code
value_of_sale
salesman_code value_of_sale
Sales_Master Item_Detail
sales_receip sales_receipt_n qty_sold

sale_date
t_no o
DATA FLOW DIAGRAM
Data Flow Diagrams - Introduction

Data flow diagrams can be used to provide a clear representation of any business
function. The technique starts with an overall picture of the business and continues by
analyzing each of the functional areas of interest. This analysis can be carried out to
precisely the level of detail required. The technique exploits a method called top-down
expansion to conduct the analysis in a targeted way.
The result is a series of diagrams that represent the business activities in a way that is
clear and easy to communicate. A business model comprises one or more data flow
diagrams (also known as business process diagrams). Initially a context diagram is
drawn, which is a simple representation of the entire system under investigation. This is
followed by a level 1 diagram; which provides an overview of the major functional areas
of the business. Don't worry about the symbols at this stage, these are explained shortly.
Using the context diagram together with additional information from the area of interest,
the level 1 diagram can then be drawn.
The level 1 diagram identifies the major business processes at a high level and any of
these processes can then be analyzed further - giving rise to a corresponding level 2
business process diagram. This process of more detailed analysis can then continue –
through level 3, 4 and so on. However, most investigations will stop at level 2 and it is
very unusual to go beyond a level 3 diagram.
Identifying the existing business processes, using a technique like data flow diagrams, is
an essential precursor to business process re-engineering, migration to new technology,
or refinement of an existing business process. However, the level of detail required will
depend on the type of change being considered.

Data Flow Diagrams – Diagram Notation
There are only five symbols that are used in the drawing of business process diagrams
(data flow diagrams). These are now explained, together with the rules that apply to
them.
This diagram represents a banking process, which maintains customer accounts. In this
example, customers can withdraw or deposit cash, request information about their
account or update their account details. The five different symbols used in this example
represent the full set of symbols required to draw any business process diagram.
External Entity
An external entity is a source or destination of a data flow which is outside the area of
study. Only those entities which originate or receive data are represented on a business
process diagram. The symbol used is an oval containing a meaningful and unique
identifier.
Process
A process shows a transformation or manipulation of data flows within the system. The
symbol used is a rectangular box which contains 3 descriptive elements:
Firstly an identification number appears in the upper left hand corner. This is allocated
arbitrarily at the top level and serves as a unique reference.
Secondly, a location appears to the right of the identifier and describes where in the
system the process takes place. This may, for example, be a department or a piece of
hardware. Finally, a descriptive title is placed in the centre of the box. This should be a
simple imperative sentence with a specific verb, for example 'maintain customer
records' or 'find driver'.
Data Flow
A data flow shows the flow of information from its source to its destination. A data flow is
represented by a line, with arrowheads showing the direction of flow. Information always
flows to or from a process and may be written, verbal or electronic. Each data flow may
be referenced by the processes or data stores at its head and tail, or by a description of
its contents.
Data Store
A data store is a holding place for information within the system:
It is represented by an open ended narrow rectangle.
Data stores may be long-term files such as sales ledgers, or may be short-term
accumulations: for example batches of documents that are waiting to be processed.
Each data store should be given a reference followed by an arbitrary number.
Resource Flow
A resource flow shows the flow of any physical material from its source to its destination.
For this reason they are sometimes referred to as physical flows.
The physical material in question should be given a meaningful name. Resource flows
are usually restricted to early, high-level diagrams and are used when a description of
the physical flow of materials is considered to be important to help the analysis.
Data Flow Diagrams – The Rules
External Entities
It is normal for all the information represented within a system to have been obtained
from, and/or to be passed onto, an external source or recipient. These external entities
may be duplicated on a diagram, to avoid crossing data flow lines. Where they are
duplicated a stripe is drawn across the left hand corner, like this.
The addition of a lowercase letter to each entity on the diagram is a good way to
uniquely identify them.
Processes
When naming processes, avoid glossing over them, without really understanding their
role. Indications that this has been done are the use of vague terms in the descriptive
title area - like 'process' or 'update'.
The most important thing to remember is that the description must be meaningful to
whoever will be using the diagram.
Data Flows
Double headed arrows can be used (to show two-way flows) on all but bottom level
diagrams. Furthermore, in common with most of the other symbols used, a data flow at a
particular level of a diagram may be decomposed to multiple data flows at lower levels.
Data Stores
Each store should be given a reference letter, followed by an arbitrary number. These
reference letters are allocated as follows:
'D' - indicates a permanent computer file

'M' - indicates a manual file
'T' - indicates a transient store, one that is deleted after
processing.
In order to avoid complex flows, the same data store may be drawn several times on a
diagram. Multiple instances of the same data store are indicated by a double vertical bar
on their left hand edge.
Data Flow Diagrams – Relationship Grid
There are rules governing various aspects of the diagram components and how they can
relate to one another.
Data Flows
For data flows the rules are as follows:
Data flows and resource flows are allowed between external entities and processes.
Data flows are also allowed between different external entities. However, data flows and
resource flows are not allowed between external entities and data stores.
Processes
For processes the data flow rules are as follows:
Data flows and resource flows are allowed between processes and external entities and
between processes and data stores. They are also allowed between different processes.
In other words processes can communicate with all other areas of the business process
diagram.
Data Stores
For data stores the data flow rules are as follows:
Data flows and resource flows are allowed between data stores and processes.
However, these flows are not allowed between data stores and external entities or
between one data store and another. In practice this means that data stores cannot
initiate a communication of information, they require a process to do this.
Data Flow Diagrams – Context Diagrams
The context diagram represents the entire system under investigation. This diagram
should be drawn first, and used to clarify and agree the scope of the investigation.
The components of a context diagram are clearly shown on this screen. The system
under investigation is represented as a single process, connected to external entities by
data flows and resource flows.
The context diagram clearly shows the interfaces between the system under
investigation and the external entities with which it communicates. Therefore, whilst it is
often conceptually trivial, a context diagram serves to focus attention on the system
boundary and can help in clarifying the precise scope of the analysis.
The context diagram shown on this screen represents a book lending library. The library
receives details of books, and orders books from one or more book suppliers.
Books may be reserved and borrowed by members of the public, who are required to
give a borrower number. The library will notify borrowers when a reserved book
becomes available or when a borrowed book becomes overdue.
In addition to supplying books, a book supplier will furnish details of specific books in
response to library enquiries.
Note, that communications involving external entities are only included where they
involve the 'system' process. Whilst a book supplier would communicate with various
agencies, for example, publishers and other suppliers - these data flow are remote from
the 'system' process and so this is not included on the context diagram.
Data Flow Diagrams – Context Diagram Guidelines

Firstly, draw and name a single process box that represents the entire system.
Next, identify and add the external entities that communicate directly with the process
box. Do this by considering origin and destination of the resource flows and data flows.
Finally, add the resource flows and data flows to the diagram.
In drawing the context diagram you should only be concerned with the most important
information flows. These will be concerned with issues such as: how orders are received
and checked, with providing good customer service and with the paying of invoices.
Remember that no business process diagram is the definitive solution - there is no
absolute right or wrong.
Data Flow Diagrams – Level 1 Diagrams
The level 1 diagram shows the main functional areas of the system under investigation.
As with the context diagram, any system under investigation should be represented by
only one level 1 diagram.
There is no formula that can be applied in deciding what is, and what is not, a level 1
process. Level 1 processes should describe only the main functional areas of the
system, and you should avoid the temptation of including lower level processes on this
diagram. As a general rule no business process diagram should contain more than 12
process boxes.
The level 1 diagram is surrounded by the outline of a process box that represents the
boundaries of the system. Because the level 1 diagram depicts the whole of the system
under investigation, it can be difficult to know where to start.
There are three different methods, which provide a practical way to start the analysis.
These are explained in the following section and any one of them, or a combination, may
prove to be the most helpful in any given investigation.
There are three different methods, which provide a practical way to start the analysis.
These are introduced below and any one of them, or a combination, may prove to be the
most helpful in any given investigation:
Data Flow Diagrams – Resource Flow Analysis

Resource flow analysis may be a useful method for starting the analysis if the current
system consists largely of the flow of goods, as this approach concentrates on following
the flow of physical objects.
Resource flow analysis may be a useful method for developing diagrams if the current
system consists largely of the flow of goods. Physical resources are traced from when
they arrive within the boundaries of the system, through the points at which some action
occurs, to their exit from the system. The rationale behind this method is that information
will normally flow around the same paths as the physical objects.
Data Flow Diagrams – Organizational Structure Analysis
The organizational structure approach starts from an analysis of the main roles that exist
within the organization, rather than the goods or information that is flowing around the
system.
Identification of the key processes results from looking at the organizational structure
and deciding which functional areas are relevant to the current investigation. By looking
at these areas in more detail, and analyzing what staff actually do, discrete processes
can be identified.
Starting with these processes, the information flows between them and between these
processes and external entities are then identified and added to the diagram.
Data Flow Diagrams – Document Flow Analysis

The document flow analysis approach is appropriate if the part of the business under
investigation consists principally of flows of information in the form of documents or
computer input and output.
Document flow analysis is particularly useful where information flows are of special
interest. The first step is to list the major documents and their sources and recipients.
This is followed by the identification of other major information flows such as telephone
and computer transactions. Once the document flow diagram has been drawn the
system boundary should be added.

Data Flow Diagrams – Top Down Expansion
The section explains the process of top down expansion, or leveling. Furthermore, it
illustrates that whilst there can only be one context and one level 1 diagram for a given
system, these normally give rise to numerous lower level diagrams.
Each process within a given business process diagram may be the subject of further
analysis. This involves identifying the lower level processes that together constitute the
process as it was originally identified. This procedure is known as top-down expansion
or leveling.
As a business process diagram is decomposed, each process box becomes a boundary
for the next, lower level, diagram.
Data Flow Diagrams – Top Down Expansion Illustrated
In order to illustrate the process of top-down expansion, consider the three processes
shown within this business process diagram. No detail is shown, only the outline of the
process boxes, which have been identified during the drawing of a level 1 diagram.
Any area of a level 1 diagram is likely to require further analysis, as the level 1 diagram
itself only provides a functional overview of the business system.
Therefore, below the level 1 diagram there will be a series of lower level diagrams.
These are referred to as level 2, level 3, etcetera. In practice, level 2 is usually sufficient
and it is unusual to carry out an analysis beyond level 3.
In this example the process numbered 3, at level 1, will be investigated further thereby
giving rise to a level 2 diagram.
In the level 2 diagram four processes of interest have been identified and the numbering
of these processes must reflect the parent process. Therefore the level 2 processes are
numbered 3.1, 3.2, 3.3 and 3.4
Suppose that of these four level 2 processes, one was of sufficient interest and
complexity to justify further analysis. This process, let's say 3.3, could then be further
analyzed resulting in a corresponding level 3 diagram. Once again the numbering of
these processes must reflect the parent process. Therefore these three level 3
processes are numbered 3.3.1, 3.3.2 and 3.3.3. Data Flow Diagrams –
Numbering Rules
The process boxes on the level 1 diagram should be numbered arbitrarily, so that no
priority is implied. Even where data from one process flows directly into another process,
this does not necessarily mean that the first one has to finish before the second one can
begin.
Therefore the processes on a level 1 diagram could be re-numbered without affecting
the meaning of the diagram. This is true within any business process diagram - as these
diagrams do not imply time, sequence or repetition.
However, as the analysis continues beyond level 1 it is important that a strict numbering
convention is followed. The processes on level 2 diagrams must indicate their parent
process within the level 1 diagram. This convention should continue through level 3
diagrams, and beyond, should that level of analysis ever be required.
The diagram on this screen clearly illustrates how processes on lower level diagrams
identify their ancestral path.
Data Flow Diagrams - When to Stop

It is important to know when to stop the process of top-down expansion. Usually this will
be at level 2 or level 3.
There are 3 useful guidelines to help you to decide when to stop the analysis:
Firstly, if a process has a single input data flow or a single output data flow then it should
be apparent that there is little point in analyzing it any further.
Secondly, when a process can be accurately described by a single active verb with a
singular object, this also indicates that the analysis has been carried out to a sufficiently
low level. For example, the process named validate enquiry contains a single discrete
task.
Finally, ask yourself if anything useful will be gained by further analysis of a process.
Would any more detail influence your decisions?
If the answer is no, then there is little point in taking the analysis further.
Data Flow Diagrams – Keeping the Diagrams Clear

DFD (Context Level Diagram)
Generate
Sell Goods Sale Receipt
SALES Stores
MONOTORIN Dept.
SalesMa G
n
Receive the
Receipt
Process the goods
sold
DATA BASE DESIGN
Tables
The core element in any database design is the table. Essentially a table is a
repository for sets of related information. Below is an example of a simple table
called Employee and some data that it stores.
Name City Salary

Mary Toronto $60 000
Hari Vancouver $70 000
Jean Montreal $80 000
Our Employee contains three records. Notice that the three fields or columns
Name, City and Salary are all important to an employee. One would not create a
table with unrelated information in each row or record. For example, columns such
as Slope, Latitude, or Government would not be added to this table, but columns
such as Email, Address and Last_Name might be useful. The idea when designing
tables is to keep the information relevant to what is being stored.
In the above example notice that each column stores a different kind of information.
The kind or type of information stored is called the datatype of the column. The
columns Name and City store text information, while Salary stores currency or
money information.
Above is the Employee table defined in Visual Case for Microsoft Access XP. When
you change the database type, the data types (Text, Currency, etc.) will change as
different database management systems have different datatypes that they support.
Below is the Employee table as it would look if we switched to Oracle:
Notice that the Salary column is now just a number. This is because Oracle 8 does
not have support for a money or currency field. This is okay though since the data is
really just a number anyway.
Changing Database Types
You can change the type of a database that you are designing in Visual Case. When
you change the type of a database, Visual Case will automatically change the
datatypes of the columns within the tables to match the new dbms. This is not exact
however, as sometimes datatypes aren't supported in various database sytems (as
seen above with Oracle and the currency field).
Indices
In a large database, tables will often have hundreds, thousands or even more
records in them. A large company may have tens of thousands of employees around
the world, each occupying a record in the Employee table. Indices are important in
maintaining data integrity and order within the table.
An index is a set of columns from the table that have certain constraints on them.
In our employee table, we could create an index on the Name field indicating that it
must be unique. Our index would then be called a unique index, and if a new
record was added to the table that violated our index, an error would occur.
In most relational database management systems we can create a special kind of
index called a primary key. The set of columns that make up a primary key are
special as they can uniquely identify a record in the table. Take another look at our
simple Employee table:
Name City Salary

We can create a primary key on the Name column. This is valid for if we ask for the
employee named "Mary" only one record or row is found. Below, a new record has
been added to our table:
Name City Salary

Mary Halifax $50 000
Now, if we ask for the employee named "Mary" there are two results, the one in
Halifax and the one in Toronto. To solve the problem, we can add City to the
primary key. The combination of Name and City now uniquely identifies each record
in the table.
Creating a Primary Key with an Auto Numbered
Column
You may have noticed that we still have a problem. We would like to have a primary
key as we need a way to uniquely id the employees, but it is likely that there is more
than one employee with the same name and city.
Sometimes (as in our Employee table) there is no combination of columns that is
convenient to uniquely identify a record. You can create a column (Employee_ID in
the example above) and set it to be automatically numbered. That is, each time a
new record is added to the table, the value is automatically set to a unique value. In
the example above, a primary key has been created on the Employee_ID column.
Columns that are in a table's primary key are underlined on the diagram.
Foreign Keys
After tables, foreign keys are arguably the most important thing in a relational
database. Once you have some tables in your database, a way is needed to connect
all of the data together. Foreign keys, are the easiest way to do it.
Above, the Employee table has been changed. You will recall that previously, the
City field was stored as text. This could create problems and waste time if each time
the city has to be typed in. In the table, you could end up with errors and
inconsistencies with employees working in 'Winipeg' and 'Winnipeg' for example.
Instead, we can create another table called city:
City_ID Name
1 Toronto
2 Vancouver
3 Montreal
4 Winnipeg
5 Halifax
Now in the Employee table, only the unique identifier of the City is referenced. This
has the following advantages:
• The city name is only stored once in the database. Multiple tables and
records may reference the same city, but in each case only a number is
stored, not the entire name. This can save a significant amount of space on
disk.
• The incidence of errors is reduced in the database. Further, if a city changed
its name, only one change need be made in the database.
• Other information could be stored about a city in the City table. For example,
in Canada you may wish to store the English and French versions of a name
to display to different users. With the design above, the underlying data need
not be changed and our multi-lingual display becomes transparent.
Foreign key relations can be used between any tables. A client may have many
purchases, a library may have many books, a school many classes and a class many
students, and so on.
Below are some rules to remember when creating foreign keys:

• The foreign key goes from child table to parent table. In our example, the
Employee table is the child and it references the parent table City. Visual
Case shows an arrow pointing to the parent table.
• The child table is said to be the owner of the foreign key. Above, the foreign
key is considered a constraint on the Employee table.
• The child table must include the columns defined in the primary key of the
parent table. That is, each record in the child table, must be able to
uniquely identify a record in the parent table by its foreign key.
Multiplicity
In the example of Employee and City, the multiplicity is said to be many to one.
For each employee there is one city, but for each city there are many employees. In
Visual Case you can specify the multiplicity on a foreign key (unless not supported by
the selected database type).
Recall the constraint on a foreign key that the child table must uniquely identify a
single record in the parent table. This means that the multiplicity of the parent table
is always one. The child table can have the following multiplicities:
• Many
• One
• Zero or Many
• Zero or One
On the rare occasion in your designs you will run into a situation in which you need a
many to many multiplicity on a foreign key. A course has many students and a
student has many courses.

In the case of a many to many relationship, you need to create an intermediary
table. The way it works is that each record in the Student_Course_Connection table
connects a single student with a single course. Each instance of a student taking a
course is represented as a row in the intermediary table.
Putting it all Together
You now have all the basics required to design a relational database. Beginning with
tables you can build storage compartments for the various data that need to be
maintained in your system. Indices on the table allow for easier access as well as
control and validation over the data. Finally, foreign keys allow you to relate the
data in one table to that in another.
When designing your database try to keep each table focused and straightforward.
Each table should only have the information relating to the data being stored.
Also, look for situations where a related table would better serve the purpose as we
did above with the City field. In general, you want to avoid duplicating data entry
and storage.
Don't be afraid to have a greater number of smaller tables. In our student and
course example, the school may specify that a student can take no more than 6
courses. It may be tempting to put Course_ID1, Course_ID2... Course_ID6 columns
in the Student table and avoid the need for the intermediary table to support the
many to many relationship. You need to think ahead though. What will be required
if down the line the rules are changed and a student can take eight courses. All of a
sudden you have to change the database design (and convert the existing data) as
well as your code and the user interface for your system.
List of Tables:
Table Name Table Description
ITEM Item Master
ITEM_DETAIL Item Details
MONTH_SALES Sales Details
SALESMAN Salesman Master
SALES_MASTER Sales Master
0
1
Database Description
0 Salesman File:
Fields Data Width Description

type
Salesma Number Long Unique code given to each
n_code Integer salesman.
Salesma Text 50 Name of the Salesman.
n_name
D_o_j Date Date of Joining of the
Salesman.
Year_sal Number 10 Annual Sale done by the
es salesman
1 Item File:
Fields Datatyp Width Description

e
Item_cod Number Long Specific code to identify
e Integer any item.
Supp_co Number Long Reference supp_code in
de Integer Supplier file
Item_na Text 50 Name of that item.
me
Item_rat Currency Rate of the item.
e
QOH Number Long No. of units of item
Integer available in the stock
2 Sales Master File:

e
Sale_rec Number Long Specific code to identify a
eipt_no Integer Sale Receipt.
Sale_rec Date Date on which Sale Receipt
eipt_dat is made.
e
Salesma Number Long Reference salesman_code in
n_code Integer Salesman file.
Value_of Number Long The value of sale to that
_sale Integer receipt no.
3
4
5
6
7 Item Detail File:

e
Sale_rec Number Long References the
eipt_No Integer sale_receipt_no in
Sales_Master file.
Item_cod Number Long References the item_code in
e Integer item file.
Qty_sold Number Long The quantity of goods sold.
Integer
8 Monthly Sale File:
Fields Dataty Width Description

pe
Salesman_ Numbe 6 References the
code r salesman_code in Salesman
file.
Month Numbe 2 The month number in which
r the sale made.
Sale Numbe Long The value of sale done by a
r Integer particular salesman in a
particular month.
SECTION 5
SCREENS & VALIDATION CHECKS

Input Screens:
0 Salesman Master:
1 Item Master:
3. Sales Master – I:
0 Sales Master - II:
Section 6
Reports
Outputs:
0 Sales Analysis Report:

1 SalesMan Analysis Report:
SECTION 7
CODING
Option Explicit
Dim code() As String
Private Sub cmdClose_Click()
Unload Me
End Sub
Private Sub cmdDelete_Click()
If MsgBox("Are you sure to delete this record", vbYesNo,

"Purchase Order System") = vbYes Then
If rs.State = 1 Then
rs.Close
End If
rs.Open "delete from item where item_code='" & Label2 &

"'", cn, adOpenForwardOnly, adLockOptimistic
List1.RemoveItem (List1.ListIndex)
MsgBox ("The record deleted successfully")
End If
Form_Load
End Sub
Private Sub cmdSave_Click()
If cmdSave.Caption = "Save" Then

rs.Close
End If
If Text1.Text = "" Then
MsgBox ("Please enter the Item name")
Text1.SetFocus
Exit Sub
ElseIf Text2.Text = "" Then
MsgBox ("Please enter the Item rate")
Text2.SetFocus
Exit Sub
MsgBox ("Please enter the Quantity on Hand")
Text3.SetFocus
Exit Sub
End If
rs.Open "select * from item", cn, adOpenForwardOnly,

adLockOptimistic
rs.AddNew
rs(0) = Label2.Caption
rs(1) = Text1 & ""
rs(2) = Text2 & ""
rs(3) = Text3 & ""
rs.Update
MsgBox "Inserted"
List1.AddItem Text1
ReDim Preserve code(UBound(code) + 1)
code(UBound(code) - 1) = rs(0)
Form_Load
ElseIf cmdSave.Caption = "Modify" Then
rs.Close
End If
MsgBox ("Please enter the Item name")
Text1.SetFocus
Exit Sub
MsgBox ("Please enter the Item rate")
Text2.SetFocus
Exit Sub
MsgBox ("Please enter the Quantity on Hand")
Text3.SetFocus
Exit Sub
End If
rs.Open "update item set item_name='" & Text1 &
"',item_rate=" & Text2 & ",qoh=" & Text3 & " where
item_code='" & Label2.Caption & "'", cn,
adOpenForwardOnly, adLockOptimistic
MsgBox "Updated"
List1.List(List1.ListIndex) = Text1
Form_Load
End If
Text1.SetFocus
End Sub
Private Sub Form_Load()
cmdDelete.Enabled = False
ReDim code(0)
List1.Clear
cmdSave.Caption = "Save"
Text1 = ""
Text2 = ""
Text3 = ""
Set rs = New ADODB.Recordset
Call auto("item_code", "item", Label2, "I")
rs.Close
End If
rs.Close
End If
rs.Open "select item_code,item_name from item", cn
Do While Not rs.EOF
List1.AddItem rs(1)
rs.MoveNext
Loop
End Sub
Private Sub Form_Unload(Cancel As Integer)
MDIForm1.Item.Checked = False
End Sub
Private Sub List1_Click()
cmdDelete.Enabled = True
Dim a As Integer
rs.Close
End If
rs.Open "select * from item where item_name='" & List1 &
"'", cn, adOpenForwardOnly, adLockOptimistic
cmdSave.Caption = "Modify"
Label2.Caption = rs(0)
Text1 = rs(1)
Text2 = rs(2)
Text3 = rs(3)
End Sub
Option Explicit
Unload Me
End Sub
Private Sub cmdok_Click()
Dim i As Integer
Dim qty As Integer
Dim qtyleft As Integer
rs.Close
End If
If Combo2.Text = "" Then
MsgBox ("Please enter the Item Name")
Combo2.SetFocus
Exit Sub
ElseIf txtqty.Text = "" Then
MsgBox ("Please enter the Quantity Purchased")
txtqty.SetFocus
Exit Sub
End If
rs.Open "select * from item where item_name='" & Combo2
& "'", cn, adOpenForwardOnly, adLockOptimistic
qty = rs(3)
qtyleft = qty - txtqty
If qtyleft < 0 Then
MsgBox "The quantity on hand is " & qty & " only."
txtqty.SetFocus
Exit Sub
Else
cn.Execute ("update item set QOH= " & qtyleft & " where
item_code='" & txtcode & "'")
End If
i = frmSales.MSFlexGrid1.Rows
frmSales.MSFlexGrid1.Rows = frmSales.MSFlexGrid1.Rows +
1
frmSales.MSFlexGrid1.TextMatrix(i, 0) = i
frmSales.MSFlexGrid1.TextMatrix(i, 1) = txtcode
frmSales.MSFlexGrid1.TextMatrix(i, 2) = Combo2
frmSales.MSFlexGrid1.TextMatrix(i, 3) = Text1
frmSales.MSFlexGrid1.TextMatrix(i, 4) = txtqty
Unload Me
End Sub
Private Sub Combo2_Click()

txtcode = code(Combo2.ListIndex)
rs.Close
End If
rs.Open "select * from item where item_name='" & Combo2

& "'", cn, adOpenForwardOnly, adLockOptimistic
Text1 = rs(2)
End Sub
ReDim code(0)
rs.Close
End If
rs.Open "select * from item where QOH<>0", cn,

Do While Not rs.EOF
Combo2.AddItem rs(1)
rs.MoveNext
Loop
End Sub
Option Explicit
Dim value As Integer
Unload Me
End Sub
value = 0
rs.Close
End If
If Combo2.Text = "" Then
MsgBox ("Please Select the Salesman Name")
Combo2.SetFocus
Exit Sub
End If
rs.Open "select * from sales_master", cn,

rs.AddNew
rs(1) = MaskEdBox1.Text
rs(2) = code(Combo2.ListIndex)
rs.Update
rs.Close
End If
rs.Open "select * from item_detail", cn, adOpenForwardOnly,

adLockOptimistic
Dim i As Integer
For i = 1 To MSFlexGrid1.Rows - 1
rs.AddNew
rs(1) = MSFlexGrid1.TextMatrix(i, 1)
rs(2) = MSFlexGrid1.TextMatrix(i, 4)
rs.Update
Next
If rs1.State = 1 Then
rs1.Close
End If
rs1.Open "select * from salesman where salesman_code='" &

code(Combo2.ListIndex) & "'", cn, adOpenForwardOnly,
adLockOptimistic
If IsNull(rs1(3)) Then
rs1(3) = value
Else
rs1(3) = rs1(3) + value

End If
rs1.Update
rs.Close
End If
rs.Open "select * from month_sales", cn,

rs.AddNew
rs(0) = code(Combo2.ListIndex)
rs(1) = Month(MaskEdBox1.Text)
rs(2) = value
rs.Update
MsgBox "Inserted"
Form_Load
End Sub
ReDim code(0)
Combo2.Clear
MSFlexGrid1.Rows = 1
Call dateconv(Date, MaskEdBox1)
Call auto("sales_receipt_no", "sales_master", Label2, "SR")
rs.Close
End If
rs.Open "select * from salesman", cn
Do While Not rs.EOF
Combo2.AddItem rs(1)
rs.MoveNext
Loop
Combo2.ListIndex = "0"
MSFlexGrid1.FormatString = "S. No.|<Item Code|Item Name|

Rate|<Quantity Sold"
MSFlexGrid1.Width = 6975
MSFlexGrid1.ColWidth(0) = 500
End Sub
Private Sub MSFlexGrid1_MouseDown(Button As Integer,

Shift As Integer, X As Single, y As Single)
If Button = 2 Then
PopupMenu MDIForm1.salespopup
End If
End Sub
Option Explicit
Unload Me
End Sub
Private Sub cmdDelete_Click()
If MsgBox("Are you sure to delete this record", vbYesNo,

"Purchase Order System") = vbYes Then
rs.Close
End If
rs.Open "delete from salesman where salesman_code='" &

Label2 & "'", cn, adOpenForwardOnly, adLockOptimistic
List2.RemoveItem (List2.ListIndex)
MsgBox ("The record has been deleted successfully")
End If
Form_Load
Text1.SetFocus
End Sub
On Error Resume Next
If cmdSave.Caption = "Save" Then

rs.Close
End If
MsgBox ("Please enter the Salesman Name")
Text1.SetFocus
Exit Sub
ElseIf MaskEdBox1.ClipText = "" Then
MsgBox ("Please enter the Date of joining")
MaskEdBox1.SetFocus
Exit Sub
End If
rs.Open "select * from salesman", cn, adOpenForwardOnly,

adLockOptimistic
rs.AddNew
rs(1) = Text1 & ""
rs(2) = MaskEdBox1
'rs(3) = Text2 & ""
rs.Update
MsgBox "Inserted"
List2.AddItem Text1
Form_Load
ElseIf cmdSave.Caption = "Modify" Then
rs.Close
End If
MsgBox ("Please enter the Salesman Name")
Text1.SetFocus
Exit Sub
ElseIf MaskEdBox1.ClipText = "" Then
MsgBox ("Please enter the Date of joining")
MaskEdBox1.SetFocus
Exit Sub
End If
rs.Open "update salesman set salesman_name='" & Text1 &

"',d_o_j='" & MaskEdBox1 & "' where salesman_code='" &
Label2.Caption & "'", cn, adOpenForwardOnly,
adLockOptimistic
MsgBox "Updated"
List2.List(List2.ListIndex) = Text1
Form_Load
End If
Text1.SetFocus
End Sub
List2.Clear
cmdDelete.Enabled = False
Text1 = ""
'Text2 = ""
'Text3 = ""
Call dateconv(Date, MaskEdBox1)
Set rs = New ADODB.Recordset
Call auto("salesman_code", "Salesman", Label2, "S")
rs.Close
End If
rs.Open "select salesman_code,salesman_name from

salesman", cn
Do While Not rs.EOF
List2.AddItem rs(1)
rs.MoveNext
Loop
End Sub
Private Sub List2_Click()
cmdDelete.Enabled = True
MaskEdBox1.Mask = ""
rs.Close
End If
rs.Open "select * from salesman where salesman_name='" &

List2 & "'", cn, adOpenForwardOnly, adLockOptimistic
cmdSave.Caption = "Modify"
Label2.Caption = rs(0)
Text1 = rs(1)
MaskEdBox1 = rs(2)
'Text2 = rs(3)
'Text3 = rs(4)
End Sub
Private Sub add_Click()
frmItem_det.Width = 6000
frmItem_det.Height = 4500
frmItem_det.Top = 1500
frmItem_det.Left = 2000
frmItem_det.Show
End Sub
Private Sub exwin_Click()
'ExitWindowsEx(0, 0) = 1
End Sub
Private Sub exit_Click()
End
End Sub
Private Sub item_Click()
Me.Item.Checked = True
frmItem.Show
End Sub
Private Sub MDIForm_Load()
cn.Open "provider=microsoft.jet.oledb.4.0;data source=" &

App.Path & "\SalesMonitoring.mdb"
'Set cn = New ADODB.Connection
'cn.Open "lib1", "scott", "tiger"
End Sub
Private Sub sales_Click()

frmSales.Show
End Sub
Private Sub salesman_Click()
frmSalesman.Show
End Sub
Private Sub SAR_Click()
'Screen.MousePointer = vbHourglass
'CrystalReport1.ReportFileName = App.Path &

"\SalesAnalysis.rpt"
'CrystalReport1.Destination = crptToWindow
'Me.CrystalReport1.WindowTitle = "Sales Analyzing Report"
'Me.CrystalReport1.WindowState = crptMaximized
'CrystalReport1.PrintReport
'
'Screen.MousePointer = vbArrow
DataReport4.Show
End Sub
Private Sub SMAR_Click()
DataReport2.Show
''Screen.MousePointer = vbHourglass
''
''CrystalReport1.ReportFileName = App.Path &
"\Report1.rpt"
'''Me.CrystalReport1.SelectionFormula =
"{month_sales.salesman_code}={Sales_master.salesman
_code}"
''CrystalReport1.Destination = crptToWindow
''Me.CrystalReport1.WindowTitle = "SalesMan Analyzing

Report"
''Me.CrystalReport1.WindowState = crptMaximized
''
''CrystalReport1.PrintReport
''Screen.MousePointer = vbArrow
End Sub
Public cn As New ADODB.Connection
Public rs As New ADODB.Recordset
Public rs1 As New ADODB.Recordset
Public Sub auto(f As String, t As String, lbl As Label, c As

String)
rs.Close
End If
rs.Open "select max(" & f & ") from " & t & "", cn
If IsNull(rs(0)) = True Then
lbl = c & "00" & 1
ElseIf Val(Right(rs(0), 3)) > 0 And Val(Right(rs(0), 3)) < 9

Then
lbl = c & "00" & Val(Right(rs(0), 3)) + 1
ElseIf Val(Right(rs(0), 3)) >= 9 And Val(Right(rs(0), 3)) < 99

Then
lbl = c & "0" & Val(Right(rs(0), 3)) + 1
ElseIf Val(Right(rs(0), 3)) >= 99 And Val(Right(rs(0), 3)) <

999 Then
lbl = c & Val(Right(rs(0), 3)) + 1
End If
End Sub
Public Sub dateconv(dt As Date, mk As MaskEdBox)
Dim y, d, m As String
y = Year(dt)
m = Month(dt)
d = Day(dt)
If Len(m) = 1 And Len(d) = 1 Then
mk = "0" & m & "/0" & d & "/" & y
ElseIf Len(m) = 1 Then
mk = "0" & m & "/" & d & "/" & y
ElseIf Len(d) = 1 Then
mk = m & "/0" & d & "/" & y
Else
mk = m & "/" & d & "/" & y
End If
End Sub
Limitations and Areas of Enhancement
• This project can be customized to connect many Branches of a

single Company in India and make a centralized sales monitoring
system with a centralized database.
• Better security mechanisms can be applied like admin
passwords, encryption techniques etc.
• Can be made more customizable.
• Report generation can be enhanced more to facilitate the user of
this system. Like reports, which depict weak areas in marketing
strategies, used.

Sales (Final RPT)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sales (Final RPT)

Uploaded by

Copyright:

Available Formats

TABLE OF CONTENTS

1.1 Objectives OF the Project

This project does the complete automation of sales monitoring

Key feature of the System : -

Software keeps track of :-

2.1 Identification Of The Need

2.2 Preliminary Investigation

2.3 Feasibility Study

2.3.1 Technical Feasibility

2.3.2 Economical Feasibility

2.3.3 Operational Feasibility

Different Modules In Computerized System:

Module 1: Item Module

Module 2 Sales Man Module

Module 3 Sales Module

Module 4 Report Generation

Depending on the results of the initial investigation, the survey is expanded to a

1. Statement of the problem: A carefully worded statement of the

2. Summary of finding and recommendations: A list of the major

3. Details of findings : An outline of the methods and procedures under-

4. Recommendations and conclusions: Specific recommendations

SOFTWARE REQUIREMENT SPECIFICATION

Modular Break –Up Of The System:

Description Of The Modules:

Module 1: Item Module

Module 2 Sales Man Module

Module 3 Sales Module

Module 4 Report Generation

 Identify The Various Tables Required.

Software/Compilers Required Developing This

Software means a collection of program where the objective is to enhance the

4.1 Data Flow Diagram (DFD)

4.2 E-R Diagram

4.3 Menu Flow Diagram

4.4 Database Design

Menu Flow Diagram

Master Report Exit

The Entity-Relationship Approach

tools, and is supported by all dictionaries, repositories and encyclopedias. Properly

development methodologies use the ER approach to model data.

Most popular analytical approaches, or methodologies, focus either on the processes

being performed or on data elements presumed to be needed by the user. Some

are called relationships.

themselves must be described.

radically different, from other members of the same group.

as first knowing or suspecting that they exist.

processes of the business.

As with any analytical method, the effectiveness of the ER approach is limited, or

entity definition, and (3) business context.

time" are attributes of employee.

data modeling technique of the entity-relationship approach.

the specific environment of the firm.

An attribute is any aspect, quality, characteristic, or descriptor of either an entity or a

between attributes of entities. To illustrate,

The entity "person" could be anyone.

women, adults from children, and one person from another.

unrelated people, a family, or a corporation.

Entities and their attributes

with other entities. An entity description consists of a series of statements which

"the entity does ...."

or is it the specific type of customer (such as mail order or retail), or is it a single

the following example.