Employee Df the Month Certificate

Description

Employee Df the Month Certificate document sample

Shared by: quf19830

Tags

Stats

views:: 148
posted:: 1/29/2011
language:: English
pages:: 63

Public Domain

Document Sample

(A Project Report Submitted in partial fulfillment of the requirements for the award of
the degree of B.Tech.)

Employee State Insurance Corporation
(Employee Registration Module)

Developed for National Informatics Center (NIC)
New Delhi

Submitted by: Madhur Ahuja

University Roll No: 226085951
College Roll No: 411/02

Under the guidance of: -

Sh. Sanjay Kumar, Scientist „C‟
National Informatics Center, New Delhi.

Department Information Technology
D.A.V. Institute of Engineering and Technology
Jalandhar, (Punjab)
(Affiliated to Punjab Technical University)
Government of India
Ministry Of Communications & Information Technology
Department Of Information Technology

National Informatics Centre
This is to certify that Mr. Madhur Ahuja, ID.N0 7692 a student of Bachelor of

Information Technology (VIIth Semester) from Punjab Technical University (PTU),

Jalandhar has done his full-semester project training at Training Division, NIC, New

Delhi, from 15th July 2005 to 10th January 2006.

The project work entitled “Employee Registration Module under ESIC Project”

embodies the original work done by Mr. Madhur Ahuja during his above full semester

project training period.

Project Guide/HOD Head, Training Division
Abstract

The project has been developed to fulfill the requirements of the Employees’ State Insurance
Corporation (ESIC). The current product is a part of overall web-based Employee Registration
under ESIC .The product will take care of government employees, their employers and various
facilities provided them by government under ESI Act. Subsequently the following points were as
the broad features required in the software to be developed for Employees’ State Insurance
Corporation Computerization at National Level with a facility to meet the additional /local
requirements of the respective States.

 Declaration Form submitted by employee registered under a principal employer or
secondary employer
 Generation of Various Cards for the Employee and IPCode
 Maintenance of Allotment Register to track the progress of registration Process
 Allowing Deletions and Updations in the Record of employees
 Authentication and Authorization of various employers, clerks and employees

The work done on the module is adhering to sound software engineering principles .All phases of
the software development lifecycle, namely System Analysis, System Design , Testing and
Implementation have been carried out in a systematic manner . the tools and technologies is
used for developing the software are php and MVC Frameworks on apache Web Server and
Postgresql Database Server at Linux Platform and tool used is Macromedia Dreamweaver.

Keywords.
1. ESIC= employee state insurance corporation
2. MVC= model view controller
3. Employer= the one who setups industry
4. Employee= one who works for employer
5. Registration=one who search for employer registration
6. ACID=atomicity, consistency, isolation, durability
7. PHP=hypertext preprocessor
8. Insurance =one who search for insurance
Acknowledgement
I deeply acknowledge the efforts of my parents and my colleagues who contributed
for the successful completion of my project work.

I would like to express my gratitude to Mrs. JRD Kailey, Senior Technical Director,
NIC to allow us to work on a project of this magnitude.

I would like to thank my external project guide Mr. Sanjay Kumar Scientist „C‟ for his
guidance, which was instrumental in the development of the Project. He gave us all
the support, required.

I am highly thankful to Director, Ministry of Labour for taking Interest in the Project.
It has been a pleasure to work with the staff of NIC. I am highly obliged.

Madhur Ahuja
(B.Tech. VIIth Semester)
Table of Contents
o About NIC

o Project Description

o Component Assigned Description

o Tools and Technology used

o SRS of the Component

o Design of the Component

o Testing

o Conclusion

o Annexure
About NIC
About NIC
National Informatics Center (NIC) of the Department of Information Technology is providing
network backbone and e-Governance support to Central Government, State Governments, UT
Administrations, Districts and other Government bodies. It offers a wide range of ICT services
including Nationwide Communication Network for decentralized planning, improvement in
Government services and wider transparency of national and local Governments. NIC assists in
implementing Information Technology Projects, in close collaboration with Central and State
Governments, in the areas of (a) Centrally sponsored schemes and Central sector schemes, (b)
State sector and State sponsored projects, and (c) District Administration sponsored projects.
NIC endeavors to ensure that the latest technology in all areas of IT is available to its users.

NIC Headquarters is based in New Delhi. At NIC Headquarters, a large number of Application
Divisions exist which provide total Informatics Support to the Ministries and Departments of the
Central Government. NIC computer cells are located in almost all the Ministry Bhawans of the
Central Government and Apex Offices including the Prime Minister’s Office, the Rashtrapati
Bhawan and the Parliament House. Apart from this, NIC has various Resource Divisions at the
Headquarters, which specialize into different areas of IT and facilitate the Application Divisions as
well as other NIC Centres in providing state-of-the-art services to the Govt.

At the State level, Nics State/UTs Units provide informatics support to their respective State
Government and at the District level lie the NIC District Informatics Offices.

NIC has conceptualized, developed and implemented a very large number of projects for various
Central and State Government Ministries, Departments and Organizations. Many of these
projects are continuing projects being carried out by various divisions of NIC at New Delhi
Headquarters and State/District centers throughout the country. Some of the most important note
worthy projects, which offer a glimpse of the multifaceted, diverse activities of NIC, touching upon
all spheres of e-governance and thereby influencing the lives of millions of citizens of India are
given below:

o Agricultural Marketing Information Network (AGMARKNET)
o Central Passport System
o Community Information Centres (CICs)
o Computerized Rural Information Systems Project (CRISP)
o Court Information System (COURTIS)
o Department of Agriculture Network (DACNET)
o Examination Results Portal
o India Image
o Land Records Information System (LRIS)
o National Hazardous Waste Information System (NHWIS)
o Public Grievance Redress and Monitoring System (PGRAMS)
o Spatial Data Infrastructure (SDI)
o Training
o Video Conferencing

Web Site of NIC: -http://indiaimage.nic.in/
Project Description
Project Description
Input
1. Source of information regarding Employees

(a). Declaration Form submitted by Employer or Employee.
(b). Employee Photograph and Family Photograph.

2. Other Information required prior to Declaration Form

(a). Regional Office Code
(b). Employer Code
(c). Branch
(d). Employee Code Extension

Processing

1. Phase A (Declaration Form)

(a). Entry in Employee database.
(b). Validating Input.
(c). Generation of IP Code.

