Water TOR

Section VII – Purchaser’s Requirements 125
System Integrated Enterprise Resource Planning
Specific Product Name
Version and Release

Date
Country of Origin
Mandatory Detailed Explanation to

# Requirement description
/ Optional Requirement
3.2.1 Financial Management System Requirements
A: General Ledger A1:

Chart of Accounts
3.2.1.1 One must be able to define and maintain

M
the structure of the Chart of Accounts
The system should allow for the same

3.2.1.2 Chart of Accounts that can be used by O
multiple entities
The system must provide for the use of

3.2.1.3 different Chart of Accounts by more than M
one entity

The Chart of Account must provide for a

unique alpha-numeric, flexible account
3.2.1.4 code structure with a user-defined M
number of segments and lengths per
segment.
The accounting structure must be

3.2.1.5 M
accessible from all locations
Changes to the Chart of Accounts must

be controlled and require necessary
3.2.1.6 M
approval or amendment to be restricted to
authorized personnel
The system must be able to maintain

3.2.1.7 budgets at all levels of the Chart of M
Accounts
The system must be able to create/setup

3.2.1.8 GL accounts and deactivate the same M
without erasing it in its entirety
Enable the viewing and extraction of GL

3.2.1.9 M
accounts listing
Ability to create profit and cost centres

3.2.1.10 M
and report at those levels
The chart of accounts MUST be flexible

3.2.1.11 to accommodate the future business M
expansions in the segments & GL codes

The accounting structure MUST have

control inbuilt not to allow updates by
users from other sub ledger modules
3.2.1.12 unless it is approved. The application M
MUST freeze the changes made in the
structure and also display the last updated
by.
The application SHOULD facilitate

3.2.1.13 summary account reporting based on all M
dimensions available in the database
The system must be able to support

3.2.1.14 M
reporting on separate Chart of Accounts
The application MUST have the

capability to generate parent child within
the accounts defined or account
3.2.1.15 M
categories for all possible combinations.
The system MUST be able to generate
reporting for specific accounts.
Reporting Requirements for the Chart of Accounts

Dynamic reports with the provision for a
3.2.1.16 M
drill-down capability.
Create customized reports (user defined).

3.2.1.17 Users who perform this function will M
have to be trained on use of the tools
3.2.1.18 Reports with the following parameters: M


• Expenditure/Revenue by chart of
account code either individually or as
consolidated
• Expenditure/Revenue by Cost
centre
• Supplier/Staff/Customer accounts
• Based on posting date, date of

data capture
• Reversed journals
A2: Currencies
The system must be able to support the

Kenya Shilling as the functional currency
and should further be able to support
3.2.1.19 other major currencies including but not M
limited to Euro, US Dollar, Sterling
Pound. Additional currencies should also
be configurable.
The system should allow one to upload

currency exchange rates downloaded in
3.2.1.20 M
predefined file formats from certain
websites e.g. CBK, Commercial Banks,
Able to translate amounts from

functional currency or source currency in
3.2.1.21 M
the originating ledger, based on a
specified exchange rate

Should be able to perform foreign

3.2.1.22 exchange gain/loss per transaction and M
post in the designated account.
The application MUST support

Conversion: Convert foreign currency
amounts in journal entries to functional
3.2.1.23 M
currency at the time of entry. Converted
values are factored into the computation
of average balances functional currency.

Revaluation: Revalue of accounts at the
end of each year which are recorded on
3.2.1.24 books in a foreign currency. Revalued M
balances, as well as the unrealized
exchange gain or loss, are factored into
the computation of average balances.

conversion rate types to automatically
3.2.1.25 assign a rate while converting foreign M
currency journal amounts to functional
currency equivalents.

The application MUST maintain all

3.2.1.26 effective exchange rates for all foreign M
currency transactions.
Reporting Requirements for Currencies

3.2.1.27 M

Reports with the following parameters:
• Foreign currency trends
• Currency loss/gain per transaction
• Currency loss/gain translation at

3.2.1.29 defined periods M
• Invoices/Credit Notes/Debit Notes

in foreign currency
A3: Journals
The application MUST provide a facility

to input, update, copy, balance, and post
3.2.1.30 the Journals. Journal Voucher No. MUST M
be automatically generated by the
system.

The application MUST restrict updates to

3.2.1.31 account structure and amounts of a M
Journal Voucher after posting.
The system must be able to create and

3.2.1.32 M
post journal entries
The system must allow the holding of

3.2.1.33 M
journal entries
The system must enable held journals to

3.2.1.34 M
be viewed and posted
For any transaction posted through this

system, the system must allow for
3.2.1.35 M
correction/reversal of the same through
an approved workflow process
When reversing a transaction, the system

should perform a Credit/Debit transaction
and must maintain the previous
3.2.1.36 transaction historically instead of erasing M
it. However, for rejected journals, the
system should cancel the transaction
without keeping its record.
The system should be able to handle

different types of journals e.g. budget
3.2.1.37 M
journal, general ledger journal, accrual
journal, etc.

The system must be able to maintain a

3.2.1.38 history of full details of all transactions M
and avail them for printing when required
Establish an accounting system capable

of accurately and simultaneously
3.2.1.39 M
recording and reporting financial data for
TAWSB on accrual basis.
Maintain a user defined period (in years)

3.2.1.40 M
prior history on-line before archiving.
A facility to enable enquiry on archived

3.2.1.41 M
data and reports
The system must be able to

import/upload journal vouchers in batch
3.2.1.42 from a spreadsheet document or text M
files. There should be workflow for
approving such uploads.
The system must be able to export

3.2.1.43 journal vouchers in batch to spreadsheet M
or text file
The application MUST have the

functionality of defining journal sources
3.2.1.44 M
based on which transactions are
monitored
The application MUST generate interface

3.2.1.45 reports for the transactions source M
modules.

The application MUST be reporting the

3.2.1.46 exception reports for sub-ledger modules M
for reconciliation purpose.
The application MUST have categories

3.2.1.47 M
for single journals and batches
The application MUST provide the

capability to identify source documents
or module references which are
3.2.1.48 associated with the journal entry (e.g., M
Invoice No., Payment Voucher No.,
Telephone No. etc.) for reporting
purposes.
Capability to set and journals entries for

3.2.1.49 transactions that are processed in a M
recurring manner
The application SHOULD provide for

Recurring Journals - This is a journal that
posts a fixed amount to an account
beginning from an effective date and
continuing through the user specified
3.2.1.50 O
end-date. The user can define the cycles
for recurring transactions. The system
automatically generates and posts the
recurring JVs. Recurring JVs may cross
more than one fiscal year.

Recurring Journal Entries may be based

3.2.1.51 on saveable templates with predefined O
schedules.
Posting to control accounts must only

3.2.1.52 M
take place via sub-ledgers
Period-end closing should be performed

3.2.1.53 O
by account type
Reporting Requirements for Journals
3.2.1.54 M

Reports with the following parameters
• Foreign currency journals
• Journals reports by prepared,

3.2.1.56 reviewed, posted M
• Journals held (pending posting)
• Journal reversal
• Journals by date/user defined
period
A4: Calendar
The system must have a mechanism for

3.2.1.57 defining a financial year and setting up M
accounting periods it contains.

The system should be able to close

3.2.1.58 accounting periods at pre-defined M
frequencies
One must be able to set up and update

3.2.1.59 separate accounting periods for adjusting M
and closing entries
The system must be capable of posting to

3.2.1.60 M
multiple posting periods
The application SHOULD change a

period’s specifications, except for the
3.2.1.61 M
period type, as long as the period has not
been used in a set of books.
Reporting Requirements for Calendar

3.2.1.62 M

Reports with the following parameters
• Notifications on due date
• Change of dates
3.2.1.64 M
• Calendar by due date
• Calendar by competed activities
• Calendar by pending activities
A5: Other General Ledger Requirements


Setting up GL parameters that will

ensure:
• Ledger validity and approvals are
captured
• Transactional rules are defined
• Handling of bank payments
• Definition of currency rules such

as payment limits, currency rates,
3.2.1.65 M
tolerance levels, and other currency
related parameters
• Authorised payment overrides
• Unique identification/numbering
of a voucher
• Origination details of the GL are

captured (staff name, date, etc.)
Query functionality must be sufficient

enough to query all information that has
been captured on:
3.2.1.66 • GL accounts M
• Ledgers
• Journals
• Payment vouchers
• Receipts
Capable of maintaining separate general

3.2.1.67 ledgers for head office and different M
branches

Capable of carrying out document

3.2.1.68 M
splitting across cost centres
The system must be able to consolidate

3.2.1.69 M
several general ledgers into one
The system should enable one to preview

3.2.1.70 all open items such as open purchase M
orders, open invoices, etc.
Ability to meet requirements of the

following types of tax and have provision
for setting up any additional tax
requirements:
• Corporation tax
3.2.1.71 • Withholding tax M
• Withholding Value Added Tax
• Pay As You Earn (PAYE)

• Value Added Tax (VAT)
• Any other defined taxes
• Reverse VAT
In addition to a flexible report extraction

facility, the following reports must come
3.2.1.72 inbuilt in the application: M
Journal listing
Held journal listing
The system must address balance brought

3.2.1.73 forwards on assets & liabilities M
(suppliers, customers, staff loans, etc. )

The application MUST support the

functionality to allocate overhead costs to
relevant departments based on common
3.2.1.74 M
cost drivers. The system MUST
accommodate user defined cost drivers
for allocation
Maintain either twelve or thirteen periods

for current-year transactions and a
3.2.1.75 M
number of additional periods for prior
year adjustments for allowed users.
Allow prior period and prior year

adjustments and allow this facility to be
3.2.1.76 restricted. Prior year adjustments should M
be allowed simultaneously with current
year accounting entries
Provide facilities posting adjusting

3.2.1.77 journal entries to prior periods by M
authorised users (only)
Ability to support postings of journal

entries to future periods (where current
3.2.1.78 M
period is open and need to begin new
accounting period)
Provide multi-segment facility for the

3.2.1.79 M
Chart of Accounts.

Reporting Requirements for Other General Ledger Requirements

3.2.1.80 M

The system must be able to generate the

following financial statements (IPSAS &
IFRS formats) and reports:
• Statement of comprehensive
Income
• Trial Balance
• Statement of Financial Position
• Cash Flow Statement

3.2.1.82 • Changes in Equity M
• Taxes e.g VAT/W/Tax by user
defined dates
One should also be able to generate the

financial statements in a particular
format/template for the purpose of
meeting statutory requirements including
explanation notes for any of the above.
B: Accounts Payables
The system must be able to process

3.2.1.83 supplier invoices by interfacing with the M
procurement module

Ability to raise, print and post payment

3.2.1.84 M
vouchers
The system must embed a workflow for

verifying and approving invoices
3.2.1.85 M
received for payment. The approval
levels will depend on the invoice value.
The system must have an inbuilt

workflow for processing payment
3.2.1.86 M
vouchers that have been converted from
credit notes
Calculate tax for vendor invoices and

3.2.1.87 M
record tax transactions separately
Automate the generation of remittance

3.2.1.88 M
advice and tax certificate
The system should be able to process

3.2.1.89 payments in multiple currencies, capture M
the foreign exchange rate, and date.
The system must be able to capture all

the relevant details relating to invoice
processing and maintain a complete
history for audit purposes. At a
minimum, the following information
3.2.1.90 needs to be captured: M
• Invoice type (debit memo, credit

memo, expense, etc. )
• Invoice number

• Invoice currency
• Invoice amount
• Payment terms
• GL date
• Supplier details
• Transaction date
• Line description / details
• Payment Voucher number
• Payment Voucher amount
• Balance
• Payee
• Cheque number (physical

cheques) / EFT reference
• Budget line number/description
• Bank details (bank code, bank

description, etc.)
• Division/department
The system must support payment of

invoices in partiality or instalments.
3.2.1.91 Where partial payments are being made, M
the cumulative payment should match the
Purchase Order value.

The system must have controls that

prevent duplicate processing of payments
or over-payment. It should prompt the
user upon detecting the same invoice
3.2.1.92 M
number from different suppliers, and
allow it to be processed, but prevent
processing of the same invoice number
from the same supplier.
The system should be able to indicate

payment type: cash, physical cheque,
3.2.1.93 M
EFT, Card, Mobile money transfer/pay,
and RTGS
The system must be able to maintain a

3.2.1.94 complete payment history and enable M
extraction for analysis
The system should automatically notify

the payment recipient via email upon
3.2.1.95 completion of the payment process M
(completion of bank processing of the
particular payment)
The system should be able to cluster

3.2.1.96 similar payments into categories (i.e. cost M
centre based categorisation)
The system should be able to produce

3.2.1.97 reports on various payment categories as M
defined above

System should be capable of grouping

3.2.1.98 several invoices to be settled as a single M
payment or settled individually
The system must be able to convert

3.2.1.99 approved loans/advance applications to M
payment vouchers
Support matching: Requisition,

3.2.1.100 Purchase/Service Order, Goods/Service M
Receipt Note, Invoice & payment:
The system should be able to close a

3.2.1.101 purchase order upon payment of the full M
amount.
The system must be able to create and

maintain supplier payment information
(if not captured in the procurement when
creating a supplier):
• Supplier details (e.g. name, physical

address, contact details)
3.2.1.102 M
• Bank account details
• Payment details e.g. payment mode,

frequency, discounts, penalties, rating,
etc.
• Currency details

• Tax details (PIN, tax category,

compliance, injunctions)
• User defined
data/miscellaneous/comments
The setting up of all supplier details

3.2.1.103 M
should be via a workflow/process
The system must interface with the

procurement module so as to be able to
3.2.1.104 M
retrieve all other supplier master details
relevant for the payment.
The system must be able to capture

