Table of Contents

CHAPTER ONE..............................................................................................................................1

1. Introduction..................................................................................................................................1

1.1 Background of the organization.............................................................................................2

1.2 Statement of problem.............................................................................................................2

1.3 Motivation..............................................................................................................................3

1.4 Objectives of the project........................................................................................................3

1.5 Team composition..................................................................................................................3

1.6 feasibility study......................................................................................................................4

1.7 Scope and limitation of the project........................................................................................6

1.8 Methodology and Development Tools...................................................................................6

1.9Significance of the project......................................................................................................8

1.10 Beneficiary of the Project....................................................................................................8

Chapter Two..................................................................................................................................11

Literature Review..........................................................................................................................11

2.1 Introduction..........................................................................................................................11

2.2 System Development Methodology.....................................................................................12

2.3 Organizational Structure......................................................................................................13

CHAPTER THREE.......................................................................................................................16

3. Related Work.............................................................................................................................16

CHAPTER FOUR.........................................................................................................................17

Description of the existing system.................................................................................................17

4.1 Introduction..............................................................................................................................17

i
 4.1.1 Players in the existing system...........................................................................................17

4.1.2 Activities in the existing system(Report generated).........................................................18

4.1.3 Major function of existing system....................................................................................19

4.1.4 Business rules....................................................................................................................19

4.1.5 Paper document in the existing system.............................................................................20

4.1.6 Bottlenecks of the existing system....................................................................................21

4.1.7 Problem in Existing system...............................................................................................22

4.1.8 Practices to be preserved...................................................................................................23

4.1.9 Alternative solution...........................................................................................................23

4.1.10 The proposed system.......................................................................................................23

4.11 Requirements of the proposed system...............................................................................24

4.2 system analysis........................................................................................................................26

4.2.1 Introduction.......................................................................................................................26

4.2.2 System requirement specification (SRS)..........................................................................27

4.2.2.1 Use Case Diagrams........................................................................................................27

4.2.2.3 System use case..............................................................................................................28

4.2.2.4 Use case description.......................................................................................................30

4.2.2.5 Sequence Diagram.........................................................................................................38

4.2.2.6Activity Diagram.............................................................................................................49

4.2.2.7Analysisclassdiagram......................................................................................................59

4.2.2.8 User interface prototype.................................................................................................61

CHARTER FIVE...........................................................................................................................63

SYSTEM DESIGN........................................................................................................................63

5.1 INTRODUCTION...................................................................................................................63

5.2 Class Type Architecture..........................................................................................................63

ii
5.3 Class Modeling........................................................................................................................64

5.4 State chart modeling................................................................................................................67

5.5 collaboration modeling............................................................................................................70

5.6 Component Modeling..............................................................................................................74

5.7 Deployment Modeling.............................................................................................................76

5.8 Persistence Modeling...............................................................................................................78

5.9 User Interface Design..............................................................................................................79

References......................................................................................................................................82

iii
List of figures
Figure 1 Time line schedule.............................................................................................................9
Figure 2 Organizational structure.................................................................................................15
Figure 3 Paper document for estimation.......................................................................................20
Figure 4 Paper document for estimation.......................................................................................21
Figure 5 system use case diagram.................................................................................................29
Figure 6 Sequence Diagram for Login..........................................................................................39
Figure 7 Sequence Diagram for register address..........................................................................40
Figure 8 Sequence Diagram for register expenditure...................................................................41
Figure 9 Sequence Diagram for report sales information .............................................42
Figure 10 Sequence Diagram for register daily sales...................................................................43
Figure 11 Sequence Diagram for report annual tax......................................................................44
Figure 12 Sequence Diagram for calculate annual tax.................................................................45
Figure 13 Sequence Diagram for manage account........................................................................46
Figure 14 Sequence Diagram for view notification.......................................................................47
Figure 15 Sequence Diagram for send notification.......................................................................48
Figure 16 Activity diagram for Log in..........................................................................................49
Figure 17 Activity diagram for register address...........................................................................50
Figure 18 Activity diagram for register expenditure....................................................................51
Figure 19 Activity diagram for register daily sales......................................................................52
Figure 20 Activity diagram for report sales information..............................................................53
Figure 21 Activity diagram for create account..............................................................................53
Figure 22 Activity diagram for update account............................................................................54
Figure 23 Activity diagram for review taxpayer...........................................................................55
Figure 24 Activity diagram for view notification.........................................................................56
Figure 25 Activity diagram for view annual tax...........................................................................57
Figure 26 Activity diagram for send notification.........................................................................58
Figure 27 Class Analysis Diagram................................................................................................60

iv
Figure 28 user interface prototype................................................................................................62
Figure 29 Class type architecture.................................................................................................64
Figure 30 Class modeling.............................................................................................................66
Figure 31 State chart modeling for login.....................................................................................67
Figure 32 State chart modeling for registration............................................................................68
Figure 33 State chart modeling for registration..........................................................................68
Figure 34 State chart modeling for view notification..................................................................69
Figure 35 State chart modeling for review tax payer information...............................................69
Figure 36 State chart modeling diagram for send notification....................................................70
Figure 37 Collaboration modeling for login.................................................................................71
Figure 38 Collaboration modeling for register address................................................................71
Figure 39 Collaboration modeling for register expenditure.........................................................72
Figure 40 Collaboration modeling for register daily sales............................................................72
Figure 41 Collaboration modeling for report daily sale information............................................73
Figure 42 Collaboration modeling for send notification to tax payer...........................................73
Figure 43 Component modeling...................................................................................................75
Figure 44 Deployment modeling..................................................................................................77
Figure 45 Persistence modeling....................................................................................................78
Figure 46 User interface design of home page.............................................................................79
Figure 47 User interface design of tax payer................................................................................80
Figure 48 User interface for login page........................................................................................81

v
List of Tables
Table 1 Team composition..............................................................................................................4
Table 2 Economical feasibility for existing system.........................................................................4
Table 3 Economical feasibility for current system..........................................................................5
Table 4 Development Tools.............................................................................................................8
Table 5 Cost for materials..............................................................................................................10
Table 7 Use case description for Login.........................................................................................30
Table 8 Description for Register address use case........................................................................30
Table 9 Use case description for Register expenditure use case...................................................31
Table 10 Use case description for Register daily sales..................................................................32
Table 11 Use case description for Report sale information...........................................................33
Table 12 Use case description for calculate daily sales.................................................................34
Table 13 Use case description for create account..........................................................................34
Table 14 Use case description for manage account.......................................................................35
Table 15 Use case description for review taxpayer.......................................................................36
Table 16 Use case description for view annual tax.......................................................................36
Table 17 Use case description for view annual tax.......................................................................37
Table 18 Use case description for send notification......................................................................37

vi
ABBREVIATION, ACRONYMS AND DEFINITION

ABBREVIATION

AET: Annual Estimated Tax

CT: Collected Tax
EDSRAT: Registering daily sales And Reporting calculated annual Tax
PHP: Hyper Text Preprocessor
ERCA: Ethiopian Revenue and Custom Authority Service
SIGTSAS: System Integrated Government Tax Administration System
TIN: Taxpayer Identification Number
TOT: Turn Over Tax
UC: Use case
UML: Unified Modeling Language
VAT: Value Added Tax

ACRONYMS AND DEFINITION

Annual tax is the yearly tax that the government agency levy on citizen to generate
income used for government program.
Annual tax report is yearly tax that present in an organized format for specific
purpose
Collected tax is amount of tax collected from customer.
Daily sales are a measure of the average number of day that it takes a company to
collect payment after a sale has been made.
Estimation is the process of finding an estimate, or approximation, which is a value
that is usable for some purpose even if input data may be incomplete, uncertain, or
unstable.
Estimated tax is a periodic advance payment of tax based on the amount of income that
is earned and the amount of estimated tax liability that will be incurred as result.
Tax Payer is a person who pays a tax
VAT is a conception tax placed on a product whenever value is added at each stage of
supply chain from production to point of sale.

vii
 Abstract

Estimation is the process of finding an estimate, or approximation, which is a value that is

usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value
is nonetheless usable because it is derived from the best information available.
Nowadays, using traditional mechanism by organization for serving their client is changing into
automated system. Ethiopian revenue and custom authority was established with objective of to
streamline the public revenue generation function by bringing the relevant agencies under the
umbrella of the central revenue collector body. This structuring aimed at improving service
delivering, facilitating trade, enforcing the tax and customs laws and thereby enhancing
mobilization of Government revenue in sustainable manner. The agency uses traditional
estimation process for category “C” tax payer.
This project is aimed to design and develop automated Registering daily sales and reporting
calculated annual tax for Ethiopian revenue and custom authority category “C” tax payers. The
new system is improving the traditional way of Registering daily sales and reporting calculated
annual tax of category “C” tax payers by android and desktop web service platform.
The methodology which we used different requirement collection mechanisms. And also we used
agile software development model, for requirement analysis we used Object Oriented analysis
technique, as well as for designing Object Oriented Design technique, for testing we used white
box and black box testing mechanism.
Therefore, the new system improve the existing system of Ethiopian revenue and custom
authority in category “C” tax payers daily sales estimation and annual tax report to be
accurate.
Keyword: estimation, daily sale, annual tax, tax payer, annual tax report

CHAPTER ONE

1. Introduction
Estimated tax is a periodic advance payment of tax based on the amount of income that is earned
and the amount of estimated tax liability that will be incurred as result.
A tax is a mandatory financial charge or some other of levy imposed up on a taxpayer (an

viii
individual or other legal entity) by a governmental organization in order to found various
public expenditure. Tax is the best way of collecting money from the citizens for the sake of their
Welfare. Because the tax or money collected from the people or company are distribute again for
the citizens in case of infrastructure such as school, health care and others. Local bodies or
municipals need collect different kind of taxes from the citizens like land tax, property tax, rental
tax and soon. Every citizen need to pay tax of the property for the particular authorities.
According to Ethiopian revenues and custom authority, proclamation there are three categories
of tax payer depends on their annual income capital. Those are: Category “A” their capital is
>=1,000,000, Category “B” their capital is >=500,000 and Category “C” their capital
is<500,000.
Category “C” tax payers pay their tax based on estimated daily income capital. Estimated tax is
how you pay tax on income not subject to withholding. Examples of this income include any of
the following: Self-employment, Pensions, Unemployment compensation, Interest and dividends,
Rents, Alimony, Gains from the sale of assets, and Prizes and awards. Category “C” tax payers,
unlike category “A” and to prepare financial statements. To determine the income tax liability of
such tax payers, standard assessment or presumptive method shall be used. There is also a
process that held in manual way for category C. These are:-The tax payer must get a TIN number
from revenue and custom authority. Then the tax payer gets the business license from trade
industry office start their work. Finally the employee who are send from the office look around
each and every tax payer and estimate the daily income of the tax payer for calculating annual
tax and the government estimate daily income once for three years and also he /she does not
estimate fairly the income of tax payer .
Tax administration system application is the new system for category C taxpayer .It is both
mobile and web application. The main purpose of the new system is to provide the convenient
way for ERCA as well as for the tax payers. The objective of this application is to solve the
problems that are faced in existing system.

1.1 Background of the organization

The Ethiopian Revenues and Customs Authority (ERCA) was established by the proclamation
No .587/2008 on 14 July 2008, by the merger of the Ministry of Revenue, Ethiopian Customs
Authority and the Federal Inland Revenue Authority for the purpose of enhancing the
mobilization of government revenues, while providing effective tax and Customs administration
ix
and sustainability in revenue collection. The main objective of the establishment of ERCA was
to streamline the public revenue generation function by bringing the relevant agencies under the
umbrella of the central revenue collector body. This structuring aimed at improving service
delivering, facilitating trade, enforcing the tax and customs laws and thereby enhancing
mobilization of Government revenue in sustainable manner. The ERCA is responsible to protect
the society from adverse effects of smuggling. It seizes and takes legal action on the people and
vehicles involved in the act of smuggling while it facilitates the legitimate movement of goods
and people across the border.

1.2 Statement of problem

The best instrument which the governments can use as a source of revenue is taxation. The
central aim of the tax system in Ethiopia is to collect sufficient money to finance the
administrative machinery of the government as well as to finance the fulfillment of basic
infrastructures like roads, telecommunication, electricity and other basic social services like
education, health and water supply facilities.

The ERCA office use different process to collect the tax from the tax payer; those processes are:-
The tax payer must get the business license from trade industry office. Then to pay a tax the tax
payer gets a TIN number from their revenue and custom authority. In generally the current tax
collection from categories C tax payers have different problems. These problems are:

 Time consuming.
 There is no transparency in tax payer side.
 The tax payer income and the tax given to them is mismatch.

Therefore, tax is base for development of one country and automated tax collection will enhance
the income of ERCA. This paper or project aims to solve the problems of categories C tax payer
by designing and automating tax collection system of categories C tax payers.

1.3 Motivation
Now a day the Ethiopian revenue and custom authority use System Integrated Government Tax
Administration System for category A and B taxpayers for registration and to collect the tax.
Category C does not uses this system for the purpose of registering and calulate the tax but all
the other activity are done by traditional way. Because of this reason we are motivated to solve
x
the traditional way by designing and developing registering daily sales and Report calculating
annual tax for category C taxpayer.

1.4 Objectives of the project

1.4.1 General objective

The general objective of this project is to develop web and android based application for ERCA
to Tax administration system for category “c” tax payers.

1.4.2 Specific objectives

Specific objectives are tasks will perform that in order to achieve the general objectives of this
project. Therefore, the specific objectives of this project are the following:
 Study the current system
 Identify and design requirement of new system.
 Designing the system with appropriate methodologies and tools.
 Developing a database that will be used by the system
 Implement, test and install the new system in well manner

1.5 Team composition

Project title Web and android based tax administration(registering daily sales&
calculating annual tax) system for category “c” tax payers

Name ID NO Phone & Email

Team responsibility
1.Habtamub NCS/R/640/09 0945126446 Data controller
Teshome [email protected]
2.Mintamir Tsehay NCS/R/071/09 0927671426 Programmer
[email protected]
3.Netsanet Birhanu NCS/R/033/09 0938282551 System designer
[email protected]
Advisor Mr.Demmelash
A(Msc)
Date 22/03/2012

xi
 Table 1 Team composition

1.6 feasibility study

Feasibility is the measure of how beneficial or practical. To start with our project first we should
have to clearly notify the feasibility of the system that we are going to implement, because
without fulfilling feasibility factors (i.e. the organizational, economical, technical, and
operational feasibility) our proposed system cannot be said a good software. So in all angles the
new system should have to be feasible. The feasibility factors of our project are economic
feasibility, technical feasibility, operational feasibility, schedule feasibility and political
feasibility.

1.6.1 Economic feasibility

The project is economically feasible since its expected benefits outweigh the expected cost.

Table 2 Economical feasibility for existing system

Existing system Annual estimated Collected tax (CT) Lost tax

tax(AET)
AET=58,000,000 CT=80%AET lost tax=AET-CT
CT=46,400,000 11,600,000

Table 3 Economical feasibility for current system

current system Annual estimated Collected tax (CT) Lost tax

tax(AET)
AET=58,000,000 CT=81%AET lost tax=AET-CT
CT=46,980,000 =11,020,000

Final we comparing collected tax from existing and new system it increased by 1% .so it is
economically feasible.

1.6.2 Technical feasibility

Technical feasibility is the measure of the practicality of a specific technical solution and the

xii
availability of technical resources. In technical feasibility we should notify that our proposed
system can implement with current technology and also the system user has enough experience
using that technology. Technical feasibility addresses three main things:
 Is the technology practical
 Do we currently passes the necessary technology
 The ability to do on the technologies

Our system is technically feasible. It assess the organization‘s ability to construct the system i.e.
developed in user friendly manner.

1.6.3 Operational feasibility

Measure how much the proposed system solves the existing system problems. This project is
surely operationally feasible because the proposed system (the project) is a good solution maker
of the problem or specific solution will work in the existing system and create a good
environment towards the user of our application.

1.6.4 Schedule feasibility

Our proposed system is feasible in time comparing with the existing system .because the new
system minimize time consumption when the tax estimation committee consuming the time
during look around the businessman to estimate their daily sales to pay their annual tax.

1.6.5 Political Feasibility

The system is not conflict with any government directives, because it gives services for the
people effectively and efficiently, all the stakeholders also agreed before the system developed.
So the government is profitable and the system will be politically feasible.

1.7 Scope and limitation of the project

1.7.1 Scope
The scope of this project is

 Registering daily sales

 Report calculated annual tax for category C tax payer.
 Daily sales registration supports both web and android application.
 Calculating annual tax performed for 365 days sales.

