General Ledger 07a v04

PROJECT BACKGROUND
1.0 Introduction
A general ledger manages all the accounts for recording transactions relating to a
company's assets, liabilities, owners' equity, revenue, and expenses. In modern
accounting software or ERP, the general ledger works as a central repository for
accounting data transferred from all sub-ledgers or modules like accounts payable,
accounts receivable, cash management, fixed assets, purchasing and projects. The
general ledger is the backbone of any accounting system which holds financial and nonfinancial data for an organization. The collection of all accounts is known as ledger
account.
1.1 Problem/Opportunity Description
Its not easy to record all data in a manual process. It can take more time to write
all of this in a record book. Calculating a whole module in a manual process is not easy
to be done.
In General Ledger System, recording a data coming from other sub-system can
be done by its automatic process. Gathered data are automatically identified if it is
assets, liabilities, owners equity, revenue or expenses. Calculating of weekly and
monthly records is done by this system.
1.2 Benefits
The system for the GL will be able to secure data records, especially Contracts.
It can also provide accurate and reliable data to avoid any conflicts for both parties.
And it will be much easier for the company and the administrator themselves to transmit
data gathered from all the sub-system to the general ledger itself. The report will
accurately done by the general ledger.
Merchandising (General Ledger)
Page 1
1.3 Goal
To create a system that will manage all the specific data gathered from all the
sub systems. To make it computerize and to add more convenience in the transmission
of all data gathered.
And to create a system that will fit to the needs of the general ledger that can
provide solutions, that will help the current situation of companies and to provide a
system that will cater the process of organizing and securing data of contracts.
1.4 Stakeholders
The accountant and the management of that Company because they are
the one to use the system.

The employee because they are who will be using this kind of system for
their company.
The project team because they are the one who will going to solve the
problem of the company.
1.2 PROJECT SCOPE

Page 2
Update
Edit Chart
of Breakdown Structure
Work
General
Ledger
Edit Ledger
Transaction
General
Ledger
GENERAL LEDGER
Journal
MENU
GENERAL
Edit glAcct
File
Verify
Ledger
Edit glCode
MONTHLYDataFile CHART OF
MONTHLY
REPORTS
UPDATES
ACCOUNTS
MISCELLANE
OUS
FILE
EDITORS
Condense Edit glLock

G/L Data File
Account Trial
Balance
Create
Edit glTran
Opening File
Entries
General
Ledger
Analysis
Statement
Balance
Sheet
Income
Statement
Invoice to
G/L
Update
Receivabl
es to G/L
Update
Rent/Leas
es to G/L
Update
PayablesMENU
GENERAL LEDGER
to G/L
The EDIT LEDGER TRANSACTIONS program is used to add, change, view or delete
Update
any transaction
in the ledger database.
Payroll to
G/L
Accounts
The GENERAL LEDGER JOURNAL lists ledger transactions in journal (numerical)

order.
The Account Trial Balance lists ledger transactions by account in chronological order
Chart of
with account subtotals.

Accounts
List
Change G/L
Accounts
I.D.
Page 3
The General Ledger Analysis lists each account balance in a monthly

MONTHLY REPORTS
Letter-Perfect General Ledger Statement, Balance Sheet and Income Statement S can
be produced according to your accountants specifications.
MONTHLY UPDATES
Monthly updates from all subsidiary software packages including, order invoicing,
receivables, cylinder control, payables and payroll can be run in summary or detailed
mode to automatically create General Ledger entries.
CHART OF ACCOUNTS
The Edit Chart of Accounts program allows you to add, change, view or delete records
in the chart of accounts file.
The Chart of Accounts List shows the complete chart of accounts.
The Change G/L Account I.D. is used to change a G/L Account ID throughout the
system.
MISCELLANEOUS
The VERIFY LEDGER DATA program is a maintenance program to ensure the internal
integrity of the General Ledger data.
The CONDENSE G/L DATA program condenses/purges selected ledger entries into
one transaction per account.
FILE EDITORS
FILE EDITORS provide low level access to the database for programmer/system
administrator use only.
The EDIT LEDGER TRANSACTIONS program is used to add, change, view or delete
any transaction in the ledger database.
Used to post standard monthly periodic journal and recurring entries.
Security permission modes to prevent modification except by authorized personnel.
Page 4
Batch posting totals maintained throughout the editing session, with warning
generated if attempting to leave program out of balance.
Audit journal produced at end of editing session.
The GENERAL LEDGER JOURNAL provides a list of ledger transactions in journal
(numerical) order.
The Account Trial Balance provides a list of ledger transactions by account, in
chronological order with account subtotals.
The General Ledger Analysis provides a list of each account balance in a monthly
spreadsheet. Balance Sheet and Income Statement subtotals are included.
Detailed mode: Lists transaction ID, date, account, debit and credit and balance
amounts, and description for each transaction.
Summary mode: Lists debit and credit totals only.
Output can be directed to the screen, .PDF preview, any printer, fax, email or a
networked Hard drive on the server.
EDITING SCREEN: EDIT LEDGER TRANSACTIONS
1.2.1 Objective
- To create a cost efficient system that will be easy to understand, reliable and that has
user friendly interface for every accounting department of a merchandising special the
general ledger.
- To create a system that has ability to integrate unto the other subsystems of the
merchandising.
Page 5
- To create a system that will be capable in handing accurate data that will help the
company in terms of efficiency.
- To create a fully documented project that will include the plans, processes,
implementations whether in terms of changes or if there were standards that must be
applied.
2.2 Deliverables
General Ledger Menu
Project Deliverable
Edit Ledger Transaction
Work Products/Description
To change and update.
General Ledger Journal
To check and view the saved data.
Account Trial Balance
To list a closing trial balance
General Ledger Analysis
To look at the GL reports
Monthly Reports
Project Deliverable
General Ledger Statement
Balance Sheet
Income Statement
To record all of the transaction of the GL
To summarize the financial balances.
To shows the companys revenues and expenses
Monthly Updates
Project Deliverable
Update Invoice to G/L
Program updates a selected range of invoices as a
Update Receivables to G/L
transaction in the General Ledger database.

Program updates a selected range of Receivables
transactions as a transaction in the General Ledger
Update Rent/Leases to G/L
database.
Program updates a selected range of rent/leases
invoices as a transaction in the General Ledger
Update Payables to G/L
database.
Program updates payables transactions (vouchers and
checks) for a given period as a transaction(s) to the
General Ledger database. The resulting G/L Transaction
Page 6
will
Update Payroll to G/L
be
distributed
to
the
appropriate
G/L
Account/Subsidiary code.
Program updates a selected range of payroll checks as
a transaction in the General Ledger database.
Chart of Accounts
Project Deliverable
Edit Chart of Accounts
Program allows the user to add, change, view or delete
Chart of Accounts List

Change G/L Accounts I.D.
records in the chart of account file.

Allows to view the list of chart of accounts.
Part of the system that can change once G/L account
I.D.
2.3 Out of Scope

The general ledger only manages data reports from different sub systems, so the out of
scope would be easier to recognize, the system for general ledger manages the
summary of all reports of the sub systems such as Accounts payable and receivable,
procurement, order management, POS, treasury and sales monitoring, but not including
the specific transaction of every systems.
1.2.4 Enterprise Information System Required Functionalities
Mobile Apps The mobile apps for the accounting in general ledger
will be planned to have a mobile application for the android mobiles for
fast browsing of the information needed unto every accounts.

Free Format Query- the system for the accounting general ledger will
use a search box for every query for the fast searching of the chosen
information.
Personalized Screen- there were planned general design for every
subsystem however the proponents are given a chance to personalize
the screen to add more creative design personalized by the developer.
Page 7
Import Export- the system data must also be able to adapt into other
application such as MS word, Excel and other more applicable
devices.
1.3 PROJECT PLAN

1.3.1 Approach and Methodology
Searching the subject information through internet

It was the first time that development team will be handling accounting
matters so the team decided to look for more information regarding the
general ledger at the more convenient way internet browsing.
Data Gathering Process

The data gathering process are done with internet also but look for the
actual images and transactions of the general ledger.
Testing
The test plans are conducted through different laptops at a different
operating system to make sure that the system will be capable in adapting
unto the clients location. It can also be done through measuring the
system functions if every program within the system are functioning well.
3.2 Project Timeline

ID
1
DATE
June 27, 2014
Group meeting
Start
3pm
Finish
6pm
Duration
3hrs
July 5, 2014
Brain Storming
7pm
6am
11hrs
July 8,2014
Distribution of sub-system
3pm
6pm
3hrs
July 9, 2014
Searching about General Ledger
4days
July 14, 2014
Company search
5days
July 21, 2014
Prepare an interview question
2days
Page 8
7 August 2 ,2014
8
9
1
0
11
August
11,2014
August
17,2014
September
17,2014
October 5,
2014
Oct
2
1
21-28,2014
Nov
3
1
3-10,2014
Nov
4
1
12-26,2014
Dec
5
1
1-31,2014
Jan
6
1
1-15,2014
Jan
7
1
17-24,2014
Feb
8
1
1-15,2014
Feb
9
2
17-24,2014
Feb. 24 Mar.
0
2
21, 2014
Mar
23-28,2014
Survey (Gathering Data)
3Days
Chapter 1
2week
Chapter 2
3week
Chapter 3
2week
Analyze the gathered data and identify

the problems
Identify the objectives and find a
solution.
2week
1week
Identify the system scope.
1week
Prepare a systems layout.
2week
Start Programming/Documentation.
1month
Coding
1week
Test run
1week
Planning for system design.
1week
Implementation system design.
1week
Prepare for the defense week
1month
Defense week
1weeks
3.3 Success Criteria
The project for the General ledger is considered a successfully done if the
documents and systems had passed the standard implemented for the project.
The project will be considered a success if the system is functioning well and
were able to cater transactions, generate accurate reports.
Page 9
The project is success if the system met the requirements of the users. User is
an important part of the system, thus this project must conform to the needs of
the user to be considered a success like taking the side of the future user of the
system the developer must acknowledge not just the process but the outer look
of the system it must not irritate the eye of the user or it must not be destructive
to the eye of the client.
3.4 Issues and Policy Implication

If the system itself is already working goods, then the proponents still cannot
Avoid encountering sudden problem, such that if as the following.
1. Un-expected break down of other systems from different department, in this case
the system will fail to accept any data from the failing department but this is a
company problem that can be solved by using generator to avoid having
problems with the electricity..
2. Sudden break down of the system for general ledger also is a must to think of;
the company must have its own technical support team to avoid having problem.
3. The transmission of data can also be a problem if the other sub modules fails to
send their data unto the GL account, the system as whole must be well
integrated that if one fails to send information there must be a message that will
pop up into the screen of the account who forgets to send information and also to
the GL itself it must have its own notification that notifies all of the sent data into
the system.
3.5 Risk Management Plan
Risk Factor
Probability
Impact
Risk Management
(H-M-L)
M
(H-M-L)
H
Action
To make sure that
The outcome of
all of the team
the project
members are fine
greatly depends
and keep their focus
Page 10
on the people
on the project
assigned to
complete it
H
For the software
Failure to
and hardware
program/run the
issues the team
system due to
have decide to
software/hardwar
always prepare a
e issues.
back up for the