payment terms such as payment discount
conditions and penalty conditions to all
3.2.1.105 O
business to be able to make payment
decisions that will maximise discounts
while minimising penalties
The system must interface with the HR

module so as to be able to retrieve all
3.2.1.106 M
other employee master details relevant
for the payment.
The system must be able to generate a

file of payments that have been approved
3.2.1.107 M
for uploading to the Online Banking
portal.

The system MUST facilitate archival of

invoices, vouchers, payment forms online
3.2.1.108 O
in a separate database and MUST be
accessible.
The payment application MUST stop

payment clearance for all the vendors
3.2.1.109 M
whose payments are on hold due to
business specific reasons
Payment schedules could be based upon
• Vendor category (Local, Foreign etc.)
• Due date
3.2.1.110 • Payment method (EFT, Cheque etc.) M
• Voucher types (Vendor Invoices, Staff

advances etc.). The application SHOULD
support these payment schedules
The application MUST support payment

interventions such as partial payments,
3.2.1.111 M
stop payments, void payments, write offs
etc.
Reporting Requirements for Accounts Payables Requirements

3.2.1.112 M
following AP reports:

· Invoice Aging Report (using specific

criteria -- department, date range,
specific vendor or all vendors and
suppliers)
· Invoice due date forecast

· Down payments/payment
advances listing
· Trial Balance (This includes invoices

due for payment, those not due and those
on hold due to invoicing errors or
questions about invoice charges)
· Supplier Payment history report
· Supplier statement
· Contract Payment history report
· Project Payment history report
· Contract Payment History Report
· Project Payment History Report
· AP posting status reports per period
· Accounts payable aging report

categorizes payables to suppliers based
on time buckets:
· 0 to 30 days old
· 31 to 60 days old
· 61 to 90 days old
· Older than 90 days

Note that this report should list only

those supplier invoices that are nearly
due or overdue for payment, based on
invoice dates and supplier payment terms
C: Accounts Receivables
The system must be able to automate the

3.2.1.113 receipting process and generate Payment M
Receipts that can be printed.
The system must be able to update

3.2.1.114 accounts receivables and cash/bank as a M
result of receipting
The application MUST have the facility

3.2.1.115 of generating automatic receipts & O
clearance of the same.
The system must only accept receipts that

properly match with a receivable.
3.2.1.116 M
Receipt entries must automatically
interface with the General Ledger.
The application MUST provide facilities

3.2.1.117 M
to query accounts

The application MUST facilitate

Interfacing of invoices using Auto
Invoice interface functionality to import
and validate transaction data from legacy
3.2.1.118 M
financial systems or any other third party
system and create invoices, debit memos,
credit memos, and on-account credits in
Receivables.
The application MUST facilitate

interfacing invoices from an external
3.2.1.119 M
Billing System or revenue accounting
system and could processed in batch.
The system should be configurable so as

to allocate receipts into various GL
3.2.1.120 accounts. One should also be able to M
generate reports on receipts on the
various categories as defined.
The application must be able to restrict

3.2.1.121 posting of receipts by users to specific O
accounts.
The application MUST support the

3.2.1.122 reversals, corrections of the payments M
and the receipts.

The application MUST capture receipts

3.2.1.123 other than direct revenue generating M
activities through miscellaneous receipts.
The application MUST allow matching

of receipts to invoices based on different
3.2.1.124 M
parameters like customer id, name,
invoice numbers etc.
The receivable system MUST maintain

3.2.1.125 M
Payment terms.
Capability to charge customers for

3.2.1.126 M
bounced cheques.
Capability to charge customers for

approved penalties and/or fines. Thus,
the system should have the capability to
3.2.1.127 M
define penalties and/or fines and allow
for their selection from a drop down or
similar facility.
The system must allow one to print a

3.2.1.128 comprehensive customer account M
statement showing all transactions.
The application must be able to process

3.2.1.129 M
receipts in multiple currencies

Ability to backdate receipts date but after

several levels of approval. This is
especially important to prevent interest
3.2.1.130 M
accrual on receipts that are processed
after the system has been offline for an
extended period of time.
The system should be able to produce

3.2.1.131 cumulative reports on receipts per M
customer, per bank, etc.
The application should interface with the

bank so as to support creation of
3.2.1.132 automatic receipts based on the bank files M
having customers depositing the cash
directly into the corporate account.
The system must be able to interface with

other modules so as to be able to retrieve
customer details (such as: customer
3.2.1.133 M
codes, customer name, location, contact
details, etc.) and invoices being settled
(licenses, penalties, etc.).
The system must be able to set up

payment parameters for customers such
3.2.1.134 M
as: currency of payment, payment
frequency, etc.

The system must be able to handle

3.2.1.135 M
suppliers who are also customers.
The system must be able to detect

duplicate customers by comparing a
3.2.1.136 combination of unique customer details M
like the TAWSB internal generated
numbers and the tax PIN.
The system must be able to capture and

maintain a complete history of customer
3.2.1.137 M
transactions and generation of customer
statements that can be emailed.
Alerts and notifications when accounts

3.2.1.138 M
receivables are due.
The system must be able to produce

exception reports so as to determine
3.2.1.139 M
customers whose credit limit is older than
a specified number of days.
The System MUST generate dunning or

3.2.1.140 collection letters, to have credit limit and M
credit hold functions.
The application MUST send notification

3.2.1.141 through workflows once credit limit for M
customer is exhausted.
For customers who overpay, the system

3.2.1.142 M
should be able to:

• Perform invoice split-matching
• Allocate the excess amount to the

customer’s credit account
• Or the customer’s other accounts
Ability to define Customer credit

3.2.1.143 M
policies/limits.
Ability to track a customer’s credit

3.2.1.144 balance and issue alerts upon attainment M
of a set threshold.
The system must be able to produce aged

3.2.1.145 receivables report for various account M
categories.
The financial module should be able to

interface with the respective system so as
3.2.1.146 M
to pull credit policy conditions/terms per
category.
The system must support bad debt

3.2.1.147 M
provisioning.
The application MUST have write off

limits defined for users and inbuilt
3.2.1.148 M
approval process for bad debts or
adjustments.
Reporting Requirements for Accounts Receivables

3.2.1.149 following AR reports: M
• AR Aging Report:

· Using specific criteria --

department, date range, specific vendor
or all vendors and suppliers. The report
MUST have details in terms of payment
terms, customer profile class, customer
category, the amount overdue and the
payment mode.
· Aging report categorizes

receivables to clients based on
time buckets:
• 0 to 30 days old
• Older than 90 days
• AR due date forecast
• Down payments/payment
advances listing
• Client Payment history report
• AR posting status reports per period
• Cash Receipts Report

• Client Statement
D: Cash Management
D1: Petty Cash
The system must be able to address petty

3.2.1.150 cash disbursement through IOU or M
refund.

The system must be able to address petty

3.2.1.151 M
cash replenishment.
Staff must be able to apply for petty cash

3.2.1.152 M
online (IOU or through a refund).
System must have a workflow for

3.2.1.153 M
processing petty cash disbursements.
Automatic tracking of petty cash balance

3.2.1.154 M
for purposes of replenishment.
Raise alerts and notifications for petty

3.2.1.155 M
cash replenishment.
The system should enable posting of

3.2.1.156 M
petty cash entries to the GL.
Reminders or notifications on overdue

3.2.1.157 petty cash both to the applicant and the M
issuer.
The system should have an employee

self-service functionality that allows the
3.2.1.158 staff to clear all outstanding balances M
before they apply for new per
diem/imprest.
The system should have an employee

self-service functionality that allows the
3.2.1.159 M
staff to account for per diem/imprest that
had been advanced to the employee.

Reporting Requirements for Cash Management

3.2.1.160 M


following financial statements (IPSAS &
IFRS formats) and reports:
3.2.1.162 M
• Cash disbursements by
individual/amount/date
• Cash in foreign currency
• Cash by cost centre
D2: Bank Reconciliation
Functionality for reconciling cashbook
3.2.1.163 M
and bank statements.
The application SHOULD allow the

recording of bank entries in bank
3.2.1.164 M
statements automatically or upload
formats.
The application SHOULD provide an

extension to load bank statements online.
The application SHOULD have
3.2.1.165 M
acceptance of standard formats for bank
statements that are applicable in case of
all banking practices and standards.

The application MUST automatically

create miscellaneous transactions to
3.2.1.166 M
record bank-initiated activities like
interest gained, bank charges etc.
The system MUST facilitate auto

reconciliations based on customer id,
invoice number and site details, etc. for
3.2.1.167 M
matching. The bank balance MUST be
automatically updated online based on
clearances.
The system SHOULD have basic set up

(like limits for matching in case of
payment clearance or receipt matching
with cheque clearance). The system
SHOULD populate value dates for all
3.2.1.168 M
records. Apart from this, the system
SHOULD generate a report on the
transaction not cleared and the reason for
that (like funds getting rejected, invoice -
payment mismatch etc.).
The system SHOULD enable auto

reconciliation between the receipts
3.2.1.169 /payments within the other sub ledgers M
with the bank statement data in terms of
cheque clearances, EFT, etc.

The system SHOULD have an additional

functionality of manual clearances in
3.2.1.170 case that TAWSB opts for manual M
reconciliations in case of payment as well
as receipts for revenue.

3.2.1.171 generate reconciliation accounting M
entries.
The cash management application MUST

be well integrated with payable and
3.2.1.172 receivable system and MUST be having M
access to verify payable invoices as well
as revenue receipts.

3.2.1.173 M
record foreign currency gains and losses.
Reporting Requirements for Bank Reconciliations

3.2.1.174 M


following:
3.2.1.176 M
• Bank reconciliation report
• Direct debits/credits

• Unreconciled balances
D3: Bank Accounts
Bank details to be captured in full:
• Bank code
• Status (active/inactive)
• Bank name
• Bank branch
• Sort code
• Address
• Account name
3.2.1.177 M
• Account number
• Lookup code
• Transaction details:
• Transaction limit
• Transaction reference
• Comments
• Transaction type
• Supplier code
• Customer code
Reporting Requirements for Bank Accounts
3.2.1.178 M

• Deposit List
3.2.1.180 M
• Deposit Report

• Cash payments (supporting

electronic fund transfer)
• Cash receipts (supporting direct

debit)
• The reports conforming to

TAWSB’s existing bankers requirements
• Bank by Bank name/staff/amount
D4: Cash Forecasting
The application MUST provide cash

flows projections based on the
3.2.1.181 transactions processed in the integrated M
modules including receivables and
payables.
The application MUST provide the

facility to define cash forecast templates
such as:
3.2.1.182 M
• Forecasting periods
• Selection criteria for each source
The application MUST be able to

3.2.1.183 generate cash forecast in any currency M
based on the users parameters assigned
The application must have the ability to

3.2.1.184 O
capture market scan information

Reporting Requirements for Cash Forecasting

3.2.1.185 M

3.2.1.187 • Forecast Report M

E: Management Accounting (Budgeting)
E1: Budgeting Process
The system should incorporate online

budget preparation functionality and
3.2.1.188 should be able to cover all budgetary M
elements whether capital or operational
expenses
The system must possess functionality

that allows budget preparation at a
3.2.1.189 departmental/divisional level prior to M
merging several departments’/divisions’
budgets into a singular corporate budget.

System should be able to maintain and

track budgets and expenditure at
departmental and corporate level and be
3.2.1.190 M
able to provide alerts upon attainment of
an alert threshold (e.g. 80% of the
budget)
The system must have a workflow

approvals for creating, uploading and
3.2.1.191 M
updating the company’s annual and
supplementary budgets
The system must be able to keep historic

3.2.1.192 M
budget information
Budget amounts must be allocated to

3.2.1.193 M
accounting periods defined in the system
The system must be able to maintain

budget version number and approval
3.2.1.194 status where the annual budget has been M
updated through a supplementary
budget/budget reallocation
The system should be able to trace

3.2.1.195 payments to budget line items for cost M
management purposes
The system should be able to trace

3.2.1.196 payments to project budget line items for M
cost management purposes

The system should be able to

3.2.1.197 accommodate a budget calendar that may M
be different from a financial calendar
Capability to copy an entire budget year

on year. It should also support rolling
3.2.1.198 M
over of budget amounts/lines year on
year
Should provide functionality to view

3.2.1.199 M
actual data against budgeted data
The system must be able to support

3.2.1.200 reallocation of budgets between budget M
lines
Support Activity Based Budgeting

providing for a facility to capture
3.2.1.201 M
objectives, activities and outcomes at
item and sub item level
Multiple years budgeting – prior years

3.2.1.202 M
and at least 3 future years.
Facility to allocate budget ceilings by

3.2.1.203 M
programmes and by account code.
Ability to allow budgeting for any time

3.2.1.204 period (Monthly, Quarterly, Biannual, M
Annually etc. ).
Support both Bottom-Up and Top-Down

3.2.1.205 M
budgeting.

Support commitment control of the

budget not to allow spending on a line
3.2.1.206 M
item in the absence of a budget and
linked to procurement plan
The system MUST generate reports in

terms of budgetary control of last few
3.2.1.207 M
years with actual figures in order to key
in data for a new financial year.
The application MUST have Budget

3.2.1.208 input at account level. It may be input for M
the year or by month.
The application should support copying

of budgets from a financial period to
3.2.1.209 another. The copied budget should be M
modifiable through application of
percentages or absolute figures.
The application MUST provide online

3.2.1.210 facilities to view actual data with original M
budget or revised budgets.
The budgeting process MUST be

working in sync with procurement and
3.2.1.211 M
payment process in order to have inbuilt
control within the business cycle.

The application MUST be able to view

each department/function budget,
3.2.1.212 M
spending to date and expected
expenditures for the rest of the period.
The appropriate notifications MUST get