xiii
  Estimate the daily income of tax payer.

1.7.2 out scope

The limitation of our project is:-

 it uses only Amharic language.

 It does not include payment.

1.8 Methodology and Development Tools

1.8.1 Data gathering

To gather the requirement of the system we use different types of fact finding methods those
are:-

 Observation:-We can analyze the current system by observation. In our observation we

have tried to observe things mentioned below
 The general system of providing service in the current system.
 How the system handles and store material’s information.
 Interview:-As a method for the collection of data about the activities of registering daily
sales and reporting calculated annual tax we use interviewing method to understand
peoples who belongs to the current system also we raised questions that helps us to
develop the new system. To Uncover ambiguities, to get hidden requirements and In-
depth a stakeholders thoughts and get his or her perspective.
 Document Analysis:-In all organizations documents such as forms, records, reports, and
manuals are available. These help in determining how the present system runs. So in
addition to observation and interview we can understood the existing system by
reviewing different documents.

1.8.2 System Development Methodology

System development methodology is used to structure plan and control the process of developing
an information system. In our project, project team will use object oriented system analysis and
design (OOSAD) because OOSAD focuses on data rather than the procedures and it support re-
usability of code. Therefore, the time and cost of development is inherently less. It includes

xiv
 essential use case diagram, system use case diagram, use case descriptions (scenarios), sequence
diagrams, activity diagrams, class diagram, and class responsibility.
Some advantages of object oriented system analysis and design as follows:

 Reduced maintenance.
 code re usability.
 real-world modeling.
 and improved reliability and flexibility.

1.8.3 Development Tools

The tools that we are going to use throughout our project are listed in the following table as
grouped into hardware tools &software tools.

Tools
Hardware Software
 Flash Disk : at minimum 8GB  Microsoft 2010 :to write the entire documents
 RAM : to the maximum of 1.90GB  Power point 2010 :for presentation for both
 Hard Disk: to the maximum of phase1 and phase 2
464.6GB  Wamp server 2.5 :To run the site on the tool
 CD-R : to the maximum of 700MB bar
 Paper :size a A4  Sql database server: To store data

Table 4 Development Tools

xv
 1.9Significance of the project
The proposed project has many benefits. Those are listed below:-

 Speed up the system

 provide security
 Reduce resource wastage
 Protect data/files from unauthorized users

 Easy to calculate annual tax

 Easy to retrieve data

 Estimation is done fairly

 Decrease material consumption like paper and pen

1.10 Beneficiary of the Project

There are different bodies that can get benefit from this system such as: Mainly the organization
that is ERCA will be highly benefited from this system, Tax payer, Employees of that organization,
the whole country and its citizens.
 Benefit to the organization

The organization will be get a benefit by social, economic, political, schedule and saving their
working time that mean he/his pay his /her tax
 Benefit to the customer

Tax payer the major beneficiaries of this system that his/her income will estimate will be fair as the
income of the customer.

 Benefit to the developer

The developers benefit is that in the future when this system is implemented in social aspect
satisfied because those problems before this system is implemented cannot feet again.

xvi
 Time line Schedule

4-Jul 23-Aug 12-Oct 1-Dec 20-Jan 10-Mar 29-Apr 18-Jun

1-Nov
Title selection 12-Nov

13-Nov
Requirement gathering 15-Nov

16-Nov
Proposal 24-Nov

25-Nov
System analysis 6-Dec

7-Dec
Design phase 2-Jan

3-Jan
Implementation phase 10-May

11-May
Testing 29-May

Day to complete Start date

Figure 1Time line schedule

Cost for materials

Total
No Type Quantity Unit price(in birr) price(in
birr)
1. Paper 1 packet 120 120
2. Pen 1 packet 8 80
4. Copy 100 pages .75 75
5. Print 100 pages 1.50 150

6. Computer 2 20,000 20,425

Table 5 Cost for materials



xvii
 Chapter Two

Literature Review
2.1 Introduction
Tax payers are categorized in to three based on their income, such as category A, B and C
category “A” tax payers are expected to pay from their income which is greater than 500,000
birr. Category “B” tax payers between 100,000 and 500,000 birr category “C” tax payers less
than 100,000 birr. [ CITATION Bek05 \l 1033 ]
Taxation is a system of raising government’s revenue by imposing tax. It is a method of
collecting funds by a government from tax sources to finance its operation. Taxation is also a
means by which a government, through its law making body, raises internal income through tax
for the use and support of the government and to enable it discharge its appropriate functions
Tax administration refers to the systematic organization and arrangement of elements for tax
collection and other similar tasks or activities by the tax authorities of the federal government
and sales government.
One of the objectives of taxation is collecting sufficient amount of public revenue to meet public
expenditures. In order to attain this abuse relationship between tax structured and tax
administration and an organized tax collection structure should be maintained. Taxable business

xviii
income/profit is the amount of income or profit from business activity which is subject to
business income or profit tax. [ CITATION Bek05 \l 1033 ]
Tax is a contribution from individuals out of their property for the maintenance and defence of
Government in simpler term tax is financial charge or other levy imposed on an individual or
legal entity by government.[ CITATION Bel07 \l 1033 ]
The Ethiopian Revenue and Customs Authority is one of a body responsible for collecting
revenue from customers and domestic taxes.[ CITATION WEL14 \l 1033 ].Tax is a compulsory
contribution or unrequited payment by the people to the government for which there is no direct
return to taxpayers. A tax is a generalized exaction which may be levied on one or more criteria
upon individuals, groups of individuals, or other legal entities.[ CITATION Ket16 \l 1033 ]
Organizational Strength of tax authorities is indicated by many scholars. According to Bird and
no tax will work effectively, unless its administrators maintain an aggressive attitude with
respect to the correctness of the taxpayers’ actions. Some taxpayers will fail to file or make
mistakes through ignorance or neglect; others will deliberately cheat. A passive attitude by the
authorities towards these errors and falsifications will soon undermine the entire structure, since
the diligent and honest taxpayers will almost in self defense be forced to the level of the careless
and dishonest. A tax administration which seeks voluntary compliance must protect those who
comply or else compliance will not be forthcoming .[8] further state that the sure sign of
ineffective tax administration is the presence of a very large delinquency in tax payments for it
indicates the lack of taxpayer respect for the tax system. The taxpayer in effect is acting on his
belief that the administrative machinery may bark, but that it has no bite. These writers argue that
in large part the solution for the large delinquency lies in providing the bite. In this sense
effective tax collection is a facet of the larger problem of providing adequate penalties, to which
reference will later made. In other words tax is evaded to the extent that tax authorities are
perceived as weak by tax payers.[ CITATION Keb16 \l 1033 ]States that tax systems that depend on
arranged administrative procedures rapidly become discredited and endanger voluntary
compliance.

2.2 System Development Methodology

System development methodology is used to structure plan and control the process of developing
an information system. In our project, project team will use object oriented system analysis and
design (OOSAD) because OOSAD focuses on data rather than the procedures and it support re

xix
usability of code. Therefore, the time and cost of development is inherently less. It includes
essential use case diagram, system use case diagram, use case descriptions (scenarios), sequence
diagrams, activity diagrams, class diagram, and class responsibility.
Some advantages of object oriented system analysis and design as follows:

 Improved software-development productivity: Object-oriented programming is

modular, as it provides separation of duties in object-based program development. It is
also extensible, as objects can be extended to include new attributes and behaviours.
Objects can also be reused within an across applications. Because of these three factors
modularity, extensibility, and re usability–object-oriented programming provides
improved software-development productivity over traditional procedure-based
programming techniques. Code re usability.
 Easy to Understand: Since OOSAD principles are fundamentally based on real world
objects, it’s quite easy for everyone on the team to quickly understand what an object
name means or how a particular behaviour, well, behaves. This makes the overall
development life cycle a much smoother process, particularly if your team needs to
frequently interact with customers or other non-technical users about the objects and
components in the system. In such cases, most people still understand how system
components and modeled objects work when they’re based on real world objects and
ideas.
 Encourages Encapsulation: Since everything within OOSAD revolves around the
concept of objects (specifically, the object-oriented variety), one of the biggest
advantages of OOSAD is that it encourages planning and development of systems that
are truly independent of one another. Just like a class written using object-oriented
techniques, all the systems and objects produced during an OOSAD development life
cycle can be mixed and matched as necessary, since they will ideally be built as
completely self-contained entities.
 Faster development: Reuse enables faster development. Object-oriented programming
