RFP FOR COMPREHENSIVE FINANCIALS SOLUTION
January 2019
TABLE OF CONTENTS
Section Page
1 Introduction ...................................................................................................................... 1
2 Proposal Instructions and Conditions .............................................................................. 3
3 Proposal Response Format ............................................................................................... 6 4 PHF’s Vision.................................................................................................................. 10
5 Functional and Technical Requirements ........................................................................ 12
Appendix
A Notification of Intent to Bid Form ................................................................................. 60
1
Statement of Purpose:
SECTION 1
INTRODUCTION
2
Punjab Health Foundation intends to obtain an off-the-shelf ERP solution to be customized and
implemented, for its Financial, Procurement and Asset Management systems along with full conversion
of legacy data from its currently deployed systems serving the same domains.
There are two major objectives to be met by the development of this Request for Proposal (RFP). First, it is
intended to establish and define a set of functional requirements to be satisfied for the ERP solution. Second,
it will provide an overall direction to the vendor in submitting a bid that will best meet PHF needs.
About Punjab Health Foundation:
The Punjab Health Foundation (PHF) was established in 1993 with the prime mandate to provide financial
assistance, interest free loans, and technical support to the private sector healthcare providers so that they could
share the burden of public sector in provision of healthcare services to the general public. The Foundation is an
autonomous body, governed by a Board of Directors. The basic role of the Foundation is to encourage the
concerned Health Professionals for establishing and upgrading health institutions and allied projects. This was a
milestone step of the Government of Punjab towards proactively assisting and promoting the private sector in
broadening the overall health coverage to the people of this province.
Punjab Health Foundation’s Computing Environment
The Information Services and Technology Department (IST) support academic and administrative computing systems and spearheads IT-initiatives to ensure adequacy of the technology infrastructure. PHF offers a rich and diverse computing environment that effectively meets the productivity requirements of its loanees. The foundation network is based on a high-speed fiber backbone with Gigabit uplinks and dedicated high-end servers and switches.
Administrative System Attributes
PHF has defined a set of desired system attributes that are included in Section 4 of this RFP. In
addition, Section 5 includes system functionality that is either operational and in use by the
foundation or has been determined to be important in the new computing environment. The
requirements in Section 5 have been presented according to functionality.
Evaluation Process and Selection Criteria
PHF intention is to procure the most functionally cost-effective solution available. Responses to this RFP will be evaluated and scored by a team representing selected user groups at the PHF. The following criteria will be evaluated:
Conformance with proposal response format (RFP Section 3)
Conformance of the proposed solution to the PHF Vision (RFP Section 4)
Conformance of the proposed solution to the Functional Requirements (RFP Section 5)
A comprehensive, workable and thoroughly researched implementation plan
A tailored training and orientation plan that addresses the needs of all stakeholders (systems
administrators, user administrators, power users, key users, end users, etc.)
Vendor experience in implementing the proposed solution, with locally available and sustainable
resources – both in terms of quality and quantity
3
Vendor financial stability
Implementation cost of the proposed solution
Cost of consulting services for future customizations
For the proposed solution:
Cost of initial license
Cost of annual support over the next 2 years (both from principal and 3rd
parties, if available)
Cost of product upgrades
Frequency of upgrades
Market share in Pakistan
Each evaluation component will be rated on a one (1) to five (5) scale where five is the highest rating. The rating will be multiplied by a weight factor to produce a total score.
4
SECTION 2 PROPOSAL INSTRUCTIONS AND CONDITIONS
2.1 Examination of Contract Conditions
It is the intent of PHF, through this RFP and contract conditions contained herein, to establish to the greatest possible extent complete clarity regarding the requirements of both parties to the Agreement resulting from the RFP.
Before submitting a proposal, the vendor shall be thoroughly familiarized with all contract conditions referred to in this document and any addendum issued before the proposal submission date. Such addendum shall form a part of the RFP. It shall be the vendor’s responsibility to ascertain that the proposal includes all addendum issued prior to the proposal submission date.
The vendor shall determine by personal examination, and by such other means as may be preferred, as to the actual conditions and requirements under which the agreement must be performed. If, upon inspection and examination by the vendor, there are any existing conditions or requirements of the RFP, which are not completely understood, the vendor shall contact the individual listed in Section 2.6.
If the vendor intends to visit PHF, the vendor shall request an appointment through Manager IT, (Mr. Atif Mehmood), whose contact information has already been provided. Inquiries will not be answered by other members of the staff.
2.2 Notification of Intent to Bid
Responding vendors who expect to be notified of any correspondence or addendum related to this RFP shall complete the Notification of Intent to Bid Form (RFP Appendix A) and e-mail it to [email protected] through the office of Manager IT, whose contact information has already been provided, no later than the date specified in Section 2.8.
2.3 Pre-Proposal Vendor Meeting
A pre-proposal vendor meeting will be held at the date, time, and place specified in Section 2.8. Vendors will be afforded the opportunity to meet with staff and other appropriate personnel to clarify terms of this RFP in further detail. PHF staff will respond to pre-submitted vendors’ written questions during the meeting and will attempt to provide answers prior to the conclusion of the meeting.
2.4 Interpretations and Addendum
No interpretation made to any respondent as to the meaning of the RFP shall be binding on 22-02-2019 unless repeated in writing and distributed by this office as an addendum. Interpretations and/or clarifications shall be requested from PHF, Attention: Atif Mahmood, Manager IT, PHF. All such written requests shall specify the Section(s), Subsection(s), Paragraph(s), and page number(s) to which the request refers.
5
2.5 Preparation of Proposals
Proposals shall be prepared in accordance with Proposal Response Format, Section 3. Proposals not complying with this format may be considered non-responsive and may be removed from consideration on this basis.
2.6 Submission of Proposals
Final proposals must be received by the deadline specified in Section 2.8; hard copies of the proposal must be delivered to the following address:
Proposals must be sent in a sealed package clearly marked:
Request for Proposal: ERP Financials Solution.
Proposals will be accepted up to, and no proposals may be withdrawn after, the time and date shown in Section 2.8. Vendors are responsible for ensuring that proposals are received by the above office prior to the deadline. Proposals received after the deadline will not be considered.
2.7 Vendor’s Costs
Costs for developing proposals are entirely the responsibility of the vendor and shall not be chargeable to PHF. All costs incurred in the preparation and presentation of the proposal shall be absorbed entirely by the vendor.
2.8 Projected Schedule of Events
Release of RFP document 09-02-2019
Last day to submit Notification of Intent to Bid Form 28-02-2019
Last day to submit written questions prior to pre-proposal vendor meeting 22-02-2019
Pre-proposal vendor meeting (date/time to be decided if required) 22-02-2019 at 10:00 am
Submission of proposals 28-02-2019 at 10:00 am
Opening of responses to RFP 28-02-2019 at 10:30 am
Response evaluation period
Award of contract
Proposed contract start date
2.9 Rights to Proposal Document
All copies and contents thereof of any proposal, attachment, and explanation thereto submitted in response to this Request for Proposal, except copyright material, shall become the property of PHF. All copyright material must be clearly marked.
6
2.10 Oral Presentation and Demonstration
Vendors may be required to make an oral presentation to the client’s evaluation team during the RFP evaluation period. The foundation and vendor will schedule these presentations at a mutually agreed upon time and location. Vendors will be informed about details of the presentation and given sufficient time to prepare for such a presentation.
2.11 Award of Contract
Award of contract for the ERP financials system will be made to one vendor whose proposal provides the most favorable solution to PHF. It is anticipated that the contract, if awarded, will be awarded within 40 days of the closing date for receipt of vendor proposals. Vendors must state that the proposal is valid for 90 days from the submission date shown in the above “Proposed Schedule of Events” section. PHF reserves the right to reject all proposals and not issue any contract based on this RFP.
2.12 Projected Software Operational Date
In order to meet PHF need for a timely implementation of ERP Financials Solution, it is
anticipated that the core software system shall be operational within 6-month from signing of
contract.
7
SECTION 3 PROPOSAL RESPONSE FORMAT
In order to facilitate the analysis of responses to this RFP, vendors are required to prepare their proposals in accordance with the instructions outlined in this section. Each vendor is required to submit the proposal in a sealed package. Vendors whose proposals deviate from these instructions may be considered non-responsive and may be disqualified at the discretion of PHF.
Proposals should be prepared as simply as possible and provide a straightforward, concise description of the vendor's capabilities to satisfy the requirements of the RFP. Expensive bindings, color displays, promotional material, etc., are not necessary or desired. Emphasis should concentrate on accuracy, completeness, and clarity of content. All parts, pages, figures, and tables should be numbered and labeled clearly. The proposal should be organized into the following major parts:
Section Title
1 Executive Summary 2 Company Qualifications/Capabilities 3 Response to PHF Vision 4 Response to Functional Requirements 5 Proposed Software Solution 6 Proposed Implementation Approach 7 Maintenance and Support 8 Proposed Software Architecture 9 Third-Party Partnerships 10 Client References 11 Price Information
1 - Executive Summary
This part of the response to the RFP should be limited to a brief narrative highlighting the vendor’s proposal. The summary should contain as little technical jargon as possible, and should be oriented toward non- technical personnel. The Executive Summary should not include cost quotations.
2 - Company Qualifications/Capabilities
Vendors must provide the following information about their company so that PHF can evaluate the vendor’s stability and ability to support the commitments set forth in response to the RFP. PHF may require the vendor to provide additional documentation to support and/or clarify requested information.
The vendor should outline the company’s background including:
How long the company has been in business
A brief description of the company
Company size and organization The most recent audited financial statement (e.g., annual sales, profitability, etc.)
Presence in the ERP financials marketplace
8
3 - Response to PHF Vision
The vendor must provide narrative responses to each of the requirements listed in Section 4 of the RFP.
4 - Response to Functional Requirements
The vendor must provide responses to each of the requirements listed in Section 5 of the RFP. PHF would also require a soft copy of the response to the functional requirements (section 5) in Microsoft Excel format within the sealed package on a DVD/USB media.
5 - Proposed Software Solution
The vendor must present, in detail, features, and capabilities of the proposed software solution. The vendor should include a detailed description of all administrative software systems.
6 - Proposed Implementation Approach
The vendor must describe the tasks and methodology used to manage and perform the activities and standard
implementation approach to the proposed project.
7 - Maintenance and Support
In this section, the vendor should describe the services that support the proposed solution. As part of the
description, the vendor should describe the delivery process for new releases, enhancements, and upgrades as
well as ongoing support and/or help desk services.
8 - Third-Party Partnerships
The vendor should include any information on companies that the vendor partners with to provide an ERP
Financials Solution (if any)
10- Client References
Vendors must provide at least three client references in Pakistan that are in full production with the ERP
Financials Solution being proposed by the vendor. The solution should include, but need not be restricted to,
the solution (refer to section 5 – RFP), that PHF has sought. The reference should have licensed the proposed
software for a comparable computing environment. Information should include at minimum:
Organization Name
Industry
Contact Title
Address
Number of Users
Software Licensed and Implementation Status
Hardware Environment
Please also response to the following reference information regarding your company:
a) Indicate the number of fully in-production ERP financials customers that are live.
b) Indicate any beta customer sites in the past 10 years that were unsuccessful in implementing your ERP
Financials solution.
9
c) List any public sector customers that have entered into legal dispute with your company in the past 10
years.
d) Indicate the location of the main development efforts for the ERP Financials. e) Indicate the number of total new customers added by your company in the past 36 months.
f) Indicate the number of years that you have had a ERP Financials customers.
g) Indicate if you are able to demonstrate unscripted, integrated functionality.
10
9 Price Information
The vendor’s price information must be itemized and include all costs (e.g., license fees, source code, object code, implementation and training, travel and per diem, documentation, maintenance, and hourly rates). The following format should be used to present cost quotations.
Application Software
Provide complete data on all initial costs to license the software being proposed including documentation. Indicate the modules included with each software system and associated costs, if applicable
Application Software PKR
Implementation Support and Training
Provide complete data of all initial costs for implementation support and training of all products (including the database management system, report writer and query tools) being proposed. Indicate whether training is conducted at the vendor’s facility or at __________.
IMPLEMENTATION SUPPORT
SOFTWARE DURATION COST
Application Software PKR
Other (list) PKR
Maintenance
Provide complete data of all first year maintenance costs for all products (including the database management system, report writer and query tools) being proposed. Include maintenance costs for any additional software being proposed and associated costs, if applicable.
Application Software PKR
Additional Services
Provide complete data of all costs for any additional services (example given below) that may be contracted during this project.
Consulting Services PKR Programming Services PKR Training PKR Other: PKR Other: PKR
Note: Indicate the time frame these prices are valid.
11
SECTION 4 VISION
Examples of the key components of PHF Comprehensive Financials Solution should include the following
characteristics:
Presentation Infrastructure – The vendor should be able to deliver role-based, personalized, secure, and
customized access to PHF’ services and information through an enterprise portal.
Application Infrastructure – The vendor’s solution should include web based potential loanee profile
creation. The application infrastructure should also include the ERP business logic, common object
library, Web application services, commerce services, and business process and workflow services.
Source Code: Vendor should also provide source code to the PHF.
Enterprise Data Infrastructure: The vendor should be able to provide components that promote
manageability and consistency in data storage, reporting, and business analytics. These components
should include ERP databases, the data stores, data warehouses, unstructured content, and the metadata
dictionary.
Integration: The vendor should provide integration components that are open and built for
interoperability. Integration services should operate on several levels: presentation, data synchronization,
process integration, and method invocation.
Extensibility: The vendor should utilize an approach to extensibility that provides a metered introduction
of innovation at a comfortable pace. This approach should also minimize disruption and IT costs so that
PHF is not forced to re-implement each time innovations are introduced in updated product versions.
Reuse: The vendor should provide a solution that manages common objects and entities as shared
components through a variety of methods. A common library of objects, functions, database tables, and
tools should be used to construct applications.
PHF plans to replace its existing web based user profile creation and application processing solution in favor
of systems and technology that support this new vision. Ideally, these systems would be an integrated suite of
applications. We would like to learn how the products you (and your strategic partners) offer will fit the
process, information, and technology needs we have identified below.
4.1 Complete Solution: Vendor should provide a Comprehensive Financials Solution for PHF. The vendor
should be the single point of contact (even if partners are involved), providing software, self- service
products, implementation services, and support.
12
4.2 Forward-Thinking: The solution should have a technical foundation based on recent technological
advancements that will help PHF move its processes into the future. The vendor should also describe
future product development plans.
4.3 User Friendly: The solution should be easy to learn and easy to use, with a consistent user interface,
thorough documentation, sufficient, experienced staff able to support the size of the organization, and
preliminary and ongoing training specific to PHF’ needs. The support system should provide the PHF
with an efficient structure to quickly address user issues.
4.4 System Integration: The solution should be completely integrated across all components of the system
so that data redundancy is kept to a minimum. The solution should provide consistent standards in all
areas, such that information can be shared across offices, with the proper restrictions placed on who
views and updates information.
4.5 Software Flexibility: The solution should be structured to support PHF’s changing needs, including
regulatory changes. The solution should take advantage of the technology to provide our users with
information access 24 hours-a-day, 7 days-a-week.
4.6 Software Interoperability: The software should provide interfaces with other software packages, such
as developed by PITB online application, Web-based applications, and Web portal. The solution should
have the ability to support executive offices by providing them with comprehensive and easy to use
decision support tools.
4.7 System Security: The solution must employ data security and integrity appropriate to the level PHF
deems adequate.
4.8 Software Support: The support for the system must be dependable and must help ensure this
dependability in the future. The vendor should describe telephone and Web support, users groups, list
servers, modification support, and upgrade procedures.
4.9 System Architecture: The vendor should describe the environment in which the software will run. The
vendor should include technical structure, supported database(s), and hardware platform(s) required for
running the proposed software.
4.10 Company Stability and Industry Presence: The vendor should detail years in business, experience in
financial systems deployment, client profile, number of clients in production with a full suite of ERP
Financials products, strategic partnerships, commitment to higher education, and dedication to
Comprehensive Financials Solutions
4.11 Workflow: The vendor should describe workflow features included in the proposed software. These
workflow features should span the entire enterprise.
4.12 Implementation Services: The vendor should provide a summary of the proposed services and training.
4.13 Web Features: The vendor should describe the Web-based features of the software. The vendor should
also describe any Web products included with the proposed software and product history of these
products. This should include both self-service applications directed towards customers, employees and
other casual users, as well as Web-based applications for administrative users.
13
SECTION 5 FUNCTIONAL REQUIREMENTS
The following answer key should be used when responding to the requirements:
Y = This feature is provided as standard
B = The proposed user tools can be used to provide this feature
M = Modification/customization would be required at additional cost
N = This feature is not provided
Please Note:
We will only be targeting premier solution providers and, as such, we expect to be provided with
Industry standard solutions. We expect the respondents to dilate upon the general features of their
product: reporting capabilities, documentation, on-line support, software architecture and advantages
thereof, etc.
We would also like for the vendors to specifically mention and recommend third-party solutions where
the proposed solution does not support that requirement.
Following are the functional requirements for the ERP financial system that we intend to implement in
the first wave and is of immediate interest to us. Vendors must complete this section and additional
information has to be produced where necessary.
Page 13
Ref. # Requirement Description Response
2.1 General Ledgers (GL)
2.1.1 Global settings
2.1.1.1 Able to enter the foreign currency exchange rates for automatic translation of foreign
currency balances:
Manually
Automatically (e.g. via the internet)
2.1.2 Accounting Period
2.1.2.1 Different fiscal reporting calendars must be available
2.1.2.2 Able to control the posting periods centrally for all account types (e.g. assets, debtor,
creditor, etc.)
2.1.2.3 Allow for special periods to facilitate year-end closing by dividing the last posting period into
several closing periods (at least 12 standard accounting periods plus 1 to 3 accounting
periods for adjustments).
2.1.2.4 Able to control users to access past period for adjustments (e.g. to re-open a period that has
been closed).
2.1.3 Chart of Accounts
2.1.3.1 Flexible to accommodate current and any proposed chart-of-accounts structures and
organization structure.
Able to provide facility to define and relate the following logical grouping structure and
numbering convention to the chart of accounts:
Company
Department / Division
Location / Branches
Business Unit
Cost Center
Profit Center
Etc.
2.1.3.2 Able to provide facility to amend and delete the entities (e.g. department, division) and its
relationship to reflect changes in the organization structure.
2.1.3.3 Multiple companies and multiple divisions with different chart-of-accounts must be supported
2.1.3.4 Provide for numerical and alphanumeric chart of accounts
2.1.4 GL Master Record
2.1.4.1 Able to maintain the following master data record to store control information on how
postings into the General Ledger account: System should be able t o deal with multi currency
Name of account
Description
Type of account (e.g. revenue, asset)
Currency (local, foreign)
Tax posting
Reconciliation account in nature
Level of transaction details to be maintain within the GL account
Automatic posting to prevent manual posting to account (e.g. gain/ loss on disposal)
Page 14
Ref. # Requirement Description Response
2.1.4.2 Able to:
Copy accounts between entities
Close accounts – block/ mark for deletion
Add accounts
Delete accounts
Change description of accounts
2.1.4.3 Able to :
Assign an activity status to accounts (e.g. active, inactive)
Retrieve an account master record via account alias
2.1.4.4 Able to provide audit trail to log the creation, amendments and deletion of each GL account
code.
2.1.4.5 Ability to control creations, amendments and deletions of GL master data by user-defined
authorization.
2.1.5 GL Transaction Posting
2.1.5.1 Able to enter journal entries into an electronic document on line. The information contained in
a journal should include :
Date posted, entered/ created
Source of journal (e.g. via interface system)
Journal text
Journal type
G/L account code
G/L account name and description
Debit/ credit amount
2.1.5.2 Able to restrict access to certain accounts by user-defined group.
2.1.5.3 Able to control journal entry posting function by user-defined authorisation.
2.1.5.4 Interface with other systems to capture accounting entries generated by these systems at
regular intervals during the day.
2.1.5.5 Post accrual journals that occur over a user-definable duration and automatically reverse at a
user-definable date after the posting.
2.1.5.6 Post to a future and prior period by authorized users.
2.1.5.7 Post allocation journals with user-definable rules (e.g. apportionment of expenditure).
2.1.5.8 Validate a journal upon posting performed interactively at time of data entry (e.g. valid GL
account code).
2.1.5.9 Suspend and resume, at a later time, entry of journal that are incomplete or imbalance.
2.1.5.10 Prohibit posting to closed periods within GL and other sub systems.
2.1.5.11 Produce audit trails on changes made on document postings.
2.1.5.12 Prevent posting to control (reconciliation) accounts of subsidiary ledger.
2.1.5.13 Provide facility to:
Page 15
Ref. # Requirement Description Response
Specify templates to capture details of recurring transactions. (e.g. fixed
prepayments and accruals)
Allow amendment or deletion to recurring transactions prior to posting.
Perform the posting automatically according to user-defined specification.
2.1.5.14 Allow for multiple account entries (debits and/or credits) for each transaction type.
2.1.5.15 Provide running total of debit/ credit amount.
2.1.5.16 Provide running total of transactions in each batch.
2.1.5.17 Enter statistical information during posting. (e.g. fuel oil consumption units).
2.1.5.18 Handle user-defined base currency GL processing for all accounting entities.
2.1.5.19 Handle multi-currency processing.
2.1.5.20 Able to perform batch processing as follows:
Update by batch mode while other users are still active in the system
Provide exception report for batch update
Post through overnight batch
Provide information on batch status (e.g. posted, processing, error)
Automatically assign document or batch number after journals are posted
2.1.5.21 Provide a journal edit listing on screen or printed. The information should contain,
but not limited to the following:
o Batch number
o Journal posting date
o Journal creation date
o Journal type
o Source of journal (e.g. via interface system)
o Journal text
o G/L account code, G/L account name and description
o Debit/ credit amount
o Batch total
o Number of transactions
2.1.5.22 Able to request for authorization of transaction exceeding maximum or transaction limits by
user-defined authority.
2.1.5.23 Able to electronically route journal for approval to an authorized user before posting to the
General Ledger. If rejected, the journal should be automatically routed back to the originator
for correction.
2.1.6 GL Account Enquiry
2.1.6.1 Able to display GL account balance in multiple views as follows (but should not be limited to):
Statutory
Responsibility (e.g. cost center, division/ departmental reporting)
Geographical
2.1.6.2 Able to hold balances for multiple ledger types such as:
Page 16
Ref. # Requirement Description Response
Actual
Budget
Statistical
Forecast
Taxation
2.1.6.3 Ability to allow enquiry by:
account codes and name;
wild search;
specific range of period, year, month;
2.1.6.4 The system should be capable of displaying:
On-line at least 5 years of history for account balances and posted transactions
account activity includes opening, movement for the period, closing period and year
to date balance
breakdown of balances by drilling down to source document
GL account master data
Able to store balances for future years.
2.1.7 Periodic Processing
2.1.7.1. Able to perform month-end and year-end closing.
2.1.7.2 Able to automatically, at period end:Two eyeball review required prior to posting anything.
Post accruals
Valuate foreign currency balances, calculate and post unrealized gain/ loss on
exchange
2.1.7.3 Able to automatically initiate a new financial year.
2.1.7.4 Able to automatically update the closing balance of the previous period and opening balance
of the current period with prior period transaction postings for all ledger balances. (e.g.
actual, budget, statistical).
2.1.7.5 Able to automatically transfer net profit for the current year to retained earnings account. (for
year end closing)
2.1.8 General Ledger Integration
2.1.8.1 Able to integrate with the following modules on real time basis, but should not be limited to:
Accounts Receivable
Accounts Payable
Material Management
Plant Maintenance
Project Management
Cost Management
Cash Management
2.1.9 Reporting
2.1.9.1 Provide flexible Report Writer with the following minimum features:
Specify the format and layout of reports;
Page 17
Ref. # Requirement Description Response
Summarize and total the information to be reported;
Select records to be included in the report;
Select details from each record to be included;
Sort the information to be reported as one level within another;
Perform arithmetic calculation on the information selected or totals thereof;
Ability to add narrative comments to reports
Ability to show financial data in thousands, millions etc. without creating rounding
problem
Store the report format for later use; and
Produce reports in graphical form for presentation purposes.
2.1.9.2 Able to produce the following financial reports, but not limited to :
Profit and loss account
Analysis of Profit and Loss account
Analysis of operating expenses
Balance sheet
Analysis of Balance Sheet
Trial Balance
Cash flow statement
Notes to the accounts (account breakdowns)
in multiple levels (e.g. whole organization, reporting units such as division) and for a user-
defined period (for the month, year to date).
2.1.9.3 Able to compare actual data to actual data and/ or budgeted data to actual data in:
yearly comparisons,
half-year comparisons,
quarterly comparisons, and
monthly comparisons
2.1.9.4 Able to allow downloading of reports to standard PC applications (e.g. Excel spreadsheet)
2.1.10 Cost Allocation
2.1.10.1 Able to allocate actual or budget amount based on :
Fixed percentage
Variable percentage
Level of activity or statistical information (e.g. floor area)
Budgeted value/ quantity
2.1.10.2 Provide facility to process allocations with ability to amend details prior to allocations.
2.1.10.3 Provide facility to reverse allocations.
2.1.11 Legal Consolidation
2.1.11.1 Able to allow for user-defined rules to facilitate consolidation for similar and dissimilar chart of
accounts.
Ability to:
Consolidate in multi levels
Consolidate actual and budget at balance sheet, profit/ loss account, cash flow
statement, expenses and revenue account levels
Automate generation of elimination transaction
Automatic generation of inter company balances
Page 18
Ref. # Requirement Description Response
2.2 Accounts Receivable: Generation of loan schedule, loanee alerts for system
2.2.1 Customer Master Data
2.2.1.1 Flexibility to provide account numbers: Automatic Preferred
Automatically
Manually (by the user)
upon creation of new customer account.
2.2.1.2 Able to control the creation and change of customer master data according to user
authorization.
2.2.1.3 Able to maintain the following master data, but should not be limited to, as follows:
Account name
Account address
Customer classification (type)
Credit worthiness rating
Surcharge/ Dunning specification
Incoming/ outgoing payment specification
Customer’s agreement details
Customer contact details
2.2.1.4 Able to allow for specified fields in the master data to be made mandatory (e.g. ID/KTP
number) or optional entry.
2.2.1.5 Able to perform a consistency check on the account balance based on user defined
specification (e.g. customer has moved out, balance is zero, no remaining open item) before
account is marked for deletion.
2.2.1.6 Able to change all fields in the master data on line with real time update to the customer
account.
2.2.1.7 Able to maintain audit trail of changes such as the time of change, the user ID, old and new
field values.
2.2.2 Incoming Payments including recovery of loan
2.2.2.1 Able to:
Accept various payment methods cash, cheque, bank draft, money/ postal order
from a walk-in customer or via post (except for cash)credit card, bank transfer by
telephone or the internet
Update the customer account immediately for own region bills as well as other
region bills
Accept payments for prepaid cards
2.2.2.2 Able to automatically calculate any discounts due to customer and post the amounts to
customer account.
2.2.2.3 Able to provide fast entry template to enter incoming payment details manually in the system
to update the customer accounts, able to take upload from excel sheets
2.2.2.4 Able to issue a receipt or validate bill upon payment.
2.2.3 Document Posting
2.2.3.1 Able to provide for electronic notification to make posting into the customer account such as:
Track status of work
Delegate work to user
Prioritize work
Page 19
Ref. # Requirement Description Response
Define activities involved for each stage
Track time taken to complete tasks
Enter transaction information
2.2.3.2 Able to post transactions such as debit and credit memos into customer account.
2.2.3.3 Able to provide facility to allow for:
Automatic numbering of documents
Allow for multiple document number series (if required to be specific to station/
region)
2.2.3.4 Able to print the invoice and other related document (e.g. debit/ credit memo) for the
transaction upon request.
2.2.3.5 Able to update to the customer accounts with the following (but not restricted to)
transactions:
Transfer from one customer account to another
Write off specific debts in customer account
Miscellaneous debit/ credit memo for adjustments
2.2.3.6 Able to maintain bad debt history for future credit-worthiness assessment for a customer.
2.2.3.7 Able to automatically update the corresponding account codes in the General Ledger after posting to the individual customer account in the sub ledger.
2.2.4 Dishonored Cheque Processing
2.2.4.1 Able to: daily bankstatement upload
post adjustment into customer account i.e. reverse the original payment transaction
to reinstate the original debt
upload dishonored check details in an electronic media supplied by the bank
2.2.4.2 Able to capture reasons for dishonored and maintain the customer’s payment default history.
2.2.4.3 Able to charge penalty to the customer account based on user-defined terms
2.2.4.4 Able to re-charge penalty imposed by bank to the customer account (if any).
2.2.4.5 Able to reverse payment posting from the General Ledger automatically. Two eyeball reviews
prior to posting
2.2.5 Collateral Deposit
2.2.5.1 Able to post deposit request into customer account:
on actual basis
on statistical basis, i.e. deposit request is updated in the customer account as a
memo record but not posted in the General Ledger until settlement of deposit is made by
cash.
2.2.5.2 Able to accept both cash and non-cash deposits (e.g. bank guarantee, shares).
2.2.5.3 Able to track the following status of deposit:
Requested
Paid/ Settled
Near Expiring (for non-cash deposit to trigger renewal)
Expired
Refunded/ Returned
2.2.5.4 Able to post refund transaction automatically to General Ledger.
Page 20
Ref. # Requirement Description Response
2.2.5.5 Able to change or reverse (cancel) the deposit request amount.
2.2.5.6 Able to print deposit invoice containing the following information, but should not be limited to,
as follows:
Customer name
Customer account number
Customer address (correspondence, premise)
Region/ Station
Security deposit number
Nature of request (cash/ non-cash)
Deposit requested
2.2.5.7 Able to perform refund the customer and automatically post the refund to the customer
account.
2.2.6 Surcharge on overdue balances & Misutilization penalty calculation
2.2.6.1 Able to print reminder letters that contain the following information, but should not be limited
to, as follows :
Reference (region/station)
Date of reminder letter
Customer account number
Name of customer
Location of premise
Amount overdue
Other remarks
2.2.7 Customer Account Enquiry
2.2.7.1 Able to locate a customer account using powerful search engines. Common search fields
include ID/KTP number, name (first name, last name), address, customer account number.
2.2.7.2 Able to:
Analyze customer balance via multiple views – outstanding balances, payment
items, statistical items, all paid and unpaid items
Search, sort by fields, total, sub-total
Drill down to document details
Drill down to master data information (includes technical data such as type of meter)
Inquire payment history, dunning history, installment history
2.2.8 Reporting
2.2.8.1 Able to provide flexible reporting tools such as:
select reports
edit reports (create/change/display)
transport reports to a different systems
download data to spreadsheets (e.g. Excel)
generate reports one at a time, multiple reports at a time, ad hoc and regular reports
together
generate reports at real time/ on line basis
generate reports in background
2.2.8.2 Able to :
generate reports via overnight batch
allow creation of user-defined reports without need for technical skills
Page 21
Ref. # Requirement Description Response
Perform calculations (e.g. totaling, percentage)
Provide a drill-down list or a sorted list in a table
Restrict report selection based on security of database, organization structure
2.2.8.3 Able to group the information according to user specification. Some key groupings may
include:
Responsibility unit/ location
Customer credit risk
Due dates
Customer type e.g. residential, industrial, Government, etc.
Tariff type e.g. residential, industrial, etc.
Payment history
Customer turnover
2.2.8.4 Able to electronically route the reports to allow users to review reports.
2.2.8.5 Able to display the evaluation based on information in the master data and/ or document
within Account Receivable:
Ranking list
User should be capable of specifying the maximum number of customers to be
listed in the evaluation display.
Sorted list by days overdue
Operational statistics (e.g. units sold, units generated, units used, number of
customers, fuel oil consumption)for a specified period of evaluation definable by user
2.3 Account Payable
2.3.1 Payment Processing
2.3.1.1 Able to create a proposal list by determining:
W hat is to be paid- items to be paid are selected and grouped for payment based
on user-defined rules
When payment is carried out. – based on user needs (e.g. due date of the items)
To whom the payment is made - by specifying the payee
How the payment is made –based on the payment method (e.g. cash, cheque)
foreign or local currency) according to rules defined by the user.
From where the payment is made – based on specified bank and a bank account
for the payment.
2.3.1.2 Able to make payment via various payment methods such as:
Cash
Check – manual and pre-printed
Bank notification (transfers)
Foreign currency
Credit Card
Internet payment
2.3.1.3 Able to store other deposit information such:
type of collateral
start and expiry date of guarantee
bank guarantee information (e.g. bank guarantee reference number)
2.3.1.4 Able to update the initial deposit request with bank guarantee information such as:
Guarantee reference number
Type of guarantee
Name of guarantor
Page 22
Ref. # Requirement Description Response
Amount
Start and expiry date
2.3.1.5 Able to generate recurring payment voucher.
Recurring payment information are:
Name of vendor
Invoice number;
Recurring amount;
Accounting information;
Start and end payment date;
Frequency of payment indicator to identify the frequency of the recurring payment
(e.g. weekly, monthly, quarterly, biannually, annually).
2.3.1.6 Allow recurring payment to be deleted within its period of payment.
2.3.1.7 Able to provide access to projected cash requirement information based on selected time
frames (for e.g. projected cash requirements for the next 14 days) to notify Head Office of
funds required to be transferred to the paying account.
2.3.1.8 Able to make payment in foreign currency:
Specify the bank account to which the payment is made from.
Specify whether it is possible to use the payment method to pay in foreign currency
Specify particular currencies per payment method
2.3.1.9 For paying bank account, able to :
Bank account selection based on payment method and currency
Check whether the selected bank accounts have sufficient funds for payment
2.3.1.10 For receiving bank account (if payment method used requires vendor bank details, e.g. bank
transfers), able to :
Specify bank details during the payment run
Retrieve bank details from the vendor master data
2.3.1.11 Able to print the vendor name on cheque for payment of miscellaneous invoice, where
vendor records have not been created.
2.3.1.12 Ability to amend /delete payment or payment batches with record of amendment / deletion.
2.3.1.13 Able to display changes made and by whom.
2.3.1.14 Able to allow invoices to be released for payment prior to due date.
2.3.1.15 Able to manage part payment of invoice.
2.3.1.16 Able to display or print exception listing. The exception listing should contain blocked items
and all outstanding items which the payment program did not propose for payment (items
that could not be settled despite being due)
2.3.1.17 Able to divide the task of editing the payment proposal between various users and enable
several users to edit large payment runs at the same time.
2.3.1.18 Able to perform payment approval functions to enable certain payments to have prior
approval.
2.3.1.19 Able to provide the ability to offset balances of vendor accounts in AP with balance of
customer accounts in AR (for vendors who are also customers).
2.3.1.20 Able to integrate payments to a cash management system.
Page 23
Ref. # Requirement Description Response
2.3.1.21 Able to schedule the payment run based on the desired start time. It should have the
flexibility to:
run only the payment program first and schedule the print programs for a different
time in a separate job or both at the same time
allow for user intervention on running the payment run
2.3.1.22 Able to print check on-line and perform the following functions:
Define void reasons (used during test print, page overflow and other user-defined
reasons such as printed incorrectly, unusable)
Determine the next free check number and store the allocation of payment
document number to check number or of check number to payroll accounting results (in
the case of payment runs in the human resources application (HR).
2.3.1.23 Able to provide facility to print and reprint payment voucher together with cheque.
The reprint copy should be marked with the word ‘DUPLICATE’. The payment voucher
should include information, such as vendor invoice number, cheque number, addresses and
other user-defined information.
2.3.1.24 Able to support the real time printing of check for urgent one-off payments.
2.3.1.25 Able to provide feature to cancel payments and check.
2.3.1.26 Provide access to payment cancellation information based on user defined selection criteria
(e.g. by vendor, period etc.) and print report on cancelled check.
2.3.1.27 Provide full audit trails for cancelled cheques and payment vouchers.
2.3.1.28 Able to split payment to more than one payee. (e.g. payment involving withholding tax).
2.3.1.29 Able to create a file containing all payment information according to paying bank specification
and output into :
Another file system
Disk
Internet
2.3.1.30 Able to post payments for update to the vendor account.
2.3.1.31 Able to automatically clearing items based on user criteria after payment has been made:
By account
By document number
By amount
2.3.1.32 Able to deal with payment differences in event when:
Difference is within vendor tolerance
Difference is above vendor tolerance
2.3.2 Vendor Account Enquiry
2.3.2.1 Able to view the account balances:
In summary (opening balance, transaction per posting period and closing balances)
By line items (drill down from summary)
Page 24
Ref. # Requirement Description Response
2.3.2.2 Able to perform various display functions within a vendor account such as search, sort,
display additional details (e.g. vendor master information), total, view by currency, obtain total
purchase per posting period etc.
2.3.2.3 Able to display check payment information on-screen based on check number or payment
document number. The information includes:
Details on the check recipient
Details on the check issuer
Corresponding payment and invoice documents
2.3.2.4 Able to provide online enquiry capability to vendor information via user defined selection and
sorting criteria (e.g. all vendors that are on-hold).
2.3.3 Reporting
2.3.3.1 Able to:
select reports
edit reports (create/change/display)
transport reports to a different systems
download data to spreadsheets (e.g. Excel)
generate reports one at a time, multiple reports at a time, ad hoc and regular reports
together
generate reports at real time/ on line basis
generate reports in background
generate reports via overnight batch
allow creation of user-defined reports without need for technical skills
perform calculations (e.g. totaling, percentage)
schedule for specific dates, the generation of these evaluations on a regular basis
restrict report selection based on security of database, organisation structure
2.3.3.2 Able to produce the following payable reports, but should not be restricted to :
Invoices selected for payment by period, bank, payment method
List of approved invoices
List of cheques printed by cheque number and date
List of vendors with vendor master details
AP Liabilities Listing (Goods and non-goods)
Invoices under retention
List of inactive vendors
Un-presented cheques
List of cancelled and void cheques
Details of unpaid invoices (payment proposal exception listing)
List of realized and unrealized gains/ losses
Number of invoices and vendors processed within a payment run
2.3.3.3 Able to produce vendor payment history including:
Payment by vendor
Payment by period for the current and prior year
Total paid by year
Total cumulative payments;
Date, amount and cheque number last paid.
Page 25
Ref. # Requirement Description Response
2.3.3.4 Able to electronically route the reports to allow users to review reports.
2.4 Asset Accounting
2.4.1 Fixed Asset Organization
2.4.1.1 Able to define fixed assets at different levels such as:
Group asset (main and components)
Asset class (Group asset belongs to an asset class)
Asset type (e.g. tangible and intangible)
Balance sheet (asset class is assigned to GL account code. This forms the balance
sheet item)
2.4.1.2 Able to assign an asset to a specific reporting unit or business area (e.g. region/ branch
offices) for internal reporting purposes.
i.e. When an asset is assigned to a specific reporting unit, the system should automatically
post the transactions such as depreciation and gain or loss on disposal, to the account
related to this asset to this reporting unit.
2.4.2 Fixed Asset Master Data Maintenance
2.4.2.1 Able to maintain the following information in the fixed asset master, but should not be limited
to:
Asset number
General information (e.g. description, make/ model, quantity)
Posting information (e.g. capitalization date and amount, asset expiry date)
General ledger account assignment
Accumulated depreciation
Depreciation
Gain/ loss on disposal
Revaluation
Time-dependent assignments (e.g. cost center reporting)
Information for plant maintenance
Information on the origin of the asset (vendor information)
Physical inventory data
Insurance data/ warranty
Depreciation data – asset useful life, depreciation method
Asset location
Project/ job number
2.4.2.2 Examples of information required to be maintained within the Fixed Asset system are as
follows:
Responsible unit (e.g. region, station)
Physical location of asset
Usage (e.g. building – staff quarters, power station)
Quantity
Unit measurement
Description/ additional information (e.g. land title number, capital project number)
Source of funding (e.g. capital contribution, own funds)
Page 26
Ref. # Requirement Description Response
2.4.2.3 Able to perform:
Master record creation
Master record changes
o Deactivate master record (this should be automatic upon retirement of
asset)
o Delete master record, provided that there is no posting was made to it)
o Block asset (to block further cost posting into the asset)
o Change to location/ reporting unit
o Change in assignment of asset to asset class
o Change in asset lives
2.4.2.4 Able to carry out mass changes automatically to a large extent for user-definable asset
record selection criteria:
Mass change to depreciation methods
Mass change in depreciation rates
Mass change in useful lives
Mass change in asset classification
Mass change in locations/ reporting units
2.4.2.5 Provide audit trail for creation, amendments, transfer and deletion for all asset group and sub
groups.
2.4.3 Additional Functions on Fixed Assets
2.4.3.1 Able to automatically or manually allocating a unique asset number upon creation of the
asset master record.
2.4.3.2 Allow for asset additions and capital improvements including :
acquisition and capital improvement costs and dates;
maintenance costs and dates;
original and extended useful life;
mass additions.
2.4.3.3 Able to collect the costs in a project or under construction and later assign the cost to an
asset.
2.4.3.4 Able to capitalize asset via :
The asset transactions should be routed from AP to Fixed Assets module
Integration with AP :
Post the asset acquisition and the corresponding vendor liability in one transaction
Integration with Purchasing/ Inventory:
Upon receipt of asset (with value), before invoice receipt
Upon receipt of invoice, asset is received (un-valuated) earlier
By moving the item from inventory
2.4.3.5 Able to capitalize an addition or enhancement to an existing fixed asset in the current fiscal
year.
2.4.3.6 Able to update the acquisition transactions automatically to the respective account codes in
the General Ledger.
2.4.4 Transfer/ Splitting of Fixed Assets
2.4.4.1 Able to:
Page 27
Ref. # Requirement Description Response
Move an asset, resulting in the need to change asset master data that cannot be
otherwise changed (e.g. the asset class, main asset )
Split up an asset or move part of an asset (transfer between asset groups, sub asset
group)
Transfer between departments, regions, stations, business responsibility units
Transfer material from the inventory (current assets) to a fixed asset (for example,
for a replacement part).
2.4.4.2 Able to capture information such as:
Date of transfer
Previous department, region, station, main or sub asset group
Cost, accumulated depreciation and net book values transferred
2.4.5 Fixed Asset Disposal/ Retirement
2.4.5.1 Able to produce proposed asset listing based on user-defined criteria (e.g. asset class,
location). The listing should contain the following information, , but should not be limited to:
General master data – location, description, make/ model, acquisition date
Asset history
Asset values (book value)
2.4.5.2 Able to manually amend the partial disposal amount calculated by the system and then
recalculate the corresponding depreciation for posting to the General Ledger.
2.4.5.3 Able to capture disposal information such as :
Date of retirement
Cost, accumulated depreciation and net book values written off
Sales proceeds
Gain/ loss on disposal
Board of Survey reference number
Reasons for retirement
2.4.5.4 Ability to perform the following within the Fixed Asset system :
Perform complete/ partial retirement
Provide simple method of retiring low value assets
Perform mass retirement
Capture cost of retirement (e.g. removal cost)
2.4.5.5 Able to automatically calculate the gain or loss on disposal.
2.4.5.6 Able to post automatically or manually to the respective account codes in the General Ledger
:
Gain or loss on disposal;
Sales proceeds;
Capitalization cost; and
Accumulated depreciation
2.4.5.7 Able to automatically determine the corresponding depreciation charge for the partial
disposal, based on one of the following entries:
Amount of the acquisition costs being retired
Percentage rate
Quantity
2.4.6 Depreciation of Fixed Assets
2.4.6.1 Able to provide for various methods of depreciating an asset, such as:
Straight-line
Page 28
Ref. # Requirement Description Response
Declining balance
User-defined rate tables
Sum of digit
Unit of use
Useful life
2.4.6.2 Able to define the commencement of depreciation calculation for the automatic posting of
depreciation to the General Ledger.
For example, pro rata at period start date, depreciation is charged from the beginning of the
month which acquisition took place
2.4.6.3 Able to calculate depreciation that takes into account of the remaining useful life e.g. after a
revaluation.
2.4.6.4 Able to permit no depreciation charge to be calculated on user-specified asset.
2.4.6.5 Able to maintain depreciation schedules for purposes of accounting, taxation and budgeting
automatically perform depreciation calculation for accounting and tax purposes periodically.
2.4.6.6 Allow the user to switch depreciation methods for a specific fixed asset or group of fixed
assets during the life of the asset(s).
2.4.6.7 Able to facilitate adjustment of depreciation of fixed assets prior and after updates to general
ledger.
2.4.6.8 Able to automatically post to the corresponding accumulated depreciation and depreciation
expense accounts in the General Ledger.
2.4.7 Revaluation of Fixed Assets
2.4.7.1 Able to capture the following information:
Revaluation amount
Revaluation date
Revaluation method
Valuers’ reference
Computation of revaluation surplus/ deficit
2.4.7.2 Able to keep the original asset cost details separated from the revaluated amounts and a
history of revaluation for each asset over time.
2.4.7.3 Able to provide for recalculations of depreciation expense. For example,
Depreciation = revaluation amount
Remaining/ new estimated life
2.4.7.4 Able to automatically post revaluation transaction to update relevant accounts in the General
Ledger. Two eyeball review needed for all automatic posting.
2.4.8 Physical inventory of Fixed Asset
2.4.8.1 Able to print asset listing for physical count based on user-definable criteria. The following
information should be generate for each asset:
By location
With asset ID
With asset description
With location
With quantity
2.4.8.2 Able to capture physical count manually or automatically via data upload (e.g. using bar code
scanning device, spreadsheet).
Page 29
Ref. # Requirement Description Response
2.4.8.3 Able to process the results of the inventory manually or automatically by :
Making comparison with information in the database
Retiring the asset if asset is confirmed missing
Change location if asset has changed location
Enter the inventory date in the assets counted and assets identified as missing
2.4.8.4 Able to capture the following information for all types of adjustments such as:
Date of adjustment
Cost, accumulated depreciation and net book values adjusted
Adjustment reference document (if any) and authorization
2.4.8.5 Able to manually or automatically adjust the acquisition cost and corresponding depreciation
for the missing assets to the General Ledger upon update of Fixed Asset system.
2.4.9 Integration
2.4.9.1 Able to provide for automatic integration with General Ledger, Accounts Payable, Accounts
Receivable, Project Management and Budget, including the following capability:
Automatic posting to G/L account;
Drill-back capability to Account Payable (e.g. Invoice, Purchase Order etc)
2.4.10 Reporting and Enquiry
2.4.10.1 Able to display asset description at individual asset level, summarized levels (e.g. asset
class, by balance sheet) and by particular asset (e.g. asset number).
2.4.10.2 Able to provide drill-down from asset descriptive details to:
Balances
Depreciation
GL account code
2.4.10.3 Able to provide asset information, but should not be limited to :
By date, year (e.g. by year of capitalization, year of disposal)
By type of transaction (e.g. acquisitions)
By asset location – for small assets which are portable
By responsibility unit (e.g. department, region, station)
By asset class (main asset group, sub group, asset number)
By user-specified rules (e.g. list asset greater than Rp100,000,000)
2.4.10.4 Able to provide searches and look-ups to search for a particular asset (e.g. asset number).
2.4.10.5 Able to produce reports for various reporting, flexible report writing tools and on-line enquiry
facilities for (but not limited) to the following :
Financial reporting (e.g. audit and taxation)
Management reporting
2.4.10.6 Examples of standard reports are listed, but should not be limited to, as follows :
Assets at gross separately from accumulated depreciation – for period and year-to-
date
Asset master at summary and detail level
Asset additions
Asset retirements
Asset valuation – gross asset values, accumulated depreciation and NBV
Assets by source of funds (e.g. capital contribution, own funds)
Depreciation expense using flexible user selection criteria
Depreciation schedule showing opening, movements and closing written down
values
Page 30
Ref. # Requirement Description Response
Depreciation forecast
GL posting summary
Assets not received inventory count
Asset found at location other than that assigned in the asset record
2.4.10.7 Able to provide ad hoc listings based on user defined specifications such as (but not limited
to):
Select and sort by asset category
Select and sort by asset class
Select or exclude fully depreciated assets
Select or exclude retired assets
Select by GL account codes
Select by business units
Select by asset status
Select by asset location
Select by asset life within asset book
2.4.10.8 Able to provide reports that can analyze asset information:
By responsibility unit (e.g. region, branch offices)
By time period (e.g. year)
By company, asset type, department and location.
By movement (such as addition, transfer or disposal) by account, current month or
year-to-date activity.
2.4.10.9 Provide for complete asset history, for example:
depreciation, depletion and amortization current period, year-to-date, accumulated
net book value and residual value for finance and tax
remaining life
transaction history with line-item
repair and maintenance tracking
warranty
insurance
acquisition and retirement date.
2.4.10.10 Reconciliation of fixed asset movements
Opening balance
Additions
Disposals
Transfer in/ out
Adjustments
Qualifying costs
Non-qualifying costs
Closing balance
2.5 Cash Management
2.5.1 Bank Reconciliation
2.5.1.1 Ability to enter bank statement details: Bank Statements are received in Excel/Acrobat format
manually
by electronic means
to match bank transaction information with receipts and payments in the system to produce
an electronic bank reconciliation.
Bank statement transactions that can be recorded include, for example:
Page 31
Ref. # Requirement Description Response
bank and other charges
interest received
electronic fund transfers
periodic payments
dishonored check
2.5.1.2 Able to automatically generate postings into the General Ledger for Outgoing Cheques/
Transfers as follows:
Cleared cheque/ bank transfer data delivered by the bank to generate the clearing
entries (i.e. debit Bank Clearing account, credit Actual Bank account).
2.5.1.3 Able to automatically generate postings into the General Ledger for Incoming Checks/
Transfers as follows:
Bank transfers and checks received/ banked-in to generate the clearing entries (i.e.
debit Actual Bank account, credit Bank Clearing account).
2.5.1.4 Able to:
Print cheque deposit and bank transfer listing
Post incoming cheques individually or in batch
Provide an overview of cheque deposit processing status
2.5.1.5 Able to:
record stop payment of cheques
enable the matching of multiple receipts in the system with a single receipt
transaction on the bank statement
2.5.1.6 Able to allow for short term planning from sources affecting the cash position. This includes:
Bank balances
Maturing deposits and loans
Notified incoming payments posted to the bank account
Outgoing checks posted to the bank clearing account
2.5.1.7 Able to:
Allow update of bank balance by bank accounts
Group bank accounts in a logical hierarchy by type of account (e.g. collection and
payment bank account) to allow for cash planning
Display bank accounts by group or in more detail by bank accounts via drill down
2.5.2 Cash Management for Collection Accounts
2.5.2.1 Ability to transfer funds from collection bank account to Current fund account. Flexibility to:
Automatically generate a proposal of amounts, by bank accounts, that can be
transferred based on user defined rules (e.g. transfer any excess above the minimum
level to be maintained in the account)
Edit proposed bank transfer amount by bank accounts
Delete bank transfer proposal
Provide information such as planned opening balance, transfer amount and closing
balance by bank account
Create, change and delete payment advice to sending (i.e. collection) and receiving
(i.e. main) bank account
Create bank correspondence
Post payment advice to the sending and receiving bank account
Post automatically to the General Ledger
2.5.2.2 Able to:
Page 32
Ref. # Requirement Description Response
Allow update of bank balance by bank accounts
Compare actual bank balance against forecast cash outflow*
Compute forecast excess or deficit in bank account
Send electronic notification to the responsible party for follow-up action in event of
excess or deficit
2.5.2.3 If forecast available balance is positive (i.e. excess cash), Flexibility to:
Provide information such as planned opening balance, amount to be invested and
closing balance by bank accounts
Create bank correspondence and/ or print cheque
Post payment advice to the main bank account
Post automatically to the General Ledger (e.g. Bank and Deposit account)
2.5.2.4 If forecast available balance is negative (i.e. deficit cash position),
Flexibility to:
Provide information such as planned opening balance, amount to be received and
closing balance by bank accounts
Create, change and delete payment advice to main bank account for borrowing or
maturity of deposit
Post automatically to the General Ledger (e.g. Bank and Deposit or Borrowing
account). Interest upon maturity of deposit should also be posted
2.5.3 Cash Management for Payment Accounts
2.5.3.1 Able to forecast cash outflow based on:
Liabilities from Accounts Payable and borrowings, payroll due within a user-
specified period
User-defined level. For example, at Head Office include all branches/ regions or at
individual branch/ region
2.5.3.2 Flexibility to:
Create, change and delete payment advice from sending bank (i.e. main) account to
receiving (i.e. payment) bank accounts
Post payment advice to the respective bank account
Post automatically to the respective bank accounts in General Ledger.
2.5.4 Cash Flow Forecast and Information Systems
2.5.4.1 Flexibility to provide for:
Electronic bank reconciliation
Drilldown reporting tool
Journal/ posting overview (e.g. bank transfers, deposit)
2.5.4.2 Able to provide drill down capabilities to view details of outflows and inflows. For example,
payment from capital projects can be further analysed by projects/ jobs.
2.5.4.3 Able to provide the information relating to transactions in 2.5.4.4. affecting the liquidity
position automatically from various sub-systems such as:
General Ledger
Accounts Receivable
Accounts Payable
Materials Management
Project Management
Loans and Deposits Management
2.6 Budgeting
2.6.1 Budget Master Data
2.6.1.1 Able to define a budget hierarchy for responsibility areas within the organization to facilitate
control and monitoring.
Page 33
Ref. # Requirement Description Response
For example, Department has many divisions, that in turn, have many units. Regional office
has many stations, that in turn, have many units.
2.6.1.2 Able to classify revenue and expenditure items by means of a hierarchy.
For example, personnel costs may consist of salary, wages, overtime, bonus etc.
2.6.1.3 Able to navigate within the budget hierarchy (e.g. expand/ collapse structure, drill down for
details).
2.6.1.4 Able to provide edit functions to create, insert, copy, delete a responsible area or revenue/
expenditure item within the hierarchy.
2.6.1.5 Able to identify revenue and expenditure as controllable and non-controllable for budget
control purposes.
2.6.1.6 Able to control authorisation to create, change, delete, budget, transfer and post by :
Budget version
Responsible area/ unit
Type of revenue/ expense
For example, able to provide level of access to create and maintain relevant assigned
budgets :
Regions/ Branches can only amend/ input their own budget;
Revenue Budget can amend/ input all budgets for branches/ regions/ Head Office
departments; and
Budget can only be approved by authorized person as defined in the system
2.6.1.7 Able to determine the budgeting start year and the number of years in the future for which
budgeting is allowed.
Ability to :
Provide for flexible user-defined budgeting period, e.g. 1 year, 3 years or 5 years
Provide for sub-period budgets, e.g. monthly, quarterly, semi-annually, or annually
Provide ability to create and maintain at 12 months rolling budget
Provide for multiple levels of budgeting at division, region, station and departments
2.6.2 Prepare Revenue Budget
2.6.2.1 Able to support multiple budgets by revenue accounts and expense accounts.
For example, to provide for at least two sets of budgets such as Annual (Original) and
Revised Budgets for each accounting entity.
2.6.2.2 Able to import or export budget details from / to external systems electronically (e.g. by way
of EXCEL spreadsheets).
2.6.2.3 Able to provide Windows-based spreadsheets for preparation of budgets.
2.6.2.4 Able to copy budget values into a new budget version:
from a reference budget version (e.g. previous year budget or forecast budget)
by selecting specific revenue/ expenditure accounts
2.6.2.5 Able to update budgets on-line, either individually or in mass.
2.6.2.6 Able to extract either automatically or manually financial and statistical information for
budgeting of revenue and expenditure items from:
Within the system
Page 34
Ref. # Requirement Description Response
Other external systems
Information required includes:
Sales revenue may be determined by actual quantity consumed multiple by the
corresponding tariff rates
Load information
Salaries and wages
Historical and projected payroll cost and number of staff for user-defined period
Repairs and maintenance
Preventative maintenance schedule
Depreciation
Existing assets
2.6.2.7 Able to provide a text editor function up to the lowest budget level (i.e. revenue/ expenditure
accounts) to capture supporting workings that derive the budget amount.
2.6.2.8 Able to record budgets at all levels of the chart of accounts (all views of account number up
to lowest level of the accounts and all levels of organisation).
2.6.2.9 Able to allow for input of budget data at detail level with automatic roll-up to summary level by
way of aggregation of account (i.e. revenue and expenditure items) at multiple levels of
consolidation.
For example, user can view budgeted profit/ loss account at unit to station level, branch to
regional level.
2.6.2.10 Able to allow for input of budget data at higher level within the budget hierarchy and perform
the following:
manually allocate amounts to detail level based on user-specified methods
allocate via automatic pro-rata apportionment to user-specified detail accounts.
2.6.2.11 Allow for manual override of apportioned amounts automatically pro-rated by the system.
2.6.2.12 Allocate budgeted overheads at the same level that actual expenses was allocated or based
on information from other accounts.
For example, budgeted general expenses may be apportioned based on previous year actual
breakdowns.
2.6.2.13 Able to incorporate algebraic, mathematical and logical formulas into cost allocation formulas
at the lowest budget level.
For example, allocate sick and annual leave budgeted costs to a responsible area based on
percentage of budgeted basic salary.
2.6.2.14 Able to maintain statistical information in the budget such as budgeted units of electricity
consumed.
2.6.2.15 Able to control the following activities by account, date of change and user IDs:
unlock such budgets to reflect budget changes
lock subsidiary budgets and master budget so as no changes can be made to it
once approved
2.6.2.16 Able to provide the option to reflect changes to amounts in a new budget version or without
indicating budget as a new version (i.e. overwrite original budget).
2.6.2.17 Able to check that detailed-level budget equal summary level.
2.6.2.18 Able to provide text facility for narration for changes made and reasons of amendments
within each version of budget.
2.6.2.19 Able to retain user-specified versions of the budgets upon subsequent reviews.
Page 35
Ref. # Requirement Description Response
2.6.3 Budget Information Systems
2.6.3.1 Able to download budget information to spreadsheet (e.g. Excel) for user analysis.
2.6.3.2 Able to provide facility to present budget data in graphs or charts within the system.
2.6.3.3 Able to provide the following information in the form of reports/ for on-line viewing at multiple
levels within the budget hierarchy (should not be restricted to):
Comparison of actual against budget figures (in terms of quantity and value)
Statistical information such as electricity units generated (by different sources of
energy), electricity units sold, quantity of fuel oil consumption, electricity units used by
station
Budgeted Balance Sheet
Budgeted Profit/ Loss account
Budgeted Cash flow
2.6.3.4 Able to spread budget over the financial periods based on:
Even spread
Seasonal spread
Fixed spread
Variable spread
Manual allocation (i.e. to enter budget figure to specific month)
2.6.3.5 Able to perform automatic budget availability checks during transaction posting.
2.6.3.6 Able to define tolerance limits either as a percentage or absolute value, depending on the
amount exceed, automatically perform the following:
Trigger warning to user
Trigger warning to user and mail to budget owner
Disallow posting
2.6.3.7 Able to provide the flexibility to inquire budget information on responsibility area by user
defined parameters (e.g., time period, level of detail, activity, etc.).
For example, variance calculations on month to month, year to year, year-to-date actual of
specified balance sheet or profit/ loss items (for a particular year) against relevant budgeted
values.
2.6.3.8 Able to print variance analysis reports.
2.6.3.9 Able to electronically route the reports to allow users to review reports.
2.6.3.10 Able to provide exception reports for responsible areas (e.g. unit, station) that exceeded
budget with details such as:
Revenue/ expenditure (according to chart of accounts)
Actual to date
Budget
Variance (i.e. amount in excess of budget)
2.6.3.11 Flexibility to:
Maintain the original budget version and the revised budget version
Update the original budget by
o Increasing the budget amounts
o Reducing the budget amounts
o Transferring budget amounts. For example, transfer budget from station
to station within same region.
Page 36
Ref. # Requirement Description Response
2.6.3.12 Able to allow changes to be made to the 5 year forecast revenue and expenditure items
either by manual entry or electronic upload.
2.7 Executive Information Systems
2.7.1 Data Capturing and Extraction
2.7.1.1 Able to capture and extract financial data from ERP modules for reporting:
Profit & Loss items
Balance Sheet items
Cash flow
Loans (employee loans only)
Inventory
Fund / Investment
Capital expenditure
Foreign exchange
2.7.1.2 Able to capture and extract statistical data from other ERP modules for reporting:
Project completion progress
Project capitalization status
Inventory movement and stock-outs
Requisition fulfillment history
Vendor / Contract performance
Security incidents (e.g. theft)
2.7.1.3 Able to capture statistical data from :
manual entry
external electronic media
interfacing with external databases
2.7.2 User-defined Reporting
2.7.2.1 Able to define criteria for extraction of data.
2.7.2.2 Able to define formula for formatting data i.e. metric conversion, quantity count, percentage
calculation and arithmetic calculation.
2.7.2.3 Able to compare historical data to actual data based on user define period (e.g. monthly,
quarterly, yearly).
2.7.2.4 Able to compare actual data to Target / budget data based on user define period (e.g.
monthly, quarterly, yearly).
2.7.3 Reporting and On-line Inquiry
2.7.3.1 Able to generate reports
one at a time,
multiple reports at a time
ad hoc and regular reports together.
2.7.3.2 Able to generate reports at
real time / on line basis.
in background (when evaluation is time-consuming).
via overnight batch
specific date
regular time interval
2.7.3.3 Allow creation of user-defined reports without the need for technical skills.
Page 37
Ref. # Requirement Description Response
2.7.4 Benchmarking
2.7.4.1 Able to assign targets to statistical data based on:
2.7.4.2 Able to highlight to user when the actual data exceed predefined tolerance or an acceptable
target range
on-screen
in report printout
2.7.5 Report Distribution
2.7.5.1 Able to output reports in various media:
screen
printer
magnetic media
2.7.5.2 Able to prioritize reports for processing.
2.7.5.3 Able to define distribution list for each report.
2.7.5.4 Able to distribute reports electronically to other users:
automatically upon completion
at preset time
2.7.5.5 Able to view report before printing.
2.7.5.7 Able to export reports to standard spreadsheet, word processing and database format.
3.1 General Features
3.1.1 System is web enabled for procurement activities
3.1.2 Able to support electronic procurement for the supply of goods and services of maintenance,
repair and operations (MRO)
3.1.3 Able to integrate with all other functions within the system
3.1.4 Able to integrate workflow to Microsoft Office, Lotus Notes or other e-mail applications
3.1.5 Able to provide the same menu driven functionality as other areas of the system
3.2 Procurement
3.2.1 Integration
3.2.1.1 Able to integrate with other functional areas of the system
3.2.2 Purchase Requisition
3.2.2.1 Regional/Branch offices or departments able to send on-line requirement requests to
centralized procurement unit
3.2.2.2 Able to generate requisitions for demand from other functional areas within the system e.g.
capital works, plant maintenance, MRP etc
3.2.2.3 Able to create manual requisitions for materials or services
3.2.2.4 Able to handle requisitions for different types of purchases e.g. non-stock materials, stock
materials, services, assets, contract labour etc
3.2.2.5 Able to capture the requisition originators name and details
Page 38
Ref. # Requirement Description Response
3.2.2.6 Able to assign requisition number automatically
3.2.2.7 Able to provide user defined text fields for requisition details, special instructions
3.2.2.8 Able to attach item specifications to requisition items and be able to view the details upon
Inquiry
3.2.2.9 Able to authorize requisitions electronically on line based upon predefined criteria e.g. value,
department, type of purchase etc
3.2.2.10 Able to automatically determine the authorizer of a requisition based upon predefined criteria
e.g. manager, general manager, etc
3.2.2.11 Able to flag the requisition as requiring approval to the approving person automatically using
workflow technology
3.2.2.12 Able to escalate the requisition awaiting approval if not has not approved/rejected within a
specified timeframe using workflow technology.
For example, requisition sent to manager after 1 day not approved/rejected, send to general
manager
3.2.2.13 Able to allow approver to reject the requisition and automatically return to the originator with
a reason for rejection using workflow technology. Also have option of partial/line item
rejection of indent
3.2.2.14 Able to change the requisition and re-submit for approval as above
3.2.2.15 Able to track and record all changes made to a requisition and produce reports of the change
made upon request
3.2.2.16 Able to track and record the status of a requisition e.g. not approved, approved, rejected, etc.
3.2.2.17 Able to cancel / delete requisitions for materials or services no longer required
3.2.2.18 Able to allow for quick requisition creation for commonly purchased items e.g. use of a
requisition template
3.2.2.19 Able to provide facility to print out hard copies of requisitions for approvers or users
3.2.2.20 Able to make certain fields within the requisition mandatory, view only, etc
3.2.2.21 Able to enter a valid account number or project number to be charged for the requisition item
3.2.2.22 Able to counter check with the budget. Message will appear if no budget is available or
exceed the budget when entering the requisition accounting details
3.2.3 Purchase Requisition Reporting
3.2.3.1 Able to produce requisition reports for all requisitions captured in the system by specified
user criteria e.g. requisition number, status, date, material number, description, originator etc
3.2.3.2 Able to print reports for requisitions and / or send to another user
3.2.3.3 Able to drilldown within a report to the requisition details
3.2.3.4 Able to allow authorized users to display a requisition details upon request
3.2.4 Request For Quotation (RFQ)
3.2.4.1 Able to integrate to other functional areas within the system
3.2.4.2 Able to create an RFQ either manually or automatically from an approved purchase
Requisition
Page 39
Ref. # Requirement Description Response
3.2.4.3 Ability to select and assign vendors to RFQ’s
3.2.4.4 Able to hold a RFQ awaiting approval
3.2.4.5 Able to link to vendors database to gain vendors details if available
3.2.4.6 Able to flag the RFQ as requiring approval to the approving person automatically using
workflow technology
3.2.4.7 Able to escalate the RFQ awaiting approval if not actioned within a specified timeframe using
workflow technology
3.2.4.8 Able to include user defined weighting factors in RFQ evaluations
3.2.4.9 Able to store physical vendor responses in the system and attach to the RFQ referenced.
Also able to retrieve the responses and print when required
3.2.4.10 Able to print RFQ details on demand
3.2.4.11 Able to perform an on-line evaluation of the vendor to whom the RFQ is to be sent
3.2.4.12 Able to send RFQ response details to another user
3.2.4.13 Able to allow for quick RFQ creation for commonly purchased items e.g. a template for
regular types of RFQ
3.2.4.14 Able to provide facility to print out hard copies of RFQ’s for approvers
3.2.4.15 Able to make certain fields within the RFQ mandatory, view only, etc
3.2.4.16 Able to enter and store vendor response information into RFQ’s on-line
3.2.4.17 Able to perform on-line evaluation of the responses based on predefined criteria
3.2.5 RFQ Reporting / Display
3.2.5.1 Able to view the documents or specifications prior to attaching to the RFQ
3.2.5.2 Able to display the RFQ details on demand
3.2.5.3 Able to display the RFQ status on demand
3.2.6 Contract Management: Must Have, data extraction of key
KPIs, payment mode from the contract and its monitoring
3.2.6.1 Able to integrate to other functional areas within the system e.g. requisitions, RFQ’s,
purchase orders, vendors etc
3.2.6.2 Able to create a contract from an approved RFQ
3.2.6.3 Ability to assign vendors to a contract
3.2.6.4 Able to hold a contract awaiting approval
3.2.6.5 Able to electronically approve the release of a contract based upon predefined user criteria
Page 40
Ref. # Requirement Description Response
3.2.6.6 Able to flag the contract as requiring approval to the approving person automatically using
workflow technology
3.2.6.7 Able to escalate the contracts awaiting approval if not actioned within a specified timeframe
using workflow technology
3.2.6.8 Able to allow approver to reject the contract and automatically return to the originator with a
reason for rejection using workflow technology
3.2.6.9 Able to change the contract and resubmit for approval as above
3.2.6.10 Able to track and record the status of a contract e.g. not approved, approved
3.2.6.11 Able to cancel / delete contracts for materials or services no longer required
3.2.6.12 Able to allow for quick contract creation for commonly purchased items
3.2.6.13 Able to provide facility to print out hard copies of a contract for approvers or vendors
3.2.6.14 Able to make certain fields within the contract mandatory, view only, etc
3.2.6.15 Able to print contracts on demand
3.2.7 Contract Reporting / Display
3.2.7.1 Able to track all changes made to a contract
3.2.7.2 Able to report the status of a contract e.g. awaiting approval
3.2.7.3 Able to produce reports of contracts by user defined criteria e.g. contract number, vendor,
material number, originator, department responsible, authorizer etc
3.2.7.4 Able to attach document and specifications to contracts
3.2.7.5 Able to view the documents or specifications prior to attaching to the contracts
3.2.7.6 Able to display the contract details on demand
3.2.7.7 Able to display the contract status on demand
3.2.7.8 Able to report contract usage and performance data e.g. how often used, vendor
performance on contracted terms etc
3.2.7.9 Able to report contract validity dates
3.2.7.10 Able to view historical transactions against the contract
3.2.8 Purchase Order
3.2.8.1 Able to integrate with other system functionality e.g. requisitions, contracts
3.2.8.2 Able to create manual purchase orders for materials or services
3.2.8.3 Able to handle purchase orders for different types of purchases e.g. non-stock materials,
stock materials, services, assets, contract labour etc
3.2.8.4 Able create purchase orders in multiple currencies
3.2.8.5 Able to define the printed purchase order details and physical appearance e.g. attach the
corporations logo etc
Page 41
Ref. # Requirement Description Response
3.2.8.6 Able to create purchase orders with multiple delivery addresses/store wise delivery
Distribution
3.2.8.7 Able to capture the requisition originators name and details in the purchase order if
Applicable
3.2.8.8 Able to assign purchase order number automatically or manually
3.2.8.9 Able to provide user defined text fields for purchase order details, special instructions
3.2.8.10 Able to attach item specifications to purchase order items and be able to view the details
upon inquiry
3.2.8.11 Able to approve purchase orders electronically on line based upon user defined criteria e.g.
value, department, type of purchase etc
3.2.8.12 Able to flag the purchase order as requiring approval to the approving person automatically
using workflow technology
3.2.8.13 Able to escalate the purchase order awaiting approval if not actioned within a specified
timeframe using workflow technology
3.2.8.14 Able to allow approver to reject the purchase order and automatically return to the originator
with a reason for rejection using workflow technology
3.2.8.15 Able to change the purchase order and resubmit for approval as above
3.2.8.16 Able to track and record all changes made to a purchase order
3.2.8.17 Able to track and record the status of a purchase order e.g. not approved, approved, rejected
3.2.8.18 Able to cancel / delete purchase orders for materials or services no longer required
3.2.8.19 Able to create a purchase for the same vendor from different requisitions
3.2.8.20 Able to add lines to a purchase order as required
3.2.8.21 Able to allow for quick purchase order creation for commonly purchased items
3.2.8.22 Able to provide facility to print out hard copies of purchase orders for approvers
3.2.8.23 Able to make certain fields within the purchase order mandatory, view only, etc
3.2.8.24 Able to enter a valid account number or project number to be charged for the purchase order
Item
3.2.8.25 Able to counter check with the budget. Message will appear if no budget is available or
exceed the budget when entering the purchase order accounting details
3.2.8.26 Able to define the output of a purchase order e.g. printed, electronic, faxed etc
3.2.8.27 Able to enter duty, freight cost, storage costs, admin costs, transit storage costs and handling
charges detail into a purchase order
3.2.8.28 Able to enter multiple delivery dates for items in a purchase order e.g. each line item may
have a different delivery date or multiple line item delivery dates
3.2.8.29 Able to enter multiple cost code for a line item, e.g. an item maybe split between one or more
capital works projects or cost accounts
3.2.8.30 Able to enter and store specific terms of trade or payment in a purchase order e.g. payment
by letter of credit, due 20th
of the month following, etc
3.2.8.31 Able to enter vendor discounts in the purchase order payment details
Page 42
Ref. # Requirement Description Response
3.2.9 Purchase Order Reporting / Display
3.2.9.1 Able to track all changes made to a purchase order
3.2.9.2 Able to report the status of a purchase order e.g. awaiting approval, approved, rejected
3.2.9.3 Able to produce reports of purchase orders by user defined criteria e.g. purchase order
number, vendor, material number, originator, department responsible, authorizer etc
3.2.9.4 Able to attach documents and specifications to purchase orders
3.2.9.5 Able to view the documents or specifications prior to attaching to the purchase orders
3.2.9.6 Able to display the purchase order details on demand
3.2.9.7 Able to print a copy of the purchase order on demand
3.2.9.8 Able to report those purchase orders due or overdue
3.2.9.9 Able to flag overdue or about to become due purchase orders to the originator automatically
3.2.9.10 Able to view historical transactions against the purchase order
3.2.9.11 Able to request acknowledgement of the purchase order from a vendor
3.2.9.12 Able to record purchase order acknowledgements from the vendor
3.2.9.13 Able to track purchase order due dates and produce reports to originators of overdue
purchase orders
3.2.9.14 Able to issue / print reminder notices and send to vendors either electronically or manually
3.2.9.15 Able to track those reminder notices sent and any subsequent responses received from a
Vendor
3.2.9.16 Able to maintain vendor performance data for deliveries made against a purchase order
3.2.9.17 Able to capture delivery or shipping information relating to a purchase order
3.2.9.18 Able to report the delivery or shipping information relating to a purchase order
3.2.9.19 Able to produce reports of vendor performance based on predefined performance criteria
3.2.10 Purchase Order Receipt
3.2.10.1 Able to allow users to receipt purchase orders on-line
3.2.10.2 Able to receive materials or services against a purchase order and store the details of the
receipt in the system
3.2.10.3 Able to record item details upon receipt e.g. item serial numbers, batch numbers, user text
etc Serial number field must have a minimum of 12 characters and allow alphanumeric
3.2.10.4 Able to reject a receipt yet still enter the details into the system to enable tracking and vendor
performance to be captured
3.2.10.5 Able to store quality inspection details for an item in the system and subsequent recording of
the results of the inspection to be recorded
3.2.10.6 The receipt details captured should include:
Quantity
Page 43
Ref. # Requirement Description Response
Packing slip numbers
Carrier name
Time of receipt
Receipting person name
Quality information
3.2.10.7 Able to correct or reverse and incorrect receipt
3.2.10.8 Able to maintain an audit trail of those items received and store the information against the
purchase order
3.2.10.9 Able to optionally accrue expense purchases at the time of receipt or at period end
3.2.10.10 Able to provide the facility to track, manage, and reconcile non invoiced receipts of all items
when a period is closed
3.2.10.11 Able to produce a good received note with details of the receipt etc
3.2.10.12 Able to produce reports which detail the receipt information. Details should include:
PO number
Date of receipt
Item received
Etc
3.2.10.13 Able to display receipt information once the receipt action is completed
3.2.10.14 Able to allow partial delivery
3.2.10.15 Able to record the delivery of items to their destinations
3.2.10.16 Able to print off an expected receipts report e.g. date, purchase order, value, items, etc
3.2.10.17 Able to automatically recognise the payables liability at the time of receipt and update the
inventory control account with the value of the receipt
3.2.11 Vendor Record Management
3.2.11.1 Automatic or manual vendor number assignment
3.2.11.2 Able to integrate with Accounts Payable (AP) and purchasing
3.2.11.3 Able to define different types of vendors e.g. employee vendors, domestic vendors,
international vendors etc
3.2.11.4 Able to control the ability to create and change vendor data
3.2.11.5 Able to capture vendor data sufficient to enable normal business transactions to be
completed e.g. vendor name, number, address, contact details, payment methods, payment
terms, payment currency, alternative addresses, email address etc
3.2.11.6 Able to block vendors from being used due to a specific reason e.g. vendor bankrupt, vendor
unreliable etc
3.2.11.7 Able to change vendor information by authorized users and track those changes made
3.2.11.8 Able to produce a report of changes made to vendor masters and automatically highlight a
specific field change i.e. bank account number changed
3.2.11.9 Able to delete vendors no longer required by the corporation
3.2.11.10 Able to retain vendor history for all vendors within the system e.g. purchasing history,
Page 44
Ref. # Requirement Description Response
payment history etc
3.2.11.11 Able to provide the ability to store vendor specific information relating to an item / vendor
relationship. Minimum vendor/item information includes :
Vendor name and address
Payment terms
Vendor Price/Quantity Price
Price breaks
Requisition number and department
Free form comments (at header
or line)
Delivery information
Item number and description
Discounts
Text information
3.2.11.12 Able to restrict the ability to created purchase orders only for those preferred vendors e.g.
item can only be purchased from a preferred vendor
3.2.11.13 Able to capture free form text information or notes relating to a vendor record e.g. reasons for
no longer using a specific vendor
3.2.11.14 Able to capture vendor specific purchasing information to be printed on all purchase orders
for the vendor
3.2.11.15 Able to group vendors into like vendor types e.g. stationery suppliers, electrical suppliers,
service suppliers, etc.
3.2.11.16 Able to report vendors details based upon the vendors grouping e.g. list all vendors who
supply electrical materials and the value of those purchases
3.2.11.17 Able to capture automatically vendor Performance and produce report by reason code,
instances of :
Rejected materials
Missed Delivery
Early Delivery
Wrong location
Incomplete delivery
Returns due damage, over supply etc
Average number of days late
Ø Other criteria as defined by __________
3.2.11.18 Able to report vendor performance based on the above criteria
3.2.11.19 Able to capture vendors selection criteria for various purchasing documents
3.2.11.20 Able to capture vendors transactions history with the corporation
3.2.11.21 Able to provide Year-end commitment processing - facility to carry forward commitment.
System must provide a facility to maintain any number of summary commitment accounts.
Summary accounts must be updated when the detail accounts are updated
3.2.11.22 Able to view period-to-date, quarter-to-date, year-to-date vendor balances
3.2.11.23 Able to block vendor for payments
3.2.11.24 Able to provide automatic updates of vendor database
Page 45
Ref. # Requirement Description Response
3.3 Inventory Management
3.3.1 Maintain Storage Data
3.3.1.1 Able to support multiple physical warehouses, locations and bin locations
Including the physical description of each location
3.3.1.2 Able to support Weighted Average costing
3.3.1.3 Able to integrate to third party software i.e. bar code readers
3.3.1.4 Able to change stock location descriptions
3.3.1.5 Able to delete stock locations no longer required
3.3.1.6 Able to produce online reports for stock locations e.g. materials in a stock location, stock
movements, historical data, stock values, expected receipts etc
3.3.1.7 Able to create different types of storage locations e.g. pick face, high racks, bulk and include
dimensions and capacity for each individual location
3.3.1.8 Able to record different classes of stocks e.g. electrical, spares, project stock, mechanical etc
3.3.1.9 Able to transfer stocks and up date the system automatically
3.3.1.10 Able to write off or dispose of stocks and up date the system automatically
3.3.1.11 Able to issue stocks to remote locations which may not be on the system
3.3.1.12 Able to capture and track all stock movements within the system :
Receipts
Issues
Transfers
Quarantined stock
Transfer to obsolete stock
Returns to vendor
Consignment stock movements
Transfers to scrapped stock
3.3.1.13 Able to record and track inventory status:
Obsolete
Scrapped
Restricted use
Blocked
In transfer
Under repair
Available for issue
Special project stock
Reserved stock
Vendor consignment stock
3.3.1.14 Able to analyse trends for variance items
e.g. item Z1 is always 1ea down on stock count for past 5 counts
3.3.1.15 Able to assign a service level to an inventory item e.g. critical items may have a service level
of 100% while those less critical may only have 50%. The service level should be considered
Page 46
Ref. # Requirement Description Response
3.3.1.16 Able to report service levels of inventory items to enable reviews to take place
3.3.1.17 Able to classify inventory by ABC for various actions e.g. stock-takes, criticality, etc
3.3.1.18 Able to hold inventory values in the system in various forms e.g. weighted average cost,
standard cost, zero cost etc
3.3.1.19 Able to track and maintain inventory costs in different currencies
3.3.1.20 Able to track and maintain different values for the same item e.g. item A1 has a quantity of 3
in stock 1 @ IDR 20.000 and 2 @ IDR 22.000
3.3.1.21 Able freeze inventory for stock-take purposes
3.3.1.22 Able to produce stock-take schedules based upon predefined criteria e.g. A items counted 12
times per year, B items counted 6 times per year and C items counted 2 times per year.
3.3.1.23 Able to produce stock count sheets based on storage locations and or bin locations
3.3.1.24 Stock count sheets should contain sufficient details to enable counters to complete the task.
Details should include:
Item number
Item description
Stock Location
Bin location
Unit of measure
Alternate units of measure
Free text
3.3.1.25 Able to record the results of a stock count in the system
3.3.1.26 Able to provide an analysis of the results of the stock count for addition actions to be taken if
required
3.3.1.26 Ability to recount those stock items which are at variance with the system prior to correcting
the values in inventory
3.3.1.27 Able to record a possible reason for the variance in the system
3.3.1.28 Able to electronically approve variances to stock counts by authorized persons based on
predefined criteria i.e. value of discrepancy, type of item etc
3.3.1.29 Able to produce reports of discrepancies for inventory items counted
3.3.2 Material Receipt & Issue Management
3.3.2.1 GRN to be generated from system electronically
3.3.2.2 Electronic intimation of GRN for purchase goes to user & purchaser at the time of receipt
3.3.2.3 Electronic confirmation by user at the time of verification and acceptance
3.3.2.4 Able to create a material issue from within the system, either partially or fully
3.3.2.5 Ability to issue material to different locations / centres / departments from the system
3.3.2.6 Ability to issue CAPEX and OPEX items
Page 47
Ref. # Requirement Description Response
3.3.2.7 Online receiving department confirmation /acknowledgement
3.3.2.8 System to generate printout of acknowledgement reports
3.3.2.9 Ability to electronically register rejection of goods at the point of generating the GRN,
verification of goods, receipt of issued items
3.3.2.10 Electronic reports for delivered goods, status of GRN, verified goods and issued materials
3.3.3 Inventory/Material Forecasts
3.3.3.1 Able to maintain material forecast information / settings within the system
3.3.3.2 Able to produce forecasts for items based on industry standard forecasting methods
e.g. individual forecasts, automatic forecasts, total forecasts etc
3.3.3.3 The systems should be able to accommodate different types of forecast models e.g. trend,
seasonal, historical, constant etc
3.3.3.4 The system should have the ability to provide forecasting algorithms and have tracking
signals to lock onto for accuracy of forecasts
3.3.4 Reservation Management
3.3.4.1 Able to create a manual reservation for inventory materials
3.3.4.2 Able to credit the value of the returned materials to the job or capital works project it was
originally issue to
3.3.4.3 Able to perform an availability check at the time the reservation is created either manually or
automatically
3.3.4.4 Able to provide the following details in the reservation:
Reservation number
Date of reservation
Requestors name and details
Stock location
Material part number
Material description
Quantity required
Batch information
Date required
Accounting information (capital works project, G/L etc)
Delivery address
3.3.4.5 Able to capture returns of inventory for items partially consumed. e.g. cable drum issued with
500m and returned 200m
3.3.4.6 Able to display a reservation from within another functional area within the system
3.3.4.7 Able to delete a reservation for items no longer required
3.3.4.8 Able to capture material returns information e.g. those items returned from a capital works
project as they are no longer required
3.3.4.9 Able to enter a reason for cancellation of a reservation
3.3.4.10 Able to report those current reservations within the system and action accordingly
e.g. produce pick lists of reservation items to be delivered
Page 48
Ref. # Requirement Description Response
3.3.4.11 Able to produce reports of outstanding reservations yet to be picked
3.3.4.12 Able to produce reports of reservations for a specific job, capital works project, etc.
3.3.4.13 Able to print a reservation details on demand
3.3.4.14 Able to print reports for reservations giving details of each
5.1 System
5.1.1 ERP Implementation Environment
5.1.1.1
5.1.2
Should be able to cater for the following implementation environment:
Production
Test
Development
Training
ERP Functional Modules
5.1.2.1 Must be fully integrated with standard or proprietary of:
RPCs
Messaging
SQL language
5.1.3 ERP Development Tools
5.1.3.1 Must have standard or proprietary ERP development tools :
Tool Sets
4GL development environment
Report Writer
5.1.4 Network Protocols
5.1.4.1 Should be able to be configured with the following core Network Based Services (NBS) and
protocols.
TCP/IP
DHCP
WINS
DNS
NetBEUI
LDAP
FTP
DLC
5.1.5 API (Application Programming Interface)
5.1.5.1 Should conform to open API model specifications such as:
COM/DCOM
CORBA
RMI
5.1.5.2 Should be able to interface with middleware application through:
ALE
MQ Series Link
OLE/COM2
ODBC
5.1.6 Internet Technologies
Page 49
Ref. # Requirement Description Response
5.1.6.1 Should be able to integrate with emerging Internet technologies such as:
HTTP
XML
5.1.7 User management
5.1.7.1 Should be able to manage ERP users across the __________’s LAN & WAN (centralize user
management).
5.1.7.2 Should be able to create, change, delete, cancel, track or monitor:
User IDs
User groups
User Accounts
Track Users
5.1.8 Print Management
5.1.8.1 Should be able to integrate with print servers across the __________ LAN & WAN.
5.1.8.2 Should be able to create, change, delete, cancel, track or monitor:
Print Jobs
Spool Jobs
5.1.8.3 Should be able to integrate and configured to :
LPD / LPR
NT Print Services
5.1.9 System Monitoring
5.1.9.1 Should provide tools to provide system monitoring such as:
Display servers status
Display & controlling of work processes
Controlling user session
5.1.10 System Memory
5.1.10.1 Should provide tools for memory management.
5.1.11 System Backup & Restoration
5.1.11.1 Should be able to perform backup and restore on :
Full Backup
Incremental Backup
Online backup
Recovery purposes
Data Compression
5.1.12 Scalable Architecture
5.1.12.1 Should be able to support scalable architecture environment such as :
SMP
MPP
Clustering
5.1.13 Security Standards
5.1.13.1 Should be able to support industry standard network security and management protocols
such as :
Kerberos
RADIUS
Page 50
Ref. # Requirement Description Response
LDAP
Digital Certificates
SecurID Tokens
PKCS
5.1.14 Master Data
5.1.14.1 Should have a single master data as a key piece of information that can be seen from a
number of views corresponding to different functional modules.
5.1.15 Data Access
5.1.15.1 Should be able to provide real time data access to the centralize database
5.1.16 Firewall Technology
5.1.16.1 Can be interfaced with firewall technologies.
5.1.17 Data Export & Import
5.1.17.1 Should be able to export and import data.
5.1.18 Data Entry
5.1.15.1 The input of data can be by :
On –line data entry
Batch
Scanning
EDI
Bar code
Downloaded from PC (e.g. Internet)
5.1.18.2 Should be able to select:
Profiles from user maintained tables
Populate data entry fields
5.1.18.3 The system should be able to provide:
Escape or cancel facility provided on all data entry screens.
Scroll bar facility for any data displayed exceeds the capacity of the window.
Optional or mandatory data entry fields.
Copy existing records as templates but override any of the values for :
o The creation of transactions
o Records for static data (e.g. vendor & debtor)
5.1.19 Data Validation
5.1.19.1 Should be able to perform the below functions for data validation:
Common validation tables for all modules
Data reasonable checks
Data range checks
5.1.19.2 Should be able to :
Define business rules for transaction updates
Define validation rules to any user-defined data entry field.
Change validation rules for any standard data-entry field
Maintain a log of any changes to business and validation rules.
5.1.20 Data Integrity
5.1.20.1 Should be able to rollback to the last synch point upon abnormal termination avoiding data
Page 51
Ref. # Requirement Description Response
corruption.
5.1.21 Data Interfaces
5.1.21.1 Should be able to accept input from a variety of media.
Cartridges
Magnetic Tape
CD-ROM
CD-Writer (CD-RW)
Disk
5.1.22 Data Archiving
5.1.22.1 Should be able to provide a facility within the application to archive data.
5.1.22.2 Should be able to support archiving data to an external media:
CD ROM
Cartridge
WORM
5.1.22.3 Should be able to restore archived data easily from:
CD ROM
Cartridge
WORM
5.1.22.4 Should be able to provide user-defined control over the archive
process with respect to :
The timing of archiving
Data selection
Compression of data
5.1.23 Archive Report Listing
5.1.23.1 Should be able to generate report detailing information archived
5.1.24 Date & Time
5.1.24.1 Should be able to facilitate multiple current periods across all functional modules.
5.1.24.2 Should be able to facilitate:
Pending dates for all modules
Pending transactions can be entered with an effective date
Effective date for pending transaction can be dated up to 12 months ahead
Specify the order in which pending transactions will be processed
Pending transactions can be :
o Viewed on – line
o Deleted on – line
o Changed on –line
5.1.25 User On-line Help
5.1.25.1 Should be able to provide context sensitive help for :
Data entry fields
Menu items
Buttons
Icons
The application server should be able to provide search facility on all help and user
documentation within any open window.
The application server should be able to tailor help information.
Page 52
Ref. # Requirement Description Response
The application server should be able to provide on-line help via Internet.
5.1.26 Re-confirm task
5.1.26.1 Should provide a facility for the user to confirm or deny action to be taken before:
Critical functions such as deletion of data
Updating key transactions
5.1.27 Wild cards
5.1.27.1 Should allow wild card searches.
5.1.28 Case Sensitive
5.1.28.1 The system should provide optional case sensitive searches.
5.1.29 Authorisation
5.1.29.1 The system should only allow authorized users to update system tables.
5.1.29.2 Any menus and menu options displayed are determined by user access privileges.
5.1.29.3 Should be able to extend the security to access :
Report writing facilities
The production of standard reports
5.1.29.4 Existence of a screen displaying the list of users logged on to the system.
5.1.30 Password
5.1.30.1 Should have the following criteria for password settings and restrictions:
Encrypted
Passwords can be changed by:
o End user
o Security co-ordinator
5.1.30.2 User-defined enforced periodic password changes
Password changes requires user to re-confirm or key in the new password twice
Prevention the re-use of a previous password
5.1.31 User Access
5.1.31.1 Should be able to perform the option to activate/deactivate automatic logoff after :
A specified period of screen inactivity.
A pre-determined number of unsuccessful attempts to logon.
5.1.31.2 Should be able to allow user access privileges in terms of:
Application modules
Menu options accessible to the user
Read or update access
Specific type/s of update access (i.e. add, change, delete)
Accessing specific records of each record type
Values for a field the user can/cannot use
Access to data can be controlled to each component of the organization structure
5.1.31.3 Should be able to generate report to list for :
Page 53
Ref. # Requirement Description Response
Users who have accessed the system and what they have accessed
Users and their security access
Attempts at unauthorized access
5.1.32 Security Maintenance
5.1.32.1 System security can be maintained on – line and updated in real – time.
5.1.33 Optional Settings
5.1.33.1 Can optionally delegate nominated security functions to other authorized users.
5.2 Database Management
5.2.1 Able to provide an easy-to-use and standard call interfaces for the main programming
languages such as C, COBOL etc.
5.2.2 Able to provide object oriented features
5.2.3 Able to provide data warehousing facilities (standard feature)
5.2.4 Able to supports the industry standard structured Query Language (SQL)
5.2.5 Able to provide tools with which to analyze/optimize the data access paths needed to
process a SQL command
5.2.6 Able to run on the ‘Open System’ offered by multiple vendors
5.2.7 Able to communicate transparently with other copies of the same or different DBMS running
on other machines via a network to gather the requested information regardless of where the
required data resides
5.2.8 Able to support multiphase commits to ensure the integrity and correct sequencing of
updates across multiple databases
5.2.9 Able to provide the facilities to recover the database in the event of a disk or system crash.
Recovery will be automatic, fast and reliable
5.2.10 Able to perform remote database (e.g. on DRP machine) synchronization facility by
automatically and transparently sending update images to be applied to the remote database
periodically
5.2.11 Able to provide tools and utilities to maintain and manage the database, e.g. tools to
unload/reload, expand, repair and recover the database
5.2.12 Able to perform database utilization statistics and performance measurement statistics
5.2.13 Able to expand easily without having to unload/reload or rebuild any database structures.
Any expansion would only involve a change in the database definition without affecting the
physical files
5.3 Backup and Recovery
5.3.1 Able to perform for on-line, off-line and end-of-day back up. In the event of disaster, the
system is able to recover up to the last transaction processed. An automatic recovery
process that is easy to implement is to be provided should the system or the hard disk crash
5.3.2 Able to support the following data redundancy features :
Disk Mirroring
RAID (Specify type)
Auxiliary Storage
Others (Specify)
Page 54
Ref. # Requirement Description Response
5.3.3 Able to maintain data consistency and accuracy across database(s) to ensure data integrity
5.3.4 Able to perform on-line data retention for five (5) years is anticipated
5.3.5 Able to perform on-line data retention of summarized data for ten (10) years is anticipated
5.3.6 Can the captured off-line data be processed in batch mode
5.3.7 Describe how the system archives, and retrieves data
5.3.8 Option to specify the frequency of backups to be taken for :
Transaction files
Master files
Static data files / reference files
5.3.9 Able to have facility for on-line back-up while users are logged on
5.3.10 When backups are being taken, do they have a significant effect on response times?
5.3.11 Able to perform a ‘warm’ back up condition for all business critical applications (customer and
financial transactions) on a full time basis. Response time of critical applications must be
maintained as normal after the disaster
5.3.12 Briefly describe the recovery process after a system failure during on-line processing
5.3.13 Briefly describe the recovery process after a system failure during batch processing
5.4 Service Level Requirements
5.4.1 Able to complete crucial batch processing functions before the commencement of on-line
services for the next business day
5.4.2 Able to finish End-Of-Month batch processing <= 12 hours
5.4.3 Able to finish End-Of-Day batch processing <= 4 hours
5.5 Configuration Management Requirements
5.5.1 Able to provide the following:
Document Configuration Items:
o Customer functional specifications
o System design documentation
o Database schema
o Program sources
Software Configuration Items:
o Application Software
o System Software
5.5.2 Control Procedures : Able to perform software change management. Describe any software
change and release management facilities provided. Indicate how these facilities support
development of new software, maintenance of production system and new versions of
software
5.5.3 Describe any document change and release management facilities provided. Indicate how
these facilities support development of document (e.g. User manuals, specification, etc.)
5.5.4 Ability of the system to support standardized development and production environment for
the following :
Naming convention
Page 55
Ref. # Requirement Description Response
Database architecture
Program design
System navigation
5.6 Conversion
5.6.1 Able to provide conversion method and describe the methods and tools available for the
conversion of legacy system data to the proposed system.
6.1 Cross Modules
6.1.1 The Campus Managemetnt Solution solution must be integrated to your ERP solution.
6.2 Data Entry Screen
6.2.1 Screen labels displayed in English.
6.2.2 Able to perform scroll, tab or valid list options facility to guide users through data entry.
6.2.3 Able to perform multi session facility to allow ease of movement the system and functions,
user can use several screen sessions to perform the job.
6.2.4 Able to create a user menu that reflected their job description. It will hide all un-authorize
functions and tasks.
6.3 Executive Information System (EIS)
6.3.1 Able to generate the requested reports in all modules.
6.3.2 Able to print control reports regardless whether there are transactions/activities
6.3.3 Able to sort reports into the various departments, regions, business operating units, cost
centres, etc.
6.3.4 Able to provide a flexible report writer for the user to :
Specify the format and layout of report
Summarizes information to be reported
Select information to be included in the report
Sort information to be reported according to user selected fields
Create user defined graphical display of reports
6.3.5 Able to have all outputs produced for on-line viewing or printed (hard copy) output based on
user request
6.3.6 Able to route the report using standard e-mail system.
6.3.7 Able to allow users to print reports that have been routed for on-line viewing on request
6.3.8 Able to ensure that all reports are uniquely identified, appropriately numbered and all pages
contain period dates and times when the reports were created
6.3.9 Able to identify clearly the last page or end of all reports
6.4 Uploading/Downloading data
6.4.1 Able to perform upload/download of data other systems e.g. pervasive devices, handheld,
etc.
6.4.2 Able to perform upload/download of data to PC in ASCII format or PC Application e.g.
Microsoft EXCEL, Microsoft WORD for analysis and graphical report/presentation.
6.5 Navigation and Data Access
6.5.1 Able to access and use the on-line system functions 24 hours per day, 7 days per week,
Page 56
Ref. # Requirement Description Response
including during batch processing cycles, database logging and database back-up cycles
6.5.2 Able to switch to different programs and modules without interrupting the existing application
6.5.3 Able to perform all navigation to subsystems and functions using Microsoft Windows or
above navigation standards, including:
Controls panel lists and sub-lists
Icons
Tabs
Buttons
6.6 Data Input, Storage and Display
6.6.1 Able to prevent input and storage of duplicate data
6.6.3 Able to automatically archive transaction data to media based (machine-readable) archives
based on system administrator defined retention period for transaction types
6.7 Inquiry
6.7.1 Able to inquire upon transactional data, master data, etc.
6.7.2 Able to perform single screen for each specific type of inquiry whenever possible
6.7.3 Able to scroll forwards and backwards in all inquiry functions without re-accessing the
database
6.8 Transaction Validation and Management
6.8.1 Able to indicate which fields are mandatory and optional, prompting users in advance for
required data
6.8.2 Able to perform all edits and validations on-line at time and point of entry for all input
6.8.3 Able to present error messages that clearly indicate the exact nature of the error and the field
in the error and possible solutions
6.8.4 Able to allow transactions that are in error to be saved in a transaction recycle file that can be
accessed on-line to correct errors and re-submit the data
6.9 Transaction Controls
6.9.1 Able to check for duplicate document or data entry
6.9.2 Allow to validate field entry to the valid master data
6.9.3 Prevent storage of in-valid transaction
6.10 Run Controls
6.10.1 Able to execute all jobs from menu options, including scheduling batch job runs
6.10.2 Able to run specific transaction processing, posting, reporting and other processes on
specific defined update cycles:
Daily transaction processing cycle and postings
Periodic and monthly interface update cycles.
Monthly update and posting
Monthly archive cycles
Quarterly closing and reporting cycles
Annual closing and reporting cycles
6.10.3 Able to perform system load balancing at the end of each run or critical step within a run
6.11 Identification Management
Page 57
Ref. # Requirement Description Response
6.11.1 Able to require the user to perform valid identification for all accesses
6.11.2 Able to provide an on-line, real-time facility for the system administrator to :
Define the security and privacy of information
Add and remove users in the system
Change the security profile of users
6.11.3
6.12
Able to control security profiles of their users at various levels of authorized officers apart
from the security administrator
Access Controls
6.12.1 Able to define an expiry date for an user IDs
6.12.2 Able to provide automatic log off of user ID after a certain time period
6.12.3 Able to prevent passwords from being viewed or printed by any user including the security
administrator
6.12.4 Able to set maximum number of password attempts
6.12.5 Able to have different levels of access within a system. Restrictions should apply to:
Business units
Functions
Transactions
Fields
Screens, etc.
6.12.6 Able to specify read-access only of some fields of some users based on the access profile
6.13 System Controls
6.13.1 Able to encrypt the security database, password and data across data communication media
6.13.2 Able to perform the functionality to inhibit unauthorized operators printing hard copies of
restricted reports
6.13.3 Able to perform the functionality to inhibit unauthorized operators execute of restricted
functions/transactions
6.13.4 Able to control the distribution of reports
6.14 System Monitoring & Performance
6.14.1 Able to register any attempts (successful and unsuccessful) to access restricted resources
codes identifying the operator, terminal, date and time
6.14.2 Able to maintain a log of log-on, log-off and security violations
6.14.3 Able to complete audit trail for tracking transactions through the system showing who entered
the transaction, who authorised the transaction, when they were entered and terminal
entered
6.14.4 Able to facilitate immediate notification of violation on highly restricted resources
6.14.5 Able to notify networking operator on any attempted system hacking (attempted access from
unknown locations)
6.14.6 Able to produce reports which show all allowable accesses for users including systems,
locations and access level within system
6.14.7 Able to produce a variety of audit reports giving details of sensitive transactions, including
date, time, User ID, old and new values for changes
6.14.8 Able to perform on-line audit trail for a specified period of time before being archived
Page 58
Ref. # Requirement Description Response
6.14.9 Able to produce Access Control Report which shows all unauthorized or irregular access to
systems including date, time, User ID, location workstation ID and any sensitive transactions
(e.g. Password rejected, user not allowed in system, job submitted to update master file)
6.14.10 Able to define frequency, types and details of exception reports
6.14.11 Able monitor system performance and produce performance reports
6.15 Input Controls
6.15.1 Able to batch transactions and perform internal verification of batch totals
6.15.2 Able to limit the number of transactions per batch
6.15.3 Able to minimize data entry by providing standard data from master files, parameter files and
through the use of pre-defined defaults at the field level
6.15.4 Able to perform an audit trail showing the master file contents before and after each change,
and the details of who and when it was changed
6.15.5 Able for error correction facilities to :
Correct fields during current data input session
Highlight of all errors on input screen
Perform for transactions not being posted if errors are encountered -posted to
rejects file and later reconciled
Details error messages describing type of error
Modify/amend information on an ad-hoc basis (e.g. without having to page through a
large number of screens in order to access desired screen)
6.15.6 Able to track and report the cumulative number of changes to master file records (statistical
information)
6.16 Processing Controls
6.16.1 Able to produce print outs for batch jobs showing the result of each step of the job
6.16.2 Able to prevent premature end-of-month processing with built-in control mechanism
6.16.3 Able to perform checkpoint restart from last transaction. Ensure that records are not updated
twice for same information after a failure
6.16.4 Able to sequentially number transactions and to ensure that all transactions are processed,
rejected or updated
6.16.5 Able to provide the facility for users to recall historical information for reference
6.16.6 Able to store transactions during off-line mode for delay update of host database (in the
event that the host computer is down)
6.17 Data Security and Integrity
6.17.1 Able to allow data access only through the application data inquiry, update and reporting
processes, e.g. prevent data access outside of the application
6.17.2 Able to limit inquiry, update and reporting access to data base in user application security
level or group, e.g. limit access to sensitive data items to the assigned group responsible for
management of that data
APPENDIX A NOTICE OF INTENT TO BID FORM
(Due no later than 1700 hrs on February 10, 2012)
RE: RFP for Comprehensive Financials Automation Solution
Company Name:
Address:
City:
Country:
Phone: _
Fax:
E-Mail:
Will be submitting a Response:
Will not be submitting a Response: _
If not participating, please provide brief explanation:
_
_
Signature: _
59