2. Phase B (Declaration Form & Dependant Entry Form)

(a). Entry of Dependants.
(b). Issue of Temporary ID Card.

In case the Declaration Forms are in order in al respect the Branch office will allot the
Insurance Number (2 digit Regional Office Code + 8 digit of running serial Number)
and returns the copy of the declaration Form (lower portion of declaration form)
indicating Insurance Number and the Temporary Identity Card (valid for 13 weeks)
which contains the Dispensary name, Employer name and Number and other details
of Employee to the employer who in turn hands over the TIC to the Insured Person

DF should be submitted within 10 days from the date of appointment otherwise a
letter (Letter No. 1) is sent to the Employer from Local Office indicating that late
submission should not be repeated in the future.

If even after this letter the employer again does the same mistake then a Letter No.2
and then subsequently a Letter No. 3 is sent by the Manager of the Local office
indicating the same grievance. In spite of these letters if again the employer does the
same action then a Show cause Notice is sent from the Regional Director of Regional
Office under section 85 for committing breach of Regulation 14 of the ESI (General)
Regulation.
(c). Check List for Declaration Forms (DF):

o To watch whether all the DFs have been received in case of new coverage. If
not, follow up action.
o If, DFs are not submitted within 10 days from the date of appointment.
o Where family of employee is residing separately or in other state/area.
o Preparation of PICs, within 13 weeks.
o Preparation of separate card & MREs for I.Ps on account of Permanent
Disablement Under Rule 60 & for Retired I.Ps Under Rule 61.

3. Phase C (Allotment Register)

(a). Entry in Allotment Register.

Allotment Register is meant to Record the Status of Processing of ID Cards for
Registered Employees.

If the D.F. is in order then an entry is made in the Allotment Register. In case the
declaration form is not in order then a deficiency letter is sent to the Employer along
with incomplete D.F.

(The date of preparation of various documents and the date of dispatch of documents are
maintained in a separate Register. The format of the Register is as given below)

Date of preparation of documents Date of dispatch of documents Remarks
ID MRE Index Index Medical ID MRE Index Index Medical
Card card (in Sheets acceptance Card card (in Sheets acceptance
case of cards (in case of cards (in
panel case of panel case of
system) panel system) panel
system) system)
9(a) 9(b) 9(c) 9(d) 9(e) 10(a) 10(b) 10(c) 10(d) 10(e) 11

4. Phase D (Duplicate ID Card)

Duplicate Identity cards can be issued to the Insured Person in the following
circumstances:

(i) On loss
(ii) On destruction
(iii) On defacement

The IP will have to submit ESIC-72 form to the manager of the Local Office. In case the
ID Card is issued more than 3 years, the Duplicate ID card was issued free of cost else
the nominal fee of Rs. 1/- is taken from the IP. In the present system the particulars of the
members of the family are to be given.
An entry is made in the Local office Register of Duplicate Identity card. The format of the
same is given below:

(Local office Register of Duplicate Identity Card)
The register of DIC will be maintained in the following format.
S.

Name of the insured person to

Date of sending intimation to
No
.

Date of delivery of card
Sl. No. of card issued

Sig. of Insured person
Amount of fees paid

Receipt No. & Date
Date of Application

Initials of Manager
whom card issued

Insurance No.

Remarks if any
Date of Entry

IMO/IMP
1 2 3 4 5 6 7 8 9 10 11 12 13

At the end of the day the number of duplicate ID card issued and the amount collected is
to be tallied and the amount is to be deposited.

At the end of each month, a summary of DICs received and issued will be drawn up in
the register with the following column.

Whenever a duplicate identity card is issued to an insured person, intimation to this effect
is sent to IMO/IMP concerned.

In case the employee does not have the Temporary/Permanent Identity card or the
Temporary ID. Card was issued to the IP but it is lost/destroyed and he wants to get the
medical benefit then the employer gives the Certificate of Employment (Form ESIC 86)
so that he/she can get the medical benefit. This also facilitates a newly insured person to
avail medical benefit under that scheme in absence of an identity certificate/identity card.

5. Phase E (Request from IP for Changes/Addition/Deletion)

Changes are classified in following categories:

o General Changes
o Nominee Changes
o Address Changes

General Changes
o Change of Name
o Change of Marital Status
o Change of Regional Office
o Change of Branch

Nominee Changes
o All Nominee Details
Address Changes
o Address Change for employee

Whenever the change is brought about by the clerk, first its intimation goes to the
Administrator/Higher Authority than after he/she approves the change request, the
change is registered permanently.
And if the change request is denied, the change request is deleted from temporary
tables.

6. Phase F (Issue of permanent IC and Issue of MRE)

1. The Branch office sends the Data for insured Person form for the creation of
Permanent Identity card to outside agency, which is nominated, by the regional
office. The IP Number is of 10 digit the first 2 digit is for Regional Office and the rest 8
characters is a running serial number from the block of numbers allocated to Branch
office. Each Branch office is given a Block of numbers, which are allotted to IP. There
are separate Blocks for Male and Female IP’s. Once the Identity card is prepared the
Local Office informs the Employer on ESIC-125 regarding the distribution of Identity
Cards to Employees. It was also requested that if the Employee has left the service
before the completion of 13 weeks then all such cards might be returned back.
2. The Medical Record Envelope (MRE) is created for the employee and sent to the
respective Dispensary. Preparation of separate card & MREs for I.Ps on account of
Permanent Disablement Under Rule 60 & for Retired I.Ps Under Rule 61.

3. Alternative flow for creation of MRE: In case the dispensary does not have the MRE
of the employee in their dispensary as indicated on its Identification Card, the
dispensary (Medical Officer in charge) gives a request letter through employee to the
branch office to issue the MRE.

Output
1. Employee Database
2. Employee Code
3. Temporary ID Card
4. Permanent ID Card
5. Index Card
6. MRE
7. BO Wise List of Employee IP
8. List of Employers and its Employees
9. Deficiency Letter
10. Detailed Report of Employees with photograph on the input of IP Code
Component Assigned Description
Component Assigned Description

Employee Registration

Declaration Form from Employer & TIC Form1