project whether the
system or the
Shortage of funds
documentation
For the funds, the
unable to comply
team decided to
necessary
have budgeting plan
requirements
too make sure that

there will be no big
problem when it
comes to the
budget for the
necessary
requirements of the
project.
The system will
The system will
technology-
be pure
dependent
technology base
so if ever there
will be problems
when it comes to
the devices and
Page 11
equipment, the
developer
suggest that the
company must
have its own
technical support
to trouble shoot
the problem
Work Plan is not
The proponents
met due to
have set dates to
unexpected
do the project so
events resulting
there will be no
to delayed
expected delay,
completion of
but if in case
this project.
there are delayed

the team will still
find time to
complete the
The system may
project.
Team works
not integrate with
together as a
other modules
whole so it is
under
impossible for the
merchandising
team to have
system.
integration problem
thus, but it can, so
the whole team will
conduct integration
test 2 weeks
before the final
Page 12
defense and again

before the exact
date.
3.6 Service Transition

To manage well the system for general ledger, the company must have its own support
team, so if there were sudden problem occur, it will be easily fixed by the support team.
The role of this support team is to maintain, check and to fix problem that may occur in
wide range of using the system. As well as the development and maintenance of the
system for the brighter used of our fast moving generation. There must also be a
training given to the employees that will be using the system, this training is to
familiarize each of the involved employee on how to use the certain system, its
functions as well as to know their opinion regarding the created system and also to tell
them that the system has a help button from which they could see the possible trouble
shooting regarding the common problem that they may encounter.
3.7 Options Analysis
If In terms of system integration, the project team will keep their eye for any adjustment
and revision that will be needed by the whole Merchandising system.
If In terms of the budget, the whole team will stick in the budget of the project however if
there are unexpected necessities for the project, the team will provide the needed
money to support the necessities of the project
The teams thoughts about the software and the technical support of the development of
the project is that the software that will be needed should be licensed and for the
technical support that team will have their own gadget or laptops that is needed for the
development.
TECHNICAL FEATURES
The following are the technical features requirements in developing the project.
Page 13
Front End The proponents will be using Java Netbeans IDE 7.4 for front
end since the lead programmer is well knowledgeable in using this kind of
language for the program of the system

Back End - The proponents will be using MsSql for back end because they
are required to use MsSql for the database of the system.

Mobile Application The proponents are required to have mobile application
to their system and since the proposed system is about the statement of
accounts it will be optional if the proponents or the client wants the system to
be downloaded as mobile application
PROJECT ORGANIZATION AND STAFFING

Role
Project Manager
Name and Contact
Responsibilities
Information
Elmer Tabin
Serve as
ultimate
authority/
responsibility
for the project
Provide
strategic
direction and
guidance
Approve
changes to
scope
Business Analyst
Rowel Cabalan
Identify and
secure funding
Make
business /
Approach
decisions for
Page 14
Time
the project
Participate in
key activities
Make resources
available
Approve work
products
address issues,
and approve
change
Project Manager
requests
Report to and
receive
direction from
sponsors
Manage,
review, and
prioritize project
work plans
Provide status
reports
Manage project
team
Recommend
changes,
escalate issues,
and mitigate
risks
Participate in
Project team and
Elmer Tabin
Members
Jenelyn Arquiza
project
Rowel Cabalan
activities,
Page 15
including
planning,
implementation
of deliverables
and quality
control
Advisors and
Mr. Rico Bundoc
resources
PROJECT BUDGET
Budget Item
One-Time Costs
One-time item 1
Ongoing Costs
Ongoing item 1
Description
Description
Total One-Time Costs
Description
Total Ongoing Costs
APPENDIX A-ADDITIONAL INFORMATION
Page 16
Budget Cost
FOREIGN AND LOCAL RELATED LITERATURE

2.0 INTRODUCTION
The influenced of information system has arose the eagerness of discovering
more things that will make everything easy for client in such different aspects. It only
shows that Information system is not only for business purposes, it can be for personal
use or it depends on the user. It might be different from one another however the
objective is to create a user friendly system example of this is the local government unit.
In order to reduce the paper works of the employees and to avoid the loosing of
important documents the government decided to use computerized system. All the
transaction will be systematically organized. The traditional way of handling documents
which is manually encoding and compiling of it will be deducted. Since there is no
perfect system that exist the agency have to adapt the changes and take the risk
because the problems might occur while the system is in used. It is a good idea to use a
system to manage all the transaction and give accurate report to the public and
transparency. Like any other organization the emerging needs of fast and reliable
system is what strengthen the foundation of information technology. This chapter is the
Page 17
guideline to understand the succeeding chapters. Below are the different researched
literature and studies that will establish the knowledge of the readers.
2.1 Related Studies

2.1.1 Foreign Studies
1. University of Colorado Financial System and General Ledger
Then University of Colorado has implemented this financial system. According to
the administration The Finance System team provides support for PeopleSoft
Finance users including the areas of general accounting, accounts payable,
project accounting, billing, accounts receivable, and asset management. We are
also responsible for ensuring data integrity between all University financial
systems including Concur Expense and CU Marketplace, and other systems
such as HRMS, ISIS, and COFRS. We are also responsible for design, testing,
and project management of fixes, enhancements, and system upgrades.
URL:http://www.colorado.edu/abs/sites/default/files/attachedfiles/fin
training_manual
2. Louisiana State University General Ledger System
The General Ledger System (GLS) is the core system to the integrated Financial
Accounting System of the University. All the financial data of the University is
Page 18
stored in this system. Some of the data is fed to the GLS from other financial
systems, as depicted on the chart below, while other data is entered directly into
the GLS system via on-line screens. This User's Guide should provide you with
the information necessary to use the University Financial Accounting System and
the GLS. Under the integrated system there are 8 subsystems also called
Subsidiary Ledger. Before getting the general ledger report which is the last part
of the integrated system, the subsidiary ledger must be complete and updated to
make the report accurate. The account code structure at LSU consists of two
different types of accounts; a general ledger (G/L) account and a subsidiary
ledger (S/L) account. The general ledger accounts are further divided into three
types; assets, liabilities and mapping accounts. Each of these types of accounts
is explained in detail in the pages that follow. A separate G/L mapping account is
established for each fund/campus, or for each entity within a fund for which fund
balances are maintained or for which separate financial statements are needed.
Each S/L account is "mapped" to a specified G/L mapping account, and all
budget, encumbrances, revenues, expenditures and pre-encumbrances in S/L
accounts are recorded in summary in the G/L mapping account. Each S/L
account maps to a single G/L mapping account while one G/L mapping account
represents summary information for a group of related S/L accounts. Summary
entries to these G/L mapping accounts are system generated and are not the
responsibility of the personnel in the departments. To determine the mapping
account for a specific S/L account, view the "Basic Account Information" in the
Chart of Accounts (COA) system. See the appropriate section of this guide for
how to use the COA. The LSU Chart of Accounts system (COA) was developed
to maintain the University's valid general ledger and subsidiary ledger account
numbers. These numbers are structured nine digit numbers that are unique
across the system. The account structure section of this guide explained in detail
the meaning of the digits and the relationship between subsidiary ledger and
general ledger accounts. This section of the guide is provided to aid the user in
how to inquire into the COA and to interpret the information. There are two
different menus that relate to the University account numbers. The first is the
Page 19
COAMENU which is used to inquire into specific accounts and review the
attributes associated with specific accounts. The second is the COA/GLS MENU,
which is used to review the relationship that has been established between an
account number and specific objects, transaction types and project numbers.
There are many options available from this menu. Begin by typing the Account
Type (G or S for general ledger or subsidiary ledger accounts), the nine-digit
account number, and the appropriate fiscal year. If fiscal year is not entered, it
will default to current fiscal year. The first three options provide the user with
screens displaying the attributes that have been established for an account. For
example, the Basic Account Information screen shown on the next page
displays the account title, distribution code, begin date, expire date, and other
generic account information normally captured on most University accounts.
URL: http://www.fas.lsu.edu/acctservices/forms/far
3. University of Wisconsin Financial and General Ledger system
The General Ledger module is the core of the SFS system. Many of the tables
set up here are used by other modules throughout the system. This is where data
from all modules comes together and where most of the financial reporting is
done. Ledgers store posted general ledger journals for a set of Chartfield values
by accounting period and fiscal year. The admin represent a set of books for
each business unit and are usually populated by journal entries. There are
several ledgers that are delivered with the SFS system. Most campuses are
currently using the actual ledger, which stores all transactions except budgets
and the student budget Ledger, which stores budget information. Before looking
at the ledger the user must familiarized itself in the unique chart of fields and
different acronyms that the admin provided. In order to understand the flow of
processing general ledger reports, the business process of the system is
included as well as screenshot of different forms.
URL:http://www.uwsa.edu/fadmin/sfs/glddict
Page 20
4. APPX Software Inc.

General Ledger is a means by which you can measure the financial health of
your company. In accounting terms, the General Ledger records each
transaction coming into or going out of your company that involves the exchange
of money, or involves an increase or decrease in the overall value of your
company. These transactions can include everything from cash receipts to
depreciation on equipment; all such transactions should be reflected in General
Ledger. In order to record a transaction, you enter the amount into an account.
The full set of your accounts is called the Chart of Accounts. There are many
types of accounts in the Chart of Accounts. The broadest subdivision of accounts
separates them into Assets, which are generally tangible, valuable items that
your company owns; Liabilities, which are legal obligations your company owes
to its creditors; and Owners Equity, which reflects the amounts that various
individuals or companies have invested in your business. When a business first
begins, the only equity available is the initial investment made by the owner of
the business (the Owners Equity). As the company grows, it purchases goods,
services, supplies, and equipment; these items are necessary to conduct
business. In order to achieve transparency of the reports, the data that extract in
the ledger must be accurate and balance.
URL :http://www.appx.com/ftp/appx/documents/manuals/appx/t-apps/character
5. Open Systems Accounting Software
The Open Systems Accounting Software (OSAS) product line consists of several
accounting applications. Each application addresses a different phase of your
financial operations; together, they form a powerful accounting solution to your
daily and periodic accounting needs. Open Systems has a strong commitment to
customer service and product quality. The Resource Manager application is the
foundation or shell of OSAS; it provides the operating environment that holds the
other applications. Resource Manager also includes three powerful business
Page 21
features: Global Inquiry, Executive Information Summary (EIS) and Print

Manager. With Global Inquiry, you can drill around your accounting data to find
selected information throughout your system. With EIS, you can access company
information quickly and view summaries of all aspects of a company or a group
of companies. With Print Manager, when you print reports to file, your reports can
be stored, sorted, printed, and searched for specific text. Base applications are
designed and produced with the largest possible number of industries in mind.
They are most effective when you interface them with each other. Base
applications are usually named after common accounting operations. Examples
are: General Ledger, Accounts Payable, Purchase Order, Accounts Receivable,
Sales Order, Payroll, and Inventory. General Ledger can be used as a
standalone application, but you get optimal use from it when you interface it with
other applications. Interfacing applications means that the information you enter
in one application can be transferred to and used in other applications. So,
interfacing your applications reduces data entry time and the number of possible
errors that might creep in along the way.
URL:http://www.whiteware.com/support/Manuals%20and%20Documents/Open
%20Systems/OSAS%206.1
2.1.2 Local Literature
1. Manila Doctors Hospital Financial System
In 1989 is the birth of automated processes at the Manila Medical Service
Incorporated (MMSI) with Sycip, Gorres, Velayo as the commissioned systems
developer. MMSI implemented their first stand alone computerized business
application: the Patient Account Receivable System (PARS) with Metrobank,
Incorporated taking the lead in the project. PARS, DOS base accounts receivable
(A/R)
system
was
managed
by an Accounting
staff,
trained
at the
MeralcoFoundation Incorporated to provide internal systems support. In year