3.2.1.213 generated based on the workflow to be M
triggered for approval events.
The system MUST facilitate transferring

of budgets based on the cost codes
3.2.1.214 assigned or budget codes .It should M
facilitate smooth transition across budget
codes as well as departmental transfer.
The system MUST facilitate contingency

3.2.1.215 M
budgeting if required
The system MUST allow adding

3.2.1.216 supplementary budgets activities and by M
cost centre
Reporting Requirements for Budgeting Process

3.2.1.217 M


The reports must conform to the National

Treasury reporting requirements:
• Monthly budget reports
• Quarterly budget reports
• Reallocation reports
• Actual vs. Budget
3.2.1.219 M
• Year expenditure/revenue reports
• Annual budget reports
• Cost centre budget reports in user

defined period
• Performance contracting reports
E2: Budgetary Controls
When preparing the budget out-turn

report, one must be able to generate it
with the options of:
• Factoring in all actual payments and

3.2.1.220 committed funds (i.e. funds whose M
purchase requisition has been approved
but the actual payment has not been
made)
• Factoring in only actual payments

made
The budget out-turn should not include

3.2.1.221 future payments (not yet incurred) as a M
result of scheduled LPOs or journals.

The system must be able to capture

funded program budgets (e.g. GoK,
3.2.1.222 African Development Bank, etc. ) and M
report on them per the funder’s reporting
template.
The system must enable tracking of

3.2.1.223 budget expenditure and produce a report M
of the same
Produce comparative financial statements

showing:
3.2.1.224 M
• Prior year budget data
• Year to date budget
• Annual budget
The system must be able to produce

reports on committed budgets, actual
3.2.1.225 M
expenditures and balances per budget
line/account holder
System prevents department level users

3.2.1.226 from updating budget information after it M
has been submitted.
Allows Budget Office to "push"

3.2.1.227 worksheets out to departments M
electronically for budget preparation.
F: Financial Reporting Requirements
The system MUST facilitate forecasting

3.2.1.228 of costs and revenue in terms of trends M
based on historical data

The system MUST also allow

downloading budgeted revenue and
expense items from the budget system
3.2.1.229 M
and creating a link with the current
period data to produce variance
explanations between the two items.
The application MUST have following

types of reports
• Profit & Loss account
• Trial balance(Average, Detail &

Budget), Bal-Sheet (actual and projected)
• Performance report
• Forecasted Income Statement
• Cash Flow Statement
3.2.1.230 • Statement of changes in equity M
• Budget Vs Actuals
User defined
Complete IPSAS formats including

notes, IFRS formats,
Complete Quarterly financial statements

reports in IPSAS & IFRS formats
User defined period reports
Notes to the financial statements

Number Requirement description Mandatory / Detailed Explanation to

Optional Requirement
3.2.2. Human Resource Management System (HRMS) Requirements

A: Organisational Structure
3.2.2.1 System MUST have an ability to include M
Organization structure hierarchy definition
Using SAP we can built
Good Structure include
and organogram. Graphic Mode
3.2.2.2 System MUST be able to build an M

We Can built Good
organization structure, which caters to Graphic View
various organization types such as
departments, sections, sub-sections, cost
centres.
3.2.2.3 System MUST have an ability to have M

multiple organization (subsidiaries) Available
hierarchies.
3.2.2.4 System MUST have a functionality to M
modify the organization structures as and
when required and maintain the history of all Available
such changes.
3.2.2.5 System MUST have an ability to have O

position-based organizations. Available
3.2.2.6 System MUST have a functionality to assign M

managers to various Organizations and view Available
the managers and sub-ordinates reporting to
them.
3.2.2.7 System MUST have an ability to view M

positions linked to various Organizations. Available
3.2.2.8 System MUST have provision to define O

various organizations at various locations. Available
3.2.2.9 The system must be able to define job M

descriptions, and skills and qualifications Available
required for each position.

3.2.2.10 Jobs form will include breakdown of M

approved jobs that belong to particular
organizations (total number, vacant, Available
occupied, blocked, etc.).
3.2.2.11 The system MUST be able to identify jobs M
and positions uniquely. Available
3.2.2.12 The system MUST be able to maintain M

history of changes done to the position
details. Available
3.2.2.13 Ability to show all vacant and occupied M Available
positions & jobs.
3.2.2.14 Ability to transfer jobs and positions between M
organizations. Available
3.2.2.15 Ability for sector heads, department M

By Providing
Authorization they can
managers using the self-service to request for view
“New Jobs”, “Transfer of jobs and positions”
and build the required workflow.
3.2.2.16 Ability to link rewards and salary scales with M

employees’ position grading. Available
3.2.2.17 Availability to create new positions with M

Personnel Cost
Planning(PCP)Sub Module
integration with the budget systems. need to implement
3.2.2.18 The system must have the ability to maintain M

changes in employee position and jobs
details such as:
Available
• Position and job Transfer
• Position and job Status
• Position and job Description
• Position and job History
3.2.2.19 The system should allow for changes in M Available
position title.
3.2.2.20 The system should allow for upgrading a M
position. Available

3.2.2.21 The system should allow for downgrading a M

position. Available
3.2.2.22 The system should allow for removing or M
returning a position. Available by PA Actions
3.2.2.23 The system should allow for the ability to M

Diff Employee Groups can
create several types of employment (terms of be Create
service) such as pensionable, contractual,
internship etc
3.2.2.24 The system should allow for addition, M

PA Actions
Addition/Deletion
removal or amendment of types of Available
employment
3.2.2.25 Ability to create grading levels (managerial, M

Employee sub groups with
technical and support) and flexibility to in Group available
adding new levels.
3.2.2.26 Ability to create employee status (active M

employment, resigned, suspended, study
leave and unpaid leave) and integrate it with Available
affected areas in leave management and
payroll
Reporting Requirements for Organisational Structure

3.2.2.27 Ability to generate multiple statistical reports M
for all positions & jobs within the Available
organization.
3.2.2.28 The system MUST produce the following M

reports:
• Organizational structure reporting by Available
location.
• Organizational structure reporting by
geographical are Available
• Open and filled positions reporting. Available
Available
• Positions associated with organizations.

By PCP Module
• Budget & Actual Head Count Comparison. implementation can meet
B: Recruitment and selection

3.2.2.29 Ability to create and develop employee M
requisitions/vacancies. Available
3.2.2.30 Ability to receive applications during M

recruitments online E-Recruitment
3.2.2.31 Ability to allow for information drawn from M
physical applications to be inputted into the Available
system during recruitments
3.2.2.32 Ability to accept applications both internally M

and externally. Available
3.2.2.33 Ability to screen and select candidates. M
Available
3.2.2.34 Ability to track candidates and recruiter in M
the placement process. Available
3.2.2.35 Ability to manage pre-placement M

verification, which includes salary
authorisation.
3.2.2.36 Ability to advertise vacancies internally M Available
(self-service)
3.2.2.37 The system SHOULD enable candidates to M
apply for available vacancies. Available
3.2.2.38 Ability to generate a long list as per the job M

criteria e.g. experience, technical, academic Available
and competence qualifications.
3.2.2.39 Ability to capture interviewer notes and O

feedback. Available
3.2.2.40 System MUST have a vacancy approval M Available
process/workflow inbuilt.

3.2.2.41 System must have a recruitment and M

selection workflow that covers that process
from vacancy creation to defining a new
employee.
3.2.2.42 Ability to track recruitment drive and M

produce reports for management (e.g.
recruitment costs, time taken to fill a Available
position, status of recruitment drive, etc.).
3.2.2.43 Ability to generate resumes from candidate M

input details. Available
3.2.2.44 Ability to upload and share candidate M
documents (e.g. certificates, CV, etc.). Available
3.2.2.45 Ability to verify budget prior to recruitment M

drive. Available
3.2.2.46 Ability to generate offer letters, appointment M
letters, etc. Ability to send an offer letter Available
electronically or as a print out.
3.2.2.47 Ability to generate rejection letters. M
3.2.2.48 Ability to hire staff on contract for a M Available

specified period.
3.2.2.49 Ability to hire temporary staff and/or interns M
for a specified period. Available
3.2.2.50 The system should be able to shortlist M

qualified applicants from the long-list at the Custom Field of Status
point of job application. This will assist HR
from having to review overwhelming number
of applications from unqualified persons.

3.2.2.51 When employees are rehired, the system M

Same Employee number
should link all previous employment can assign
information to the new record.
3.2.2.52 The system SHOULD have recruitment M

planning mechanism to capture recruitment
plans online
3.2.2.53 The system MUST be able to track the M

requisitions for vacancies for a particular job, Available
organization, grade, location or position
3.2.2.54 Ability to schedule interviews O Available

3.2.2.55 Ability to track interview results M Available
3.2.2.56 The requisition form should be flexible to M

change according to requirements
3.2.2.57 Ability to register the employment contract, M

renewal and termination Available
3.2.2.58 The system must have the ability to provide a O

word processing interface for customizing
recruitment letters
3.2.2.59 Ability to implement a specified probation M

period for newly hired employees Available
Reporting Requirements for Recruitment and selection

3.2.2.60 Ability to generate the following reports: M
• Recruitment Activity reports, recruitment

reports –direct / internal reports.
• Recruitment reports based on recruiting

department.
• Vacancies report.
• Applicants Qualifications reporting.

• Statistical reports of the applicants and

provide the higher management with tabular
and graphical reports
• Statistical report of the requested number

of employees for a specific area
C: Staff orientation / induction

3.2.2.61 Should be able to develop induction program O
within the system with input from HR and
user departments.
3.2.2.62 Ability to allocate employee compensation M
and benefits (NHIF, NSSF, club
membership, advances, loans, etc.). Available
3.2.2.63 Ability to confirm/reject new employee after M

completion of probation period or extend Available
probation period.
3.2.2.64 At a minimum, the following employee M

All below Fields are
master details must be captured: Available
• Staff number (auto-generated)
• Nationality
• Ethnicity
• Disability
• Gender
• PIN Details
• NSSF Details
• NHIF Details
• ID/Passport number
• Marital status
• Date of birth
• Employees names
• Contacts (Phone Number, Postal Address,
Email etc)

• Spouse details: name, ID number,

occupation and contacts (Phone Number,
Postal Address, Email etc)
• County of origin
• Dependants: Age, Gender, relation
(daughter, son, adopted)
• Next of kin details: Names, ID number,

occupation and contacts
• Employee photo
• Employee qualifications, experience and
skills
• Previous employer
• Employment date
• Position
• Category (senior, management, mid
management, support)
• Department/division
• Employment status (contract, permanent,

probation, temporary)
• User-defined comments
The system must allow an employee to view

Employee Self Service
(ESS) Sub Module need to
personal data such as names, address, take with User Licenses
contacts, schools attended, qualifications, etc
Updating personal data be subject to
verification and approval.
3.2.2.65 The system must allow an employee to view
payment details such as bank, account name,
Manager Self
Service(MSS) need to
account number, etc. Updating this implement
information should be through a process of
approval.
3.2.2.66 The system must allow the user to view and
update information on beneficiary and Available
dependants subject to verification and
approval.

3.2.2.67 The system SHOULD have storage facility

for certification and other relevant
documents for employees DMS Required
3.2.2.68 The system SHOULD alert new employees

Training & Event
Management Sub Module
to participate in the induction program to be develope
coordinated by HR.
3.2.2.69 The System SHOULD allow grouping of
employees based on various aspects such as Available
department/section/division and grades
3.2.2.70 The system MUST be able to store working

hours details, work frequency and normal Available
timings for the employee.
3.2.2.71 The system MUST be able to store working

hours details, work frequency and normal
timings for the employee. Available
D: Employee Management
3.2.2.72 The system must be able to manage staff
transfers, acting appointments, relocations, Available
promotions and demotions and track such
movements.
3.2.2.73 The system should be able to address acting

appointments. It should be able to capture Available
under an employee’s profile:
3.2.2.74 • The event of acting appointment

Available
• Position
• Start and end dates of the appointments
• Benefits applicable
Embed a workflow that supports Employee

transfers including acting appointments

3.2.2.75 Provision for uploading and attaching

documents to an employee’s profile such as DMS Required
scanned transfer letters, etc.
3.2.2.76 Maintain a history of Employee transfers
taken and support the ability to profile the Available
same employee
3.2.2.77 Employee transfers module should be
interfaced with payroll processing Available
component
3.2.2.78 Provision for managing employee
disciplinary actions Available
3.2.2.79 Embed a workflow that supports the Available

disciplinary process (disciplinary module)
3.2.2.80 Provision for uploading and attaching
documents to an employee’s profile such as
scanned warning letters, certificates, Available
commendations, etc.
3.2.2.81 Maintain a history of disciplinary action
taken against an employee and support the Available
ability to profile the same employee
3.2.2.82 Disciplinary module should be interfaced

with payroll processing component Available
3.2.2.83 Disciplinary module should integrate with

the personal development, training and
separation modules
3.2.2.84 The system must be able to adequately
address situations where an employee is
suspended and capture this event on the
employee’s profile. This includes provision Available
of workflows for initiating the suspension
process, ending suspension and
reinstating/rejecting an employee after
suspension

3.2.2.85 The system must be able to adequately

address situations where an employee is
suspended and capture this event on the
employee’s profile. This includes provision Available
of workflows for initiating the suspension
process, ending suspension and
reinstating/rejecting an employee after
suspension
Reporting Requirements Employee Management A