Employer who is already registered with Regional Office of ESIC sends the
Declaration forms, including the temporary identification certificates, accompanied by the
return of Declaration Form in duplicate to the Local Office along with the two postcard size
family photographs of every individual employee. DF should be submitted within 10 days from
the date of appointment otherwise a letter (Letter No. 1) is sent to the Employer from Local
Office indicating that late submission should not be repeated in the future.
If even after this letter the employer again does the same mistake then a Letter No.2
and then subsequently a Letter No. 3 is sent by the Manager of the Local office indicating the
same grievance. In spite of these letters if again the employer does the same action then a
Show cause Notice is sent from the Regional Director of Regional Office under section 85 for
committing breach of Regulation 14 of the ESI (General) Regulation.

When the declaration form Form1accompanied by the return are received at the Local
Office, the registration clerk checks that all the forms listed in the return have been attached.
If any form is missing, a remark is given to that effect against the name of the employee on
both the copies of the return. The registration clerk will then enters the installment in the
combined register of declaration forms-cum-allotment of Insurance Numbers-cum preparation
of documents to be maintained in the following Performa. A Separate registers being
maintained for male and female

Format for the declaration forms-cum-allotment of Insurance Numbers-cum preparation
of documents

S. No. Date of Return of Declaration Name of Employer Code Number
forms
1 2 3 4

Number of Declaration Forms Insurance Number Date of Signature
Allotted dispatch of of Head
Received Found Found in From To temporary Clerk/
defective order identification Manager
and certificates
returned
to
employer
5(a) 5(b) 5(c) 6(a) 6(b) 7 8

If the D.F. is in order then an entry is made in the Allotment Register. In case the
declaration form is not in order then a deficiency letter is sent to the Employer along
with incomplete D.F.
Check List for Declaration Forms (DF):

a) To watch whether all the DFs have been received in case of new coverage. If
not, follow up action.
b) If DFs are not submitted within 10 days from the date of appointment.
c) Where family of employee is residing separately or in other state/area.
d) Preparation of PICs within 13 weeks.
e) Preparation of separate card & MREs for I.Ps on account of Permanent
Disablement Under Rule 60 & for Retired I.Ps Under Rule 61.

In case the Declaration Forms are in order in al respect the Branch office will allot the
Insurance Number (2 digit Regional Office Code + 8 digit of running serial Number) and
returns the copy of the declaration Form (lower portion of declaration form) indicating
Insurance Number and the Temporary Identity Card (valid for 13 weeks) which contains the
Dispensary name, Employer name and Number and other details of Employee to the
employer who in turn hands over the TIC to the Insured Person.

The date of preparation of various documents and the date of dispatch of documents are
maintained in a separate Register. The format of the Register is as given below:

1. In case for creation of Duplicate Identity card the employee has to fill up Form ESIC-72.

Issue of Permanent IC & creation of MRE

4. The Branch office sends the Data for insured Person form for the creation of
Permanent Identity card to outside agency, which is nominated, by the regional
office. The IP Number is of 10 digit the first 2 digit is for Regional Office and the rest 8
character is a running serial number from the block of numbers allocated to Branch
office. Each Branch office is given a Block of numbers, which are allotted to IP. There
are separate Blocks for Male and Female IP’s. Once the Identity card are prepared
the Local Office informs the Employer on ESIC-125 regarding the distribution of
Identity Cards to Employees. It was also requested that if the Employee has left the
service before the completion of 13 weeks then all such cards may be returned back.
5. The Medical Record Envelope (MRE) is created for the employee (Blue coloured one
Male and Red coloured for Female employee) and sent to the respective Dispensary.
Preparation of separate card & MREs for I.Ps on account of Permanent Disablement
Under Rule 60 & for Retired I.Ps Under Rule 61.

6. Alternative flow for creation of MRE: In case the dispensary does not have the MRE
of the employee in their dispensary as indicated on its Identification Card, the
dispensary (Medical Officer in charge) gives a request letter through employee to the
branch office to issue the MRE.

ESIC-86, Duplicate ID Card

Duplicate Identity cards can be issued to the Insured Person in the following circumstances:

(iv) on loss
(v) on defacement
(vi) on destruction

The IP will have to submit ESIC-72 form to the manager of the Local Office. In case the ID
Card is issued more than 3 years, the Duplicate ID card was issued free of cost else the
nominal fee of Rs. 1/- is taken from the IP. In the present system the particulars of the
members of the family are to be given.

An entry is made in the Local office Register of Duplicate Identity card. The format of the
same is given below:

Local office Register of Duplicate Identity card

The register of DIC will be maintained in the following format.
S.
Name of the insured person to

Date of sending intimation to

No
.
Sig. of Insured person

Remarks if any
Date of delivery of card
Sl. No. of card issued
Amount of fees paid

Receipt No. & Date
Date of Application

Initials of Manager
whom card issued

Insurance No.
Date of Entry

IMO/IMP

1 2 3 4 5 6 7 8 9 10 11 12 13

At the end of the day the number of duplicate ID card issued and the amount collected is
to be tallied and the amount is to be deposited.

At the end of each month, a summary of DICs received and issued will be drawn up in the
register with the following column.
Summary of DICs Received and Issued During ________

Priced Cards Free Cards
From Sl. No. To Sl. No. Total From Sl. No. To Sl. No. Total

Opening Balance
Received during Month
Grand Total
Issued:
at Local Office
at pay office
Stock transferred to Local Office(s)
spoilt Cards
Total
Balance in hand
Closing stocks as above physically verified and found correct.

Manager

Whenever a duplicate identity card is issued to an insured person, intimation to this effect is
sent to IMO/IMP concerned.

In case the employee does not have the Temporary/Permanent Identity card or the
Temporary ID. card was issued to the IP but it is lost/destroyed and he wants to get the
medical benefit then the employer gives the Certificate of Employment (Form ESIC 86) so
that he/she can get the medical benefit. This also facilitates a newly insured person to avail
medical benefit under that scheme in absence of an identity certificate/identity card.

Request from I.P. for changes/alteration/addition or deletion etc

a). Change in the Branch Office:
The IP sends an application for change in Local office in the Form ESIC-53.
The Format for this is as follows:
ESIC-53
Insurance No. Employer Code No.
Name of Insured Person
Address
To,
The R.D., ESI Corporation

Sir,
I request you to please change my allotment as follows and/or to carry out the following
changes in my records:-
(1) From Branch Office__________ to Branch Office__________________
(2) From _______________ to Dispensary ___________________
(3) From _______________ to ____________________________
Reason for change ___________________________________________________
Signature of Insured Person