1992, the General Ledger System developed by Innovative Concepts Software
House was implemented. At that time, computerization projects were still
managed by the Accounting Department. It was in year 1994 that the Electronic
Page 22
Data Processing (EDP) came into form as a section unit of the Finance Division;
with the Accounting staff manning the section and the Assistant Financial
Controller as the Head. This also marked the start of the Local Area Network
environment in the hospital. The main focus of the EDP operations at that time is
in the DOS base financial applications covering General Ledger, Billing, Check
Vouchers and Payroll modules.
URL:http://www.maniladoctors.com.ph
2. WinMed Hospital Information System (HIS)

The General Ledger application is multi company and accommodates the AHA
chart of accounts. There is a monthly closing to retained earnings, with a yearly
closing to retained earnings. The system will allow postings to previous periods,
current period, and future periods. The system includes a report writer for
tailoring financial statements. The balance sheet is free format, designed for total
control by the user. There are several formats for income and expenses
statements which lists previous periods and/or years with budget information.
The system has 10 years of history for accounts and all detailed transactions
processed in the General Ledger application with reports showing the beginning
balances, all detail transactions processed, with the closing balance. The
application also accommodates statistic information such as patient days or
payroll FTE's. The Accounts Payable application is designed to process vendor
invoices and patient refunds. This application will track vendor invoices,
payments, 1099 information and refunds to patients. Cash requirements reports
are produced upon demand and can also include an ageing. A history database
of vendor invoices and payments is a base part of the system. System bank
reconciliation and check registry are done online. Printing of checks with a laser
printer can also include signatures and bank routing information. The system also
allows flexible distribution of invoices. Payroll / Personnel were designed to be
Page 23
very flexible for hospitals use. There are many type of earnings, pay periods,
multi-company, and user defined accruals of benefits. The hospital defines their
deductions and accrual of additional compensation. The payroll checks are
printed on a laser printer which includes signatures and bank routing information.
Also available as a standard feature is direct deposit. The system produces all
required state and federal reporting. As part of the pay period processing, all
financial information is interfaced to general ledger with accrual data, and
automatic reversal of the accrual data the next general ledger period. The system
contains history databases of all employees pay information for each check/direct
deposit issued. There is also a history database of each pay period labor
distribution for each division, department, and position the hospital has defined in
their payroll. The personnel system allows for personnel actions to be
documented on the employee record. The system tracks licenses, leave, physical
examine, education, and user defined fields for tracking. The Depreciation
application is an addition to the general ledger system, and will track the
depreciation of any asset of the hospital. There a many conventions and
methods to select from for deprecation of the assets. The application tracks book
value and tax value if the user chooses these options. The depreciation is
calculated each month and posted to general ledger. As new assets are added
during the year, they will be calculated based on the method and convention
selected and posted to general ledger. Assets are tracked by division and
classification. Material Management application will maintain inventory for multi
departments within the hospital. The system can track both billable and nonbillable inventory items. The purchasing can process both inventory and noninventory items. The system also tracks inventory uses by department and
maintains a stock level for each hospital departments. The system generates
automatic re-orders based on information on each item. Physical inventory can
be done at any time, or as many times during the year the users chooses. The
material management department can continue to operate during physical
inventory and when the reports are produced will calculate any activity that
occurred during that taking of the physical inventory.
Page 24
URL :http://www.winmedhis.com/financialsystems
3. Center for Medicare and Medical Services
The Centers for Medicare & Medicaid Services (CMS) has implemented the
Healthcare Integrated General Ledger Accounting System (HIGLAS). HIGLAS is
an integrated, dual-entry, general ledger accounting system to manage
healthcare outlays. CMS has 45 million providers and beneficiaries, and it uses
HIGLAS to process approximately 4.5 million claims daily. HIGLAS improves
accountability for Medicare payments to physicians, hospitals, and other
providers servicing Medicare beneficiaries. HIGLAS is also used to support
accounting for Medicaid and Childrens Health Insurance Program (CHIP) grants
and to generate the CMS Financial Statements, including all vendor payments,
payables, and receivables.
The Healthcare Integrated General Ledger
Accounting System (HIGLAS), a single integrated Internet-based accounting

system, leverages the very latest in commercial off-the-shelf (COTS) software to
support CMS' mission to:
Collect standardized accounting data from Medicare

Contractors for Part A and Part B claims
Process Medicaid and CHIP grants
Perform internal administrative program accounting
HIGLAS is responsible for performing seven major financial functions:
Accounts Payable for disbursing payments owed to providers, physicians,
suppliers, beneficiaries, insurers, employers, and other entities. Accounts
Receivable for collection of overpayments made to providers, physicians,
suppliers, beneficiaries, insurers, employers, and other entities. General
Ledger for posting and recording all financial transactions summarizing
and maintaining account balances by the fund structure and individual
general ledger accounts. Cash Management for reconciling Medicare
Contractors' bank statements. Administrative Program Accounting for
maintaining data used to generate CMS' financial statements. Supporting
Page 25
the issuance of grants and subsidiaries made to other organizations or

Individuals supporting budget formulation and execution. Audit Control for
auditing the integrity of the data as it is entered, altered or deleted
performed financial statement audits. Healthcare Transaction Base for
providing a federal document view of the data in HIGLAS. The Healthcare
Integrated General Ledger Accounting System (HIGLAS) is a new dualentry accounting system that replaces and modernizes the existing fee for
service
Medicare
Contractor
accounting
systems
with
single
standardized system. In addition to processing Medicare claims, HIGLAS

will replace the legacy Financial Accounting and Control System (FACS),
which accumulates CMS' financial activities, both programmatic and
administrative, in its general ledger.
Benefits
HIGLAS, a component of the Department of Health and Human Services
(DHHS) Unified Financial Management System (UFMS), will:
Improve
accountability
for
Medicare's
payments
to
physicians, hospitals, and other providers servicing Medicare

beneficiaries.
Eliminate redundant accounting systems.
Allow more timely and effective collection activities on

outstanding debts
Pay nearly 3 Million healthcare claims a day.
Result in additional interest earned to the Medicare Trust

Funds.
Page 26
Meet government financial regulations including the Joint

Financial Management Improvement Program (JFMIP) and
the Federal Financial Management Improvement Act of 1996
(FFMIA)
URL:http://www.cms.gov/
4. P2 energy solution
EXCALIBUR Financial System is a powerful and comprehensive General
Ledger module is a flexible accounting and reporting system with special
emphasis placed on the requirements of the oil and gas industry. All
financial transactions entered or created in other Excalibur systems
automatically flow to the General Ledger. The General Ledger system
contains extensive standard financial reports and also allows you to
customize financial reports to your specific requirements: Journal Voucher
Data Entry Features, Duplication features to speed data entry, Unlimited
detail transaction descriptions, Copy feature for automatic duplication of
any current, historical or template journal voucher, Autoprompt feature for
changing voucher detail line amounts only while leaving all other coding
intact, Reversal feature for automatic reversal of any current or historical
journal voucher, Accrual feature for automatically creating reversing
journal vouchers in a user-specified accounting period, Recurring feature
for automatically creating duplicate journal vouchers in any number of
user-specified accounting periods, Journal voucher upload functionality
from Excel template, Internal and Accounting Controls, Flexible chart of
accounts structure to accommodate company preferences, Balanced
journal entries are required (one-sided or out-of-balance entries are not
permitted) Automatic generation of intercompany payable and receivable
entries Journal voucher review/approval required, at your option, prior to
Page 27
creation of transactions, Multiple accounting periods open simultaneously

at an entity and system-specific level, Simplified automatic year-end
closing of P&L accounts, Bank account reconciliation for outstanding
checks and deposits, Automatic entry cutback from partnerships or
subsidiaries books to parents or partners books, Automatic company
vehicle mileage allocation to AFEs, properties, leases or cost centers
based on PMTA mileage rates.
Reporting
Extensive standard financial reports, including trial balances, general
ledger activity, and comparative general ledger and financial reports
Extensive user-formatted financial reports including balance sheet,
statement of earnings (P&L), statement of cash flows, and comparative
financial statements and reports. Direct integration with desktop PC
reporting tools (such as Excel) for customized reporting without having to
rekey or download data from the system. User-defined groupings of
accounts for spreadsheet and user-formatted financial reports. Multiple
company reporting including consolidations. Detail transaction reports with
all relevant source document information. Extensive online inquiries
including general ledger balances, general ledger detail and drill-down
from balance to underlying detail transactions. Audit lead schedules online
history information available for prior periods.
URL:http://www.p2energysolutions.com/excalibur/financialaccounting/general-ledger-and-financial-reporting#sthash.IbCofUAq
5. Government Integrated Financial Management Information System
The Government of the Philippines (GOP) launched a comprehensive
public financial management (PFM) reform program in February 2011. The
details of the reform program are provided for in the Philippine Public
Financial Management Reform Roadmap, a strategic plan for a whole-ofMerchandising (General Ledger)
Page 28
government approach to PFM reforms, which aims to clarify, simplify,

improve and harmonize the financial management processes and
information systems of the civil service. This includes reengineering
business processes, integrating relevant systems in the Department of
Budget
and
Department
Management
of
Finance
(DBM),
(DOF),
Commission
Bureau
of
on
Audit
Treasury
(COA),
(BTr),
and
implementing agencies, as well as, reassigning functions between the

oversight agencies. The desired results are improvements in fiscal
discipline, fund allocation efficiency, and operational efficiency for the
effective delivery of public services. A major reform of the Roadmap is the
development
of a
Government Integrated
Financial
Management
Information System (GIFMIS), an integrated IT solution that can collect