languages come with rich libraries of objects, and code developed during projects is
also reusable in future projects.

xx
 2.3 Organizational Structure
The ERCA has its headquarters in Addis Ababa. It is led by a Director General who reports to
the Prime Minister and is assisted by five Deputy Director Generals, namely D/Director General
for Program Designing of Operation and Development Businesses; D/Director General for
Branch offices' Coordination and Support; D/Director General of Enforcement Division;
D/Director General, Corporate Functions Division; Change Management and Support Sector;
and Enforcement Sector. Each deputy director general oversees at least four directorates. Both
the Director General and the Deputies are appointed by the Prime Minister.

The ERCA, at the headquarters level, has 23 directorate .One for the list of the directorate. As
shown on the organizational chart, the directorate report to the deputy director generals and a
director heads each of them. Law Enforcement Directorate is just one of the directorate ERCA
has. To carry out its duties, the directorate is entrusted with broad powers. It investigates customs
and tax offences, institute and follow up criminal proceedings in courts and this has resulted in
the arrest and trials of hundreds of offenders and smugglers. The directorate works in close
collaboration with the federal police to prevent criminal offences committed in violation of
customs and tax laws.

Besides, the headquarters has the office of the director general which is led by a director and
comprises three positions, namely Tax and Customs Affairs, Strategic Intelligence Affairs, and
Communication and Human Resource Development Affairs.

Apart from the foregoing directorates, the ERCA has 32 field offices, of which two of them are
coordination offices located outside of Ethiopia at the port of Djibouti and at the port of Burbera,
Somalia. The primary function of the foregoing coordination offices are affording/ providing
transit service for the goods imported into or exported from the country. However, the latter
coordination office is presently not operational. The 30 branch offices in Ethiopia comprise 22
Customs Control stations, 50 Checkpoints and 153 Tax Centres. Tax Centre means a tax
collection station administered under a branch office and located in the vicinity of taxpayers
while Customs Control Station means a station administered under a branch office where
customs formalities are complied with and collection of taxes and duties take place on imported
and exported goods; checkpoint is a place where customs examination is conducted by machine
and/or manually for the purpose of ascertaining that there is no variation between the goods to be

xxi
imported-exported and the goods specified in the customs declaration.

ERCA

Head Quarter

Directoreates An Power
Branch Office
Head Quarter and Budget

Wolaita Zone
Tax Customer
Customer authority
Affairs

Strategic Auditor
Intelligence Affairs Database
Estimmation Manager Cashier
Commite

Communication and
Human Resource
Development Affairs

xxii
 Figure 2 Organizational structure

CHAPTER THREE

3. Related Work
The components in the m-tax system are interrelated in a way that the software cannot be used
without an internet enabled mobile device, and the calculations cannot be performed without the
user’s input of their personal tax information. The purpose of the m-tax system will be to
facilitate the use of mobile devices in order to allow users to perform this yearly ritual in a more
timely and convenient manner. The interface of the m-tax system will be where the system meets
its environment. This will include a user-friendly interface that will be easily compatible with all
mobile devices [ CITATION Esc13 \l 1033 ].

This study concludes that the MT model based system with usability emphasis is crucial to
develop efficient m-taxing; and thereby, accelerating the adoption of an m-taxing system for the
purpose of filling taxes with the Internal Revenue Service will be beneficial for the near future.

Information about county revenue collection, tools used and the method used was reviewed.
From analysis carried out, the results pointed out that there are major problems in revenue
collection and management in the counties .The result was the development of a mobile based
county revenue collection and management both mobile and web application. The key features of
the application include: adding new records, revenue management, debt management, payment
and reconciliation management and generate reports .The application was aimed at: increasing
revenue collection, easy retrieval of information, improve accuracy in revenue information,
creating an easy way of payment for county fees, creating a sense of responsibility and
eliminating loopholes in the whole revenue collection cycle. System testing was performed, look
and feel, ease of used, system compatibility and acceptance was done.

xxiii
 CHAPTER FOUR

Description of the existing system

4.1 Introduction
Category “C” tax payers are unlike category “A” and ”B” tax payers are not required or not
mandatory to maintain books of amount and to prepare financially statements. There is also a
process that held in manual way for category C. These are:-The tax payer must get a TIN number
from revenue and custom authority. Then the businessmen get the business license from trade
industry office. Finally before the tax payment duration start the estimation committee who are
send from the office look around each and every tax payer and estimate the daily income of the
tax payer and the government estimate daily income once for three years and also he /she does
not estimate fairly the income of tax payer.
Due to the some part the current system is manual there are problems that are occurred. These
are: - Security problem, Wastage of time, Wastage of resources, Require huge man power and
Calculating annual tax problem. The target area of this proposed system is to develop a better
solution which is both mobile and web application to Registering daily sales and Reporting
calculated annual tax that overcome the above problems.
Existing system currently performs different activities includes managing tax payer information,
make payment, schedule the tax payment period, Update the tax payer information, calculating
the annual tax and also Generate report and submitting complaints in manual way.

4.1.1 Players in the existing system

Tax payer: -The person who pay a tax.
Database manager: - These are responsible to register, delete and update the tax payer from
SIGTAS database system in revenue and custom authority.
Estimation committee:-estimate the daily income of tax payer.
Casher:-collect tax from tax payer.

4.1.2 Activities in the existing system(Report generated)

In existing system there are activities that are provided by tax payer, custom authority and trade

xxiv
industry for registration, for getting and giving business license, for generating report and for
paying tax.

Activity one:-Registration

In the existing system the tax payer registration is done by SIGTAS system and they take TIN
(tax payer identification number). The tax payer to get TIN number first he/she give finger print
and photograph for the authority. Then the tax payer takes TIN number from revenue and custom
authority. Then after he/she go to trade industry to get license and to register as tax payer. There
are two types of business license. These are individual and group.

Activity Two:-Categorization
There are three levels of tax payer according to the Ethiopian tax payer proclamation rule. Those
are: Category ‘A’, their capital is greater than or equal to one million birr. These category
businessmen are VAT (value added tax) users. That means the tax payer have responsibility to
collect 15% VAT from customer. And the tax payer is responsible to submit the report for
revenue and custom authority monthly.
Category ‘B’, their capital is greater than or equal to five hundred thousand. These category tax
payer are TOT (turn over tax) users. This means they collect 2% from service and 10% from
sale. And the tax payer is responsible to submit the report for revenue and custom authority in 3
month.

Category ‘C’, their capital is less than five hundred thousand birr. In this category the tax
payer’s estimation is done by workers who sent from revenue and custom authority once for
three years and they pay tax according to their daily sale estimation annually. In the current
system calculating the tax summary for each individual tax payer is done by accountant.
Activity Three: - Estimation

In category “C” Before the tax payment duration start the estimation committee who are send
from the office look around each and every tax payer and estimate the daily income of the tax
payer and the government estimate daily income once for three years and also he /she does not
estimate fairly the income of tax payer .

Activity Four: - Reporting

xxv
After the estimation is done by the committee the decided amount is given to the tax payer. Then
authority Post the tax payment period for the tax payer and Announcing the amount of tax bill
paid by the tax payer

Activity Five:-Payment

According to the report if the tax payer agrees he/she pays the estimated tax in a given period of
time (July 1- December 30).

4.1.3 Major function of existing system

The major function in Category “C” is before the tax payment duration start the estimation
committee who are send from the office look around each and every tax payer and estimate the
daily income of the tax payer and the government estimate daily income once for three years
and also he /she does not estimate fairly the income of tax payer .
After the estimation is done by the committee the decided amount is given to the tax payer then
authority Post the tax payment period for the tax payer and Announcing the amount of tax bill
paid by the tax payer According to the report if the tax payer agree he/she pay the estimated tax
in a given period of time(July 1- December 30).

4.1.4 Business rules

BR1: The tax payer must have license.
BR2: The tax payer must have paid previous year tax.
BR3: The tax payer must be telling the daily income to that estimation committee.
BR4: Estimation committee must estimate tax payer income.

xxvi
4.1.5 Paper document in the existing system

Figure 3 Paper document for estimation

xxvii
 Figure 4 Paper document for estimation

4.1.6 Bottlenecks of the existing system

4.6.1.1 Performance
Since it is the manual system, the response time for performing every process is very slow, and
many of the documents are stored physically it increases the space complexity. Because of the
above problem the performance of the existing system is low.

4.6.1.2 Input and Output