The Regional office sends the intimation of this effect to the Branch Manager (old) of the
IP who has all the documents of IP with a request that documents of the I.P. may be
transferred immediately to the NEW Local Office. Also IMO In-charge is requested to
transfer the record of insured person to the new Dispensary with the information to the
IMO of the new dispensary. AMO is also informed.

The Employer is also given the information so as to change the record accordingly.
Regional office is also intimated for necessary action. In case of change for the Regional
Office both the new and old regional offices are informed about these changes and Local
Office as well as Dispensary are changed. This intimation is given in the form ESIC-54.
In such cases a photocopy of the Return of Contribution is to be submitted to the New
Local Office by the Employer.

(b) Change of Dispensary/Change in Regional Office: same procedure as above

(c) Entry of marital status/ Addition/Deletion of family members:
In case of events marriage, birth or death the employer informs the Local office within 15
days for addition or deletion of beneficiary. Form 1-B (Regulation 15-B) is submitted by the IP
counter signed by the employer in that case.

(d) Change of Employment: In case of change of employment under the same regional office the

Other changes required are:

(i) Change of name
(ii) Change of residential address
(iii) Change of nominee
(iv) Change of region

Index card preparation for the case where Medical Dispensary NOT there:

In those cases where the Medical dispensary is not there an Index card (ESIC-2) is prepared
instead of MRE and then sent to the Director (Health services) of that state. The Director
Health Services has empanelled Doctors and the IP is attached to one of the empanelled
Doctor. ESIC pays to the State Government and then the Director health services in turn
pays to the empanelled doctor based on the per Index card of the IPs’. Live list is sent to the
Director Health Services so as to decide the eligibility of IPs based on the contribution pay by
the Employer.

Format of Index Card:
ESIC-2
EMPOYEES’ STATE INSURANCE CORPORATION
EMPLOYEE’S INDEX CARD
Insurance No. Employers’ code No.
Name Father’s/Husband’s
Name
Sex M/F Status Year of Birth
Date of Entry
Branch Office Dispensary/IMP
Present Address
Identification Marks

Back side of Index Card
Date of Exit Sl. No. Initial of IMP Date of re- Sl. No Initial of IMP
Entry
Technology Used
Tools and Technology Used

Tools Used
Hardware
o Intel Pentium 4 2.4 GHz
o 256 MB RAM

Software
o Macromedia Dreamweaver MX 2004 (Editor)
o CuteFTP Professional 7.0

Operating System
o Client at Microsoft Windows 2000 Professional
o Server at Linux 9

Technology used

Introduction to php.MVC
Php.MVC implements the model-view-controller (MVC) design pattern, and encourages
application design based on the model 2 paradigm. This design model allows the web
page or other contents (view) to be mostly separated from the internal application code
(controller/model), making it easier for designers and programmers to focus on their
respective areas of expertise.

The framework provides a single entry point controller. The controller is responsible for
allocating http requests to the appropriate action handler (model) based on configuration
mappings.

The model contains the business logic for the application. The controller then forwards
the request to the appropriate view component, which is usually implemented using a
combination of html with php tags in the form of templates. The resulting contents are
returned to the client browser, or via another protocol such as smtp.

Php.MVC is a php port of Jakarta struts. It currently supports many features of struts,
including declarative application configuration via the xml digester. For example,
mappings from the various action business logic components to appropriate results
pages can be specified declaratively in the xml configuration file.

The diagram below shows a high-level overview of the framework:
Figure 1: The php.MVC Conceptual Overview
As can be seen in figure 1, the framework consists of three main components: The Front
Controller, the main Controller and the request Dispatcher. We will look at each of these
components in more detail shortly.
The Benefits

The Model-View-Controller pattern for Web application design is now an industry
standard in the Java world. There are many excellent books and resources available on
the subject, which help to speed the learning process for the development team.

o Increases developer/designer role separation
o Increases code manageability
o Increase code extensibility (Ability to adapt to change)
o Why not build your own framework:
o This is not a trivial undertaking
o Can you to justify the time and expense
o The php.MVC Open source license gives you complete access to the source code
o php.MVC framework knowledge learned are transferable to Jakarta Struts
o Skills in non-standard frameworks may not be as marketable
o Experienced Struts developers should quickly become productive using php.MVC
o php.MVC is based on the industry standard and field proven Jakarta Struts. Why re-
invent the wheel?

The MVC Pattern Concepts

The php.MVC framework consists of a complex arrangement of many classes. Luckily we
do not need to know in great detail how all these classes work, in order to use the
framework. The diagram below shows the core components we need to know about in
order to get started working with the framework: Figure 2: The MVC Request/Response
Pipeline In Figure 2 we can see the how a typical HTTP request from a Web client (Web
browser) would interact with the core framework classes and our application classes, to
produce a HTTP response(Web content) to return to the Web client.

Database - postgreSQL

PostgreSQL is an object-relational database management system (ORDBMS) based on
POSTGRES, Version 4.21, developed at the University of California at Berkeley Computer
Science Department. POSTGRES pioneered many concepts that only became available in some
commercial database systems much later.

PostgreSQL is an open-source descendant of this original Berkeley code. It supports a large part
of the SQL:2003 standard and offers many modern features:

• complex queries
• foreign keys
• triggers
• views
• transactional integrity
• multiversion concurrency control

Also, PostgreSQL, can be extended by the user in many ways, for example by adding new

• data types
• functions
• operators
• aggregate functions
• index methods
Software Requirement Specification
Software Requirement Specification
Introduction
Employees’ State Insurance Scheme of India is an integrated social security scheme tailored to
provide social protection to workers in the organised sector and their dependants in
contingencies, such as, sickness, maternity or death and disablement due to an employment
injury or occupational disease. The scheme tailored to suit health insurance requirements of
workers provides full medical facilities to insured persons and their dependants, as well as, cash
benefits to compensate for loss of wages or earning capacity in different contingencies.

As provided under the ESI Act, the scheme is administered by the Employees’ State Insurance
Corporation (ESIC), a corporate body duly constituted under the Parliament Act. Union Minister
of Labour functions as Chairman of the Corporation whereas Director General as chief executive
discharges the duty of running the day-to-day administration. The ESIC body comprises members
representing Central and State Governments, Employers, Employees, Parliament and the
Medical professional.