and organize financial information in a central database to support, at a
minimum, budget preparation, execution and financial reporting. President
Benigno Simeon C. Aquino III, issued an Executive Order in September
2011 directing GIFMIS system development. In line with this, a two-track
approach
is
being
implemented
by
the
GOP.
URL:http://pfmp.org.ph/index.php/overview
2.2 Related Study
2.2.1 Foreign Study
1. General Ledger associates streamlines a shipping company
The client's internally developed operational systems each had its own
supporting financial system. It had separate accounts payable systems to
pay for terminal and depot expenses, truckers, agency commissions,
repair work orders and administrative expenses. Plus there were separate
accounts receivable systems for shipments originating overseas and for
those originating domestically. Separate, internally developed general
ledgers were maintained for corporate and the operating units. While
these operating ledgers satisfied financial requirements they were of little
value to the operating regions that maintained their own expense analysis
Page 29
systems. The task for GL Associates was to integrate all these systems
into one compliant financial systems product. First, we implemented new
corporate accounts payable and general ledger systems by designing a
new corporate chart of accounts (COA) and table of organization. New
"coding structures" supported an annual budgeting cycle even before we
implemented the new corporate ledger. This was especially critical, as the
company had started a major reorganization that was not supported by the
existing budgeting process. Next, we implemented the new corporate
ledger and accounts payable systems. These contained a level of
reporting detail and drill-down capabilities that far exceeded those of the
legacy system. We then put into place the financial systems for the
operating regions. This involved redesigning the COA so that it provided
financial reporting and meaningful analysis to operational personnel. It
was implemented concurrently with the elimination of all legacy accounts
payable systems and the accounts receivable system for domestically
originated shipments. The implementation was unusual because of the
large number of interfaces to legacy operational systems that had to be
built, the need to reassign vendor codes and the conversion of multiple
payable files, each with its own format. It also had to satisfy complex
accrual requirements to account for extensive delays in before
submissions of invoices by terminals, depots and truckers. The
streamlined systems developed by GL Associates greatly reduced the
need for internal training, eliminated most of the previous system
maintenance efforts, consolidated bank accounts, accelerated the closing
cycle and provided management with more meaningful financial reporting
and greatly enhanced analytical capabilities.
URL:http://www.glassoc.com/resource_center_case_studies.php?id=2
2. Kuali Financial System Implementation Project
Page 30
USCs existing financial system (EFS) is based on aging technologies and

is in need of replacement. Their Enterprise Information Systems
department provides core services to many USC organizations by
effectively managing EFS. However, while EFS is a collection of stable
applications that are adequate today, this aging system is at the heart of
USCs financial operations. This means that over time, EFS will become
increasingly discordant with the business needs of USC. There are high
risks associated with continuing to employ this aging technology. In
addition to the severe lack of documentation, the development platform is
old, and few experienced developers are available today. To address the
increasing risks associated with EFS, USC decided to migrate to Kuali
Financial System (KFS). The migration first addressed the General Ledger
and Chart of Accounts modules, followed by Financial Processing and
Vendor (Cashiering), Purchasing and Accounts Payable, Capital Assets,
Budget Construction, and Accounts Receivable. With the help of
Vivantech, USC identified 525 business functions required by their
financial departments. The majority of the functions are available in KFS
and a small number of functions required modification to the KFS
software. Additionally, 138 functions in KFS are new to USC and
considered enhancements to the USC systems. Vivantech mapped more
than 40 peripheral systems from EFS to KFS. USC chose a phased
implementation, bringing General Ledger and Chart of Accounts online
first at the beginning of a new fiscal year. Three months later they followed
with Financial Processing, and then two months after that added
Purchasing and Accounts Payable. The entire KFS suite migration is
scheduled to span three years and four months. Resources used
depended upon the number of modules and customization requirements;
however, Vivantech has become an extension of the USC team,
successfully executing the migration plan. Additionally, Vivantechs
onshore and offshore resources have allowed USC to scale up and down
depending on the phase of the migration.
Page 31
URL:http://www.vivantech.com/case-studies/case-study-kuali-financialsystem-implementation-project
3. Major financial institution put its trust in general ledger associates

Account administrators needed to accurately track the investments and
instructions of institutional customers in order to allocate funds for
maximum investment return. Institutional investment account managers
wanted to accurately record the current status of a clients account, as well
as any investment instructions that the client may have issued. The
instructions ranged from securities buy/sells, cash transfers to wire
transfers and check writing. Since billions of dollars were under
management, some of the instructions dictated that money be moved
overnight, and returned in the morning to gain the maximum in overnight
interest. Accuracy depended on being able to properly calculate each
accounts projected cash balance from a variety of different sources.
These included pending trades, cancelled trades and settled transactions.
Additionally, customer instructions and other extraordinary events needed
to be figured into the cash balance calculation. GL Associates
implemented a custom Intranet-based application that provided account
administrators with an efficient means of viewing all the required data and
inputting transactions and instructions in a simple yet elegant interface.
This Cash Management System provides an orderly process for gathering
and acting on cash balance information. An administrator logs onto the
system and views a grid with summary account information. A click on any
account results in a worksheet where details on account positions,
instructions and cash balances can be easily viewed. A series of
navigation buttons leads to screens that reveal more extensive details and
Page 32
entry areas for account rules, instructions and adjustments. The system
also has extensive reporting capabilities including a tool for producing
custom ad hoc reports. GL Associates relied on Microsoft technologies to
implement what was an n-tiered solution. We started with a Microsoft SQL
Server database that we populate nightly from the clients mainframe
system through IBMs MQSeries for Windows NT. In the middle tier, the
business processes were implemented using COM objects developed with
Microsoft Visual Basic and managed by COM+. Web pages that comprise
the systems top tier are Active Server Pages. During the day MQSeries
was also used to perform interactive messaging with a number of backend custody and trust accounting systems.
URL:http://www.glassoc.com/resource_center_case_studies.php?d=7
4. General ledger associates provides the right formula to solve
accounting crisis
The post-merger company found itself with over 40 separate general
ledger databases, one each for its various plants, divisions and corporate
entities. The general ledgers used different Charts of Accounts (COAs)
operated on different software products that ran on diverse hardware
platforms scattered across the country. Further complicating the situation,
the corporate ledger interfaced to yet another software product that
provided consolidation and corporate reporting. Divisional summary data
entry into the consolidated ledger was time consuming. Last minute
budget changes and adjusting entries resulted in significant discrepancies
between plant/divisional, corporate and consolidated ledgers. Frequent
business unit restructuring made ledger maintenance extremely difficult.
Month-end general ledger runs took many hours with out-of-balance
conditions frequently occurring. The various COAs not only were
incompatible but also were applied inconsistently and could not
Page 33
adequately support management reporting and financial analysis. GL

Associates first performed a two-week study to determine the best
solution. We recommended the design of a uniform COA and the
implementation of a single, integrated general ledger database using CA's
Masterpiece for both general ledger maintenance and reporting. Each
operating entity, using its local terminals, could interact with its part of the
total general ledger database. The design phase that included pro-forma
reports, the new COA and reporting structures took three months. System
implementation with all operating units was completed over 18 months.
Every phase of the project was completed on time and within budget. We
also were responsible for system documentation and user training.
Turnover was completely successful with no operating problems
experienced by the many groups assuming ledger responsibility. With our
proprietary software tools, COA maintenance on organization changes
turned into a minor task. Manual entries of divisional summary data and
discrepancies between divisional and corporate reports were eliminated.
This combination of a report-oriented COA, new relationship structures,
effective use of summary accounts and the elimination of separate
consolidation systems achieved dramatic reductions in the time needed to
produce end of month closings and reports. In one instance, the time was
reduced from 7.5 hours to a few minutes. Additionally, a number of
automated processes (validation of relationships, checks for completeness
of allocations, variance reports) were implemented to assure ledger
integrity. The general ledger system now simultaneously maintains
summary accounts for financial responsibility center, legal entity and other
management reporting. A vastly improved series of reports are produced
directly from the ledger with CA's VRW report writer. Besides significantly
reducing month end closing times, a very fragile financial reporting system
was transformed into a rock solid one with unlimited growth potential.
URL:http://www.glassoc.com/resource_center_case_studies.php?id=9
Page 34
5. General ledger associates provides the right prescription for

Merck
Change always seems to bring unintended consequences. The drug
company Merck was converting from a legacy financial system to JD
Edwards General Accounting. The change included adoption of new
+Business Unit Codes and a new Charts of Accounts. Merck had to
provide managers with the ability to look up new account numbers along
with submitting and uploading budgets quickly and easily. All modifications
and extensions to the JD Edwards system were written to run exclusively
on the AS/400 with a character-based green screen interface. For users to
have access to the AS/400 through their PCs, Merck had to install and pay
licensing fees for a copy of Rumba on every PC. Plus, users who were
accustomed to the Windows interface were forced to learn to use the
green screen interface. When Merck realized the conversion caused the
unintended consequence that account look-up and budget applications
could not be implemented using the JD Edwards standard approach, they
turned to GL Associates for a solution. The problem was solved when GL
Associates used the existing Merck Intranet to build a series of databasedriven interactive web sites on the AS/400. Their web sites contain
applications that access the JD Edwards data on the AS/400 and present
it to the user in a graphical user interface. The user could access the web
sites through the Internet browser on their PC. This solution resolved all of
Merck's concerns. It eliminated the need to train users on the JD Edwards
application. Since data access was obtained through the corporate
Intranet, software distribution was unnecessary and there was no need to
buy software licenses for Rumba to provide connectivity to the AS/400.
Because it is a huge global company, Merck's completely redesigned
Chart of Accounts (COA) was long, complex and subject to change.
Merck's budget holders around the world needed access to the new
business unit and account numbers when calculating and submitting
Page 35
departmental budgets. They needed a way to look up these numbers on

the COA without having to distribute hard copies to each user. GL
Associates developed the Account Lookup System on the Merck Intranet.
The user entered old business and account numbers via the PC's
graphical user interface. Then, the system queried the account-mapping
database on the AS/400 and presents the user with the new numbers. It
also permitted drilling down to the account balances in the General
Ledger. Query response time was instantaneous and the information was
always up to date because the data came directly from the JD Edwards
system. The solution was such a success that Merck requested a second,
larger Intranet-based budgeting system. GL Associates provides the right
prescription to make Merck healthy.
Budgeting System Merck department heads from all over the world
submitted budgetary information to the finance department by emailing
Excel spreadsheets. The spreadsheets were uploaded into the JD
Edwards system. This method became unmanageable because the
department heads changed the spreadsheet format before returning them.
The finance department then would have to manually repair each
spreadsheet before uploading to the general ledger system. Again, GL
Associates used an Intranet-based solution. Users could access those
accounts over which they have budgetary authority using a password.
Once an account is selected, the system displays a spreadsheet-like
interface that provides enhanced functionality. Users can build budget
based upon past actual or budgets or they can start from scratch. Budgets
can be entered by year, quarter or month with features such as inflation
rates and growth rates provided for ease of use. Users can then save
multiple alternative budgets on the server until choosing one to submit. A
single button click then uploads the budget into the JD Edwards database.
Total development time for the budgeting application was only two months.
URL: http://www.glassoc.com/resource_center_case_studies.php
Page 36
2.3 Synthesis and Relevance of the study