3.2.2.86 • Employee details by department, location,
positions, jobs, grades, payroll, Allowances, Available
etc.
• New appointments / joiners report.
Available
• Acting appointments report.
Available
• Transferred employees report. Available
• Employee addresses and contact details Available
report.
• Employees' summary reporting by specific
criteria e.g. by department, grade etc Available
• Employees Locations report
Available
• Employee turnover reporting and analysis BI/BO
• Disciplinary actions taken report Available
• Positions Analysis
Available
• Contract Employees Available
• Employees by Cost Centre Available
• Employees Ethnicity Reports
• Employees by Education Level Available
• Promoted Employees
Available
• Retiring Employees
Available
• Terminated Employees
Available
• Transferred Employees
Available
• Workforce planning
• Staffing level analysis
• Ages of staff Available

• Dates of employment Available

Available
• Report listing employee NHIF, NSSF,
PIN, HELB, NSSF or DIT (Directorate of
Industrial Training) details
• Gender analysis Available
• People with Disabilities (PWD) analysis Available
Skill set and competencies status: to list per
employee the professional qualifications,
academic qualifications, learning /
development map, job requirements.
3.2.2.87 Skill set and competencies status: to list per M
employee the professional qualifications, Available
academic qualifications, learning /
development map, job requirements.
E: Performance management
3.2.2.88 System MUST have an inbuilt performance M
appraisal process/workflow. Ability to
support the 360 degrees appraisal system
with the ability to be configured to any other
system such as the balanced scorecard.
3.2.2.89 Ability to define various objectives M
associated with performance management.
3.2.2.90 Ability to define and amend KPI’s associated M

with the objectives defined subjected to a
workflow approval.
3.2.2.91 The 360 degrees appraisal system and KPI’s M
must be amendable for different categories of
employees.
3.2.2.92 The system must enable calculations for the M

KPIs against predefined rules to arrive at the
performance measurement.
3.2.2.93 Ability to monitor and manage performance M

contract deliverables.

3.2.2.94 Ability to capture performance requirements M

per position: qualification requirements,
personal attributes, education, experience,
skills, etc.
3.2.2.95 Ability to receive periodic (e.g. quarterly) M
appraisal reviews/results from various
business units online.
3.2.2.96 Ability to send employees / special groups M

performance appraisal report on the system.
3.2.2.97 Ability to track performance appraisal results M

over a period of time per employee, special
group, department, etc.
3.2.2.98 The performance management system should M

interface with the Training and Development
module to enable identification of
development requirements during the
appraisal process and converting them to
training requests in the Training and
Development module.
3.2.2.99 Support the associating of evidence to M
performance KPI’s.
3.2.2.100 Extraction of performance data to (excel, ms M

word, pdf etc) per employee and per
department and divisions.
3.2.2.101 The system should support self-appraisal. M
3.2.2.102 Assessment of self-appraisals for annual or M

periodic appraisal process MUST be possible
for the managers.
3.2.2.103 Support electronic signoffs between the M
appraised and appraiser and other relevant
officials.

3.2.2.104 The performance appraisal module should M

interface with the benefits and compensation
module to be able to effect a salary
adjustment based on your performance
rating.
3.2.2.105 The system should allow the salary M
adjustment as defined in the salary
progression matrix.
3.2.2.106 The system must allow the employee to M

receive performance feedback from their
supervisor/manager.
3.2.2.107 The system must allow KPI tracking and M

management dashboards.
3.2.2.108 A workflow must be present for issuing a M

performance rating to an employee.
3.2.2.109 A workflow must be present for issuing a M

performance rating to an employee.
Reporting Requirements for Performance management

3.2.2.110 • Performance reporting per individual. M
• Performance reporting by position.
• Performance reporting by department /
special group.
• Performance reporting by department /
special group.
F: Training Management
3.2.2.111 Ability to match training needs of an M
employee against their position’s
qualification requirements (academic,
personal attributes, professional, experience,
skills, etc.), organisational growth plans and
performance management system. Ability to
identify and evaluate training needs.

3.2.2.112 Capturing of training requests submissions M

from user departments.
3.2.2.113 Ability to create a list of training providers M
and their details.
3.2.2.114 Ability to create a training plan, manage and M

update training plan.
3.2.2.115 Ability to create a short-list of candidates for M

training and compare them against the
training selection criteria (e.g. competency-
based selection).
3.2.2.116 The system must have an approval/rejection M
process for a training plan.
3.2.2.117 Ability to create, manage and update an M

employee’s personal development plan.
3.2.2.118 Ability to capture information on trainings M

attended by an employee.
3.2.2.119 Ability to capture/receive training and M

development requests from other
departments.
3.2.2.120 Ability to maintain historical data on all M
information captured e.g. trainees, trainers,
vendors, training requirements, attendance,
training record, performance, etc.
3.2.2.121 Ability to create (define) training selection M
criteria and maintain historically (e.g.
competencies-based criteri).
3.2.2.122 Ability to allocate roles to different M

personnel in the training development
process.

3.2.2.123 Ability to interface the training request O

process with financial system e.g. raising
invoice, LPO.
3.2.2.124 Ability to track the status of a training M
request from requisition through planning to
delivery and completion by trainees.
3.2.2.125 Centralised cataloguing and tracking of M

training courses
3.2.2.126 Ability to design, create and deliver online O

training programs (modules and tests).
3.2.2.127 The system should have provision for setting O
the maximum number of trainings a single
employee can receive in one financial year.
3.2.2.128 The system should have functionality to O
restrict an employee from registering the
same training course more than once after
successfully undertaking the course
3.2.2.129 The system MUST facilitate development of M
a training calendar specific to departments
within the company, jobs skills requirements,
technical aspects and publish the calendar
3.2.2.130 The system SHOULD be able to generate M

training requirements based on the existing
roles and responsibilities and the
organizational growth plans and performance
management system
3.2.2.131 The system SHOULD be able to generate M

training requirements based on the existing
roles and responsibilities and the
organizational growth plans and performance
management system
Reporting Requirements for Training Management
3.2.2.132 • Competencies reporting along with skills. M

• Training requirements reporting.
• Trainings history reporting.
• List of Attendees of a Course

• List of Attendees of a Course in a
Department
• List of Courses for a certain position
• List of Courses Taken by Employee during

a defined period
• List of Employees not Attended a
mandatory Course (if expected to attend)
• List of Positions for a Course
• Enrolled For postgraduate courses/

professional courses / scholarship.
• Employee Training/development needs
• Staff trained
• Trainings delivered
• Trainings in the pipeline
• Training plan
• Training feedback reports
• Training feedback reports
G: Training Attendance (E-Learning)
3.2.2.133 The system should be able to present to O
employees a list of approved courses from
which to choose from. The system MUST
facilitate the enrolment for training courses
3.2.2.134 The system MUST enable the users to O
maintain a history of the courses attended,
status of registrations and passes/fails
3.2.2.135 The system must be able to track enrolment O
and maintain enrolment status for all courses

3.2.2.136 If registrations are received beyond the O

maximum capacity of the course, the system
must be able to keep a waiting list for that
course
3.2.2.137 Ability to send reminders and notifications to O
employees on upcoming courses which they
have registered for
3.2.2.138 Ability to capture training evaluation and O

feedback by attendees so as to determine the
success of the training delivered
3.2.2.139 Ability to record skills gained by the trainee O

after attendance of the training
3.2.2.140 The system must be able to capture the grade O

(pass/fail/marks obtained) of an employee
upon completion of a course either
automatically or manually by the trainer
3.2.2.141 The system must be able to track on number O
of hours of training an employee has
attended for each course
3.2.2.142 The system must be able to track on number O

of hours of training an employee has
attended for each course
H: Leave Management
3.2.2.143 The system must automate the leave M
application process by enabling end-to-end
online leave management. The system must
embed a workflow for leave management Available
that can capture comments and approvals
related to the task depending on its
requirements

3.2.2.144 Ability to accrue leave days at a configurable M

rate. Available
3.2.2.145 Ability to deduct leave days. M

Available
3.2.2.146 Capability to track and extract a history of M Available
the leave management data of an employee
3.2.2.147 Calculation of leave balances and how much M
they are worth
Available
3.2.2.148 The system must be able to carry forward M
leave balances as per HR policy and Kenya Available
Statutory laws
3.2.2.149 Interfaced with payroll component of the M
HRMS so as to support the conversion of Available
leave balances to payment (during separation
only)
3.2.2.150 Should enable users to perform online leave M
planning on a calendar based system and
submission of the same into the leave
approval workflow or save plans as draft Available
3.2.2.151 Provide alerts and notifications to users and O

relevant authority on leave anniversary, Custom WorkFlow
public holidays, etc.
3.2.2.152 The system should provide for Public M

holidays Available
3.2.2.153 Enable one to apply for the following types M

of leave: Available by ESS
3.2.2.154 • Maternity M
• Examination
• Study
• Paternity
• Compassionate
• Annual

• Compulsory
• Emergency
• Sick
• Unpaid
The system must allow initiation of sick
leave application by HR personnel on behalf
of the employee
3.2.2.155 At a minimum, the following details on leave M
application must be captured: Available
3.2.2.156 • Name M
• Grade Available
• Date of appointment
• Leave entitlement (days per annum)
• Leave days applied for
• Leave start date

• Leave end date
• Contacts when away
• Leave balance carried forward
• Leave balance brought forward
• Leave balance
The system MUST have the provision to

access leave information online.
3.2.2.157 The system MUST have a facility to keep a M
track of number of days of leaves taken, for Available
the various categories of leave
3.2.2.158 The system MUST have a facility for the M
supervisors or the HR users to approve or Available
reject the leave applied by the employees


supervisors or the HR users to approve or
reject the leave applied by the employees Available by MSS
Reporting Requirements for Leave Management

3.2.2.160 • The system MUST have a provision to M
report the usages of leave types. Available
• The system MUST have reporting for
various types of leaves for employees. Available
• Leave accruals reporting. Available
I: Employee separation
3.2.2.161 A workflow must be present for TAWSB to M
initiate the separation of an employee in the
event that it is a dismissal and capture
comments where necessary.
A workflow must be present for processing a

request for separation from an employee and
capture comments where necessary
3.2.2.162 A workflow must be present for processing a M
request for separation through an employee
retirement, and demise and capture Available
comments where necessary
3.2.2.163 The system should store the notice period M

details of all employees Available
3.2.2.164 Employees clearance form should be M

accessible online No Dues Custom
3.2.2.165 At a minimum, the following should be M

captured on the clearance form: Available
3.2.2.166 • Name M

• Date employed
• Forward Contacts
• Designation
• Department
• Type of separation
• Last day of service
• Leave days due payable
• Notice period (adequate/inadequate)
• Notice period (to hand over TAWSB
Property)
• Pay in lieu of notice
• Signoff requirements with relevant

personnel, departments or bodies
Electronic signoff of clearance form between
user and relevant personnel and capture
comments
3.2.2.167 Integration with compensation module, M Available
loans, mortgages, etc.
3.2.2.168 Maintain employee exit interview M

information Customization
3.2.2.169 The system should capture the separation M

event and date under an employee’s profile. Available
Further to this, it should capture type of
separation (dismissal, resignation, death,
retirement, and contract expiry), details and
allow attaching of relevant separation
documentation
3.2.2.170 The system must have a workflow for M
processing an employee reinstatement
application that allows one to either approve Customization
and process the reinstatement or reject the
reinstatement application.

3.2.2.171 The system must be able to address the M

process of employee reinstatement. During
reinstatement, the system should allow one
to continue working with the previous data
that was captured prior to termination of the Available
employee and register the event of
reinstatement on the employee’s profile.
3.2.2.172 The System MUST allow for terminating the M
employee record at the conclusion of the
employment period without deletion.
Available
3.2.2.173 The System MUST allow for terminating the M
employee record at the conclusion of the Available
employment period without deletion.
Reporting Requirement for Employee separation

3.2.2.174 The system should have the following M
reports:
• Terminated / separated employees report. Available
• Terminated Employees by Termination
Reason. Available
• End dated positions reports.
Available
• Staff due to retire (in 3 years, 2 years, 1
year, 9 months, 6 months) Custom
• Staff due to retire (in 3 years, 2 years, 1
year, 9 months, 6 months) Custom
J: Compensation and Benefits Management (Payroll)

3.2.2.175 The system should enable compensation M
planning. Available
The system must provide a workflow for

approval or updating of all compensation
related configuration dat
3.2.2.176 Must be able to capture and maintain all M
compensation and benefits data such as gross
salary, NSSF, NHIF, allowances, benefits, Available
pension contributions, internal loans,
insurance relief, Personal Relief, PAYE, etc.

3.2.2.177 Must be able to capture Employers’ M

Contribution to Registered or Unregistered Available
Pension Scheme or Provident Fund.
3.2.2.178 Must be able to capture Employees’ M

Contribution to Registered or Unregistered
Pension Scheme or Provident Fund. Available
3.2.2.179 For the compensation and benefits data M

above, the system must be able to keep a
history of transactions and changes while
enabling the extraction of the same Available
separately as a report per employee,
department/division or company for all
employees whether current, separated, on
leave, etc.
3.2.2.180 Must be able to capture and maintain pay M
disbursement details (i.e. pay mode, bank Available
details, cost centre, etc.) allow for
amendment and keep a history of such
amendments.
3.2.2.181 Should enable computation of employee M

costs per employees, division or company. Available
3.2.2.182 Must interface with the financial system / M Available

accounting module chart of accounts so as to
allocate staff costs to the relevant cost/profit
centres.
3.2.2.183 Generation of tax returns (P9 forms) in batch M Available
or on singular basis.
3.2.2.184 The system must be able to perform salary M

transfers / Payments. Available
3.2.2.185 Provision for uploading of payroll data in M

mass from files such as spreadsheets where Available
necessary. There must be a workflow for
approving such uploaded dat

3.2.2.186 The system must be able to define categories M

of benefits and assign employees to benefit
categories based on an eligibility criteria (i.e. Available
one-off payments, periodic, recurring, etc.).
3.2.2.187 The system must be able to define salary M