ESIC has the mandate to provide health insurance to employees of factories and
establishments covered under the ESI Act. The services include health care facilities and
cash benefit as compensation to insured persons. There are about 2.5 lakh factories and
establishments registered through 34 regional offices and over 80 lakh employees of these
organizations serviced through 808 branch offices of ESIC, over 1400 Dispensaries and
141 Hospitals of ESIC spread across length and breadth of India.
A Standing Committee representing all stakeholders is elected from the body corporate for
managing the affairs of the scheme and monitoring the progress of implementation of various
decisions and policies etc. from time to time. The Medical Benefit Council, a statutory body
advises the Corporation on matters related to administration of medical benefit under the
Employees’ State Insurance scheme of India.

Structure
1. Organisational Structure
2. Functional Structure

Roles and Services
In delivery of benefits to Insured Person

The ESIC is to ensure that:

The quality and quantity of benefits is as per norms and standards laid down by the
Corporation for the purpose.
The benefits are made available within the given time frame to insured persons and
beneficiaries.
No harassment is caused to the beneficiaries across the counter at the grass root level
by way of word or deed.
All requisite information, procedural guidance etc. is made available to the beneficiaries
for claiming benefits.
All types of forms etc. are made available to the beneficiaries free of cost as may be
required by them for filing claims etc.
No beneficiary is exploited at any level in the process of delivery of benefits.
Office hours as notified for ESIC/ESIS establishments are strictly adhered to by the staff
so as to avoid any inconvenience being caused to the beneficiaries in smooth flow of
benefits.
Drugs, dressings, injections etc. as prescribed by the authorised doctors are made
available timely.

Services to Employers
To develop a responsive, purposive and productive relationship with employers.
Seek their active involvement in the improvement of the scheme as a confidence building
measure.

Provide them necessary guidance in fulfilling their lawful obligations under the ESI Act.
Make available to them requisite Forms and Performa as may be required by them from
time to time.

To ensure that any lax medical certification on part of ESIC does not bring down the
productivity of a factory or establishment.

To ensure that in case of any difficulty, doubt or misunderstanding employer is given a
chance to be heard at an appropriate level.
To ensure that all correspondence emanating from the employer is responded to, timely and
objectively.
To ensure that an employer is not being harassed by any official of the Corporation authorised to
inspect the premises or the records.
To ensure that any grievances received from employers are looked into promptly and pointedly
for speedy redressal.

Infrastructure

The central headquarters of the Corporation is located at New Delhi. For purpose of
coverage, revenue collection, extension of the scheme to new classes of establishments,
implementation of the scheme in new areas, co-ordination with the State Governments
and general administration the Corporation has established Regional and sub-Regional
Offices across the country mostly located in State capitals.

Given the huge number of beneficiaries – about 340 lakh now – the Corporation has set
up a wide spread network of service outlets for prompt delivery of benefits in cash and
kind that includes full medical care.

Medical facilities are provided through a network of 1452 ESI Dispensaries, about 3000
Panel Clinics, 307 diagnostic centres besides 140 ESI hospitals and 43 hospital annexes
with over 26000 beds. For providing super specialist medical care the Corporation has
tie up arrangements with advanced medical institutions in the country, both in public and
private sector. The medical benefit is administered with the active co-operation of State
Governments.
The payment of cash benefits is made at the gross roots level through as many as 800
Local Offices and Cash Offices that function under the direct control of the Corporation.

Revenue and Expenditure

The source of revenue of ESIC is mainly by contributions from employers and
employees. The employers’ contribution is equal to four and three fourth per cent of the
wages payable to employees. The employees’ contribution is at the rate of one and
three-fourth per cent of the wages payable to an employee. The State Governments
share expenditure on the provision of medical care. The rates of contribution are: -
(i). Employees’ Contribution: - 1.75 percent of wages
(ii). Employers’ Contribution: - 4.75 percent of wages

Purpose

The SRS provides an organized way to collect all software requirements surrounding
ESIC Schemes into one document. The complete set of requirements may indeed be
found in several different artifacts accessible by multiple tools.
1. Tools for use-case
2. Traditionally stated natural-language requirements (such as non-functional
requirements, design constraints, etc.) with a word processing tool in “supplementary
specifications”.

The “SRS package” controls the evolution of the system throughout the development and
release phases of the project. In the Unified process, the following actors use the SRS
package:
 The system analyst creates and maintains the Vision, the use-case model overview
and supplementary specifications, which serve as input to the SRS and are the
communication medium between the system analyst, the customer, and other
developers.
 The use-case specifier creates and maintains the individual use cases of the use-
case model and other components of the SRS package,
 Designers use the SRS Package as a reference when defining responsibilities,
operations, and attributes on classes, and when adjusting classes to the
implementation environment.
 Implementers refer to the SRS Package for input when implementing classes.
 The project manager refers to the SRS Package for input when planning iterations.
 The testers use the SRS Package to verify system compliance.

From Vision to SRS
In the Requirements workflow of the Unified Process, our requirements artifact structure
starts with an artifact called the Vision which describes the user's view of the product to
be developed, specified at the level of key user needs and features of the system.
The SRS Package is obviously related to the Vision document. Indeed, the Vision
document serves as the input to the SRS. But the two artifacts serve different needs. At
this stage in the project, the focus of the project moves from the broad statement of user
needs, goals and objectives, target markets and features of the system to the details of
how these features are going to be implemented in the solution.
Design of Component
Design of Component
1. Functional Decomposition Diagram

2. Entity Relationship Diagram
3. Data Flow Diagrams

(a). Declaration Form (Used for Registration of Employees)

(b). Change IP Details Form (Requests for Changes in Employee Details)

(c). Duplicate ID Form (Used to issue duplicate ID Cards to Employees)

(d). Allotment Form (Used to keep record of status of issuing various documents to IPs)
4. Data Base Design

IP Table is used to store Employees’ Details