These studies contributed a lot to the group as well as to the project. It
gives idea and enlightened the group perspective to the general ledger as
a system. In reality general ledger is one of the features of integrated
financial system however its stand at the center and the end point of the
system. In regards to the relevance of the study, many of the organization
as of now are using the automated system to improve the progress of the
giving a good service to the clients and to the reduced the manual
activities. There is organization that used general ledger however it is not
integrated on the other hand the user needed to encode the data
manually. There is some organization that separates the general ledger
from the financial system however it is integrated with the other
subsystems or features, some of features are budget preparation, payroll,
Inventory etc. The thing is the all the input data will be merge into one
database and the ledger will extract and ready to print the report. There is
organization that using general ledger as an independent system. As the
new researchers the entire group decided to continue what being started
in order to achieved a quality general ledger system. There is case study
stated that general ledger will be more functional if it is integrated to the
other system. For the future researchers the group will ensured to make
this project as a good reference.
EIS Blueprint, Design, and Development
Figure 1: General Ledger Used case Diagram
Page 37
CHAPTER 3.0 RISK MITIGATION, MONITORING, AND MANAGEMENT PLAN
Page 38
1.0 Introduction
The Risk Mitigation, Monitoring and Management plan is about looking forward for
the possible circumstances that may occur within the development cycle of the
project. In this section the proponents prepares a list of the possible risk that may
affect the implementation of the system with the solution for that risks and also
blocking the away the risk even before it comes.
1.1 Scope And Intent Of RMMM Activities
The scope of the system is all about the management of the general ledger,
this includes all the companys report that has to do with all the necessary
and important files that the ledger must took good care in order to maintain
the balance within the whole company and in order to do that the developer
must possess a good relationship with the client to clearly know the business
processes of the GL so there will be no problem regarding the business
transaction of the company. In this case the scope also of the risk mitigation,
monitoring and management has been clearly stated, its boundary is the
overall scope of the general ledger of the merchandising but not involving the
operation of the other sub-systems with the ledger.
1.2 Risk Management Organizational Role
Creating a project has a need for a team work this includes choosing a
team member that are all good in functioning to suit all the needs of the
project.
Everyone in the group must know their specific function and in this section
the proponents will state all of the person associating the project and their
possible contribution to avoid risks.
Software development is the development of the project and it can

be a problem but can be avoided too by regular checking of all the
schedule, project size, estimates and costs of the development.
Page 39
Customer it is one of the biggest part of the building the project

because he will also be the one to detailed explain the whole
business process of the system but this can also avoid risks by
clearly stating all the necessary details that the system must have
to avoid having trouble in the completion of the project.
Software development team is the one to build a system for the

company so there will be a problem if just in case they cater the
wrong business transaction but it can avoid the risks by rechecking
and re assuring all the needed details, information, tools and proper
team member orientation about their specific function.
Admin can also help by cooperating and willingness to meet and

Check the system and giving opinion with the development team.
2.0 Functional Data Description(Risks Description)

The system that the proponents is proposing is about the general ledger that is for
all we know the general ledger is the end storage of all the thrown data report by the
different sub-systems, this ledger handles all the summary report of the whole
company so in this case the possible problem that might arise is the size of the
product, and the capability of the system to gather thrown data.
2.1 Risk Table
The proponents are aware that it is not really easy to look and read risks
from project documentation so the proponents decided to find a way that the
readers and the next generation wont find it hard for themselve to look and find
those risks from the system. In this section youll see a list of the risks that the
system might encounter in the development process organized inside a table to
be easier for the readers to look and read.
The probability of the risk table will be categorized specifically. Below are
the sample risks that the proponents might encounter during the development
process;
Page 40
Employee risk -The outcome of the project greatly depends on the people
assigned to complete it
Process risk- Failure to program/run the system due to software/hardware
issues.
Financial risk- Shortage of funds unable to comply necessary requirements
Technology risk- The system will technology-dependent
Business Risk- Work Plan is not met due to unexpected events resulting to
delayed completion of this project.

Integration risk- The system may not integrate with other modules under
merchandising system.
2.1.1 DESCRIPTION OF RISK MANAGEMENT
Business Impact Risk:
Business impact includes ability of the system to suit and provide
the needs of the general ledger because without the proper knowledge of
the specific business transaction of the ledger is like building something
clueless, the created system will just going to be ruined.
Customer Risks:
Customer risks includes acknowledging the side of the one whos
going to use the finish product, this has to do with the quality,
environment, function and over all conveniences that the system must
provide to the user because if the user cannot use the system because of
some kind of a matter regarding the appearance, environment and
function of the product then the development team failed in providing
conveniences for the user.
Development Risks:
Development risk is about the equipment and tools needed by the
system to achieve quality assurance like security that if fil to provide then
the system itself may also be fail.
Page 41
Employee Risk:
Employee risk is about the software development team their
functions and the possible risks that they may encounter in the
development process.
Process Risk:
Process risk is about the client willingness to share information
about their company, that if they fail to give the exact transaction of the
product then the whole system will be useless.
Product Size:
Knowing the exact size of the product is one of the big matters to
be considered this includes learning how to over-estimate the project to
avoid problems on the storages of data gathered.
Technology Risk:
Technology risk is keeping your eye with what is latest and what are
the softwares that cannot stand for several more years, this is also very
important to consider to prevent technical problems.
2.1.2 PROBABILITY AND IMPACT FOR RISK MANAGEMENT

The following is the sorted version of the above table by probability
and impact:
Page 42
Category
Risks
Probability
Impact
Employee Risks
Lack of training and experience
40%
Process Risk
Low product quality
35%
Product Size
Where size estimates could be wrong
30%
Development Risks
Insufficient resources
30%
Customer Risk
Customer may fail participate
20%
Technology Risk
Obsolete technology
10%
Business Impact
Product may harm the business
10%
Table Risk Table (sorted)

Impact Values
Description
Catastrophic
Critical
Marginal
Negligible
3.0 RISK MITIGATION, MONITORING AND MANAGEMENT

Risk management involves monitoring, so in this section the proponents will BE
having a detailed talk of the risks and ways to avoid it.
3.1 Risk Mitigation For Risk Management
Risks Mitigation is about assumption of the possible risks that may come
along the development process of the system and attack to this risk even
before they come.
3.1.1 Product size
The general ledger is the one who handles all the data report of the
whole system so the product size must be measured right based on
the actual size of the system. The developer must know how to
Page 43
estimate the size of the system he must know how to overestimate

to make sure that the system is capable in handling large amount of
records because if they fail in the size of the system then the
system will be worthless.
3.1.2 Business Impact
Since the system is about general ledger the proponents
must be eager in learning everything about the system that they are
about to do, because if they fail in providing the needs of the
company or if they fail to create a system that is based on the plan,
the whole system will be useless.
3.1.2 Customer (User) Risks
This section involves customers and the team willingness to
cooperate and to provide the details and information that the team
needs in order to create the system. If the customers themselves is
not willing to share any details regarding their company then the
software development team will be suffer from the knowledge
lacking about the system that they must create.
3.1.3 Process Risks
Process risks could also be a problem If the client fails to
describe the supposed to be process of their system the product
quality will be affected most of all if the client fails to describe the
real business function of the system that the proponents will going
to do.
3.1.4 Technology Risks
The technology changes almost all the time and this could
be a problem if the developer fails to provide the latest and flexible
kind of software for the system it can also be a problem if the
Page 44
software that the proponents use for the system can no longer
manage to be in the industry for several more years, so the
developer must know all the updates regarding the changes in the
software world.
3.1.5 Development Risks
Not all system are perfectly independent, there are some
systems that alone cannot manage all security that leads in
providing other equipments, this section will tell the risks in not
providing appropriate tools and equipment to make the system all
set.
3.1.6 Employee Risks (Teammates)
The development team themselves can also be a problem
by having lack of knowledge about the system that they are going
to create this can really make mistakes most especially if the
developer doesnt really aware of using the software that the
company is using this could take a lot of time to look on how they
are going to create the project.
3.2 Risk Monitoring For Risk Management
Since the possible risks has been assumed, in this section the proponents
will now going to monitor the system development to avoid and to prevent the risks
from entering the system.
3.2.1 Product Size

Since this could be a threat for the development team one must be the one
to over look at all the aspects regarding the size of the system and they must
assign someone to regularly check the status of the company and to know if there
Page 45
will be any changes so that adjustment would be much more easier for the team if
ever there will be any.
Business impact includes taking look at the both sides the business process
of the system and of course user of the finished product. In order to provide their
needs the developer must spend more time with the user to know all the needs of
the user and all transaction that the user is handling.
To avoid having trouble with the user in the completion of the system, the
proponents must know all the transaction that the general ledger is doing in order
to provide good quality product.
3.2.4 Process Risks
Since the proponents goal is to provide quality assured product, they must
set up a goal guide line to be followed by the team in order to complete the project
sticking to the goal.
To avoid having trouble with technology one member of the team must be
the one to look at every update of the software and look at the possible software
that can adapt to the current system that you were working.
Tools and equipment in bringing the quality of the product is a must so the
team must determine all the needed tools and equipment and give the customer
options of the equipment based on the price and quality and explain why the
system needs that and tell them some pointers and idea so that they know what
will happen if they fail to provide the equipments. Give them options so that the
customer can still choose what is best for their system
Page 46

In monitoring everything within the project, they must also be aware on
monitoring one another if they are still sticking to the project and the goal and to
know if they are still willing towards the accomplishments of the system.
3.2 Risk Management For Risk Management
This section is about waste management. If after assuming and continuously
monitoring the system and yet there still problems arise in this section the
proponents will state how are they going to handle and manage the risks from
infecting the whole system.
3.3.1 Product Size
Product size is of a certain company can always be change so it must
always be updated, after spending time on monitoring the system and still end up
having the problem about size then, this time they must spend much more time in
monitoring the companys product size, the team must assign one group member
to monitor all the changes of the company and one must check the estimation of
the developer.
So the business impact has been monitored, and if the developer still finds
error on the project then, this time they must assign two member of the team to
spend more time in being with the customer to know all of the transaction that he is
doing.
Page 47
Base on the plan, the proponents will going to meet the customer every
week so he could monitor the development of the project so in this case it is really
impossible to have problems with the customers opinion, and if ever there will be
minor problem that the customer find in the system, then there is nothing to worry
because the proponents will going to have a help and guideline on how the
customer will trouble shoot the problem.
3.3.4 Process Risks
The process risk is about risking the quality standard. If the team still fails to
provide the quality standard that the company is looking for, then this will going to
be the time to give more focus on the transaction process of the company, assign
again different group member to analyze the business process of the company to
meet their quality standard.
If the technology still becomes a problem then the team must go on a trial
and error method to see if there is any software that their system can adopt in
developing their system.
If the team encountered financial shortage regarding tools and equipment
that must be added to the system, provide the client options in the equipments and
tools. This includes the functionality, price, quality of the product.
It is not really impossible to dont encounter a employee risks, because it is
really hard to be consistent, but if the team member still be the problem then, ask
them about how they feel or if they are having problem with their tasks, helping one
another will be a great help to accomplish everyones task.
4.0 Special Conditions
Page 48
The PC
The system that the proponents proposing must be adoptable to other
computers it must be running even in the clients facility, in case that the
application have already installed to the clients computer and they find it a
problem for the employees to use the software, then the developer will request to
make a seminar and a training on how to use the software.

Log In
Can also be included in the special conditions, such that the employee must
understand that in some cases there are accounts inside the system that cannot
be edit and add because the system is specially created to for confidential
records where in only the authorize personnel of the company can only access
the specific accounts even though they are using same system within the
department.
SOFTWARE CONFIGURATION MANAGEMENT PLAN