plans (i.e. salary ranges and pay plans) for
different categories of employees and
associate an employee to a salary plan based Available
on predefined rules/qualification criteri
3.2.2.188 Ability to compute employee salary M

increment based on salary progression Available
matrix.
3.2.2.189 The system must be able to compute salaries M

in Kenya Shilling. Available
3.2.2.190 The system must be able to compute salaries M

Available, But periodically
currency ration need to
in Foreign Currency. maintain
3.2.2.191 The system should enable attaching or O

referencing of documentation related to Available
employee compensations e.g. garnishment
letters, etc.
3.2.2.192 Staff must be able to view their pay O
information online. Available
3.2.2.193 Provision to enable application for loans and M

salary advances and facilitate approval of the Available
same through a workflow.
3.2.2.194 Provision for Alerts when the employee’s M
deductions reach a set threshold – 1/3 of
Payroll Admin can be, but
for employee need to
monthly pay. develop

3.2.2.195 The system must be compliant to the legal M

requirements in Kenya regarding employee
Compensation earning and deductions. Available
3.2.2.196 Ability to process partial deductions if an M

employee’s pay are insufficient to cover the Available
Deduction.
3.2.2.197 Ability to compute associated employee M

taxes while taking into consideration the Available
employee’s benefits.
3.2.2.198 Ability to facilitate payroll planning and M

calculations. Available
3.2.2.199 Ability to pay mass salary changes M
retroactively and with different Available
parameterisation options.
3.2.2.200 The system must be able to address M
payments/deductions missed out in the past
either to a single employee or a group of Available
employees.
3.2.2.201 The system must be able to record M
loans/advances to the employee under the Available
employee’s profile.
3.2.2.202 The system must correctly recover loans / M

salaries advanced to the employee. Available
3.2.2.203 TAWSB provides insurance to its employees M

by insuring with a third party and recovers
the amount from the employees’ payroll. Available
The system should have capability for setting
up deductions from an employee’s payroll.
3.2.2.204 The system must be able to post the M
recovered amounts correctly to the financial Available
system.

3.2.2.205 All compensation and benefits must be M

formula driven / criteria based. The systems
MUST NOT allow arbitrary allocation of
compensation/benefits to an employee.
3.2.2.206 The system must have robust security M
features that will protect sensitive salary Available
related information from unauthorised users.
3.2.2.207 The system should support multiple payroll M

cycles (weekly, fortnightly, monthly, etc.). Available
3.2.2.208 The system must allow one to define the date M

when the payroll is run and the date when the Available
salary transfer takes place. The system
should allow these dates to be changed in the
event that they fall on a holiday.
3.2.2.209 Provision for having different payrolls to M
cater for: Available
3.2.2.210 • Permanent employees M Available
• Casual employees (wages)

• Intern employees
They system must have flexibility for
configuring earnings and deductions so as to
capture all earnings and deductions
applicable at C
3.2.2.211 There should be provision to schedule M
earning and deductions in order to address Available
situations where an earning/deduction is one
time or severally over a period of time.
3.2.2.212 The system must offer functionality to make M

corrections to a payroll already processed. Available

3.2.2.213 There must be a detailed payslip explaining M

every earning and deduction made for every
payroll run. The payslip should clearly Available
separate earnings from deductions.
3.2.2.214 The system should maintain a history of all M
payroll runs and all their information
(payments made and costings generated). Available
3.2.2.215 The system must notify HR once the payroll M

runs and payroll transfers are complete. It
must allow HR to track their statuses and be Available
able to view any error/exceptions in the
process and view successfully processes
payrolls.
3.2.2.216 The system must notify HR once the payroll M
runs and payroll transfers are complete. It
must allow HR to track their statuses and be Available
able to view any error/exceptions in the
process and view successfully processes
payrolls.
Reporting Requirements for Compensation and Benefits Management (Payroll)

3.2.2.217 In addition to a flexible reporting facility, the M
system must be able to extract the following
payroll related reports per employee, per
department and per company:
Available All Below
• Pay slip. Reports
• Bank advice.
• Payroll per month
• Staff journal.
• Additions (benefits, allowances, low
interest benefits, bonuses, reimbursement,
etc.).
• Deductions (loan repayment, HELB,
insurance premiums, pensions, mortgage,
etc.).

• Contributions (pensions, etc.).
• Club subscriptions.
• Tax returns (P9 forms).

• Employee costs.
• Employee compensations details report.
• Salary related costing details report.
• Overtime payment report.

• Payroll related costing reports.
• Salary on Hold reporting.
• Report for pending payments to

employees.
• Statutory report such as PAYE reporting.
• End of service calculations report.
• Reimbursement status report Not Available
• Reimbursement status report Not Available
K: Awards
3.2.2.218 The HR system SHOULD have a provision M
to develop and manage awards / rewards,
recognition, and incentive / motivation Not Available
programs.
The system SHOULD facilitate tracking and

recognition of service awards such as gifts,
certificates.
3.2.2.219 The system SHOULD be able to store all the M
employee related awards history. Available
3.2.2.220 The system SHOULD have a provision of M

reflecting awards related information to an Available
employee's performance.

3.2.2.221 The system SHOULD have a provision of M

reflecting awards related information to an
employee's performance.
Reporting Requirements for Awards

3.2.2.222 The ability to generate reports pertaining to M
awards:
• Awards issued per period.

• Awards issued per employee.
• Incentives provided per period.
• Incentives provided per employee.
• Listing of awards type.
• Listing of incentive type.

• The system SHOULD facilitate reporting
of service awards such as gifts, certificates.
• The system SHOULD facilitate reporting
of service awards such as gifts, certificates.
L: Self – Service
L1: Employee Self – Service

3.2.2.223 The system MUST enable the users to M
maintain their personal data such as name,
address, telephone numbers, contacts,
qualifications, school and colleges attended, Available
skills attained etc. subject to the supervisor’s
verification.
The system MUST enable the users to view

their pay slip on-line for all the processed
payrolls.
3.2.2.224 The payment details for employees such as M
bank name, bank branch, account number
etc. MUST be visible to users and they must Available
be able to modify the same.


users to maintain their beneficiary details and Available(Custom)
dependents information.
3.2.2.226 The system MUST facilitate the users to M

maintain their emergency / next of kin Available
contact details.
3.2.2.227 The system MUST have the leave request M

functionality, which would enable the users Available
to apply for leave.
3.2.2.228 The system MUST be able to display the M

leave balances, leaves taken and eligible Available
leaves for the users.
3.2.2.229 Allow employee to update his training M

information. Available
3.2.2.230 Allow employee to update his training M

information. Available
L2: Manager Self – Service
All information may not
required to check by
immediate superior, some are
directly hit to Personnel
3.2.2.231 Line managers MUST have an access to M Administrator
search and view information pertaining to
their sub-ordinates.
A supervisor MUST have access to view

his/her sub-ordinates’ employment as well as
applicant history.
3.2.2.232 Supervisors MUST have access to view the M
team members’ leave requests and approve- Available
reject those.
3.2.2.233 Manager MUST be able to view absence M Available

history for his/her entire team.

3.2.2.234 Manager MUST be able to view absence M

history for his/her entire team. Available
M: Medical
3.2.2.235 Staff (or HR) should be able to access Sick M
Sheets online and update the same.
An inbuilt workflow for initiating and

processing sick sheet and capturing
comments and approvals from relevant
personnel.
3.2.2.237 The following details must be captured on M
the Medical Claim Form at a minimum:
3.2.2.238 • Serial number (auto-generated) M
• Employee’s name
• Patient name
• Designation
• Staff number
• Medical billing details
• Valid dependants name & age (pulled from
the employee master details so as to process
sick sheets for dependants only)
• Medical facility
• Medical Scheme (where applicable)

Be able to interface with the Finance Module
and Payroll Module for management of the
medical payment process.
3.2.2.239 Capture and maintain details (such as M
contacts, names, location, address, etc.) of
medical service providers (dentists, doctors,
hospitals, laboratories, pharmacists, etc.
3.2.2.240 Maintenance of medical limits per employee M
and be able to track utilisation of the medical
limits

3.2.2.241 Alerts and notifications when a staff is about M

to go beyond their medical limits
3.2.2.242 Provide medical statements to the employee. M
3.2.2.243 Ability to the employee to request New M

Medical Card, Medical card removal,
Medical card Replacement, or Employee ID.
3.2.2.244 The system SHOULD facilitate processing of M
insurance claims with insurance company,
where applicable.
3.2.2.245 The system SHOULD maintain accident O
records separately.
3.2.2.246 The system SHOULD be integrated with M

Accounts payable module for raising
invoices.
3.2.2.247 The system SHOULD integrate with Payroll M

for medical leaves.
3.2.2.248 The system MUST have a functionality to M

keep a track of insurance eligibility for
various employees depending upon their
hierarchical position in the organizations.
3.2.2.249 The system MUST be able to manage the O
agencies providing the insurance coverage.
The system MUST be able to add new
agencies, delete the existing agencies etc.
3.2.2.250 The users MUST be able to upload the M
claims related documents in the system.
Reporting Requirements for Medical
3.2.2.257 Provide medical statements analysis by M
spend per
• Medical Provider
• Employee
• Medical reports to track utilisation of
medical limits per employee

N: Loans and advances

3.2.2.259 Staff must be able to fill loan application M
form online through the self-service module
for the different types of loans and advances:
• Salary advance
• Car loan
• Property loan / Property refinancing
• Car overhaul advance
• Furniture loans
• Car Insurance advance
An inbuilt workflow(s) for processing
applications of the different types of loans
and advances must be present that addresses
the unique qualification requirements for
each loan/advance. The workflow must
address the entire loans application,
processing and approval process.
3.2.2.260 The system must capture the loan/advance M
against the employee’s compensation and
benefits profile
3.2.2.261 The system must interface with the payroll M
component so as to correctly record issued
loans, recovered loans/advances.
3.2.2.262 The system must not allow for issuance of M

loans/advances that violate the statutory
guidance on employee deductions in Kenya
3.2.2.263 The system must not allow for issuance of M

loans/advances that violate the statutory
guidance on employee deductions in Kenya
Reporting Requirements for Loans and advances
3.2.2.264 Production of the various Payroll M
forms/reports including:
• P9A - Tax Deduction Card (Benefits /
Owner Occupiers Interest / Normal Cases)

• P9A (HOSP) - Tax Deduction Card (Home

Ownership Savings Plan)
• P9B - Tax Deduction Card (Tax Free

Remuneration)
• P10 - Employers Covering Certificates

End of Year Returns
• P10A - Supporting list to End of Year
Certificate
• P10B - Fringe Benefit Tax Return
• P10C - Employer's Certificate (WCPS

Cases Only)
• P10D - PAYE Quarterly Return Form
• P11 - Credit Slip Pay In Book (sample)

(only originals are acceptable)
• P11 - Credit Slip Pay In Book (sample)
(only originals are acceptable)
O: Vehicle management
3.2.2.265 The system must cater for the capturing and M
updating of vehicle related details including:
• Registration Number
• Make
• Type of vehicle
• Specialised use of the vehicle
• Specialised equipment on the vehicle
• Year of Manufacture
• Insurance
• Fuel type
• Tyre size
• Etc.

The system must cater for the capture of

vehicle related maintenance including:
3.2.2.266 • Lubrication History M
• Vehicle Repair History

• Travel itineraries History (including the
start and return odometer readings)
The system must cater for the capture of
vehicle fueling and associated odometer
reading
3.2.2.267 The system must cater for the capture of the M
vehicle booking and maintain the car
booking status detail (e.g. Available, booked,
in use, under repair, etc.)
driver allocation and maintain the driver’s
allocation status detail (e.g. Available,
allocated, on safari, Not on duty, etc.)

vehicle Work ticket
3.2.2.270 The system should have the ability to link the M

vehicle to a specific driver
3.2.2.271 The system must cater for the capturing and M

updating of driver related details (Staff No,
Class of Driving License, etc.) and should
have the provision to be linked to Employee
Master details
3.2.2.272 The system must cater for the capture of the O
details of vehicle usage and the responsible
department

3.2.2.273 The system must capture the manufacturer M

recommended vehicle’s Maintenance
schedule
3.2.2.274 The system must produce the Resource M

utilization and optimization report
3.2.2.275 The system must capture the details of New M

Insurance Registration, Renewals,
Modifications, and Cancellations.
3.2.2.276 The system must capture the details of M
Maintenance Activity Reports
3.2.2.277 The system must report using Trend Analysis M

per vehicle with respect to usage,
maintenance, and consumables
3.2.2.278 The system must produce the New and M
Retiring Vehicles Report

Number Requirement description
/Optional Requirement
3.2.3 Asset Management System Requirements

A: Asset Administration
Ability to generate asset tag based on asset

3.2.3.1
class & predefined sequence numbering to
M
help in the process of physical verification
process.
3.2.3.2.
Ability to allocate each asset to one or more
O
insurance policies
3.2.3.3.
Provide alerts for payment of insurance
M
premium before the expiry
3.2.3.4.
Ability to trigger off alerts as reminders for
M
maintenance for assets
3.2.3.5.
Ability to register and track warranty
M
information
Ability to associate a fixed asset with a

3.2.3.6.
regional office and/or lower organization-
M
entity and calculate depreciation expense
accordingly
3.2.3.7.
The system provides the ability to store
M
manufacturing information

3.2.3.8.
The system provides the ability to store
M
supplier information.
3.2.3.9.
The system provides the ability to track to
O
what system a piece of equipment belongs to
The system provides the ability to track the

3.2.3.10.
asset installed dates, removed dates, original
M
costs, life-to-date repair costs, current
replacement costs.
The system provides the ability to allow for