Database Name: INSURANCE
Table Name: IP
S.N Field Name Data Type Description Defaul Rem.
o t Value
1. EmployerCode Char(12) PRIMARY
Employer Code
2. IPCode Char(8)
I. P. Number
3. TempIPCode Char(8)
Temp I. P. Number
4. Branch Char(3)
Local Office
5. IPName Varchar(50)
IP Name
6. IPDoB DateTime
IP DOB
7. IPGender Char(1)
Male/Female
8. IPMaritalStat Char(1)
Marital Status
9. IPFHName VarChar(50)
Father/ Husband Name
10. Address1 VarChar(40) Address First Line
11. Address2 VarChar(40) Address Second Line
12. Address3 VarChar(40) Address Third Line
13. District Char(3) District
14. State Char(2) State
15. PINCode Char(6) PIN Code
16. NomineeName VarChar(50)
Nominee Name
17. NomineeDoB DateTime
Nominee DOB
18. NomineeFHName VarChar(50) Nominee Father Husband
Name
19. NomineeRelation Char(3)
Relationship with IP
20. NomineeAddress1 VarChar(40) Address First Line
21. NomineeAddress2 VarChar(40) Address Second Line
22. NomineeAddress3 VarChar(40) Address Third Line
23. NomineeDistrict Char(3) District
24. NomineeState Char(2) State
25. NomineePINCode Char(6) PIN Code
26. VarChar(200)
IDMarkIP ID Mark of IP
27. FamilyStays Char(1) Whether family of IP stays
with IP
28. Disp_Panel Char(1) Whether Dispensary or D D for Dispensary
Panel System & P for Panel
29. DispCode Char(3)
Dispensary Code
30. Remarks VarChar(250)
Remarks
31. DtAppoint Date
Date of Appointment
32. DOE Date
Date of Entry
33. DirectContract Char(1) Direct or Contract basis D D for Direct & C
for contract
34. Department VarChar(50)
Department
35. NatureofWork VarChar(250)
Nature of Work
36. ECodeExtn Char(12) 0
Employer Extended Office
37. SubCode Integer Number of Registered
Offices

IPDependants Table is used to store Dependants’ Details
Database Name: INSURANCE
Table Name: IPDependents
S Field Name Data Type Description Defaul Rem.
. t Value
N
o
1 IPCode Char(8) PRIMARY
.
I. P. Number
2 TempIPCode Char(8)
.
Temp I. P. Number
3 FamilySLNo Integer
.
Serial Number of IP
4 DependentName VarChar(50)
.
Dependent Name
5 DependentDOB DateTime
.
Dependent Date of Birth
6 StaysWith Char(1) Y
.
Stays with IP (Y/N)
7 Relationship Char(1)
.
Relationship with IP
8 Handicapped Char(1) N
.
Handicapped (Yes/No)

IPDupIDCard Table is used to Store Record of Duplicate Card Issued to IPs
Database Name: INSURANCE
Table Name: IPDupIDCard
S.N Field Name Data Type Description Defaul Rem.
o t Value
1. DtEntry DateTime PRIMARY
Date of Entry
2. DtApplication DateTime
Date of Application
3. IPCode Char(8) Code of the insured person
to whom card issued
4. FeesPaid Float
Amount of fees paid
5. ReceiptNo Char(1)
Receipt No.
6. DtReceipt DateTime
Receipt Date
6. DtDelivaryCard DateTime Date of delivery of card
7. DtSendingInfo DateTime Date of sending intimation to
IMO/IMP
8 Remarks VarChar(250)
Remarks if any

Allotment Table is used to keep the Record of Processing Details taking place after Employee
Registration…
Database Name: INSURANCE
Table Name: IPAllotment
S.N Field Name Data Type Description Defaul Rem.
o t Value
1. DtReturnDF DateTime Date of Return of PRIMARY
Declaration forms
2. IPCode Char(8)
Insured Person Code
3. DFReceived Integer Number of declaration forms
received
4. DFDefectReturn Integer Number of declaration forms
received and Found
defective and returned to
employer
5. DFFoundOrder Integer Number of declaration forms
found in order
6. FromInsuranceN Char(8)
o
Insurance Number From
7. ToInsuranceNo Char(8)
Insurance Number To
8. DtDispatchTIC DateTime Date of dispatch of
temporary identification
certificates
9. DtPreIDCard DateTime Date of preparation of ID
Card
10. DtPreMRE DateTime
Date of preparation of MRE
11. DtPreIndexCard DateTime Date of preparation of Index
Card
12. DtPreIndexSheet DateTime Date of preparation of Index
Sheet
13. DtPreMAC DateTime Date of preparation of
Medical acceptance cards (in
case of panel system)
14. DtDispIDCard DateTime
Date of dispatch of ID Card
15. DtDispMRE DateTime
Date of dispatch of MRE
16. DtDispIndexCard DateTime Date of dispatch of Index
Card
17. DtDispIndexShee DateTime
Date of dispatch of Index
t
Sheet
18. DtDispMAC DateTime Date of dispatch of Medical
acceptance cards (in case of
panel system)
19. DEID Char(3) Dealing Assistant/Entry
Identification
20. Remarks VarChar(250)
Remarks (if any)

MenuTable Table is used to Dynamically Create the Main Menu
Database Name: INSURANCE
Table Name: MenuTable
S Field Name Data Type Description Defaul Rem.
. t Value
N
o
1 menuorder int(11)
.
Order of Menu
2 menugroup varchar(100)
.
Group of Menu Items
3 menutitle varchar(50)
.
Title of Menu
4 menulink varchar(100)
.
Link on Menu Item
5 lowerlevel int(11)
.
Lower Level
6 itemorder int(11) Y
.
Order of subItem
7 upperlevel int(11)
.
Upper Level
8 officecode varchar(5) N
.
Office Code(BO/RO)

Gnrlhistory table is Used to record the history of changes made to General IP Fields
Database Name: INSURANCE
Table Name: gnrlhistory
S Field Name Data Type Description Defaul Rem.
. t
N Value
o
1 Hipcode varchar(10)
.
IPCode
2 Typeofchange varchar(2)
.
Change Sought
3 Oldvalue varchar(50)
.
Old Value
4 Newvalue varchar(50)
.
New Value
5 Remarks varchar(100)
.
Remarks
6 Hdtentry Date Y
.
Date of Entry