1.0 Introduction
Page 49
In creating a system there will always be a change and we cannot control it not to
happen, so in this project the development team decided to create a software
configuration plan to identify, control, and make sure that the plan is implemented
correctly.
1.1 Scope And Intent Of SCM Activities
The scope of the Software Configuration Management plan is only within the
boundary of the GL, Its main purpose is to collect data so it must be accurate,
in this section the proponents will ensure that all of the data gathered are
collected by the system accurately, and this will be properly solved if the
system is already working well so the purpose of SCM activities is if ever that
there were changes to be implemented within the development of the system
all of the changes will be controlled since there were all be identified and using
this SCM the proponents can make sure that all of the changes will be
properly implemented because everything will be documented.
1.2 SCM Organization Role
The development team is just composed of a small team so all the team
member agreed to accept responsibilities most of all if within the changes.
Everyone must be working to aim the goals of the team. There will one group
member to analyze all the must be changed modules inside the system and
one to check all the changes implementation and the others are the one to
record and monitor all the changes all of the changes are being decided by
the whole team and let it check by the adviser to know if he already approves
it.
2.0 SCM TASKS
In this section we will be describing the software management configuration plan in
detailed form. In this section all the task will be describe and will be assigned to the
group members. The clients will also be updated from any changes that the
proponents will be implemented but we will make sure that this changes will not
Page 50
affect the users and if in case the changes affect the use of software , it will be
discussed with the entire team to the clients team in the meeting.
2.1 Identification
All of the software configuration will be describe and identified and will be
used for the software configuration management plan.
2.1.1 Description
Identify change
In the development phase of the system the team must work to identify all
the changes they have figured out in the system and ask all their
suggestion if they are agreed to implement change as well.
Approve change
The system likes to make sure all the changes of the software will be a
great help for the system. So we will be having rules for the changes, and
one of those is one can never implement changes in the software without
any consult and permission from team members.
Ensure that change is being properly implemented
The team will going to check if the changes are properly implemented
without causing troubles to the other parts system.
Document the change

The proponents will going to make sure that all the changes will be
detailed documented for to make sure that all of the changes will be
reported to the clients and the team.
Page 51
2.1.2 Works products and documentation

Identify change
The proponents is aware that there is no instant perfect project and
everything must undergo through several changes both in the documentation
and in the software so the proponents decided to identify the change first
and create a plan on are they going to fix it.
Control change
Aside from a deep planning and analyzing changes the proponents would
have to control the changes they are going to implement to avoid having
trouble in fixing the software if in case affected by the changes they created.
Ensure that change is being properly implemented
Assurance of implementing changes must always be monitored in order to
see if the created changes are working together without affecting the user of
the software.
Document the change
In every changes that the team will going to implement there must always be
someone to document the change, it is important specially, if they find trouble
during the development process in this case it would be easier for the
developer to find the root of the problem.
2.2 Configuration Control

2.2.1 Description
The system that the proponent is proposing is about the general
ledger, this general ledger is the end storage of all the reports
Page 52
gathered from the different sub systems so obviously it is quite

large and crucial and impossible not to meet changes specially at
the software storage so in this section the proponents will going to
use two methods in order to monitor the changes.
Request the change
Software developer will evaluate the change
The result of the evaluation will be presented as change report
The decision on change will be created
And if change is already approved:

1. Define the constraint
2. Check out the items for change
3. Implement the change
4. Apply the SQA activities
5. Check in items
6. Apply testing activities
7. Rebuild the software
8. Distribute the software
2.3 Version Control

2.3.1 Description
In changing anything within the document and software, all the
change must be recorded in the module and added to the version
number this will be done to know where are the changes located
and how is it done and this important to know where you get wrong
so if incase the developer seems to be wrong, then he could
automatically compare it to the old version to know if there were
wrong move.
2.3.2 Increasing Version Number
Page 53
If the change request is filed, a change report will always be the

next one. The proponents will be using decimal point version
number system.
<major update>.<minor update><bug fix>
Bug Fix
If enough bug fixes have been done on the module, the version
number will also increase. Bug fixes can affect the number of the
versions.
Minor Update
A minor upgrade can be used to add new features and components
but cannot reorganize the feature-component tree.
Major Update
A major update is a comprehensive update of a product that has a
need to be changed for the product code property.
2.3.3 Work Products and Documentation
The proponents used a version revision history that will be used to
document all the version revisions.
2.4 Configuration Status Accounting (Csa)

The CSA or configuration status accounting is all about updating the
changes to one another, here are some of the ways of the development team to
communicate. The proponents will be using a three different ways to
communicate to all the team members if ever there will be changes. Since the
Page 54
development team is only a small group the proponents will find a way to
communicate to other team members regarding the changes that they plan to
implement.
Description
In communicating to other team member we prepare three tools in order to

communicate to other people associating the team members. We have there
the following;
Online Help Desk

This tool will be useful to communicate with the clients. The clients can
send reports and other opinions regarding the system. They can also
post progress and submit it to the help desk for further communication.
Change request report

We will also going to have two forms for the change report, and it is the
change request form for the SCM, this will be in Html format so it can
be send to the web.
Verbal Communication
Aside from the technical and computer base communication, since the
group is only small we will still be implementing a verbal talk which is
done every meeting.
Work products and documentation
Online help desk
Page 55
This will be helpful for all of the clients if ever the software is already
delivered, the online help desk will be very useful for trouble shooting
the software without a need to call for a programmer.
Change request report generator

The change request report generator will be implemented as of the
software development process to document all of the changes that will
be done for the software and documentation.
Emails
Emails can also help to keep in touch with the developer in the long
time process of using the software.
Test Errors will be documented electronically

The test errors will also be documented electronically so the errors will
be monitored, in this case the roots of all the errors will be easier to
know.
Suggestion notes
Suggestion notes will also be reviewed for developing the system.
3.0 Software Quality Assurance Overview

The system that the proponent proposing is about the general ledger of the
accounting department this is the end storage of all the reports of all the sub
systems so this must be secured and reliable. The proponents decided to have a
software quality assurance to make that everything will fall into what has been
planned.
The software quality assurance is about the assurance of the whole system, we will
check all the boundary of the system to avoid wastes of time and other risks and to
avoid troubles in the completion date of the systems.
Page 56
Scope and intent of SQA activities

The scope and intent of the software quality assurance are;
To create a quality management approach
To have effective software engineering technology.
To have a formal technical reviews for the software process
To draw a multi strategy testing
To control all the changes of the software documentation
To make sure that the team is still meeting the quality standard that tey are
aiming.
To easier manage the product.
Reviews and Audits

This involves all of the formal technical reviews of the software quality
assurance performed of the software engineers. this are the objectives of the formal
technical review.
To uncover the errors in representations of the software
To verify if the software have already meets its requirements
To make sure that the software has been represented according to

clients standards.
To achieve software in uniform manners
To make projects more manageable.
3.1 Generic Review Guidelines
Page 57
Here the lists of ISO 9001 quality standards that must be applied to the
software by the software engineering, these are the 12 requirements
delineated by them and the proponents would like to apply it as their quality
assurance.
-Management responsibilities
-Quality system
-Contract Review
-Design Control
-Document and data control
-Product Identification and trace ability
-Process control
-Corrective and Preventive action
-handling storages
-control quality audits
-training
-Servicing
-Statistical Technique
3.1.1 Conduction a Review
The proponents will going to conduct a review regarding the changes, if the
changes may affect the client, then the changes will be discussed first to the
client and must consult first to the other team mates.
3.1.2 Roles and Responsibilities
The proponents decided to distribute the work to the five team members of
the team and give their specific work fields.
Page 58
3.1.3 Review Work Product

The proponents will make a weekly report, there must be someone to
generate report, all the changes will be reported and documented and
compare to the previous change documents.
3.2 Formal Technical Review

The proponents will be having a FTR that will be conducted during the software
process. It will be done in every interface, the proponents will test every interface In
order to make sure that the software meets the quality assurance that the team is
aiming.
3.2.1 Descriptions of Review Walkthroughs
3.2.1.1
The system will work alone without integrations so this

doesnt need to have any extended or additional
equipments.
3.2.2 Description of review inspections

3.2.2.1 In this section the proponents will focus on the parts that are mainly
designed by the group such as the interfaces, forms and databases.
3.2.3 System Specification Review
The proponents will change some of the system design but without changing the
systems features and correctness of the systems process.
3.2.4 Software Project Plan Review
The system will be created for the accounting department who handles the
General ledger so the plan will still be the same to create a system that will handle
the system for accounts payables and receivables.
Page 59
3.2.5 RMMM Review

The proponents will going to use the RMMM methods in the software to monitor
and prevent meeting problems within the software.
3.2.6 Requirements Review (Models and Specification)
The software design and specification will be specified and checked.
3.2.7 Data Design Review
The data design must also be reviewed each and every interfaces.
3.2.8 Architectural Design Review
Architectural Design describes the whole project design, layout and data flow.
3.2.9 Interface (GUI)
The software that the proponents proposing must be created according to the
client requests so the system must be designed according to their opinion.
3.2.10 Component Design Review
Since the software will going to be handled by the accountants the database
be designed and re engineered to suit the needs of the company.
3.3 SQA Audits
-
The team will going to monitor every one and will going to have weekly report of
everything that will be done.
The members will going to note their part of the system and interfaces and their
share between the members.
All the changes that the system will be implemented will be consulted first to all of
the team members before doing any changes.
Page 60
3.4 Problem Reporting and Corrective Action/Follow Up

This section will be focused on describing the problem and reporting
mechanism that are conducted within the software in countering the problem that
they might encounter.
3.4.1 Reporting Mechanisms
The software that the proponent proposing will be browser based. Which will
be very convenient for the users these will also have trainings not just for the
team member but for the users too.
3.4.2 Responsibilities
Each member of the team will be having a part for the system. Everyone must
have their own responsibilities but the proponents will be helping each other for
the success of the project.
3.4.3 Data Collection and Valuation
The plan will always be involve the opinion of the clients, all of their opinion
will be acknowledged, tell them to evaluate the project.
Page 61
SOFTWARE QUALITY ASSURANCE PLAN

1.0 INTRODUCTION
In creating a project everything must be documented to make sure that the final
product will never met a problem, so the proponents decided to make a soft ware quality
assurance plan to prevent any possible troubles that they might encounter in the
development process. The software quality assurance plan is created to monitor and
document everything that goes on inside the software. In this phase the proponents will
have to lay down all their plans in assurance of the software while developing.
1.1 SCOPE AND INTENT OF SQA ACTIVITIES
The objectives of SQA are;
To have a quality management approach

To have a effective software engineering methods and tools
To have a formal technical reviews applied throughout the software process
To draw a multi testing strategy
To control software documentation and changes.
To assure compliance with software development standards
For the measurement and reporting mechanisms.
To know all the people that needs to be involved.
1.2 SQA ORGANIZATIONAL ROLE

We have a relatively small team, only 3 members. So the team will use the team will
use Ego less structure.
Page 62
Ego-Less Structure
Editor/Teste
r/
maintenanc
Conceptual &
Advance Interface
Development (1)
User Interface
Design &
Development
-Conceptual & Advanced Interface Development: Cabalan, Rowel T.