3.2.3.11.
componentization of an asset (apply different
M
depreciation methods for different
components of a major asset)
B: Asset Movement Management
The system should have the functionality to

request for and get approval of an asset
3.2.3.12 M
movement/transfer from one location to
another

3.2.3.13 monitor the asset movements within M
TAWSB
Provide facility to generate asset movement

forms when asset is moved and identify
3.2.3.14 M
current location and current user (whenever
it is applicable)

Ability to facilitate inter-branch / inter-

3.2.3.15 M
department asset issues and transfers
Ability to facilitate inter-branch / inter-

3.2.3.16 M
department asset receipts
Reporting Requirements for Asset Movement Management

3.2.3.17 produce standard reports on the asset M
movements within TAWSB
C: Asset Maintenance Management

The system must be able to maintain an
3.2.3.18 M
Asset Maintenance budget

manage Preventive maintenance. It should
have the ability to:
• Define PM (preventative
maintenance) parameters per asset
• Define PM inspection schedules per

asset
3.2.3.19 • Capture PM inspection feedback M

reports per asset
• Capture PM actions carried
• Update PM next inspection date
• Capture the team (internal or

outsourced) scheduled to carry out the PM

• Track all stock items issued

towards the asset maintenance work order
• Track all outsourced service orders

issued towards the asset maintenance

manage Breakdown Maintenance. It should
• Capture BM (breakdown
maintenance) reported per asset
• Capture BM inspection feedback

reports per asset
• Capture BM actions carried
• Define PM next inspection date

3.2.3.20 M
• Define the next PM actions

outsourced) scheduled to carry out the BM
• Track all stock items issued towards

the asset maintenance work order



manage Corrective Maintenance. It should
• Capture CM (corrective maintenance)

reported per asset
• Capture CM inspection feedback

reports per asset
• Capture CM actions carried

3.2.3.21 M

outsourced) scheduled to carry out the CM



manage Time Based Maintenance. It should
3.2.3.22 M
• Capture TBM (Time Based

• Capture TBM inspection feedback

reports per asset
• Capture TBM actions carried

outsourced) scheduled to carry out the TBM
• Track all stock items issued

towards the asset maintenance work order


manage Condition Based Maintenance. It
should have the ability to:
• Capture CBM (Condition Based

3.2.3.23 M
• Capture CBM inspection

feedback reports per asset
• Capture CBM actions carried



outsourced) scheduled to carry out the CBM


The system should have the functionality for

the estimation of work order costs, and
3.2.3.24 M
ensuring that costs incurred are sent to the
appropriate location in budget module
Ability for creating task lists, assigning

3.2.3.25 M
materials, and creating maintenance plans
Manage data on maintenance availability

3.2.3.26 (the contractor) including dates, rates and M
attachable documents.
Identify important dates in operations

3.2.3.27 (maintenance deadlines, stages and M
conditions).
Create individual reports for presenting data

3.2.3.28 M
on operations and maintenances

Inform corporate users, partners or service

3.2.3.29 providers on changes in maintenance O
progress schedule.

initiate an asset repair (i.e. to be carried out
locally or overseas) request from the
3.2.3.30 M
workshop, track repair progress, inspect the
repaired asset before accepting back (or
rejecting).

3.2.3.31 M
have standard asset repair reports
The fixed assets module must be able to

maintain a history of changes to fixed assets
and be able to track all the changes
including:
3.2.3.32 M
• Maintain the maintenance record of
an asset
• Maintenance costs
• Maintenance dates
The fixed asset module should be able to

3.2.3.33 M
allow for ad hoc inquiry of an asset’s history
Reporting Requirements for Asset Maintenance Management

Provide reports on:
3.2.3.34 • PM scheduled, conducted on time, M

conducted after due date, and not yet done

• Per selected
period/department/organisation unit
actions carried out under:
• PM
• CM
• BM
• TBM
• CBM
• Per selected period/department/

organisation unit the costs incurred under:
• PM
• CM
• BM
• TBM
• CBM
The system should generate the following
reports:
• Assets beyond their useful life
• Assets that have been maintained over

3.2.3.35 a select period M
• Assets with maintenance costs over a

select threshold
Assets with +/- maintenance budget balances
The system should be able to generate the

3.2.3.36 M
following work order reports:

• How many work orders in a certain

time period were scheduled or non-scheduled
• How many work orders in a certain

time period by reason, subassembly and/or
repair type
• Open work orders by type, by status

(pending, waiting parts, etc. ), by location,
and/or by asset category
The system should be able to generate the

Asset/Equipment downtime report by
summary or detail by user defined periods
3.2.3.37 for: M
• Each location
• Cost centre
• Asset Category
D: Asset Disposal Management
Ability for creating annual/ad hoc disposal
3.2.3.38 M
plans

3.2.3.39 M
manage different types of asset disposals

3.2.3.40 manage asset disposals through Sale by M
Public Tender process


3.2.3.41 manage asset disposals through Sale by M
Public Auction process

3.2.3.42 manage asset disposals through Donation M
process

3.2.3.43 manage asset disposals through Trade-In M
process

3.2.3.44 manage asset disposals through Waste M
Disposal process
Ability to mark assets, in the approved

3.2.3.45 disposal plan, for disposal as well as readmit M
assets back into the assets listing.
Ability to calculate and create automated

journals and reverse accumulated
3.2.3.46 M
depreciation at the time of sale, scrap, and
retirement of asset
The system should have the functionality for

the estimation of disposal costs, and ensuring
3.2.3.47 M
that costs recovered are sent to the
appropriate location in budget module
3.2.3.48 Interface to HR/GL/Assets/Inventory/etc. M


Manage all asset disposal related data

3.2.3.49 including dates, rates and attachable M
documents.
Allow for the management of important

3.2.3.50 dates in the asset disposal plan (deadlines, M
stages and conditions).
Create individual reports for presenting data

3.2.3.51 M
on asset disposal
The system must enable various departments

to develop their disposal plans for the year
3.2.3.52 whose view can be broken down to enable M
viewing as per various periods e.g. month-
on-month, week-on-week, etc.
Consolidation of disposal plans of various

3.2.3.53 departments into a single disposal plan and M
vice versa
Ability to print both a summarised and a

3.2.3.54 M
detailed view of the disposal plan
Have a workflow for disposal plan

3.2.3.55 M
preparation and approval
Enable the attachment of documentation to

3.2.3.56 disposal plans submitted by departments and M
avail the same during consolidated viewing

The system must be able to address the

requirement of updating the disposal plan on
3.2.3.57 M
a periodic basis by having an inbuilt
workflow for updating the disposal plan
Ability to track disposal requisitions against

3.2.3.58 the disposal plan at departmental level and M
company-wide level
The system should be able to allow

3.2.3.59 M
categorization of disposal plan requests
The system should be able to set alerts with

3.2.3.60 respect to initiation of disposal plans M
preparation
Reporting Requirements for Asset Disposal Management
The system should have a functionality that

allows one to generate a number of different
standard reports, including:
• Current asset tagging listing (i.e.

Asset No., Tag No., tag date, goods receipt
3.2.3.61 No., etc. ) M
• List of fixed asset transferred between

locations or custodian during the period
• List of newly added fixed asset


• Assets disposed during the period

indicating the reserve disposal price,
actual disposal price, and variance
• Assets earmarked for disposal listing
All these reports can have their layout

changed and have fields included / excluded
depending on the users’ needs.
E: Asset Accounting
The system must be able to perform fixed

3.2.3.62 assets registration. The registration should M
be from the procurement/AP process.

relevant asset accounting details including:
• An asset serial No.

• Asset tag (Barcode)
• An asset to be uniquely identified

3.2.3.63 M
• An asset classification(s)
• An asset to be adequately described
• The status of the asset to be

monitored (whether active, suspended, or
disposed)

• Impact on the depreciation

accounts (balance sheet and profit & loss)
when different periods are selected
• The location and holder

(responsible person) of the asset to be
determined and transfers to be recorded
• Quantity and value of fixed assets per

category and in summary to be determined
• Categorisation of fixed assets
• Depreciation value to be computed

using various methods and parameters
• Fixed asset details to be retrieved

such as cost, useful life, salvage value,
date of commissioning, etc.
• Warranty & licensing information to

be captured
• Inspection data to be recorded

(tagging)
• Revaluation
• Impairments

The system should have flexible reporting

functionality that enables one to extract any
3.2.3.64 information above as a report. It should have M
a report on assets whose residue book value
is fully depreciated.

3.2.3.65 assets disposal through a workflow. This M
disposal may be a full or partial disposal.

3.2.3.66 assets depreciation with options for using M
different depreciation methods
The system must be able to post fixed assets

3.2.3.67 M
ledger entries to the general ledger
Provide an option for performing

3.2.3.68 depreciation of different currencies with M
different exchange rates
Automated calculation of net book value and

3.2.3.69 M
gains/loss of asset value
The system should allow for revaluations of

3.2.3.70 M
fixed assets
Ability to automatically check and stop

depreciation on reaching the user defined
3.2.3.71 M
residual values for assets or predefined
service years

Provide facility to account for the

retrospective change in depreciation rate/
3.2.3.72 method (i.e. calculate depreciation for prior M
periods as per revised depreciation
rate/method)
Provide facility to distribute depreciation

3.2.3.73 expenses among reporting units & M
department
Ability to handle impairment of fixed assets

3.2.3.74 M
and its accounting treatment
Ability to permit accounting of sale of fixed

3.2.3.75 M
assets as per statutory requirements
Reporting Requirements for Asset Accounting
The system should have a functionality that

allows one to generate a number of different
standard reports, including:
• Fixed assets register
• Fixed asset valuation report
3.2.3.76 • Fixed asset deprecation report M
• Fixed asset reports by asset type and

other asset category
• Depreciation forecasting report
• Accumulated depreciation list by

category by Location

• List of fixed asset transferred between

locations or custodian during the period
• List of newly added fixed asset
All these reports can have their layout

changed and have fields included / excluded
depending on the users’ needs

3.2.4 Procurement Management System Requirements
A: Formulation of procurement plan

3.2.4.1.
Ability for creating annual/ad hoc
M
procurement plans
3.2.4.2. The system to allow for procurement plan

approval based on the set thresholds for the M
different approvers in the work flow process.

The system must enable various departments

3.2.4.3. to develop their procurement plans for the
year whose view can be broken down to M
enable viewing as per various periods e.g.
month-on-month, week-on-week, etc.
3.2.4.4.
Automatic confirmation of procurement
M
plans against departmental budget
3.2.4.5. Consolidation of procurement plans of

various departments into a single M
procurement plan and vice versa
3.2.4.6.
Ability to print both asummarised and a
M
detailed view of the procurement plan
3.2.4.7. Have a workflow for procurement plan

preparation and approval by the relevant M
approvers.
Enable the attachment of documentation to

3.2.4.8.
procurement plans submitted by departments
M
and avail the same during consolidated
viewing
Enable the attachment or association of

3.2.4.9.
requisite documentation associated with each
M
procurement plan submission where
necessary

The system must be able to address the

3.2.4.10.
requirement of updating the procurement plan
M
on a periodic basis by having an inbuilt
workflow for updating the procurement plan
3.2.4.11. Ability to track requisitions against the

procurement plan at departmental level and M
company-wide level
3.2.4.12. The system should be able to allow

procurement personnel to group procurement M
plan requests into categories
3.2.4.13. The system should be able to set alerts with

respect to initiation of procurement plans M
preparation
Formulation of procurement plan – Reporting

3.2.4.14.
Ability to track and report on purchasing
M
trends against the procurement plan
3.2.4.15. Procurement Plan implementation report

based on a defined criteria e.g. per period, M
department e.t.c
B: Registration/Prequalification of suppliers
3.2.4.16 The system must support the registration and
M
prequalification of suppliers
3.2.4.17 The system must support an on-line supplier

portal that shall allow interaction between M
suppliers and C

The suppliers should be able to:
• Track on-line the status of their

procurement documents (e.g. order, invoice,
etc.).
• Maintain supplier information (e.g.

Contacts, bank details, etc.)
• Register as a supplier and submit bids and

seek clarifications pertaining to open bids.
Embed a workflow for the supplier

3.2.4.18 registration and prequalification process and
M
capture approvals and comments associated
with this process
Should be able to capture the following

supplier details and maintain a central
repository (supplier master database):
• Supplier number (auto-generated)
• Supplier type
• Category of service
3.2.4.19 • Items / services supplied M
• Supplier’s name
• Multiple supplier addresses
• Office address
• Physical location
• Nature of business
• Telephone
• E-mail address
• Trade licence no

• Certificate of incorporation/registration
• Registration no. & date

• Business Permit/License Number
• County of Operation
• Tax compliance certificate number
• Tax compliance certificate valid to date
• VAT Certificate
• VAT number
• PIN Certificate
• PIN number
• Details of directors (name, nationality,
shares)
• Share capital
• Name of bankers
• NSSF Compliance Certificate
• NHIF Compliance Certificate
• Certificate of Good Conduct
• Youth Access to Government Procurement

Opportunities (YAGPO) Certificate
• Maximum value of business which can be

handled by your firm at any given time
• Bank details
• Supplier status
(Active/Inactive /Blacklisted)
• Comments on the supplier

• Ownership/directorship of the company
The system must allow users in the

procurement department to change the status
3.2.4.20 of a successfully registered or prequalified M
supplier to various status e.g. active to
inactive/blacklisted/suspended and vice vers
Allow sharing of supplier data in the central

3.2.4.21 M
repository.
Detection of duplicate suppliers based on

unique multiple supplier identification
3.2.4.22 M
number such as PIN, Internal TAWSB
reference numbers, etc.
For suppliers with more than one location, the

system should be able to capture all the
3.2.4.23 M
alternate locations of the supplier under one
profile (belonging to the supplier).
Enable the attachment of documents to