Resiaddhistory table is used to record the history of Changes made to employees’ Address
Database Name: INSURANCE
Table Name: resiaddresshistory
S Field Name Data Type Description Defaul Rem.
. t
N Value
o
1 Hipcode Char (10)
.
IPCode
2 oaddress1 Varchar(40)
.
Old address 1
3 oaddress2 Varchar(40)
.
Old address 2
4 oaddress3 Varchar(40)
.
Old address 3
5 Ostate Char(2)
.
Old state
6 Odistrict Char(3)
.
Old District
7 naddress1 Varchar(40)
.
New address 1
8 naddress2 Varchar (40)
.
New address 2
9 naddress3 Varchar (40)
.
New address 3
1 State Char(2)
0
.
New State
1 Ndistrict Char(3)
1
.
New District
1 Hdtentry date
2
.
Date of Entry
Nomineehistory table is used to record the history of Changes made to Nominee Details
Database Name: INSURANCE
Table Name: nomineehistory
S. Field Name Data Type Description Default Rem.
N Value
o
1. Hipcode Char(10)
IPCode
2. Hnomineename varchar(50)
Nominee name
3. Hnomineedob Date
Nominee dob
4. Hnomineefhname varchar(50)
Nominee father’s name
5. Hnomineepincode Char(6)
Nominee pincode
6. Hnomineerelation Char(3)
Nominee relation
7. hnomineestayswith char(1)
Stays with?
8. Hnomineeaddress1 varchar(40)
Nominee address 1
9. Hnomineeaddress2 varchar(40)
Nominee address 2
1 Hnomineeaddress3 varchar(40) Nominee address 3
0.
1 Hnomineedistrict char(3) Nominee district
1.
1 Hnomineestate char(2) Nominee state
2.
1 Newnomineename varchar(50) New Nominee name
3.
1 Newnomineedob date New Nominee dob
4.
1 newnomineefhname varchar(50) New Nominee father’s name
5.
1 newnomineepincode char(6) New Nominee pincode
6.
1 newnomineerelation char(3) New Nominee relation
7.
1 newnomineestayswith char(1) New Stays with?
8.
1 newnomineeaddress1 varchar(40) New Nominee address 1
9.
2 newnomineeaddress2 varchar(40) New Nominee address 2
0.
2 newnomineeaddress3 varchar(40) New Nominee address 3
1.
2 newnomineedistrict Char(3) New Nominee district
2.
2 Newnomineestate Char(2) New Nominee state
3.
2 Dtentry Date Date
4.

UserTable table is used to Authorize and Authenticate the User during Login Process

Database Name: INSURANCE
Table Name: UserTable
S Field Name Data Type Description Defaul Rem.
. t
N Value
o
1 username varchar(15)
.
User Name
2 password varchar(10)
.
Password
3 upperlevel int(11)
.
Upper Level
4 lowerlevel int(11)
.
Lower Level
5 officecode varchar(5) PKey
.
Office Code
6 regionaloffice char(2) Y
.
Regional Office Code
5. Physical Design (Physical Files and their Description)

The Web Server Directory Layout and Files
In this section we will look at the anatomy of a simple php.MVC Web application and
typical application and library locations.
The figure below shows how a php.MVC application and the core php.MVC libraries can
be deployed.

The php.MVC Libraries
We can see in the diagram above that the php.MVC library files have been installed in a directory
called Dev that is used hold other common libraries that may be used on this Web server by
php.MVC applications or other programs. (for more details of php.MVC libraries please see in
Annexure).
Test plan/Test Cases
Test Plan/Test Cases

During the course of module two kinds of testing were done, namely Unit testing and Integration
testing

Unit Testing

In the Employer Registration Module under ESIC Project, each individual module has been tested
using two techniques namely:

1. Client side testing
2. Server side testing using the validation framework provided by php.MVC

Each individual form has been validated (Client Side) so that user enters only valid data at
every time For e.g., Type checks, Dependency checks, Mandatory Fields checks. Data has
been verified for consistency at server side like primary Key, Foreign Key Constraints.

Integration Testing

In Employer Registration Module under ESIC Project, integration testing was implemented.
Whenever new units were added to the module, all the related units were tested for the
effect.

Test Plan:

 Each unit (sub module) was tested for its functionality
 Each unit was validated for inputs.
 Once a unit was developed and deployed with the module each related unit was
checked for effects and over all functionality.
Conclusion
Conclusion

By designing the “Employee Registration Module Under ESIC Project” through php.MVC
Technology , we are able to provide the basic functionality related to the Employees’ State
Insurance Corporation with great ease. The use of php.MVC technology provides reliable
implementation of web based applications with proper security of software at reliable speed. This
design model allows Web pages or other contents (Views) to be separated from the applications
business logic, or code (Model). The use of this design philosophy makes it easier for designers
and programmers to focus on their respective areas of expertise. The framework provides a
single entry point application controller. The Controller is responsible for allocating HTTP
requests to the appropriate Action handler (Model) based on XML mappings defined in the
application XML configuration file. The Model contains the business logic (code) for the
application.

The “Employee Registration Module Under ESIC Project” is still taking shape, there are many
more modules and functionalities left on this project.

Coding Scheme
(Generalized Programming is emphasized)

o Variables required at project level are to be declared globally
o Refresh the global variables after their use.
o Variables required at only the function and procedure levels are to be declared locally.
o Record sets to be used within function and procedure levels are to be declared locally.
o Any feature, which needs to be optionally used, must be controlled by a constant which
will defined in the module.
o Error handler must be declared in all the procedures and functions
o Any validation done on the controls such as text box, data combo must be at the lost
focus of the control.
o No user-id and passwords will be hard coded.
o Combo-box should be used as a drop down list.
Annexure
Annexure
1. Screen Shots

Declaration Form Opened in Save Mode
Declaration Form Save Mode Message
Other Part of Declaration Form
EntryDF for Entry to all forms…

List of Establishments/Principal Employers

List of Registered Offices
Allotment Form
Dependant Form (Save Mode)

Change Request Form

Branch Change Form
Dispensary Change Form

Marital Status Change Form

Nominee Change Form
Address Change Form

List of Requests For Administrator
List IP for Printing Index Cards

Index Card

List of Files