-User Interface Design & Development & Trainer: Tabin, Elmer D.
-Editor/Tester/Maintenance: Arquiza, Jenelyn E.
Relative Cost of Correcting an Error
Unacceptable Range
100
0 Merchandising (General Ledger)
1
time
Page 63
3070
time
401000
times
Acceptable Range
for Errors
1540
100
10
tim
1
0
3-6
time
s
Req.
Design
Coding
Dev. Test
System Test
Field Operation
The Relative Cost of Correcting errors that must be done are visually explained at the
above Figure. The proponents have declared the expected error graph ranging from 1
time error to 40 to 1000 errors.
2.0 SQA TASKS

Here are the tasks we have for the SQA:
- Voting system
- this will be for decision making, all of the decision will be voted in this case there will
be fair opinion and all of the decision will be base on each others opinion.
- Close contact with the client
Page 64
-this is to form a good communication with the client, In this case all of the sharing of
information will be easier since the development team and the client always talked.
- Extensive detail design
-it is also included to have a system detailed design just like the actual but more
efficient.
- Research on the subject
- The development team must be willing to research on the subject to know more about
the project.
2.1 Task Overview
This section involves all the assurance within the general ledger system, the
quality control, design and to save time and costs and to minimize errors, problem
tracking and data flow.
2.2 Standard, Practices and Conventions (SPC)
The proponents chose to use a voting system for every decision that they are
going to implement, there will no leader and super visor but everyone must work
according to their specific tasks. And if in case there will be any changes, it will be
discussed first within the team members. Aside from the teams decision the proponents
are also acknowledging the clients opinion so there must be a close contact with the
client not just for a good relationship as partners but also for the discussion of the
extensive detailed design that will be implemented into the system.
1.3 SQA Resources
There will be no external resources are defined for this project.
4.0 Reviews and Audits
This involves all of the formal technical reviews of the software quality assurance
performed of the software engineers. this are the objectives of the formal technical
review.
To uncover the errors in representations of the software
To verify if the software have already meets its requirements
Page 65
To make sure that the software has been represented according to

clients standards.
To achieve software in uniform manners
To make projects more manageable
3.1 Generic Review Guidelines

Here the lists of ISO 9001 quality standards that must be applied to the
software by the software engineering, these are the 12 requirements delineated
by them and the proponents would like to apply it as their quality assurance.
-Management responsibilities
-Quality system
-Contract Review
-Design Control
-Document and data control
-Product Identification and trace ability
-Process control
-Corrective and Preventive action
-handling storages
-control quality audits
-training
-Servicing
-Statistical Technique
3.1.1 Conducting a review
There will be two kinds of review that the proponents will do, one is
the Review cases with the client, and the other one is review cases with
the team mates to maintain the good communication inside the team.
3.1.2 Roles and Responsibilities
There will be distribution of responsibilities inside the team to make
sure that everything will fall into what is planned.
Page 66
3.1.3 Review Work Product

The proponents will generate weekly report for each member to
monitor their consistency and focus for the project making and will
compare it to the previous report this will help the developer to know all
the progress that their team is doing.
3.2 Formal Technical Review
The proponents will going to have a FTR that will be conducted during the
software process. It will be done in every interface, the proponents will test every
interface In order to make sure that the software meets the quality assurance that
the team is aiming.
3.3 SQA Audits

-
The team will going to monitor every one and will going to have weekly report of
everything that will be done.
The members will going to note their part of the system and interfaces and their
share between the members.
All the changes that the system will be implemented will be consulted first to all of
the team members before doing any changes.
After presenting the changes in the team members, the client should also know
the changes made. Clients will be notified for small changes, while an agreement
between the client and the development team should be made for major
changes.
Past and revised versions of the project will also be recorded. The documents
will be noted to identify what kind of revision was made and by who.
5.0 Problem Reporting And Corrective Action/Follow-Up

In this section the proponents will describe their reporting mechanism that may
occur as a consequence that will be conducted to the system and the resolution and
correction follow up at every risk.
Page 67
5.1 Reporting Mechanisms

The team decide to use the famous facebook site for the reporting the
problem to the team members. It will be very convenient for this season since
there always a free internet at each of the networks.
5.2 Responsibilities
The team will be compose of the five members but since there are only
three of us now it has been decide not to select a team leader and instead of
that all three remaining members will do their best and with the best of their
knowledge to comply all the needed matter to complete the project.
-Conceptual and Advance Interface Development Elmer Tabin
-User Interface Design & Development Elmer Tabin
-Editor /Tester/Maintenance Jenelyn Arquiza and Rowel Cabalan
4.3 Data Collection and Valuation

To create a system for the General Ledger there will be a need to
review look and search for another related sources regarding the project
to make sure that the created system will satisfy the one that will be using
the system in the long run.
5.3 Statistical SQA
To have a better system the development team must follow the
trends and requirements of the new quality assurance of every software, It
is important to follow the statistical requirement of the SQA to make sure
that the system will also reflects the quality of the newly created software
as of the new generation. Here are the list of the statistical quality
assurance that must be applied to the project.
Information about the software defects must be collected,
analyze and prevent.

Do the attempt do the attempt at every side of the system,
this will help the developer if there are problems regarding
the defects of the system includes the non working functions
Page 68
of the system, violation of standards, and to make sure that

the system is working base on the actual general ledger that
the accountant are using at their department.

Once the defect at the system has been traced that defects
must urgently corrected to avoid the problems.
Although hundreds of different errors can be uncovered even for a small scale project
like this all can be tracked to one ( or more ) of the following causes.
Incomplete pr erroneous specification (IES)

Misinterpretation of customer communication (MCC)
Violation of programming standards (VPS)
Error in data representation (EDR)
Inconsistent module Interface (IMI)
Error in design logic (EDL)
Incomplete or erroneous testing (IET)
Inaccurate or In complete documentation (IID)
Error in programming language translation of design (PLT)
Total
Error
IES
No.
Serious
%
No.
MCC
VPS
EDR
IMI
EDL
IET
IID
PLT
Page 69
Moderate
% No.
Minor
% No.
Ei = the total number of errors uncovered during the ith step in the
software engineering process.
Si = the number of serious errors
Mi = the number of moderate errors
Ti = the number of minor errors
PS = size of the product.
The above table and functions will be used in the future, since we dont
have enough data to support it yet.
5.0 Software Process Improvement Activities

Determinants for Software Quality Organization Effectiveness
Customer
Characterist
ics
Process
Technology
Business
Condition
s
People
5.1 Goal and Objective of SPI

Here sure some of the goals of SPI
1. All errors and defects are recognized
by origin (e.g. flaw in specification, flaw in logic,
Development
nonconformance to standards).
Environment
2. The cost to correct each error and defects is recorded.

Process
Page 70
Product
3. The number of errors and defects in each category are counted and ordered
descending order.
4. The overall cost and defects in each category is computed.
5. Resultant data are analyzed to uncover the categories that result in highest cost to
the organization.
6. Plans are developed to modify the process with the intent of eliminating (or reducing
the frequency of occurrence of) the class of errors and defects that is most costly.
The graph below illustrated the errors that we expected for the project. They
categorized in six fields:
Field
Logic
%
30
Reason
None of the member have any experience on doing a project this size,
Interface
25
nor the experience on the project in this project degree of difficulties

We have 15+ interfaces that contain more than 400+ elements
Data
15
combined. And each element has average of 3+ functions behind it.

This project involved a lot of data accessing/storing, data flow
Handing
between each interfaces.

Its not easy to keep track of them.
Error
10
checking
HW/SW
Standard
10
10
And the queries that the database used are pretty much outdated.
We practically proud of this field because for the job in this size
Page 71
Data
Logic
Logic30%
30% Handli
ng
Stand
15%
ard
15%
5.2 SPI Tasks and Responsibilities

Each member of the group needs to do the SPI activities
6.0 Software Configuration Management and Overview

There will be lots of changes for sure at the development process regarding the original
plan so the team have decided to have a software configuration plan so that the
changes will be controllable and to make sure that all the changes will be properly
implemented and also to have a change report to be reviewed by the team member and
the client
7.0 SQA Tools, Technique, Methods
To make sure that every decision has been properly decided and implemented, lots of
tools and methods are included at this documentation like the voting system, close
contact with the team members, and research on the subject. There are different tools
to use at this project for the SQA. And for the problem solving the proponents have also
decide to follow the ISO 9001 Standards for the organizational structure ,
responsibilities, procedures, processes and resources to make sure that the project are
Page 72
being followed by the quality managements. But still having problem about the time and
size of the team for the over lapping of the functions of every member.
SYSTEM SPECIFICATION
1.0 Introduction
A general ledger manages all the accounts for recording transactions
relating to a company's assets, liabilities, owners' equity, revenue, and expenses.
So the system must make sure that everything will fall into its proper
specification.
1.1 Goals and objectives
The projects aims to provide solutions that will help the current situation
of companies in terms of general ledger.
The project aims to promote the efficiency of using technology on
companies to improve its productivity, most of all in the accounting
department.
1.2 System statements of the scope

The scope of the system specification is in the main field of the general
ledger such as The Journal Entries if the system can receive journal entries.
Adjusting Entries if the system is capable in adjusting the data gathered if
needed. GL account postings to make sure that the account for GL is capable in
account posting and to make sure that the system is capable in doing the normal
work .of the accountant in GL like Period-End Closing, Year-End Closing,
Financial Statements.
1.2.1 General Requirements
There are general requirement for the system that is specified below;
1. Interface to create a interfaces that will suit to the needs of the accountant
at the General ledger.
2. Database data base that can provide all of the needed storage for the data
gathered and GL transaction.
Page 73
3. Training Training that will be provided into the users of the system
4. Mobile Apps ability of the system to be adoptable into mobile such as
android phones for the easily browsing of information of the GL.
5. Free Format Query ability of the system to have a easy query box that can
ensure the easily querying of information that has been encoded in the
system.
6. Personalized Screen to create an personalized and creative attachment to
the created system but not over reacting in to the eye of the possible user
7. Import Export ability of the system to share resources like transferring the
data unto other equipments and windows such as printers and Microsoft
offices such as excel and power point and Microsoft word.
1.3 System Context

The created system for the general ledger is very important for the company who
handles GL for the faster transaction and accuracy of the system results, aside from it
can lessen the time consume at every transaction, this system can easily used by the
accountant and it can give reliable data base on the gathered information.
1.4 Major Constraints
1. Compatibility - if the system is not compatible into other devices and equipment
that needs to be installed to run the system successfully
2. Integration - if the system fails to integrate in to the other modules.
3. People ware - if the developer fails to meet the GL actual system.
4. Data Requirements - if the developer fails to achieve the dta requirements that
are needed to complete the project.
Page 74
2.0 FUNCTIONAL DATA DESCRIPTION

2.1 SYSTEM ARCHITECTURE
2.1.1 Architecture Model
Page 75
Page 76
Page 77
Page 78
Page 79
2.1.2 Current Subsystem Overview

2.2 DATA DESCRIPTION
2.2.1 Major Data Objects
2.2.2 Relationships
Page 80
3.0 Subsystem Overview

3.1 Subsystem Flow Diagram
4.0 ENHANCED INTERFACE PROTOTYPING

4.1 PROTOTYPING REQUIREMENTS
Page 81
Page 82
Page 83
Page 84
Page 85
Software Requirements Specification

