RFP for ERP Financials - eproc.punjab.gov.pk · Request for Proposal: ERP Financials Solution. Proposals will be accepted up to, and no proposals may be withdrawn after, the time

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


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.


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


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


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


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


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


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


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


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


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


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


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


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



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


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


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


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


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


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


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


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


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


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


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.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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

Documents

RFP for ERP Financials - eproc.punjab.gov.pk · Request for Proposal: ERP Financials Solution. Proposals will be accepted up to, and no proposals may be withdrawn after, the time