Serial No. File Names Purpose of File
1 AllotmentForm.php Allotment Register to
2 AllotmentForm.tpl record the status of
3 AllotmentFormAction.php Processing of Documents
for Insured People
4 AllotmentList.php
5 IPRegistrationBO.php
6 DeclarationForm.php Form for Registration of
7 DeclarationForm.tpl Employees
8 DeclarationFormAction.php
9 DependantIndex.tpl
10 IPRegistrationBO.php
11 DefaultPath.php Default path for database
connectivity
12 DependantForm.php Form for Recording the
13 DependantForm.tpl Dependants of employees
14 DependantFormAction.php
15 DependantList.php
16 Dependent.tpl
17 DependentAction.php
18 IPRegistrationBO.php
19 DuplicateIDForm.php Form for Duplicate ID Card
20 DuplicateIDForm.tpl Generation
21 DuplicateIDFormAction.php
22 DuplicateIDList.php
23 DuplicateIDList.tpl
24 IPRegistrationBO.php
25 EmployeeDetail.php Print Employee Details
26 EntryDF.php Entry to various
components of employee
Registration
27 FillSelectBoxes.php PHP file to Fill select
Boxes dynamically
28 Footer.php Footer File
29 GenerateIC.php Generate Index Card
30 GenerateMenu.php Create Main Menu
Dynamically
31 GeneratePIC.php Generate Permanent ID
Card
32 GenerateTIC.php Generate Permanent ID
Card
33 GetIPForBOWiseListIP.php
34 Header.php Header File
35 Libfunctions.php All Library functions
36 ListChangeRecorded.php List of Changes Submitted
by the User to
Administrator
37 ListEstablishment.php List of Establishments
based on Regional Office
38 ListIP.php Print List of Insured People

39 ListRegisteredOffices.php Print List of Registered
Offices
40 Login.php Login Screen
41 LoginClass.php Authorisation and
authentication functions
42 PermitChangeRequest.php Administrator can Approve
or deny the changes
requested
43 PrintIC.php Print Index Card
44 DateFromToDIC.php Report form for printing
reports of duplicate Ids
issued from x date to y
date
45 ProcessDateFromToDIC.php Process the Report taking
the input = from and to
dates
46 ProcessDuplicateIDForm.php Report for duplicate Ids
with the calculated total
amount of fees paid
47 ProcessLogin.php Login Processing
48 RequestChange.php Input change sought for
expected changes
49 ResultCV.php Processing of
requestchange form
50 ChangeForm.php Forms for changing the old
values in IPTable
51 CommitChangeRequest.php Commiting changerequest
to main tables and history
tables
52 CreateMenu.php Create menu is a special
class to generate dynamic
main menu
53 DateClass.php Includes all date functions
54 Datediff.php Finds out the Difference
between two dates.

php.MVC
Remaining Part of php.MVC Libraries

This Dev (or Development) directory is located off the Web server root directory. By not being
located in the Web root, the libraries are protected from direct Web access by users.
If we need to install the php.MVC libraries within the Web root for some reason we can use a
.htaccess file (or similar) to control who can access this directory. An example Apache .htaccess
file is shown below.

This instructs the Apache Web server to:
1. Deny all access to the directory containing this .htaccess file, and all directories below. In
this example that means the php.MVC library /WEB-INF directory, and all the other files
and directories it contains.
2. Allow access to localhost. This refers to the Web server host machine. This would allow a
developer on this Web server could browse to the test directories within the library and run the
unit tests, if required.The php.MVC library files should require no further modification for normal
use. To access the library classes from our application , we set the $appServerRootDir variable in
the applications Main.php file, something like:

The php.MVC Web Application

In the diagram above we see that the developer has created a directory within the Web root
called SalesReports that will contain the application.Within the top level SalesReports application
directory we have several directories and the Main.php file. The art directory is used to hold the
application graphics, and will be accessible to
the Web. The style directory is used to hold the application style sheets and will also be
accessible to the Web. These directories can be renamed to suit the developers preferences. We
can access these resources from our template pages something like:

Next is the /WEB-INF directory. This is where we locate the application classes and
resources.The /WEB-INF directory should not be accessible to the Web, and so is also protected
by a .htaccess file. In this example we have a classes directory and a tpl directory. The developer
is free to create directories and subdirectories as required within the /WEB-INF directory, and
name them as needed. The only requirement is that the paths to these directories should be
declared in the ModulePaths.php file, as we will see shortly. In the example above the classes
directory holds the application classes, and perhaps other resources such as string
resource property files. The tpl directory holds the applications View resources, such as page
templates.Also within the /WEB-INF directory are the .htaccess, ModulePaths.php,
phpmvcconfig.xml, phpmvc-config_1_1.dtd, phpmvc-config.data and prepend.php files. The
.htaccess file has been discussed previously.
The ModulePaths.php file is used to define the application specific paths to our classes and
resources. We can define the application paths like this:
The phpmvc-config.xml file is the central component of the php.MVC application. This is where
we setup our application using XML nodes to define behaviour and properties. We will look at the
phpmvc-config.xml file in more detail below.
The phpmvc-config_1_1.dtd file contains the Document Type Definitions (DTD) for the phpmvc-
config.xml file. The DTD specifies what can and cannot be included in the phpmvcconfig.xml file,
and is the ultimate reference to the behaviour of the application. Most good XML editors use the
DTD file to validate the phpmvc-config.xml file.The phpmvc-config.data file contains the serialised
configuration data for the application. This configuration data is regenerated whenever the
application phpmvc-config.xml file is modified.
Tip: if your application does not respond as expected, "touch" (white-space edit) the
phpmvcconfig.xml file and re-run the application to force the serialised configuration data to be
regenerated.The prepend.php file is used to include application files. We do not need to include
the application classes and template files as the framework will find then provided we have
specified the paths correctly, as outlined above. However we may need to include other class
files and resources, as shown below:

The Main.php file is the single entry point for an application, and is located in the application root
directory. This is the single entry point for an application. All requests to a particular php.MVC
application are handled by the applications Main.php file. The Main.php file is also used to set
some parameters that help setup the application when a request comes in.As we saw above, the
path to the php.MVC library must be defined in the $appServerRootDir variable:

Next the path to the application is define in the variable $moduleRootDir like this:

Where SalesReports is the application root directory.We also set the path to our applications
ActionDispatcher. Each php.MVC application will usually use a custom ActionDispatcher that is
tailored to that applications specific requirements. We define the ActionDispatcher variable like
this:

The ActionDispatcher is covered in more detail later in this guide.The $osType variable is an
optional parameter that can be defined if the php.MVC framework has
a problem detecting the host operating system (OS). Normally the framework should auto-detect
the host operating system and setup the application paths accordingly. If it appears that the
application paths are not correct, we can manually set the OS parameter like this:

for the Unix and Linux type of operating systems. And like this:

The remaining parameters in the Main.php file should not normally require modification.
Bibliography

10.1 Web References
 http://phpmvc.net/
 http://php.net/
 http://sourcerforge.net
 http://postgresql.org

10.2 Books

 PHP5 and MySQL Bible
 PHP Manual

10.3 Manuals AND Reports

 The ESI Act, 1948