As a manual system, redundant documents are stored as an input and maybe it is inaccurate
document, this makes difficult to find the desired document (output) from the stored documents
in the existing system. This results inaccurate output.

4.6.1.3 Security and Controls

In the existing system those data we have records are easily accessed by others. The only way
xxviii
that we have taken as a security and control method is duplicating the data in to different box
file, but it is not sufficient. And also the place of storage is no secure so to control that data are
difficult this show that existing system data storage not secure and low control.

4.6.1.4 Efficiency
As we have seen, the existing system encounter different problems like, it consumes man power,
time, space and redundancy of data. Because of such problem the existing system is not enough
efficient.

4.1.7 Problem in Existing system

Taxation in developing countries is a challenging topic and has attracted increasing attention in
the last two decades. Many problems observed like poor administration, failing to collect
sufficient tax revenues, tax structures where tax horizontal and vertical equity considerations are
not integrated, lack of government and economic stability. In many developing countries it is
observed that there is low capacity of tax administration to monitor compliance among
taxpayers.

Ethiopia, like any other developing countries, faces difficulty in raising revenue to the level
required for the promotion of economic growth. Hence, the country has been experienced a
consistent surplus of expenditure over revenue for sufficiently long period of time.

Category “C” tax payers are unlike category “A” and ”B” tax payers are not required or not
mandatory to maintain books of amount and to prepare financially statements. There is also a
process that held in manual way for category C. These are:-The tax payer must get a TIN number
from revenue and custom authority. Then the businessmen get the business license from trade
industry office. Finally before the tax payment duration start the estimation committee who are
send from the office look around each and every tax payer and estimate the daily income of the
tax payer and the government estimate daily income once for three years and also he /she does
not estimate fairly the income of tax payer.
Due to the some part the current system is manual there are problems that are occurred. These
are: - Security problem, Wastage of time, Wastage of resources, Require huge man power and
Calculating annual tax problem.
Therefore, to addressing this gap we design and develop a better solution which is both mobile

xxix
and web application to Registering daily sales and Reporting calculated annual tax that overcome
the above problems.

4.1.8 Practices to be preserved

Practices to be preserved from existing system to new system are SIGTAS system to register
the information of tax payer, we appreciate the habit of hard working regarding to work load, and
the rule and regulation that are used in ERCA are strong.

4.1.9 Alternative solution

The first alternative solution is develop both mobile and web application to Registering daily
sales and Reporting calculated annual tax for tax payer and authority office that mean the tax
payer register their daily income on the application and the estimation committee view their
daily income that are registered by tax payer .

The second alternative solution is develop android app that is only used by authority office that
mean the estimation committee register the daily income of tax payer by going to their business
centre.

The third alternative solution is developing desktop application for tax payer that he/she register
his daily in come without network connection and the authority office check the registered
income by going to their business canter.

4.1.10 The proposed system

After We studying the existing system problems, we have decided to develop a both mobile and
web application to Registering daily sales and Reporting calculated annual tax to remove these
problems. So the proposed system is developing both mobile and web application to Registering
daily sales and Reporting calculated annual tax for category “C” tax payers. The tax payers book
their daily income and expenditure in to the android app then after the data he/she insert in to
database. The estimation committee check the information that are booked in the database .The
system calculate the tax payer daily income according to the data inserted and the system
calculate the annual tax and Reporting calculated tax to tax payer. Finally the tax payer view the
calculated annual tax.

xxx
The proposed system has the following advantages:

 To solve the problems that are lack of fairness, Negligence, Intentional, Poor and
tiresome collection procedure, time consumption, tax calculation error.
 Reduce resources consumption's that are wasted in the manual system. For example, if
the tax payer information stored in the database then the paper and pen consumption will
be resolved.
 The proposed system enhances the performance. For instance, if we want to access tax
payer information simply write the TIN to the text field then search it after that the tax
payer information will be displayed with in microsecond. This indicates that there will be
fast response time in proposed system
 Security problem will be resolved because to access any information the system needs
authentication for that purpose
 Enable easy way of generating report
 To enable the tax revenue office staff to facilitate their day to day activities efficiently by
using the new technology.
 Annual tax will be calculated easily and efficiently.
 The tax payment period will be announced easily for the tax payer on line.

4.11 Requirements of the proposed system

4.11.1 Functional requirements

The functional requirements are functions or features that the system must include to satisfy the
system need and to be acceptable by the user. The actors of our system are the tax payer,
estimation committee, admin and system.

The developed system is able to provide the following functionalities with respect to each actor:

 Login
 Registration of Address
 Registration of Expenditure
 Registration of Daily sales

xxxi
  View annual tax
 calculate the daily sales
 calculate annual tax
 Report sales Information
 Report annual tax
 Review taxpayer Activity
 Manage account
 Update profile
 Send notification
 View notification

4.11.2Non-functional requirement of the proposed system

A non-functional requirement of our project also referred to as technical requirement pertains to
the technical aspects the system must fulfill such as performance related issues, reliability issues,
and availability issues, User friendly, Response time , Compatible , Database size etc. Non-
Functional Requirements are those requirements that have nothing to do with the functionality of
the system but they determine the performance of the whole system. Generally Non-functional
requirement are Describe restriction on a system that limit the choices for its construction as
solution to a given problem.

4.11.2.1 User friendly/ system interface

The system provide easily understandable system interface to the user and that does not
confuse the user. Because our system support local language for user to understand the system
easily what the system do.

4.11.2.2 Response time

Our system does not register daily sales once to the server, but it will wait up to his/her work is
finished then, after upload once to the server.

4.11.2.3 Reliable
To check the reliability in our system there is submission key the user submit and what they
miss during submission. key .This key is used to send notification to the user to submit daily
sales plus the error when

xxxii
4.11.2.4 Compatible
Our system is compatible because of android web service, that mean it support both mobile and
web application. It can work in both mobile and desk top computers.

4.11.2 .5 Database size

The data base row size built in the input of the user that is registering daily in to the system.

4.11.2.6 Security
The users should have a user account to access the system. The system must allow only valid
users to access the system and for unauthorized person it requires authentication and also a
person who has a TIN can access the system. In addition, all the information exchanged in the
system should be encrypted by best encryption algorithm.

4.11.2 .7 System modification

In system modification we use object oriented for our system because of object oriented easily
replace necessary object.

4.11.2.8 Maintenance
The system should stay in good condition by providing easy repair and backup. In other word,
when a failure occurs within the system, it should be restored to operational status at ease and
speed.

4.2 system analysis

4.2.1 Introduction
System analysis is an essential activity that must be taken in any project in order to have a clear
idea of a proposed system. During object oriented analysis the major activities are modeling the
functions of the system (Use Case Modeling) which includes identifying if there are any
additional actors and use cases, constructing a use case model, and documenting the use case
course of events. In sequence diagram we want to represent the chronology of the passing of
message between system object and actor. In activity diagram illustrates the dynamic nature of
system by modeling the flow of control from activity to activity.

xxxiii
4.2.2 System requirement specification (SRS)
System Requirements Analysis gives the professional systems engineer the tools to set up a
proper and effective analysis of the resources, schedules and parts needed to successfully
undertake and complete any large, complex project.

4.2.2.1 Use Case Diagrams

Use case diagram is primary form of system/software requirements for a new software program
under developed. Use case specify the expected behavior(what), and not the exact method of
making it happen(how).a key concept of use case modeling is that it helps us design a system
from end user’s perspective.

Use Cases

A use case defines a goal-oriented set of interactions between external actors and the system
under consideration. It describes the sequence of interactions between actors and the system
necessary to deliver the service that satisfies the goal. A use case is represented by an oval.
Use case include is a directed relationship between two use cases which is used to show that
behavior of the included use case (the addition) is inserted into the behavior of the including (the
base) use case.
The include relationship could be used:
 to simplify large use case by splitting it into several use cases,
 to extract common parts of the behaviors of two or more use cases.

<<include>>

Use case Extend is used when a use case conditionally adds steps to another first class use case.

xxxiv
 <<extend>>
Actors

An actor is an entity that interacts with the system and/or needs to exchange information with the
system. Actor is the entity that performs a role.
The new system actors are Tax payer, Estimation committee system admin and system.
Tax payer
A person who pay tax and the activities that are performed by tax payer are login to the system,
register address, register expenditure, register daily sales, view annual tax and report sales
information, view notification, update profile, and report sale information.
Estimation committee
There activities that are performed by estimation committee. These are login to the system
review taxpayer activity, update profile and send notification.
System admin
The activities that are performed by system admin are login to the system, manage account and
update profile.
System
The activities that are performed by system calculates daily sale of the tax payer, calculate
annual tax report annual tax.