supplier prequalification tasks e.g. tender
3.2.4.24 advertised, supplier responses, filled business M
questionnaire, prequalification document,
etc.
The system MUST be able to block the

3.2.4.25 M
supplier's who have been debarred
The system MUST be able to unblock the

3.2.4.26 M
supplier by appropriate authority

The system MUST be able to record

3.2.4.27 M
complaints about the supplier.
The system MUST maintain a list that shows

3.2.4.28 M
the items supplied by different suppliers.
The application MUST facilitate assignment

3.2.4.29 of different items/products to a supplier upon M
prequalification/registration.
Registration/Prequalification of suppliers – Reports
The system should maintain Purchases Year

3.2.4.30 to Date (YTD) in number and currency per M
supplier
The system MUST support reporting of

supplier performance analysis in a given
3.2.4.31 M
period e.g quality defects, delivery
performance, cost/price amongst others.
The system MUST support reporting of

supplier performance in a given period e.g
3.2.4.32 M
Price, quality, delivery, rejected items in
number and currency amongst others.
The system MUST support generation of a

3.2.4.33 M
report on shortlisted suppliers

3.2.4.34 report on status of supplier prequalification
process.


report history of bidders who have been given
work many times (to promote fairness). The
report should have the following details:
3.2.4.35 M
• Name of supplier
• Date of award
• Nature of work
• Value of work
• Date of prequalification
The system MUST support generation of

3.2.4.36 M
reports for supplier company ownership
The system MUST support generation of

3.2.4.37 historical information on purchase M
order/contract cancelled by Company, if any
C: Tendering and Requests for Quotations
The system must be able to capture the

following tender details. At a minimum,
these details are:
• Tender number
• Name / description of service, goods or
3.2.4.38 works M
• Tender submission format e.g. combined
technical and financial proposal
• Location of the bid document e.g. on

website or obtained from procurement office

• Tender submission location
• Deadline for tender submission
• Date of tender opening

• Bid bond
• Handling fee & mode of submission

(banker’s cheque, cash, insurance bond, etc )
• Tender evaluation results (both technical

and financial results)
• Currency of the quotations

• Tender Validity period
• Tender document (specifications, terms &

conditions, etc. )
• Status (Evaluation, under negotiation,

awarded, advertised, etc. )
• Value of tender/quotation
• Name of bidder
• Number of tenders issued
• Responder details: Name of responders,

value, technical and financial scores, etc.
• Location of the suppliers

• Performance bond value
• Expected date of start and completion
• Source of funds/budget availability for the

tender
• User department

• Date of contract signage

• Nameofpersonssigning the
contract/signatories
• Date of advertisement
• Date of tender award
• Method of tender procurement (direct

procurement, open tender, restricted, etc.)
• Reasons for using the method of

procurement
• Persons who approved the tender
• Tender termination details: tender number,

reasons for termination
The system should support the generation of

3.2.4.39 tender number for the different types of M
tender
The system must be able to print out the

3.2.4.40 tender details above for purposes of M
advertisement and reporting

3.2.4.41 manage procurements throughOpen M
Tendering process

3.2.4.42 manage procurements through Request for M
Proposals process


3.2.4.43 manage procurements through Request for M
Quotations process

3.2.4.44 manage procurements through Restricted M
Tendering process

3.2.4.45 manage procurements through Direct M
Procurement process

3.2.4.46 manage procurements through Low Value M
Procurement process

3.2.4.47 manage procurements through Design M
Competition process

3.2.4.48 manage procurements through Electronic M
Reverse Auction process

3.2.4.49 manage procurements through Framework M
Agreements process

3.2.4.50 manage procurements through Force Account M
process


3.2.4.51 manage procurements through Two-Stage M
Tendering process
For all the above tendering processes, based

on the Procurement Plan, it should then
provide reminders (to user departments and
3.2.4.52 M
procurement department) within a pre-
defined advance period to initiate tender
requests.
The value based on which the system

determines whether an RFQ or a tender is
3.2.4.53 M
needed should be configurable as per the
procurement method.
The system should support the RFQ process

by providing a workflow that allows
procurement division to:
• Receive purchase requisitions from the

user department
• Convert the purchase requisition into an

RFQ if it is less than a certain amount
3.2.4.54 M
• Allow prequalified suppliers to be selected.
• Automatically send the RFQ to the selected

suppliers via email or allow for printing
• Convert an RFQ to the procurement

department’s purchase requisition

• Convert the procurement department’s

purchase requisition to an LPO upon approval
• Email the approved LPO to a supplier.
The workflow must be able to clearly capture

all approvals that have taken place.
Provide functionality for evaluating and

3.2.4.55 ranking supplier responses to an RFQ so as to M
determine the lowest quoting vendor.
For each RFQ sent, the system should be able

to capture the following details:
• RFQ reference number

3.2.4.56 • Description of service
M
• Names of suppliers to whom the RFQ was
sent
• Name of responders
• Prices quoted
• Results of evaluation
• User defined comments
Ability to keep track of the tender evaluation

process and stages through the process
3.2.4.57 including:
M
• Tender opening:
• Technical evaluation
• Financial evaluation

• Management of tender opening/evaluation

committees
• Supplier notification
The management tender opening/evaluation

3.2.4.58 committee’s access rights are only valid for
M
the duration the tender is active or their
appointment is active.
3.2.4.59 Ability to track timelines for each stage of the

M
procurement process
Ability to maintain documents associated

with the tender process such as:
3.2.4.60
• Minutes of opening of tenders M
• Evaluation reports
• Contracts
• LPOs
Ability to create a "single "contract number

per physical contract that can be utilized
3.2.4.61 M
across all operations of the ERP, and other
TAWSB systems.
Create standardized contracts quickly and

3.2.4.62 easily by utilizing standard menus, lists and M
auto-fills for population of contract dat
Need to have the ability to create contracts

3.2.4.63 M
using standard terms and clauses.

The system supports required fields to avoid

3.2.4.64 M
missing information
The system differentiates between

3.2.4.65 M
prospective and existing vendors.
Allow special item products to be defined as

3.2.4.66 M
needed
The system should have the ability for

contract specialists to document the products
3.2.4.67 M
covered by the contract. This should include
general and specific product information.
Build mechanisms for pricing and service-

3.2.4.68 M
level agreement flexibility into the contract.
Support for document management to

maintain a tender library of templates and
sample documents for the various elements
3.2.4.69 of a tender including tender terms and M
conditions, draft contract terms and
conditions, specifications and related
documents
Ability to track timelines associated with

3.2.4.70 each stage in the contract process and flag M
where these are exceeded

Ability to track status of bid bonds. Bid

3.2.4.71 bonds for unsuccessful bidders should be M
returned when sending regret letters.
Tendering and Requests for Quotations – Reporting
The system MUST be able to generate reports

3.2.4.72 M
on tenders in the pipeline and their status

on status of the tendering process e.g. contract
3.2.4.73 M
being drawn, awarded, evaluating,
advertised, etc.

3.2.4.74 on a list of tenders whose submission dates M
were extended.

on a list of RFQ sorted by different criteria
3.2.4.75 M
e.g. RFQ number, supplier, material group,
material/product e.t.c

3.2.4.76 M
on a price comparison list for RFQs

on a summary of tender awards by
3.2.4.77 M
procurement method, value, reserved tenders
e.t.c

The system should generate reports on the

responsiveness in a particular period e.g.
3.2.4.78 M
How many responsive/unresponsive tenders
in a particular period.
The system should generate a list of tenders

3.2.4.79 M
that have been terminated.
D: Purchase requisition and Purchase Order Management
Embed a workflow for the purchase

requisition process and capture approvals,
3.2.4.80 M
comments and documentation associated
with this process/task.
The system should allow for requisition

3.2.4.81 approvals based on the set thresholds for the M
different approvers in the work flow process.
Avail online a purchase requisition form for

business end users for raising purchase
requisitions to the procurement department.
The purchase requisition form should capture
the following details:
• Department and division raising the request

3.2.4.82 M
• Requisition date
• Description of the item requested
• Quantity of items
• Reasons for purchase
• Technical specifications (e.g. SoW, ToR,

engineering specifications, etc)

• Budget code
• Budget availability (this should be the

funds available as at the time of making the
requisition)
• Name of requestor
• User manager/departmental/divisional
approval
• Date of approval
Once the purchase requisition is submitted to

procurement, the procurement departments
should be able to input extra data that will
enable the requisition to be converted to a
Purchase Order:
• Name of suggested supplier
• Address of suggested supplier
• Quantity & unit of measure

3.2.4.83 M
• Description/quality of goods
• Costs
• Name of alternative supplier
• Address of alternative supplier
• Delivery address
• Delivery date of goods
• Deadline of submission of the
quotation/tender
• Discount (percentages, amount)


• VAT
• Tender/quotation number
3.2.4.84 The system should have provision for raising

M
purchase requisition in foreign currency
The system should have a workflow that

allows the following to be carried out when
raising a purchase requisition:
• Enables verification of the requisition

against departmental budget so as to confirm
the availability of funds
3.2.4.85
• Capturing approval/rejection of the M
requisition by the user manager and
departments/divisional head
• Verification by finance that the budget code

has been allocated correctly
• Computation of departmental budget

balance following the final approval of the
purchase requisition

The workflow for raising a purchase

requisition must be set up such that approval
3.2.4.86 of the budget code associated with a purchase M
requisition is subjected to the approved
procurement plan and the available budget
The system should be able to perform funds

3.2.4.87 M
reservation for budgeted items
For purchase requisitions that have been

3.2.4.88 rejected, the system must be able to release M
the commitment of funds
The system must automate the raising of

purchase requisition for stocked and non-
3.2.4.89 M
stocked goods, and services from short listed
suppliers
The system MUST capture the following

details for Purchase order header
• PO Number
• PO description
• PO type (maintenance & repair , one time
3.2.4.90 purchase, and service contract) M
• Description
• Requestor ID
• Supplier & Site
• Priority
• Comments
• Ship to address

• Terms (FOB, C&F, ...etc)
• Payment term
• Fully /Partially shipments
• Supplier terms
• P.O date
• Expiry Date
• Extension date
• Total value of the PO/Contract
• Quantity
And any other necessary details for a PO
The system SHOULD be able to print the PO

information with company logo only once as
3.2.4.91 M
an original copy. The re-print option
SHOULD indicate duplicate copy.
The system must have a workflow for

3.2.4.92 generation / raising of local purchase orders M
following approval of purchase requisition
Ability to record purchase order

3.2.4.93 M
acknowledgement from vendor
The system should be able to generate Local

3.2.4.94 M
Service Orders (LSO) through a workflow.
System should automatically generate an alert

3.2.4.95 if acknowledgement is not received within a M
specified time from PO issue date

All LPOs and LSOs generated should include

terms and conditions; the system should
3.2.4.96 M
allow for the definition and maintenance of
the terms and conditions.
The system shall allow an authorised user to

3.2.4.97 change shipping, payment method for a M
purchase order
Ability to merge several requisitions into a

3.2.4.98 M
single purchase order
The system shall notify the user about any

3.2.4.99 M
changes made to the order.
Confirmation of item stock levels prior to

3.2.4.100 M
raising a purchase requisition
The system should have a workflow for

processing Purchase Requisitions where:
3.2.4.101 M
• The supplier and prices have been
identified
• The supplier and prices have not been
identified

approvals related to the purchase requisitions.
These include:
3.2.4.102 M
• Electronic signoff/approvals at the user
department level (name, department,
division, date of approval)

• Approval references such as referencing to

tender deliberation minutes, etc.
• All approvals on the system must be clearly

captured.
The system should have provision for raising

3.2.4.103 M
purchase requisition for recurring services
The system should have provision for raising

purchase requisition for recurring services
3.2.4.104 M
that do not issue an invoice such as invoices
from utility companies, etc.
The system should be able to provide for

3.2.4.105 M
supplementary LPOs and PRs
System should be able to support

procurement of different services i.e. fixed
3.2.4.106 M
rate contract service/fixed rate temporary
labour/rate based temporary labour
Manage the entry of Service Entry Sheets i.e.

3.2.4.107 the acknowledgement of the of services M
received against an PO or Contract

System is able to show Inco terms and display

clearly the inco terms with selection options
3.2.4.108 for Countries and their city (s). the final M
output on PO should be e.g. Free On
Board(FOB)
Ability of the system to carry out price

3.2.4.109 M
trending per item and units of services
Ability of the system to track the total cost

Ownership for projects. The system to
provide traceability of all cost relating to
3.2.4.110 M
initial acquisition, installation,
maintenance/support as well as disposal
/residual value especially for projects.
Ability of the system to provide flex fields for

3.2.4.111 M
end user acceptance of goods and comments
Ability of system to generate material

3.2.4.112 requests from vendors for consignment M
stocks, based on the set up min-max levels.
Ability to have the material requests for

consignment stock generated go through an
3.2.4.113 M
approval process and a purchase order created
from them.
Ability of the system to allow for multiple

3.2.4.114 M
line description per item

• Processes multi-item type Pos
The system should be able to process POs

3.2.4.115 M
with multiple ship-to locations
The system Checks for duplicate Purchase

3.2.4.116 M
order numbers
Purchase order numbers to be system

3.2.4.117 M
assigned
System should allow reprint of PO with 'copy,

3.2.4.118 amendment no., reprint' marked on the print M
out
Ability to enter project details while creating

3.2.4.119 purchase order and interface the details to M
project
Ability to print purchase order terms and

3.2.4.120 M
conditions
Ability to allow authorised users to track

3.2.4.121 status of approval their purchase requisitions M
and related purchase orders
Ability to restrict information that end users