1.0 Introduction
A general ledger manages all the accounts for recording transactions relating to
a company's assets, liabilities, owners' equity, revenue, and expenses. In modern
accounting software or ERP, the general ledger works as a central repository for
accounting data transferred from all sub-ledgers or modules like accounts payable,
accounts receivable, cash management, fixed assets, purchasing and projects. The
general ledger is the backbone of any accounting system which holds financial and
non-financial data for an organization. The collection of all accounts is known as
ledger account.
Page 86
1.1 Goals and Objectives

To create a system that will manage all the specific data gathered
from all the sub systems. To make it computerize and to add more
convenience in the transmission of all data gathered.

to create a system that will fit to the needs of the general ledger.
To record all gathered data to be pass by the other sub system.

Its not easy to record all data in a manual process. It can take
more time to write all of this in a record book.
To secure data Using a password, the company can secure the

data that they recorded.
1.2 System Statements of Scope

The scope of the system belongs to the summary of the whole
merchandising.
The general ledger are the last to receive all the data gathered from each
of the sub-systems inside the merchandising. The system can only
manage all the reports of every fields and they are the one to check all the
received reports within the boundary of every system.
So in short the scope of the system is just the received reports, such as
information, inventory, supplies monitoring, suppliers and sales.
1.2.1 General Requirements
1. System Functionality - A way in which a system could have a working system
functionalities
2. Interface - A way in which a system would have a several interfaces that will suit
to the needs of general ledger accounts.
3. Database - A way in which a system could provide data base for the actual
transaction of the data base.
4. Training - a way in which a system and the developer would have a training for
the user and other related employees.
5. Mobile Apps - a way in which a system would have a capability in adapting to the
android phones as application
6. Free Format Query - a way in which a system would have a search box that can
easily provide the users query.
Page 87
7. Personalized Screen - a way in which a system would have a creative and

personalized touch of the user
8. Import Export - a way in which a system will be adaptable in transferring data
into other application such as microsoft word, excell and other equipments .
1.3 System Context
The system that the proponents proposing for the accounting general ledger can
be used for a larger departments such that can able to adapt to any location
within the company and be used by multiple user.
It can provide the user efficiency when it comes to faster transaction of the
accountants and would provide reliable data and security to all of the gathered
information.
Time
Time-one of the biggest constraint is the time where in the proponents is just
given a short time to search and interview all the necessary details that the
system must adopt. The system for the general ledger is very important for, it
was the one who handles al the report from the whole company, in this case the
developer must be well knowledgeable about everything that will be implemented
inside the software it must provide all the needs of the company for the general
ledger.
2.0 Functional Data Description
2.1 System Architecture
2.2.1 Architecture Model
Page 88
Page 89
Page 90
Page 91
Page 92
2.2.2 Subsystem Overview

2.2 Data Description
2.2.1 Major Data Objects
2.2.2 Relationships
Page 93
2.3 Human Interface Description

1. Login to the system - the system will have a log in page that be use as the
security of GL data
2. Record Journal Entries - this interface will be use as the page that has the list
of all the recorded transactions
3.Record GL Postings - this interface is for the crated records of the general
ledger.
4. Record Adjusting Entries - this is for the recording, adjusting and deleting the
records of the GL.
5. Period-End Closing - This is for the dated posts records of GL.
Page 94
Test Specification
1.0 Introduction
This section provides an overview of the entire test document. This document describes
both the test plan and the test procedure.
1.1 Goals and Objectives
Overall goals and objectives of the test process are described.
1.2 Statement of Scope
A description of the scope of software testing is developed.
Functionality/features/behavior to be tested is noted. In addition any
functionality/features/behavior that is not to be tested is also noted.
Any business, product line or technical constraints that will impact the manner in which
the software is to be tested are noted here.
2.0 Testing Plan
We want the product to be bug free. We also want to make sure that there are no
defects in the product. So we will be spending large amount of the total software
development time on the testing. Below is the description of the testing procedure and
strategy. We will also be presenting the timing and scheduled of the tests to be carried
out.
2.1 Software (SCIs) to be test
2.1.1 Interfaces
Page 95
Page 96
Page 97
Page 98
Page 99
2.2 Testing Strategy

In the following section we will describe the testing strategy. We will user four different
methods to test our product.
2.2.1 Unit Testing
In the unit test case we will be testing the separate modules of the software. We will
carry out white box testing where each module or component of the software is tested
individually. We will test the components by passing data through it and we will be
monitoring data to find the errors.
We will be looking for entry and exit conditions of the data. We will make sure that all
the components work without any troubles.
Page 100
The test primarily be carried out by the programmer who designed and implemented the
module. Lead tester will carry out test on the modules to finalize the testing.
2.2.2 Integration Testing
In this method of testing we will implement the software at the clients location and will
run it. So we will be testing the product on clients network. As art of testing, will be
looking for any signs of the collision between our software components and those of the
clients. We will install the software at the clients site and will run it. We will have several
different other applications open as well. This applications will be the once that have to
interact with our software on normal bases. We will make sure that all the data is saved
correctly and there is no loss of data or database anomalies in the product. We will be
carefully looking for any sort of collision between several different applications.
2.2.3 Validation Testing
In this method of test we will be working with the customer to find out if the software
developed in valid for the clients. We want to make sure that the client is getting what
he asked for. We will look at the software requirement document in the case of conflict
or misunderstanding with client regarding software components.
We will perform the black box testing where the software is completed and we test all
the software components together. We will have several input data or test data that we
will derive results for. We will insert this data in the software and will get results from the
software. We will compare the results from the software with the results that we derived.
This way will check for the validation of the software.
2.2.4 High-Order Testing
Recovery Testing
No Recovery testing will occur. While system failures are undesirable, termination of the
program in the event of a crash is acceptable.
Security Testing
No Security testing will occur. There are no security issues.
Stress Testing
Page 101
The world builder and the engine will be loaded with abnormally high sprite counts (with
attributes and sounds) to determine how much Game Forge can handle.
Performance Testing
The engine will be loaded with an increasing number of sprites while the frame rate is
monitored using the Frame Rate Counter.
2.3 Testing Resources and Staffing
Resources
No special resources are required beyond those already needed for development.
2.4 Test Record Keeping
Test record keeping and Test work Products are described in section 3.4 of Test
Specification Document. For Information these topics, please refer to section 3.4 of the
Test Specification Document.
2.5 Testing Tools and Environment
The proponents are used as testing tools as well as the testing environment. Test data
files will be constructed for unit and integration testing. A Frame Rate Counter is also
used in determining program performance. There are no other special tools or
hardware.
2.6 Test Schedule
3.0 Test Procedure
In this section we will describe the test procedures in detail.
3.1 Software (SCIs) to be tested
For detailed list of the software components items please refer to section 2.1 from the
Test Specification document.
3.2 Testing Procedures
Page 102
In this section we will try to describe over all software specification. We will describe the
methods for all the different tests to perform and will also declare the expected outputs.
3.2.1 Unit Testing
In this method of testing we will test the smallest unit of software called modules. We
will be testing all the important paths to find any errors within the boundary of module.
So here we will apply sort of white box search. We will be testing parts of the software
rather than the entire software. The modules are as follows.
3.2.2 Integration Testing
In this method of testing we will implement the software at the clients location and will
run it. So we will be testing the product on clients network. As art of testing, will be
looking for any signs of the collision between our software components and those of the
clients. We will install the software at the clients site and will run it. We will have several
different other applications open as well. This applications will be the once that have to
interact with our software on normal bases. We will make sure that all the data is saved
correctly and there is no loss of data or database anomalies in the product. We will be
carefully looking for any sort of collision between several different applications.
Testing Procedure for Integration

The system will be integrated incrementally, to control the amount of bugs that need to
be fixed at any given time. The engine will be integrated in the following order: draw
handling, input handling, sound handling, logic handling.
The system will be tested for errors in a black box fashion, after each component is
integrated
Stubs and Drivers Required
The Object Handler is used as a test bed.
Page 103
The Data Loader is used to parse information from the datafiles into the Object
Handler.
Test Cases and Their Purpose
Each component will be attached to the Object Handler in theorder specified

above.
Expected Results
The system is expected to integrate without major flaws
3.2.3 Validation Testing
Testing Procedure for Validation
The feature and functionality in the final system will be cross-referenced with the
Software Requirements Specification document to verify that the software demonstrates
conformity with the requirements.
Test Cases and their Purpose
Features corresponding to the design requirements will be evaluated.
Expected Results
The software will perform within the specification of the software requirements
document.
3.2.4 High-Order Testing
Recovery Testing
No Recovery testing will occur. While system failures are undesirable, termination of the
program in the event of a crash is acceptable.
Security Testing
Page 104
No Security testing will occur. There are no security issues.

Stress Testing
The world builder and the engine will be loaded with abnormally high sprite counts (with
attributes and sounds) to determine how much can handle.
Performance Testing
The engine will be loaded with an increasing number of sprites while the frame rate is
monitored using the Frame Rate Counter.
3.3 Testing Resources and Staffing
Testing Resources
No special resources are required for testing beyond those already needed for
development.
3.4 Test Record Keeping and Log
Microsoft Excel will be used to evaluate immediate test results. After the results have
been evaluated, they will be submitted to a Mysql express database for storage.
A test log is kept to monitor the tests that have been applied. An error, or buglog is kept
to monitor any problems that have arisen during testing. Also, a betatester report form
exists to aid beta testers in organizing their communication with PA Software.
Page 105

General Ledger 07a v04

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

General Ledger 07a v04

Uploaded by

Copyright:

Available Formats

PROJECT BACKGROUND

Merchandising (General Ledger)

the one to use the system.

1.2 PROJECT SCOPE

Condense Edit glLock

The GENERAL LEDGER JOURNAL lists ledger transactions in journal (numerical)

with account subtotals.

The General Ledger Analysis lists each account balance in a monthly

Merchandising (General Ledger)

General Ledger Journal

To check and view the saved data.

Account Trial Balance

To list a closing trial balance

General Ledger Analysis

To look at the GL reports

Update Receivables to G/L

transaction in the General Ledger database.

Update Rent/Leases to G/L

Update Payables to G/L

Merchandising (General Ledger)

Chart of Accounts List

records in the chart of account file.

2.3 Out of Scope

1.2.4 Enterprise Information System Required Functionalities

fast browsing of the information needed unto every accounts.

Merchandising (General Ledger)

1.3 PROJECT PLAN

Searching the subject information through internet

Data Gathering Process

3.2 Project Timeline

Searching about General Ledger

July 14, 2014

July 21, 2014

Prepare an interview question

Merchandising (General Ledger)

Survey (Gathering Data)

Analyze the gathered data and identify

Identify the system scope.

Prepare a systems layout.

Planning for system design.

Implementation system design.

Prepare for the defense week

3.3 Success Criteria

Merchandising (General Ledger)

3.4 Issues and Policy Implication

all of the team

members are fine

and keep their focus

Merchandising (General Ledger)

For the software

issues the team

back up for the

have budgeting plan

too make sure that

The system will

The system will

Merchandising (General Ledger)

have set dates to

there are delayed

The system may

not integrate with

impossible for the