4.2.2.3 System use case

System use case diagram displays the relationships between customer and providers of
application service. The purpose of system use case diagram is to help to describe and validate
the interaction between actors and their roles with applications.

xxxv
 Registering daily sales and Reporting Calculated Annual tax(Tax Administration )For Category \ C[

Create
Register address account
Deactivate <<extends>>
Manage
<<extends>>
<<extends>> account
Tax payer Activate
Register expenditure System admin

<<includes>>
Register daily <<includes>>
sales Logout
<<includes>>
<<includes>> <<extends>>
Report sales
information <<includes>> <<includes>> Verify
Login
<<includes>>
View annual <<includes>>
tax <<includes>>
Display error
View notification <<includes>> message
Calculate
<<includes>> annual
tax
Calculate daily
Review sales System

Send notification Report

annual tax
Estimation commite Setting
Help
Contact us
About us
News

Figure 5 system use case diagram

4.2.2.4 Use case description

Table 6 Use case description for Login

Use case name Login

xxxvi
Use case id Uc1
Description System allows users to login using user name and Password

Participating actor Tax payer, estimation committee and system Admin

Pre-condition The user must have application to log in.
The tax payer should have an account for login that is
registered in SIGTAS system. For other users they should have
an account.
Flow of events Actor/user Action System Response
Step1.The user clicks on Step2.The system displays
login button/link. the login page.
Step3.The user enters user Step5.The system verifies the
name and password. form.
Step4.The user click login Step6.The system displays
button. the actor’s page.
Step7.The use case ends.
Alternative action Step1: the user enters Step2: the system displays
invalid user name or error message and goes to
password. text field that error has
occurred and give chance to
. user to try.

Post condition The user login to their privileged page

Table 7 Description for Register address use case

Use case name Register address

Use case id Uc2
Description System allows tax payer to register address.
Participating actor Tax payer
Pre-condition The tax payer must have to login to the system.
The tax payer must fulfill whatever required information.

Flow of events Actor/user Action System Response

xxxvii
 Step 1.The tax payer Step 2. The system displays the
click the register registration address form
address link/button Step 4. The system validates
Step 3. Tax payer fill whether the submitted information
the form and click is correct or not.
register button Step 5: The system registers and
displays registration successful
Step 6:The use case ends

Alternative action Step1: The tax payer Step2: The system displays an
enters invalid error message and goes to text
information. field that error has occurred.

Post condition Tax payer address Registered successfully

Table 8 Use case description for Register expenditure use case

Use case name Register expenditure

Use case id Uc3
Description System allows tax payer to register expenditure.
Participating actor Tax payer
Pre-condition The tax payer must have to login to the system.
The tax payer must fulfill whatever required information.

Flow of events Actor/user Action System Response

Step 1.The tax payer Step 2. The system displays the
click the register registration expenditure form
expenditure Step 4. The system validates
link/button whether the submitted information
Step 3. Tax payer fill is correct or not.
the form and click Step 5: The system register and
register expenditure displays registration successful
button message.
xxxviii
 Step 6:The use case ends
Alternative action Step1: the tax payer Step2: the system displays an
enters invalid error message and goes to text
information. field that error has occurred.

Post condition Tax payer expenditure Registered successfully

Table 9 Use case description for Register daily sales

Use case name Register daily sales

Use case id Uc4
Description System allows tax payer to register daily sales.
Participating actor Tax payer
Pre-condition The tax payer must have to login to the system.
The tax payer must fulfill whatever required information.
Flow of events Actor/user Action System Response
Step 1.The tax payer Step 2. The system displays the
click the register daily registration daily sales form
sales link/button Step 4. The system validates
Step 3. tax payer fill whether the submitted information
the form and click is correct or not.
register daily sales Step 5: The system registers and
button displays registration successful
Step 6:The use case ends

Alternative action Step1: the tax payer Step2: the system displays an
enters invalid error message and goes to text
information. field that error has occurred.

Post condition Tax payer daily sales Registered successfully

Table 10 Use case description for Report sale information

Use case name Report sale information

xxxix
Use case id Uc5

Description System allows the tax payer to report sale information.

Participating actor Taxpayer
Pre-condition The tax payer must have to login to the system.
The tax payer must fill daily sale.
Flow of events Actor/user Action System Response
Step 1.The tax payer Step 2. The system display the
click report sale stored sale information
link/button. Step 4.system display reported
Step 3. Tax payer click successfully message.
report button. Step 5. use case end.

Alternative action ……………………

Post condition Reported successfully.

Table 11 Use case description for calculate daily sales

Use case name calculate daily sale

Use case id Uc6
Description System calculates daily sales.
Participating actor System
Pre-condition The tax payer must register daily sale.

Flow of events 1. The system calculate daily sale

2.System store calculated result in to the database
4. The use case ends
Alternative case …
Post condition Display calculated value.

Table 12 Use case description for create account

Use case name Create Account

Use case id Uc7
Description System allows the system admin to create account for
estimation committee.
Participating actor System admin

xl
 Pre-condition The system admin must have to login to the system.
The estimation committee must be employ of the organization.
Flow of events Actor/user Action System Response
Step 1. The system Step 2. The system display
admin click on create create account form.
account link/button. Step4: The systems checks the
Step 3. The system information is correct or not.
admin fill the form and Step5: Use case ends.
click submit button.
Alternative action Step1: The system Step2: The system display error
admin does not fulfill the message and return to goes to
required information. text field that error has occurred.

Post condition The estimation committee account is created.

Table 13 Use case description for manage account

Use case name update account

Use case id Uc8
Description System allows the user to update account.
Participating actor System admin, Taxpayer and Estimation Committee
Pre-condition The user must have to login to the system.
The user must be registered before.
Flow of events Actor/user Action System Response
Step1.The user clicks on Step2.The system displays
update account update account page.
link/button. Step4.The system verifies
Step3.The user update, validity of the user information
their account by inserting and response with success
necessary information. message.
Step5.Use case ends.

Alternative action Step1. The user enters Step2: the system displays an
invalid information while error message and goes to text

xli
 updating account. field that error has occurred.

Post condition The users account is updated successfully.

Table 14 Use case description for review taxpayer

Use case name Review

Use case id Uc9
Description System allows the user to review taxpayer activity.
Participating actor Estimation committee
Pre-condition The user must have to login to the system.
The tax payer must report daily sale.

Flow of events Actor/user Action System Response

Step1: Estimation Step2. The system display the
committee clicks on reported daily sale to estimation
review link/button. committee.
Step3: use case ends
Alternative action …………………………………
Post condition review taxpayer activity

Table 15 Use case description for view annual tax

Use case name View annual tax

Use case id Uc10
Description System allow the user to view annual tax
Participating actor Taxpayer, Estimation committee
Pre-condition The user must have to login to the system.
The tax payer must report daily sale.
The system calculate daily sale
The System calculate annual tax

Flow of events Actor/user Action System Response

xlii
 1.The user click view 2. The system display the
button calculated annual tax

Alternative action ……………………

Post condition View Annual tax

Table 16 Use case description for view annual tax

Use case name Calculate annual tax

Use case id Uc11
Description System calculates annual tax.
Participating actor System
Pre-condition The tax payer must register daily sale.
Flow of events 1. The system calculate annual tax
2.System store calculated annual tax in to the database
3. The use case ends
Post condition Display calculated value.

Table 17 Use case description for send notification

Use case name Send notification

Use case id Uc12

Description System allows the estimation committee to send notification.

Participating actor Estimation committee.
Pre-condition The estimation committee must have to login to the system.
The estimation committee review reported sale information.
Flow of events Actor/user Action System Response
Step 1.The estimation Step2: The system displays the
committee click send form to write notification.
notification link/button. Step4.system display send
Step3: The estimation successfully message.
committee writes Step 5. Use case end.
notification message in
the form and click on
send button.

xliii
 Alternative action Step1. The estimation Step2: The system displays an
committee does not error message and back to step3.
enter notification
message.
Post condition Notification sent successfully.

4.2.2.5 Sequence Diagram

Sequence diagram shows the sequence activities performed and their interactions among objects
and used to represent or model the flow of messages, events and actions between the objects or
components of a system. Sequence diagrams are also used primarily to design, document and
validate the architecture and interfaces of the system by describing the sequence of actions that
need to be performed to complete a task.

xliv
Actor Home page Login link System
Login controller
controller Login form Database

1.Browser()

2. click()

3.call()

4.create()
5. display the form()

6. fill user name, password and submit

7.return field information()

9. If invalid go to step 6() 8.validate

10. If Valid Login

11. display actor main page()

Figure 6 Sequence Diagram for Login

xlv
 Register address System Register address
Tax link controller form Database
payer

1. click()
2. Call()

3. create()

4. display the form()

5. fill form and submit()

6. return field
information()

7.validate
9. If Invalid Go To Step 5() form()

8 .if valid ADD()

10. successful message()

Figure 7 Sequence Diagram for register address

xlvi
 Register address System Register address
Tax link controller form Database
payer

1. click()
2. Call()

3. create()

4. display the form()

5. fill form and submit()

6. return field
information()

7.validate
9. If Invalid Go To Step 5() form()

8 .if valid ADD()

10. successful message()

Figure 8 Sequence Diagram for register expenditure

xlvii
 Report link System controller Database

Tax
payer
1. click()

2. call()

3. insert()

4. reported successfully

Figure 9 Sequence Diagram for report sales information

xlviii
 Register daily System Register daily Database
tax
sale link controller sales form
payer

1. click()

2. Call()

3. create()

4. display the form()

5. fill form and submit

6. return field
information()

9. if invalid go to 7.validate
step 5() form()

8. If Valid insert

10. successful message

Figure 10 Sequence Diagram for register daily sales

xlix
 System System controller link Database

1. intiation()

2. Report annual tax()

Figure 11 Sequence Diagram for report annual tax

l
 System System controller link Database

1. intiation()

2. Select daily sales()

3. Calculate()

4. store annual tax

Figure 12 Sequence Diagram for calculate annual tax

li
 Register daily System Register daily Database
tax
sale link controller sales form
payer

1. click()

2. Call()

3. create()

4. display the form()

5. fill form and submit

6. return field
information()

9. if invalid go to 7.validate
step 5() form()

8. If Valid insert

10. successful message

Figure 13Sequence Diagram for manage account

lii
 view notification
System System controller Database
link

1. Click()

2. Call()

3.select()

4. display notification()

Figure 14Sequence Diagram for view notification

liii
 System Notification
Notification Database
controller form
Estimation Link
Commite

1. click()
2. Call()

3. create()

4. display the form()

5. fill form and sent notification

6. return field
information()

9. if invalid Display 7.validate

error message form()

8. If Valid send to data base

10. Display successfully sent Notification

Figure 15Sequence Diagram for send notification

4.2.2.6Activity Diagram
Activity diagram is another important diagram in UML to describe the dynamic aspects of the

liv
System. Activity diagram is basically a flowchart to represent the flow from one activity to
another activity. The activity can be described as an operation of the system. The control flow is
drawn from one operation to another. This flow can be sequential, branched, or concurrent.
activity diagram is used to show message flow from one activity to another.

Browse Home
page

Click login
link

Fill user name

and password

Field invalid Display error

check message
valid

actor main
page displayed

Figure 16 Activity diagram for Log in

lv
 clik register
address link

open address
register form

Fill form

Field invalid Display error

check message
valid

succesfully registerd
message

Figure 17 Activity diagram for register address

lvi
 click register
expenditure link

open expenditure
register form

Fill form

Field invalid Display error

check message
valid

succesfully registerd
message

Figure 18 Activity diagram for register expenditure

lvii
 clik register
daily sales link

open daily sales

register form

Fill form

Field invalid Display error

check message
valid

succesfully registerd
message

Figure 19 Activity diagram for register daily sales

clik report sales

information link

Display succesfully
report message

lviii
Figure 20 Activity diagram for report sales information

clik create
account link

create accunt
form dispayed

Fill form

Field invalid Display error

check message
valid

succesfully created
message

Figure 21Activity diagram for create account

lix
 clik update
account link

update accunt
form dispayed

Fill form

Field invalid Display error

check message
valid

succesfully updated
message

Figure 22 Activity diagram for update account

lx
 clik review link

List pf report
display

Select report

View tax payer

information

Figure 23 Activity diagram for review taxpayer

lxi
 click view
notification link

List of notification
display

Select notification

View notification
succesfully

Figure 24 Activity diagram for view notification

lxii
 click view
annual tax link

View annual
tax
succesfully

Figure 25 Activity diagram for view annual tax

lxiii
 clik send
notification link

Notification text
field dispayed

Fill form

Field invalid Display error

check message
valid

succesfully sent
message

Figure 26 Activity diagram for send notification

lxiv
 4.2.2.7Analysisclassdiagram
a class diagram is diagram that describes the structure of a system by showing the systems
Classes, their attributes, operations (or methods) and the relationships among objects Class
Diagrams can also be used for data modeling. Class diagram has three components. The top
Component contains the name of the class. The middle components contain the attributes of the
class. The bottom component contains the operations the class can execute.

lxv
 Login

-username:
-password:

Tax payer Estimation commite

System Admin
-Fname: -first name:
-mname: -mname:: * 1 -username:
-lname : -Lname:
-address: -phone:
* 1͙*
-bussiness type:
-TIN: +send notification()
+review()
1
+view notification()
+report sales info() +update()
System
+view annual report()
+calculateAnnualTax() +update()
+register() *
+calculateDaily()
1͙.*
+reportAnnualTax()
1 1

News
Dailysales Manage
BussinessAddress -date:date
Expenditure
-date: +post() -fname:
-kebele:Stiring -date: +update -mname:
-item number:
-houseNo:intiger -item name: +setTaxPrice() -lname:
-amount:
-amount: -quantity +announcePaymentP
+create()
-quantity: eriod()
+activate()
+view
+deactivate()

Annual tax User help

+taxAmount:double +changeSetting()
+reportSalesInfo() +view()

Figure 27Class Analysis Diagram

lxvi
 4.2.2.8 User interface prototype
User interface flow diagram show the relationships between the major user interface
elements. Interface prototype describes the skeleton of the structural model of the system.
User interface prototype is used to determine gathering requirements for use case modeling,
domain modeling to determining the requirement of the system.

lxvii
 Registering daily sales and reporting calculated annual
tax(Tax Administration)
For Category ͟C͟Tax payer

Home Login Notification Contact us About us

Estimation Review tax

Tax payer System Admin
committee payer ativity

Register
Send
address Manage
notification
account
Register
expenditure

Register daily
sales

Report sales
information

View
notification

View annual
tax

Figure 28 user interface prototype

lxviii
 CHARTER FIVE

SYSTEM DESIGN

5.1 INTRODUCTION
System design is the process of planning a new business system or replacing an existing system
by defining its components or modules to satisfy the specific requirements. This chapter focuses
on transforming the analysis model into the design model that takes into account the non-
functional requirements and constraints described in the problem of the statement and
requirement analysis sections discussed earlier. The purpose of designing is to show the direction
how the system is built and to obtain clear and enough information needed to drive the actual
implementation of the system. It is based on understanding of the model the software built on. It
also the system to have high quality. Implementing of high quality system depend on the nature
of design created by the designer. We can change the system easily after deployment depends on
the quality of the system design, if the system is designed clearly and effectively.

5.2 Class Type Architecture

Since our system modeling approach is object oriented, we have to describe the system in terms
of its architecture. In this section we have demonstrated different types of class type
architectures; that represent a high level layering strategy for software application. The various
layers are represented by the rectangles and collaboration between layers indicated by the
arrows. The primary name of the layer is indicated first, and other common names indicated in
parenthesis.
1. Interface: This layer covers access to the system and system interface.There are two
categories of interface class-user interface (UI) classes that provide people access to the system
and system interface (SI) classes that provide access to external systems to the system.
2. Control/process layer: This layer represents controller/process class that implements
business logic that involves collaborating with several business or domain classes or even other
process classes.
3. Domain: This layer implements the concepts pertinent to your business domain such as

lxix
customer focusing on the data aspects of the business objects.
4. Persistence/Data layer: This layer is used to encapsulate the capacity to store, retrieve and
delete objects permanently without revealing details of the under laying storage technology.
5. System layer: This layer is used to represents system class that provides operating system
specific functionality for the applications.
Generally what we have explained in the above is described in the following form of
architecture.
User Interface (system interface)
- customer
-employee
-admin

Control/process layer
(Application, controller)
-Validate System User
System
(infrastructure
plat form)
Domain (Business)

Persistent classes (Data) Store

search Delete update

Database

Figure 29 Class type architecture

5.3 Class Modeling

The class modeling is the main building block of object-oriented modeling. It is used for
general conceptual modeling of the structure of the application, and for detailed modelling
translating the models into programming code. Class diagrams can also be used for data
modeling. The classes in a class diagram represent both the main elements, interactions in the

lxx
 application, and the classes to be programmed.

In the diagram, classes are represented with boxes that contain three compartments:

 The top compartment contains the name of the class. It is printed in bold and cantered,
and the first letter is capitalized.
 The middle compartment contains the attributes of the class. They are left-aligned and the
first letter is lower case.
 The bottom compartment contains the operations the class can execute. They are also
left-aligned and the first letter is lower case.
Components of class diagram

 Class
A class represents a relevant concept from the domain, a set of persons, objects, or ideas that are
depicted in the IT system. Class contains two component those are attribute and operation

 Relationship: is the relationship between two or more classes.

Association
An association represents a relationship between two classes. An association indicates
that objects of one class have a relationship with objects of another class, in which this
connection has a specifically defined meaning.

Generalization:-Generalization is a relationship between two classes: a general class and a

special class:

Aggregation
An aggregation is a special case of an association.

 Multiplicity
A multiplicity allows for statements about the number of objects that are involved in an
association:

lxxi
 Login

-username:Stiring
-password:Stiring
+Logout()

Tax payer Estimation commite

System Admin
-Fname:Stiring -first name:Stiring
-middle name::Stiring * -first name:stiring
-mname:Stiring 1
-lname:Stiring -last name:Stiring -middle name:Stiring
-address:Stiring -phone:Intiger -last name:Stiring
-bussiness 1͙* -phone:Intiger
*
type:Stiring +send notification() 1 +manage accont()
-TIN:Stiring +review +update()
System
+view notification() +update()
+calculateAnnualT +report sales info()
ax() +view annual report *
+calculateDaily() 1 * +update
+reportAnnualTax( +register 1
)
1

News

-date:date Manage
BussinessAddress
Expenditure Dailysales +post()
+update -fname:Stiring
-kebele:Stiring +date:date +date:date -mname:Stiring
-houseNo:intiger +setTaxPrice()
+item name:Stiring +itemnumbed:Stiring +announcePaymentP -lname:Stiring
+amount:double +amount:double eriod() +create()
+quantity:double +quantity +view +activate()
+deactivate()

Annual tax User help

-taxAmount:double +changeSetting()
+reportSalesInfo() +view()

Figure 30 Class modeling

lxxii
 5.4 State chart modeling
State chart modeling is a view of state machine that models the changing behaviour of state.
State chart diagram shows the various states that an object goes through, as well as the events
that cause a transition from one state to another.

Figure 31 State chart modeling for login

lxxiii
Figure 32 State chart modeling for registration

Figure 33 State chart modeling for registration

lxxiv
 Figure 34 State chart modeling for view notification

Figure 35 State chart modeling for review tax payer information

lxxv
 Figure 36 State chart modeling diagram for send notification

5.5 collaboration modeling

The class collaboration modeling describes interactions among objects in terms of sequenced
messages. Collaboration modeling’s represent a combination of information taken from class,
sequence and use case diagrams describing the static structure and dynamic behavior of a
system. The following diagram is class collaboration diagram for our system:

lxxvi
 Figure 37 Collaboration modeling for login

Figure 38 Collaboration modeling for register address

lxxvii
Figure 39 Collaboration modeling for register expenditure

Figure 40 Collaboration modeling for register daily sales

lxxviii
Figure 41 Collaboration modeling for report daily sale information

Figure 42 Collaboration modeling for send notification to tax payer

lxxix
 5.6 Component Modeling
Component modeling is implementation type modeling that are used to graphically depict the
graphical architecture of the software of the system. They can be used to show how the
programming code is divided into module or component and to depict the dependency between
those components.

The general purpose of component diagram can be summarized as: -visualize the components of
a system, construct executable by using forward and reverse engineering and describe the
organization and relationships of the components.

lxxx
Figure 43 Component modeling

lxxxi
 5.7 Deployment Modeling
Deployment diagram is implementation type diagram that describe the physical architecture of
the hard ware and the software in the system. They depict the software component, processor and
devices that make up the system architecture.
The purpose of deployment diagram in our project can be described as: visualize hardware
topology of the system, describe the hardware components used to deploy software components
and describe run time processing nodes.

lxxxii
Figure 44 Deployment modeling

lxxxiii
 5.8 Persistence Modeling
Persistence modeling is used to communicate the design of the database, usually the database to
all users and developers. This is basically the entity relation in database application. The
persistent classes are used to store most important and permanent information of the system. It
also used to describe the persistence data aspect of the system.

Login

-username:Stiring
-password:Stiring
+Logout()

Tax payer Estimation commite

System Admin
-Fname:Stiring -first name:Stiring
-middle name::Stiring * -first name:stiring
-mname:Stiring 1
-lname:Stiring -last name:Stiring -middle name:Stiring
-address:Stiring -phone:Intiger -last name:Stiring
-bussiness 1͙* -phone:Intiger
*
type:Stiring +send notification() 1 +manage accont()
-TIN:Stiring +review +update()
System
+view notification() +update()
+calculateAnnualT +report sales info()
ax() +view annual report *
+calculateDaily() 1 * +update
+reportAnnualTax( +register 1
)
1

News

-date:date Manage
BussinessAddress
Expenditure Dailysales +post()
+update -fname:Stiring
-kebele:Stiring +date:date +date:date -mname:Stiring
-houseNo:intiger +setTaxPrice()
+item name:Stiring +itemnumbed:Stiring +announcePaymentP -lname:Stiring
+amount:double +amount:double eriod() +create()
+quantity:double +quantity +view +activate()
+deactivate()

Annual tax User help

-taxAmount:double +changeSetting()
+reportSalesInfo() +view()

Figure 45 Persistence modeling

lxxxiv
 5.9 User Interface Design
User interface design focuses on what user need to do and ensuring that the interface has
elements that are easy to access. The goal of user interface design is to make the user’s
interaction as simple and efficient as possible, in terms of accomplishing user goals.

Figure 46 User interface design of home page

lxxxv
Figure 47 User interface design of tax payer

lxxxvi
LOGIN PAGE

Figure 48 User interface for login page

lxxxvii
 References

[1] B. Hailu, "Tax evaluation and adminstration in catagory C tax payers," p. 13, 2005.

[2] B. &. A. A. Belachew, Assesment of Catagory "C" Business Tax Payers' Perception On Tax ., 24.,
2007.

[3] W. WEGAYEHU, "AN ASSESSMENT OF CHANGE MANAGEMENT IN THE CASE OF ETHIOPIAN

REVENUE AND CUSTOMS AUTHORITY," p. 7, 2014 .

[4] K. D. Wolde, "Factors Affecting Tax Compliance of Small and Medium Business Profit Taxpayers
in Addis Ababa," p. 11, 2016.

[5] M. &. T. T. Kebede, Problem Associated With Tax Payers And Revenu Authority, 25, 2016.

[6] K. Escarfullet and C. Jantzen, "Development of A Mobile Tax System With Usability Features,"
University of West Florida, pp. 66-70, 2013.

[7] G. Njenga, Mobile Based Country Revenue Collection System., 76., 2017.

[8] A. Young, Value Added Tax In Developing And Transition Countries. Bird R,, 05., 2005.

http://www.tutorialspoint.com/object_oriented_analysis_design/ooad_object_orie
nted_system analaysis design

http://www.tutorialspoint.com/uml/uml_component_diagram.htm

http://www.tutorialspoint.com/uml/uml_class_diagram.htm

http://www.tutorialspoint.com/uml/uml_standard_diagrams.htm

lxxxviii
Approval sheet

This is certify that the final year industrial project proposal prepared by group 7 entitled Web and android
based Tax Administration System(Registering Daily Sales and Calculate Annual tax) for category “c” tax
payers submitted in partial fulfillment of the requirements for the Bachelor of Science Degree in
Information System complies with the regulations of the university and meets the accepted standards
with respect to originality and quality.

Signed by the Examining Committee:

Name Signature Date

Advisor:

Examiner:

Examiner:

Wolaita sodo University

Wolaita, Ethiopia

February,2020

lxxxix
xc