3.2.4.122 should view in the procurement process such M
as vendor awarded
Ability to enforce requirement for a contract

3.2.4.123 M
based on the nature of items/service or value
Purchase requisition and Purchase Order Management- Reporting


The system MUST Provide a report of all

3.2.4.124 M
requisitions for a specific Period.
The system MUST provide a report of all

3.2.4.125 pending requisitions as at a certain date M
showing how long they have been pending
The system MUST generate reports on

3.2.4.126 Frequency and volumes purchased and M
seasonal trending of items
The system MUST generate reports on a list

3.2.4.127 M
of open purchase orders
The system MUST generate reports on open

purchase order cost centre wise, which can be
3.2.4.128 M
used to review the open purchase order
relating to one or more cost centres.

overdue supplies, which can be used to
3.2.4.129 M
follow-up with suppliers for the material to be
supplied.

Purchase order commitment, which is used to
3.2.4.130 M
show the monetary value of the purchased
commitments for the specified period.


Purchase order detail showing the details of
all type of purchase orders specified by the
3.2.4.131 M
user. It MUST display the quantity received
against the purchase order so that one can
monitor the status of the purchase order
E: Goods/Services Receipts and Inspections
The system allows for the receipt of goods,

3.2.4.132 services, works, repaired items, inter stores M
transfers, etc.
The system automates generation of Goods

3.2.4.133 Received Note (GRN) that must be associated M
/ matched with an open Purchase Order(s).
The system allows for full or partial receipts

3.2.4.134 M
against a purchase order or contract
The system must allow for the inspection of

3.2.4.135 M
goods/services/works
The system must allow for ad hoc set up of

3.2.4.136 M
the Inspection and Acceptance Committee
The system must be able to capture the

3.2.4.137 Inspection and Acceptance Committee M
reports after a workflow approval process

The system must be able to address situations

3.2.4.138 where the goods have been received but needs M
to be returned to the supplier.
The system should be able to provide alerts to

3.2.4.139 key stakeholders on attainment of certain M
GRN status
Allow for invoicing only for an approved

3.2.4.140 M
GRN or for consolidated GRNs
The system has the ability to support one time

3.2.4.141 M
vendors
The system has the ability to maintain

3.2.4.142 approved supplier catalogue/ lists for M
inventory items
Goods/Services Receipts and Inspections – Reporting
The system has the ability to generate reports

3.2.4.143 on pending PR/PO supplier-wise, item-wise M
and department-wise
The system should be able to support the

3.2.4.144 M
production of standard goods receipts reports
F: Stores Management
F1: Inventory Item
The system MUST allow the definition of

3.2.4.145 new Item without affecting the ongoing M
processes.

The system MUST allow the definition and

3.2.4.146 maintenance of alpha numeric character M
codes for items
The system MUST allow the definition of all

3.2.4.147 M
the inventory items at one master location.
The system MUST allow the definition of

3.2.4.148 item templates with predefined set of item M
attributes
The system MUST capture following

important information for each Item:
Item Number/code (alphanumeric)
Item description (brief information)
Unit price
Minimum stock quantity, maximum stock
quantity
3.2.4.149 Safety stock level, re-order stock quantity M
Last stock date, last stock quantity
Cycle count code

Physical attributes such as weight, volume,
length e.t.c
Lot number, serial number, bar code number
Supplier information, country of origin
Expiry date, purchase date


The system MUST allow the definition of the

following inventory types inside the
3.2.4.150 M
application e.g. Discrete Items and fluids,
Serial numbered items e.t.c
The system MUST have an ability to define

3.2.4.151 new Item categories and Catalogues based on M
their characteristics
The system MUST allow the assignment of

3.2.4.152 Inventory items to one of these categories and M
catalogues defined
The system allows for the issuance of goods,

3.2.4.153 M
inter stores transfers, etc.
The system automates generation of Goods

3.2.4.154 Issue Note that must be associated / matched M
with a stores requisition note.
The system allows for full or partial

3.2.4.155 issues/receipts against a stores requisition M
note or contract
Ability of the system to enable creation and

3.2.4.156 M
maintenance of approved items price lists
Ability of the system to enable creation and

3.2.4.157 M
maintenance of supplier items catalogues

Ability of the system to create Electronic

3.2.4.158 M
Catalogue for all items /Services
The system allows for the receipt of goods to

3.2.4.159 M
a specific location in the store
The system must allow for the issuance of

3.2.4.160 M
goods from a specific location in the store
The system must allow for the generation of:
• stores issue notes

3.2.4.161 M
• stores receipt notes
• goods in transit notes
• prove of delivery notes
The system has the functionality that allows

3.2.4.162 different movements of stock items from one M
store location to another
The system has the functionality to close a

3.2.4.163 M
store for stock take purposes
The system has the functionality to open a

3.2.4.164 M
store after a stock take
The system has the ability to create a new

storage location including:
3.2.4.165 M
• A new store
• A new stock room
• A new bin location
The system has the ability to retire an existing

3.2.4.166 M
storage location including:

• A store
• A stock room
• A bin location
Inventory Item – reporting
The system can generate, per storage

location, the store movement reports
including:
• Current stocks (Value and Quantity reports,

reorder level, balance to reorder level, etc.)
• Receipts per a selected period (Value and

Quantity reports)
• Issues per a selected period (Value and

Quantity reports)
• Transfers ((Value and Quantity reports))

3.2.4.167 M
• Damaged stocks (Value and Quantity
reports)
• Expired stocks (Value and Quantity
reports)
• ABC analysis Report: this report gives

information classifying all the items available
based on their importance and value.
Item Overhead Report: Each item is
associated with some overheads before it
is actually consumed. It can be storage,
processing, transportation and packaging.
This report will give overhead details for
given set of items including cost
associated with the same.
• Item categories Report


• Stock issuances
• Per user
• Per department/division
G: Inventory maintenance
Embed a workflow for the receipt/rejection of

inventory (including related procurement and
stores movements) and capture approvals,
3.2.4.168 M
comments and documentation associated
with this process/task and updating of the
inventory data
Automatic updating of inventory levels and

3.2.4.169 balances after issuance/reception of inventory M
(stocked items and services)
Valuation of stock: The following options

must be available for calculating the unit cost
of a good in the store:
3.2.4.170 • Last In First Out (LIFO) M
• First in First Out (FIFO)
• Simple average
• Weighted average
The following details should be captured for

updating the stock levels:
• Item / part number

3.2.4.171 M
• Item name
• Inventory type/category
• Item description
• Stock date

• Comments
• Goods Receipt Note (GRN) number
• Delivery note number

• Quantity in
• Cost of items
• Quantity out
• Expiry date
• Supplier number (referenced to the supplier

master data in the procurement module)
• Supplier name (referenced to the supplier

master data in the procurement module)
Allow the receiving of inventory both at once

3.2.4.172 M
and partially
Should maintain a central access-controlled

3.2.4.173 M
items master database
The system must give alerts and notifications

3.2.4.174 when stocks are at the re-order level and on M
expiry dates
Embed a workflow for the disposal of items

(fixed assets and store items) and capture
approvals, comments and documentation
3.2.4.175 M
associated with this process/task and updating
of the information in the fixed asset register
or inventory.

Support the identification of items for

disposal both manually and through
3.2.4.176 M
preconfigured rules e.g. expired, useful life
exhausted, damaged, etc.
3.2.4.177 Automatic generation of disposal codes M
Inventory maintenance – Reporting
The system must have provision for

3.2.4.178 extracting any or all of the information above M
as a report.
H: Stock takes
The system should be able to generate a Stock

3.2.4.179 M
take count lists
Allow the manual stock verification stock

counts capture by the system, reconcile the
3.2.4.180 M
physical count against the system count and
produce a variance report
The system should allow for the different

actions to be carried out to address the
3.2.4.181 identified variances (e.g. adjustments of the M
system values, or capture of missing store
movements, etc.)
The system should allow for approval of the

3.2.4.182 M
stock take through a workflow process

The system should allow for the following

types of stock takes:
• Annual stock take

3.2.4.183 M
• Periodic stock takes
• Ad hoc stock takes
• Select (e.g. Fast moving items, etc.) stock
takes
The system should have the ability to stop,

complete, approve/cancel, and/or suspend the
3.2.4.184 M
movement freeze the stock movements
during the period of stock take.
The system should allow for scheduled stock

3.2.4.185 M
takes alerts
The system should have the ability to set up

3.2.4.186 an ad hoc Stock take and Physical O
Verification Committee
The system should have the ability to set up

access rights to the ad hoc Stock take and
3.2.4.187 M
Physical Verification Committee for only the
duration of the stock take
The system should have the ability to carry

3.2.4.188 out the stock take for a section or stock room M
of the store

The system should have the ability to

3.2.4.189 generate all standard reports with respect to M
stock takes
The system should allow for capture of stock

3.2.4.190 take notes/observations to accompany the M
physical counts
I: Additional Reporting requirements
In addition to providing a flexible reporting

mechanism, the system must be readily able
to generate the following reports:
3.2.4.191 • Value of store with options for calculating M

the value of the store
With items flagged for disposal
Minus items flagged for disposal
The Head of Procurement should have access

to a screen that provides him/her with an
update on the status of all workflows in
3.2.4.192 his/her department. The objective of this is to M
allow the procurement manager to have an
overview of the status of all requests and
activities of his department.

3.2.5 Project Administration and Accounting
A: Project Administration
The system is expected to provide fully

automated interfaces with the following
systems/modules:
3.2.5.1.
• Procurement module to receive supplier M
invoices
• Human Resources - Payroll and other

employee related transactions
The system should perform flexible

3.2.5.2.
budgeting for capital and operating projects
M
while adhering to level of budgetary controls
established in the General Ledger.
3.2.5.3. The system should have the ability to

differentiate transactions between operating M
and capital budget items.
The system should provide budget

3.2.5.4. forecasting for multi-year periods, which can
support development of a Capital M
Improvement Plan and an Operating Project
Improvement Plan.
3.2.5.5.
The system should allow for multiple fiscal
M
year budgets for projects.
3.2.5.6. The system should provide multiple

revisions and amendments to the budget in M
the above detail.

3.2.5.7.
The system should track projects over
M
multiple years.
3.2.5.8.
The system should track projects by budgets. M
3.2.5.9.
The system should allow users to create and
M
maintain project schedule templates.
The system should support the recording of

3.2.5.10 scanned supporting documentation and will
. link the document from the document M
management system (DMS) with the ERP
transaction.
B: Project Accounting
The system should be completely integrated

with other system modules to provide real-
time transactional information for
requisitions, contracts and labour
3.2.5.11 distributions. These modules include but are
. not limited to the following: M
Procurement
Payroll
3.2.5.12 The system should track both outsourced

M
contracts and in-house spending to a project.
3.2.5.13
The system should track multiple contracts to
. M
a single project

C: Project Budgets
The system should allow for inquiries into

3.2.5.14
project budgets, pre-encumbrances/
. M
encumbrances, revenues, and expenditures
at any level described above.
3.2.5.15
The system should access prior years' project
. M
cost.
3.2.5.16
The system should establish reimbursable
. M
budgets for projects.
3.2.5.17 The system should track Reimbursable

. budgets control expenditures available for M
project billing only.
3.2.5.18
The system should report actual project cost-
. M
to-date for the capital or operating budget.
Reporting Requirement for Project Administration and Accounting

3.2.5.19
The system should provide multiple levels of
. M
reporting
3.2.5.20
. M
3.2.5.21 Create customized reports (user defined).

. Users who perform this function will have to M
be trained on use of the tools
Following additional reports:

3.2.5.22 • Monthly budget reports
. • Quarterly budget reports M
• Reallocation reports
• Actual vs. Budget

• Year expenditure/revenue reports
• Annual budget reports

• Cost centre budget reports in user defined
period
• Performance contracting reports

Water TOR

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Water TOR

Hochgeladen von

Copyright:

Verfügbare Formate

Section VII – Purchaser’s Requirements 125

System Integrated Enterprise Resource Planning

Specific Product Name

Version and Release

Mandatory Detailed Explanation to

3.2.1 Financial Management System Requirements

A: General Ledger A1:

3.2.1.1 One must be able to define and maintain

The system should allow for the same

The system must provide for the use of

Mandatory Detailed Explanation to

The Chart of Account must provide for a

The accounting structure must be

Changes to the Chart of Accounts must

The system must be able to maintain

The system must be able to create/setup

Enable the viewing and extraction of GL

Ability to create profit and cost centres

The chart of accounts MUST be flexible

Mandatory Detailed Explanation to

The accounting structure MUST have

The application SHOULD facilitate

The system must be able to support

The application MUST have the

Reporting Requirements for the Chart of Accounts

Create customized reports (user defined).

3.2.1.18 Reports with the following parameters: M

Mandatory Detailed Explanation to

• Based on posting date, date of

The system must be able to support the

The system should allow one to upload

Able to translate amounts from

Mandatory Detailed Explanation to

Should be able to perform foreign

The application MUST support

The application MUST support

The application MUST support

Mandatory Detailed Explanation to

The application MUST maintain all

Reporting Requirements for Currencies

Dynamic reports with the provision for a

Create customized reports (user defined).

Reports with the following parameters:

• Foreign currency trends

• Currency loss/gain per transaction

• Currency loss/gain translation at

• Invoices/Credit Notes/Debit Notes

The application MUST provide a facility

Mandatory Detailed Explanation to

The application MUST restrict updates to

The system must be able to create and

The system must allow the holding of

The system must enable held journals to

For any transaction posted through this

When reversing a transaction, the system

The system should be able to handle

Mandatory Detailed Explanation to

The system must be able to maintain a

Establish an accounting system capable

Maintain a user defined period (in years)

A facility to enable enquiry on archived

The system must be able to

The system must be able to export

The application MUST have the