FUNCTIONAL SPECIFICATION DOCUMENT 2018 · PMS Performance Management System PPOA Public Procurement...

0

FUNCTIONAL SPECIFICATION DOCUMENT 2018

VIKTAS SACCO LTD

Viktas Sacco Ltd – Functional Specification Document 2018

1

Table of Contents

List of Acronyms ...................................................................................................................................... 5

1.0 INTRODUCTION ........................................................................................................................... 6

2.0 GENERAL REQUIREMENTS .......................................................................................................... 8

2.1 ACCOUNTING PACKAGE .......................................................................................................... 8

2.2 LOAN PORTFOLIO .................................................................................................................... 8

2.3 SAVINGS, DEPOSITS WITHDRAWALS AND SHARES ................................................................. 9

2.4 CUSTOMER INFORMATION ................................................................................................... 10

2.5 EXPANDABILITY AND INSTITUTIONAL GROWTH ................................................................... 11

2.6 FLEXIBILITY ............................................................................................................................ 11

2.7 USABILITY .............................................................................................................................. 14

2.8 REPORTING ........................................................................................................................... 14

2.9 COMPLIANCE STANDARDS .................................................................................................... 16

2.10 ADMINISTRATION AND SUPPORT ......................................................................................... 16

2.11 FAULT TOLERANCE AND ROBUSTNESS ................................................................................. 17

2.12 END OF PERIOD PROCESSING ............................................................................................... 17

2.13 SUPPORT INFRASTRUCTURE, MAINTENANCE AND UPGRADE STRATEGY ............................ 18

2.14 TECHNICAL SPECIFICATION ................................................................................................... 18

2.15 PRICING AND COSTS.............................................................................................................. 19

3.0 FINANCE DEPARTMENT ............................................................................................................ 20

3.1 THIRD PARTY CHEQUES TO SUPPLIERS ................................................................................. 20

3.2 PETTY CASH PROCEDURES .................................................................................................... 22

3.3 BUDGETS ............................................................................................................................... 23

3.4 BUDGETARY CONTROL .......................................................................................................... 25

3.5 GENERATION OF SASRA REPORTS ........................................................................................ 26

3.6 BANK/ATM/PAYBILL/MOBILE BANKING RECONCILIATION ................................................... 27

3.7 REPORTING ........................................................................................................................... 29

3.8 GENERAL LEDGER .................................................................................................................. 31

3.9 IMPREST PROCEDURES ......................................................................................................... 37

3.10 MPA (MEMBER PERSONAL ACCOUNT) RECONCILIATION .................................................... 39

3.11 LIQUIDITY MANAGEMENT .................................................................................................... 41

3.12 OVERDRAFTS MANAGAMENT ............................................................................................... 41

3.13 LOAN PRODUCT PRICING ...................................................................................................... 42

3.14 FOSA SHARES ........................................................................................................................ 43

4.0 CREDIT DEPARTMENT ............................................................................................................... 44


2

4.1 LOAN REGISTRATION ............................................................................................................ 44

4.2 LOAN APPRAISAL ................................................................................................................... 46

4.3 LOAN DISBURSEMENT ........................................................................................................... 47

4.4 DEBT COLLECTION ................................................................................................................. 48

4.5 RECOVERY OF DEFAULTED LOANS ........................................................................................ 49

4.6 BRIDGING OF LOANS/REFINANCING/RESCHEDULING .......................................................... 50

5.0 FOSA & OPERATIONS ................................................................................................................ 53

5.1 CASH DEPOSITING PROCEDURES. ......................................................................................... 53

5.2 CASH WITHDRAWAL PROCEDURES ....................................................................................... 54

5.3 ATM CARD PROCESSING ....................................................................................................... 56

5.4 ATM WITHDRAWALS SETTLEMENT PROCEDURES ................................................................ 57

5.5 REFUND PROCESSING PROCEDURES. .................................................................................... 58

5.6 STANDING ORDER PROCESSING PROCEDURES ..................................................................... 59

5.7 FOSA LOANS PROCESSING PROCEDURES .............................................................................. 61

5.8 DIVIDEND PROCESSING PROCEDURES. ................................................................................. 62

5.9 FIXED DEPOSIT PROCESSING PROCEDURES. ......................................................................... 63

5.10 DEFAULTED FOSA LOAN PROCESSING PROCEDURES ........................................................... 64

5.11 BANKERS’ CHEQUE PROCESSING PROCEDURES. .................................................................. 66

5.12 POSTING OF CHEQUES .......................................................................................................... 67

5.13 TELLER’S CASH REPLENISHMENT PROCEDURES. .................................................................. 68

5.14 CHEQUE RECEIVING AND PROCESSING PROCEDURES. ......................................................... 70

5.15 VERIFICATION OF TELLER TRANSACTION PROCEDURES. ...................................................... 71

5.16 MOBILE BANKING.................................................................................................................. 72

5.17 TERM DEPOSITS .................................................................................................................... 73

5.18 UNCLEARED EFFECTS ADVANCES .......................................................................................... 74

5.19 MANAGING DECEASED MEMBERS/WITHDRAWALS ............................................................. 74

6.0 HUMAN RESOURCE MANAGEMENT ......................................................................................... 76

6.1 STAFF PERSONAL DETAILS (BIO DATA) .................................................................................. 76

6.2 PAYROLL PROCEDURE ........................................................................................................... 78

6.3 PERFORMANCE APPRAISAL ................................................................................................... 80

6.4 TIME MANAGEMENT ............................................................................................................ 81

6.5 ACTING APPOINTMENT ......................................................................................................... 83

6.6 PROMOTION AND UPGRADING ............................................................................................ 85

6.7 STAFF TRAINING .................................................................................................................... 86

6.8 LEAVE MANAGEMENT........................................................................................................... 88

6.9 STAFF LOANS AND ADVANCES .............................................................................................. 90


3

6.10 DISCIPLINARY AND GRIEVANCE HANDLING .......................................................................... 91

6.11 EXIT PROCESS ........................................................................................................................ 92

6.12 RETIREMENT ......................................................................................................................... 93

6.13 DEATH IN SERVICE ................................................................................................................. 95

6.14 MEDICAL INSURANCE CLAIMS .............................................................................................. 97

7.0 ICT AND SYSTEM ADMINISTRATION ......................................................................................... 98

7.1 SYSTEM INTEGRATION ................................................................................................................ 98

7.2 AUDIT TRAIL ........................................................................................................................ 102

7.3 SYSTEM BACKUP AND DATA RECOVERY ............................................................................. 103

7.4 SYSTEM UPDATES ................................................................................................................ 104

7.5 ACCESS RIGHTS ................................................................................................................... 104

7.6 SYSTEM FLEXIBILITY ............................................................................................................ 106

7.7 REPORTING ......................................................................................................................... 108

7.8 POSTING OF TRANSACTIONS .............................................................................................. 110

7.9 SECURITY AND SYSTEM CONTROLS .................................................................................... 110

7.10 BRIDGE MANAGEMENT ...................................................................................................... 111

8.0 RECORDS DEPARTMENT.......................................................................................................... 112

8.1 REGISTRATION OF MEMBERS ................................................................................................... 112

8.2 MANAGEMENT OF FILES AND CORRESPONDENCE- RECEIVING ......................................... 115

8.3 REQUISITION OF FILES FROM RECORDS ............................................................................. 116

8.4 CLOSING OF FILES ................................................................................................................ 117

8.5 CHEQUE DISPATCH .............................................................................................................. 118

8.6 ARCHIVE MANAGEMENT .................................................................................................... 118

9.0 INTERNAL AUDIT & CONTROLS ............................................................................................... 120

9.1 AUDIT FEATURES ....................................................................................................................... 120

9.2 ACCOUNT CONTROLS .......................................................................................................... 121

9.3 USER RIGHTS ....................................................................................................................... 121

9.4 INCIDENT REPORTING ......................................................................................................... 121

9.5 AUDIT PROCESS ......................................................................................................................... 123

9.5 RISK ASSESSMENT ..................................................................................................................... 123

10.0 MARKETING DEPARTMENT ..................................................................................................... 124

10.1 MEMBER REGISTRATION AND LOAN APPLICATIONS .............................................................. 124

10.2 CUSTOMER COMMUNICATION ........................................................................................... 125

11.0 INVENTORY & ASSETS MANAGEMENT ................................................................................... 127

11.1 STOCK CONTROL PROCEDURES .............................................................................................. 127

11.2 PROCUREMENT ................................................................................................................... 131


4

11.3 ASSETS MANAGEMENT ....................................................................................................... 136

11.4 FIXED ASSETS REGISTER ...................................................................................................... 137

12.0 DATA ANALYTICS ......................................................................................................................... 147

12.1 ROLE-BASED DASHBOARDS ..................................................................................................... 147

12.2 BUSINESS INTELLIGENCE ..................................................................................................... 147

13.0 OTHER REQUIREMENTS .............................................................................................................. 148

13.1 CHEQUE MANAGEMENT ..................................................................................................... 148

13.2 PAYBILL AUTOMATION ....................................................................................................... 149

14 DOCUMENT MANAGEMENT SYSTEM ................................................................................. 150

15 INVESTMENT COMPANY ..................................................................................................... 150

16 ADDITIONAL REQUIREMENTS ............................................................................................. 151

16.1 LOANS AND ADVANCES........................................................................................................... 151

16.3 ADDITIONAL CUSTOMER INFORMATION ................................................................................ 152

12.0 CONCLUSION ........................................................................................................................... 153


5

List of Acronyms

AGM Annual General Meeting

AML Anti-Money Laundering

BF Benevolent Fund

CCIA Co-op Consultancy and Insurance Agency Limited

FOSA Front Office Service Activities

KYC Know Your Customer

PMS Performance Management System

PPOA Public Procurement Oversight Authority

RFP Request for Proposal

RTGS Real Time Gross Settlement

EFT Electronic File Transfer

SACCO Savings and Credit Co-operative Society

SASRA Sacco Society Regulatory Authority

TAT Turnaround Time

SLA Service Level Agreement


6

1.0 INTRODUCTION

1.1 About Viktas Sacco

Viktas Sacco (a licensed deposit taking Sacco) is a growing rural Sacco with its headquarters in

Nyandarua county, Ndaragwa sub-county at Mairo-Inya shopping center.

We have an approximate membership of 4,500 serving them from through three (3) outlets, and

ten (10) full-time employees.

1.2 Purpose

The purpose of the Functional Specification Document (FSD) is to specify the overall system

requirements that will govern the development and implementation of the system that Viktas

Sacco is looking for. The document will also establish initial expectations of the system

performance.

However, the selected vendor is expected to perform their own system requirements scoping as

the first task once engaged.

1.3 Scope

This document covers all basic expectations of an ERP system based on the needs of the Sacco.

The key modules broadly covered in the requirements scoped in this document are:

Membership Management

BOSA

Credit Management

Finance & Accounting

HR

Supplies Management

Alternative Channels (Mobile, ATM, Agency, Online Portal)

Customer Service

Reports Management & Business Intelligence (Data Analytics)

Documents Management

Information Security (Basic System Administration), capability to print documents with

security features i.e. cheque leaves, share certificates, receipts.

Some of the requirements contained therein may not be directly under these modules, hence the

vendors are to respond to the detailed requirements below.

1.4 Major System Conditions

The system should meet the following conditions.

System must be compatible with the cloud environment

System must be available 24 hours per day

System must be accessible by mobile devices

System must be able to accept electronic payments

System must interface with existing mobile and ATM channels


7

The system should be able to accommodate multiple branches and decentralize

accounting on the same.

1.5 Licensing Requirements

The system should have sufficient concurrent licenses for at least 10 staff. Unlimited, perpetual

licenses is best preferred.


8

2.0 GENERAL REQUIREMENTS

2.1 ACCOUNTING PACKAGE

The accounting package should have the ability to offer the following requirements:

• Tracking of cash-flow, revenues and expenses by profit/cost centers should be possible;

• The system should have user-definable chart of accounts. Should allow at least 5 nesting levels assets, liabilities, income, expenditure and equity;

• For accrual- based accounting accrues interest to General Ledger accounts on monthly basis (at the beginning of due month). Allows to accrue

interest expense for savings/deposits but not to post accrued interest income for loans;

• The system should be able to perform cost and profitability analysis by product, branch, client;

• The system should be able to calculate and post the necessary loan provisions;

• The system should be able to permit back valued transactions and transaction reversal with according interest recalculations;

• The system should have Asset and Liability Management facilities;

• The system should be able to provide full range of standard financial reports e.g.: balance sheet, income statement, cash flow including regulatory

SASRA Reports

Maker – checker controls in journal entries

2.2 LOAN PORTFOLIO

The loan portfolio package should have the ability to offer the following requirements:

• Keeps historic data on loan products;


9

• Collateral and guarantors tracking, individual and group guarantees;

• Mandatory savings/deposits linked to loans;

• Permits the addition and modification of loan products;

• Information tracking by Loan officers;

• Integrated with accounting system, deposit monitoring and customer information;

• Correct handling of early, late and partial payments;

• Correct handling of extra payments;

• Automatic and configurable handling of Loan insurance functionality;

• Credit scoring capabilities from internal and/or external sources;

• Ability to provide a complementary loan statement to members;

• Controls to ensure that loans cannot be issued without full settlement of initial loans in the same category except for refinancing cases;

• Ability to flag loan accounts that do not meet the group criteria that has been defined for the product and generate exception reports on the same;

• Ability to categorize loans with 0.00 balance appropriately and indicate them as paid/closed, preventing over recovery or auto provisioning; and

• Modifications to an existing or completed loan accounts should trigger a request for approval before being implemented. System should be able to

restrict such access to specific staff.

Maker – checker controls

2.3 SAVINGS, DEPOSITS WITHDRAWALS AND SHARES

The Savings deposit withdrawals and shares package should have the ability to offer the following requirements:

• Keeps historic data on savings products;

• Integrated with accounting system, deposit monitoring and customer information;


10

• Tax withholding functionality;

• Dormancy concept for inactive account with separate interest rates;

• Identification of beneficiaries;

• Option of jointly held accounts and/or group savings;

• Transactions between accounts of one or different members;

• Advanced functionality, such as ATM cards, mobile banking; and

• Permits different product types: advances, fixed deposits, savings, shares, savings accounts.

• The system should restrict linking of ATM Cards to pre-defined account types e.g. Loan Accounts, Fixed Deposit accounts, Internal Accounts etc.

• Ability to prevent pre-defined accounts from being over drawn e.g. FOSA accounts, Fixed Deposit accounts etc. through either customer activities

or internal transactions such as Journal entries and reversals. (Such parameters should be definable on product level or individually for each account)

• Only allow linking of ATM cards to bank accounts related to the same customer.

• The system should be able to store the unique reference transaction codes generated by ATM / VISA switch or mobile transactions to aid in

reconciliation.

The system should be able to generate a reconciliation report of all ATM/ VISA switch and mobile transactions carried out showing exceptions and

reconciled entries.

Maker – checker controls on data entry

2.4 CUSTOMER INFORMATION

The Customer Information package should have the ability to offer the following requirements:

• Maintains all basic customer information, such as name, family information, age, gender, business name etc.;

• Aggregation of customer data by gender, branch, business activity, loan officer, marketing officer etc.;


11

• Able to track customers and non- customers at different stages of the process. Guarantor tracking should also be possible;

• Identifies potential double entry of customers;

• The customer profile should be able to display all the historical and running products the member has e.g. loans;

• Contain additional KYC identification options such as pictures , signatures; and

• Facilities to check customer behavior – credit and deposit status and history from Internal or external sources.

Maker – checker control on data entry

2.5 EXPANDABILITY AND INSTITUTIONAL GROWTH

The system should be able to support the horizontal and vertical institutional growth of the Sacco (Scalability) in terms of:

• The system should have a modular structure that would support products roll out or services planned in future e.g. e-loan, micro-credit, internal

departments, new products etc. through patches or upgrades.

2.6 FLEXIBILITY

The system should be flexible in terms of:

2.6.1 Lending

The lending package should have the ability to offer the following requirements:

• Support of reducing balance interest rates; amortized, or P+I

• Support of variable rate, where interest rate can be changed for a whole product or all accounts in one product;

• Commissions and fees should be defined as settings linked to products and/or customer groups. The system should be able to apply these

automatically without manual intervention.


12

• Support of free schedule and balloon payments;

• The system should be able to allow preview of the different repayment schedules before adopting them;

• Repayments schedule should be recalculated automatically if member actually pays in advance;

• Selection of initial and subsequent payment dates;

• Support of full loan processing cycle (application, review, approval, disbursement) online;

• Support of different payment methods: cash, cheque, card, salary check off, standing order, money order;

• Permits grace periods; and

• Permits refinancing of the loan.

2.6.2 Savings

The Savings package should have the ability to offer the following requirements:

• Supports all account types: savings, term deposits, demand deposits, shares;

• Should be able to set withdrawal limits (amounts, number of operations) and either block and impose fees on withdrawals. The system should also

be able to apply penalties or reduced interest rates for premature withdrawals (on term deposits);

• The system should be able to automatically roll over Post-matured term deposits to the next term and possibly update interest rate;

• Share dividends should be calculated either based on interest rate, or profit figure for the year. (distributed between members, based on interest

points or monthly/quarterly / annual shares balance etc.);

• The system should be able to define stepped rates or bonus interest to allow changing interest earned depending on amount saved;

• The system should be able to set the minimum balance for each of the accounts ;

• The system should be able to calculate Interest based on 30 days/month. Optionally also 365 days/year or 52 weeks/year should be supported;


13

• The system should be able to calculate Interest based on minimum daily/monthly/quarterly balance, average daily/monthly balance, as well as

average/ending/minimum balance during user-defined period;

• Maintains group savings accounts ;

• The system should support additional payment frequencies so that interest can be paid out on daily, weekly, bi-weekly, every four weeks, semi-

monthly etc. User-defined periods can be set;

• The system should be able to calculate withholding tax, products can be excluded from the calculation. Member can be marked as “exempt from

withholding tax”; and

• The system should be able to backdate Interest rate changes, and accrued interest should be corrected accordingly.

2.6.3 Other flexibility

The system should have the ability to offer the following flexibility requirements:

• Full support for the FOSA (as well as branches and remote workstations) is in place to allow the FOSA to operate in real-time mode, or at a minimum

in a store-and forward mode during connection failure. Frequency of updates to/from head office is user-definable. Remote real-time workstations

should be supported (with minimal requirements for data transfer speed);

• Data transfer between the FOSA and head office (and between branches themselves, if and when applicable) should be accomplished using

inexpensive (and relatively slow) channels;

• The system should allow customer have many different accounts and account types

Ability to maintain branch accounts as well as consolidated accounts


14

2.7 USABILITY

The system should have the ability to offer the following usability requirements:

2.7.1 Ease of use:

• Vendor should provide quality and conclusive training that is not time consuming for all the users(e.g. Management, Support and end- user ) and

sign off done after the training ;

• The user documentation supplied should be comprehensive and up to date;

• On-line context-sensitive help should be provided; and

• Operations of the system should be straight-forward and easy to understand, allowing for easy error correction.

The user access should be web-based

2.7.2 User Friendliness:

• The System should have a graphical interface;

• The system should provide mechanism for mass data entry (multiple transactions or accounts);

• The system should follow general platform standards in terms of screen interface and keyboard commands (i.e., no user-defined buttons/combo

boxes etc.); and

• The system should be able to restrict different users to certain menu operations, functions, reports etc.

2.8 REPORTING

The reporting package should have the ability to offer the following requirements:

• Report formats should be user-modifiable (subtotaling, layout etc.);

• The system should allow reports to be printed out to suit various audiences (management, operational, supervisory etc.);


15

• The system should be able to report on budget versus actual expense & income;

• For management purposes the system should be able to provide staff performance, Assets Liability Management reports and trend analysis reports

in narrative , data/statistical and graphical views;

• The system should provide ratios and trend analysis reports, calculations of the ratios should be adjustable, clear and understandable;

• The system should be able to print reports that show inflationary and subsidy adjustments;

• Reports should be generated in batches (either on request or at preset time of the day), or separately by request;

• Reports should be printable for any previous date, or even a specific transaction;

• The system should support user-defined reports, via built-in functionality ;

• The system should be able to print reports on wide variety of printing devices, can utilize various paper formats;

• In addition to capturing details of all users involved in the transaction (initiator, approver, reviewer) The system should be able to print the Audit

trails ;

• Error-catching reports should be in place (For example interest rate less than Sacco rate, loan outstanding amount greater than granted, interest

rate changes that exceed reasonable limits for the product, manual postings to system accounts such as accrued interest, etc.);

•The system should come with a CEO / Top management dashboard containing various predefined and customizable reports on business and staff

performance. Including pending issues and any system red flags across the business/departments in narrative , data/statistical and graphical views;

•The system should be able to input and output data in specific required standards e.g. SASRA formats .These outputs should be customizable and

configurable to accommodate changes from stakeholders; and

• The system should provide a way to store report’s output (i.e., in PDF/XLS/XLSX/DOC file) for later viewing.


16

2.9 COMPLIANCE STANDARDS

The system should be able to meet the following compliance standards:

• The general ledger should be updated online or in batch mode;

• Interest accruals account should be separate from interest received/paid accounts;

• The system should be able to cease to accrue interest on loans in arrears once the total accrued interest equals the principal amount in arrears;

• Savings and loans interest should be accrued on user-defined period basis and posted to interest income/expense accounts; and

The system should have the ability to be integrated into national payment systems e.g. RTGS, Mobile Money(MPESA, Airtel Money, YUCash), etc.

2.10 ADMINISTRATION AND SUPPORT

The administration and support package should have the ability to offer the following requirements:

2.10.1 Security

• User levels (or groups) should user-definable, can be added/changed/deleted. Each level should be assigned access right to specific menu items,

functions, reports;

• Access rights to database should be defined both by fields and subset of records;

• The system should include automated tools to check for database consistency;

• The system should be able to define rights to post, reverse and cancel transactions;

• The system should be able to define limits for transactions;

The system should be able to require passwords change regularly, be complex and store them in encrypted format;

• The system should be able to record all security violation attempts;


17

• The system should be able to Provide means for off-site storage of records by allowing backups of all data to external removable media / external

network/ DR site;

• Time-of-day or terminal access restrictions should be available in the system; and

The system should only allow users to select accounts related to the Member being processed during loan creation , disbursement , repayment, Fixed

Deposit preparation etc.

Backup and Recovery

The system should be able to have the following requirements on backup and recovery:

• The system should have end of day processing that checks database for any corruption, and provides notifications about errors;

• The system should be able to support both full and incremental backups; and

• The system should be able to maintain the Status of each user.

2.11 FAULT TOLERANCE AND ROBUSTNESS

• Remote processing centers/FOSA (branches if and when applicable) should be able to function off-line in case of communications failure.

2.12 END OF PERIOD PROCESSING

• The Period duration should be user-definable;

• Interest should be processed, accrued and posted at proper intervals; and

• Late fees, penalties should be calculated and posted.


18

2.13 SUPPORT INFRASTRUCTURE, MAINTENANCE AND UPGRADE STRATEGY

• Support hotline should be provided, 24/7 where appropriate;

• A bug tracking (service desk) system should exists to ensure all complaints are resolved;

• The Vendor should be able to provide manuals for end-users, administrators, for training purposes; and

• There should be a documented change request procedure/platform in place that customers can use to place their requests.

2.14 TECHNICAL SPECIFICATION

The system should have the following technical requirements:

• The system should use a client-server architecture;

• The system should be able to run on widespread hardware platforms (PC, Mac), and use standard operating systems (MS Windows, Mac OS, Unix

etc.);

• The system should have no obscure restrictions on operating system/database versions;

• Source code control should be employed;

• There should be clearly stated performance limits depending on number of accounts, transactions or concurrent users;

• Disk space requirements should be clearly stated; and

• The system should have an open architecture and standard file formats to allow integration with other systems such as a document management

system.


19

2.15 PRICING AND COSTS

The system should have the following requirement for pricing and costs:

• no payment should be required for unused / inactivated modules in the system ; and

• In case of non-payment of the license fee only support and/or upgrades are terminated, not the license itself.


20

3.0 FINANCE DEPARTMENT

3.1 THIRD PARTY CHEQUES TO SUPPLIERS

The system should be able to capture the following details from the supplier invoice:

• Name of the supplier;

• Supplier reference number;

• Invoice reference number(supplier's invoice number);

• Supplier bank details;

• Expense account (for service invoices);

• Stock item code;

• Stock item name;

• Quantity;

• Amount; and

• VAT amount.

• Withholding tax amount (where applicable)

The system should enable Viktas Sacco to create customizable user fields that will capture additional information not specified above.

The system should be able to attach scanned documents received (if any) and assign it to the record created in the system.

The system should be able to match the input invoice against the related purchase order.

The system should be able to update the budget actual amount with the amount posted in the invoice.

The system should be able to facilitate the preparation of a payment voucher based on the details captured in the supplier invoice.

The system should have different levels of authorization for the payment vouchers.


21

The system should be able to send an alert after the payments are sent to the supplier.

After approval of the voucher the system should be able to post the entries in the vote book.

The system should allow for the payment type e.g. cash/cheque/direct credit to be selected.

Reports

Basic purchasing reports such as open LPO/GRN/Invoice report, closed LPO/GRN/Invoice report.

Basic accounts payable reports such as payments to supplier, Cheque Register, Cash Requirements, Vendor information report.

The system should provide a purchase analysis report by supplier with the following details:

• Supplier code and name;

• Invoice numbers;

• Invoice dates;

• Invoiced amounts;

• Paid amounts.

The system should provide a purchase analysis report by item to with the following details:

• Item code and name;


• Invoice dates;


• Unit costs.


22

3.2 PETTY CASH PROCEDURES

The system should be able to capture the following details from the imprest form:

• Name of the person taking the imprest;

• The PF Number/Staff Number;

• The imprest amount;

• The purpose of the Imprest;

• The recommender of the imprest;

• Outstanding imprest by the officer; and

• Imprest approval.

The system should be able to capture the following details from the imprest surrender form:

• The Current date;

• The surrender amount;

• Approval details;

• Breakdown of the expenses; and

The system should be able to capture replenishment amount by the petty cashier.



The system should be able to reject any petty cash payments that is beyond (variable) shillings ceiling.

The system should enable the petty cashier to claim against the surrendered amounts

The system should allow setting of the maximum amount to be paid by the petty cashier, the float amount and the minimum float amount.


23

The system should be able to recover the un-surrendered imprest from the payroll

The system should be able to automatically update the petty cash book balance upon any surrender.

Reports

The system should provide an imprest expenses reports( Per staff, per department, per expense type)

The system should provide a report on surrendered imprest per staff member etc.

The system should be able to provide a report of all the imprest not surrendered.

3.3 BUDGETS

The system will allow for three sets of budgets to be held against an account:

• Original budget;

• Revised approved budget;

• Latest forecast; and

• Cash flow budget.

The system will allow the following year's budget(s) to be set up without overwriting current year budgets.

There will be facilities for phasing an annual budget over the various accounting periods on the basis of:

• Equal monthly apportionment; and

• Specified monthly profile (of which there can be more than one).

It will be possible for budgets to be generated automatically from previous year actuals or budgets and development plans, with a percentage increase

or decrease by income / expense code range.

The system should allow for loading budgets from an Excel spreadsheet.


24

The system should allow the creation of an unlimited number of budgeting units/cost centers.

The system should provide functionality for each unit to enter and maintain budgets on-line.

The system should allow for the capture of the following budget details:

• Budgeting unit:

• Account code;

• Account/item name;

• Total line item budget amount;

• Total budget amount.

• Separate Fixed costs and variable costs

The system should be able to capture allocated revenue ceilings for the different budgeting units.

The system should allow for creation of multiple budgets/ forecasts in same year (original, revised and approved, and cash flow budget at a minimum).

The budgets must be locked and retained once approved.

The system should allow the following year's budget(s) to be set up without overwriting current year budgets.

The system should allow budgeting at various levels (e.g. sub account level for some accounts, income/expense level for other accounts).

The system should be able to maintain current and future year forecasts.



The system should be able to calculate and maintain actual-to-budget.

The system should allow for reallocation of budget amounts to different accounts within a budgeting unit subject to approval.

The system should automatically validate input budget totals against the revenue allocations and generate an alert where ceilings are exceeded.

The system should have capabilities for zero budgeting


25

3.4 BUDGETARY CONTROL

The system should maintain a budget control system through which all transactions are passed.

The Budget control module should have online approvals for transactions.

The Budget control module should automatically update available budget amounts after a transaction has been approved.

The Budget control module should block transactions whose amounts exceed the remaining budget balance.

Reports

The system should be able to produce performance reports with the following details:

• Period budget;

• Period actual;

• Variance amount;

• Variance percentage;

• Year budget;

• Year budget balance;

• Year balance percentage;

• Last year budget;

• Last year actual;

• Last year variance;


26

• Last year variance percentage;

• Cash flow budget; and

• Revised approved budget.

• Separate fixed costs & variable costs

• Budgetary variances per branch

• Branch profitability report.

• Budget forecasting based on prior performance for x period in the future. (fields can be filtered as per user needs)

3.5 GENERATION OF SASRA REPORTS

The system should be able to link the SASRA reports module with the budget and the GL modules

The SASRA reports should only be visible to authorized management staff.(Finance manager, chief manager Finance , the person preparing, CEO)

Reports

The system should be able to print out the following SASRA reports as per templates:

Form 1: Capital adequacy;

Form 2: Liquidity return;

Form 3: Statement of Deposit return;

Form 4: Risk classification of assets and provisioning;

Form 5: Investment return;

Form 6: Statement of financial position;

Form 7: statement of comprehensive income;


27

Form 8: other disclosures;

3.6 BANK/ATM/PAYBILL/MOBILE BANKING RECONCILIATION

The system should be able to capture details of:

• Bank Account Statement; and

• Cash book.



System should be able to import the bank account statement and capture the following:

• Bank Account Name and Number;

• Deposit/withdraw description; and

• Amount.

The system should be able to compare the bank account statement with the cash book and verify the following fields:

• Amount;

• Account detail;

• Date of deposit / entry ; and

• Description of entry.

The system should have standard codes for repayments e.g. loan repayments

The system should be able to integrate the GL to the MPA

The system should have proper controls to ensure that all the postings are done correctly e.g. no savings are debited


28

The system should be able to identify entries that do not have proper narrations at the bank and customer queries so that auto-matching can be done

and GLs posted accordingly

The period close and opening should be adjustable by an approved staff.

The system should allow for online viewing and approval of a reconciliation report.

The system should allow periods to be closed to reduce cases of back dating receipts and ensure historical reports remain accurate.

Reports

Discrepancies report _ Date, reference, and amount.

Cash book adjustments.

Exception report on mismatched discrepancies.

Unbanked receipts (amounts received but not transferred to bank).

Unpresented Cheques (Cheque payments not receipted by the bank).

Cheques in transit report


29

3.7 REPORTING

The system should provide Ad hoc report function to allow an unlimited number of financial reports for balance sheet, income statement, supporting

schedule, and other user specific account analysis

The system should allow the users to specify accounts for inclusion by: - account number; profit centre/cost centre; range of account numbers; range

of account numbers with specified exceptions.

The system should allow users to report on actual + committed costs versus budget.

The system should allow the user to include calculated columns in reports e.g. actual - budget, period 1 + period 2

The system should be able to generate graphs of reported data.

The system should allow ability to drill down to supporting transaction detail of budget lines from the screen output of financial reports.

The system should allow suppression of zero value accounts.

The system should provide a management Statement of cash flow detailing revenue inflows/outflows, non-operational inflows/outflows, net

inflow/outflow and bank account reconciliation.

Reports

The system should generate the following reports:

• Chart Of Accounts listing;

• General Ledger Reports for GL accounts and transactions;

• Profit & Loss Statement;

• Balance Sheet;

• Cash flow statement; and

• Trial Balance Report (5 years).


30

• Changed in equity (shareholders’ funds).

The system should be able to print out the following management reports:

• Balance Sheet (Statement of Financial Position);

• Trial Balance;

• Income and expenditure statement; and

• Cash Flow Statement.

• Changed in equity (shareholders’ funds).

Branch Reports

The system should be able to print out the following management reports per branch:

• Balance Sheet (Statement of Financial Position);

• Trial Balance;

• Income and expenditure statement; and

Customizable Reports

The system should be able to print out the following management reports from the finance dept.;

• Cost benefit analysis on projects

• cost benefit analysis on departments e.g. Marketing


31

3.8 GENERAL LEDGER

General Requirements

The system will provide the facility to have multiple, independent general ledgers.

It will be possible for information to be consolidated within and across general ledgers for a month end reporting purposes.

Each general ledger will be capable of supporting and be fully integrated with the purchase ledgers and cash book.

Each subsidiary ledger will relate to a separate control account in the general ledger.

Postings to subsidiary ledgers will result in automatic postings to the control accounts in the general ledger.

The system should support the creation of an account code with support for the following:

• Alphanumeric characters for the cost centres (departments);

• Alphanumeric characters for the expense / income account codes;

• Alphanumeric characters for the analysis codes; and

• The system will only prompt for analysis codes on those expense / income codes for which they are relevant.

If transaction batching is used by the system, it will support batch control on input. Agreement of batch controls will be mandatory before batches

are accepted for posting.

Batch numbers will be allocated by the user.

Batches will be limited to:

• A single period; and

• A single transaction type.

Batches will be written to a 'holding' file, and be available for recall and modification before posting.


32

It will be possible for valid batches to be posted selectively by the user.

The system will provide the facility for the users to define their own transaction types, e.g. month end allocation journals, payroll journals etc.

The system should provide the following fields will be input on transactions:

• Transaction type (unless input at batch level);

• Transaction reference;

• Transaction narrative (minimum 20 characters);

• Transaction date; and

• Accounting period (unless automatically derived from date).

• Account code;

• Description (minimum 20 characters);

• Value;

• Debit/credit indicator;

• Quantity (optional); and

• Analysis code (see below).

Analysis codes will be available on transaction records for analysis separate from that based on the account code, e.g. on some transactions a staff

code will be entered, to facilitate analysis of certain types of expense by staff member.

Separate tables of valid analysis codes will be maintained for validation purposes and appropriate descriptions displayed on entry of the analysis code.

It will be possible for account codes to be looked up during data entry (on the basis of all or part of the account name).


33

It will be possible for trial month ends to be carried out, i.e. month end reports produced etc, but still allowing for further transactions for the month

to be subsequently input, and reports re run.

It will be possible for bank statement information to be entered, and a bank reconciliation statement automatically produced.

The system will allow bank statement information to be entered automatically from a text file supplied by the bank.

It will be possible for specified account balances to be automatically reallocated over a range of other accounts, according to pre-determined

apportionment ratios, i.e. a number of account balances are apportioned over departments using various bases.

Create different account structures for different business units or cost centres of the organization.

Automatically accept and post journal entries from other systems (Payroll, Accounts Payable, Accounts Receivable, Fixed Assets, etc.) i.e. real time

update of information into the General Ledger.

The system will automatically transfer balance sheet account balances forward at the end of each financial year, and zero-ise P&L account balances.

It will be possible to keep the previous year open for at least (X) number of days while processing the next year's data.



The general ledger will hold balances for each account code as follows:

• Each period;

• Year to date;

• Budgets for each period;

• Budgets for year to date;


34

• Budgets for year;

• Each period previous year;

• Total for previous year; and

• Year to date last year.

The general ledger transactions will contain the following fields:

• Full account code;

• Transaction type;

• Batch number;


• Transaction date;

• Accounting period;

• Transaction narrative;

• Value; and

• Debit/credit indicator.

Account level enquiry: The following information will be available on entry of account code:

• Net movement by period;

• Net movement by period compared with:

• Budget, and variance; and

• Previous year, and variance.

• On selection of a period it should then be possible to see all the transactions making up the net movement;


35

• The following fields will be displayed at transaction level:



• Transaction date;

• Transaction narrative;

• Transaction value; and

• Supplier or customer code for postings derived from purchase or sales ledgers.

• It will be possible to see all the other general ledger entries relating to a particular transaction on the screen, if required.

Transaction enquiry: It will be possible to enquire on the transaction file on a variety and combination of different fields, the system displaying all

transactions which meet the defined criteria. Such criteria will include:


• Period;

• Range of transaction references;

• Range of account codes; and

• Range of transaction values.

It will be possible for wild carding to be used in the search criteria (e.g. display all transactions with 04 in positions 3 and 4 of the account code).

Reports

The system should be able to generate the following reports:

• Trial balance;

• Income and expenditure account at cost centre and analysis levels;


36

• Balance sheet;

• Net movement by account, showing opening balance at start of month, net transactions value (or detailed transactions) and closing balance; and

• Current month’s transaction listing (by account code).

The system should allow creation of ad hoc reports, particularly in relation to transactions, will be required.

The report writer will be able to access all data items in the database to enable a wide range of custom reports to be written.

The system should provide a general ledger report writer. At a minimum, it will be able to report the following values:

• Current month actual;

• Current month budget;

• Current month last year;

• Current month variance;

• Year to date actual;

• Year to date budget;

• Year to date last year; and

• Year to date variance.

It will support the following features:

• sort routines;

• Extraction by criteria;

• Ability to round reports to the nearest thousand;

• Automatic formatting;


37

• On line view;

• Variable width;

• User defined columns;

• User defined rows; and

• Arithmetic calculation facilities.

The user will be able to define a range of account codes, so that each account and its description and other selected fields is automatically displayed

(i.e. no need to define each code and description individually).

It will be able to access transaction data as well as account level data.

The system will maintain an organizational structure for cost centres, but will also be able to use alternative hierarchies for reporting purposes.

3.9 IMPREST PROCEDURES

The system should be able to capture the following details from the imprest form:


• The imprest amount;

• The purpose of the Imprest;

• The recommender of the imprest(HOD);

• Outstanding imprest by the officer; and

• Imprest approval;

The system should be able to capture the following details from the imprest surrender form:


38


• The Current date;

• Amount surrendered;

• Approval;

• Breakdown of the expenses; and

• Confirmation



The system should allow for the relevant approvals before payments are done

The system should facilitate the recovery of unsurrendered amounts through the payroll.

The system should be able to update the imprest balances automatically upon imprest payments or surrender

The system should facilitate the staff members to fill in the surrender forms

Any imprest of less than KES xxxx (variable) should be handled by the system as petty cash.

Reports

The system should provide an imprest expenses reports( Per staff, per department, per expense type)

The system should provide a report based on the amount spent per each expense and the total disbursement.

The system should provide a report on surrendered imprest per department with the following details:

• The name of the person surrendering;

• Members Number;

• Purpose of the imprest;


39

• Invoiced amounts; and

• Paid amounts.

The system should be able to provide a report on the unsurrendered imprests.

3.10 MPA (MEMBER PERSONAL ACCOUNT) RECONCILIATION

For each MPA account, the system should be able to capture:

• The minimum share contribution amount;

• Mandatory BF contribution amount;

• Expected loan interest repayment amount; and

• Expected loan principle repayment amount.

The system should be able to accept payments via the following means:

• Monthly Payment schedule from employer ;

• Regular Standing orders from FOSA and external accounts; and

• Irregular / regular payments from individual members for a specific product.

The system should be able to upload monthly payment schedules from employers e.g. the church and capture the following fields:

• Member Number;

• Amount submitted;

• Contribution category;

• Loan balances;


40

• Shares amounts;

• BF Contributions.

The system should be able to allocate the amounts based on byproduct (payment schedule) breakdown submitted by the employer

The system should be able to generate payment schedule templates for employers that submit schedules in hard copy.

The system should allow for verification and approval of the prepared schedule prior to posting in the system

If the employer/member does not provide a breakdown of the figure of the amount submitted in the payment schedule e.g. (400 for loan A, 200 for

shares etc.) the system should be able to apportion the amount received based on the society’s priority e.g. interest repayment, principal repayment,

shares, BF contribution etc.

The system should be able to identify and report accounts where no money has been received or funds received were less than expected amounts.

The system should be able to identify an over recovery and apportion the excess funds remitted accordingly e.g. to member Savings or allow for a

refund if necessary.

The system should be able to enforce segregation of duties of the various users



Reports

• Arrears report for different accounts (loan, share, BF, interest etc.);

• Double (duplicate) deductions report;

• Fall -off (no funds received) cases Report ;

• Over recoveries report;

• Under recoveries report;

• Payslips vs. Loan (differences in balances) report;


41

• Exact recoveries report;

• Mistaken loans(unknowns) report; and

• Unallocated amounts report.

3.11 LIQUIDITY MANAGEMENT

The system should be able to prepare data sheets of the Sacco’s liquidity position real-time. The system should;

• Track all liquid assets of the society

• Monitor treasury positions of all branches

• Analyze available idle cash within the Sacco

• Recommend best available investments in the market

• Track loans approvals daily to assess cash demands

• Analyse and track loan performance Sacco wide

System should be flexible to enable users add new data sheet templates

System should be flexible to enable users modify existing data sheet templates

3.12 OVERDRAFTS MANAGAMENT

The system should be able to capture the following from a members account:

• Name of Member / Member number;

• Beneficiary FOSA account;


42

• Amount requested.

• Limit loading.

• Approval process flow for granting overdraft requests


Reports

The system should:

• all overdrawn positions;

• performance of overdrafts;

• overdrawn positions after expiry of overdraft facility;

3.13 LOAN PRODUCT PRICING

The system should be able to provide an in depth analysis of cost of funds vis-à-vis product pricing;

• cost of investments

• cost of fixed deposits running

• facility to advise tellers online and provide framework where Finance Department can input the minimum and maximum rates for Fixed deposits

based on market conditions. Tellers can only use such rates without necessarily calling head office.

• The system should be able to advise best rates for business loans for unique customers who may require such exceptions from the management.

There should be user customizable fields to amend or update parameters as shall be dictated by business needs.


43

3.14 FOSA SHARES

The system should be able to provide a platform to manage FOSA shares;

• buy and sell FOSA shares (like NSE)

• be able to match willing sellers to willing buyers of those shares from within the Sacco membership.

• The system should be able to levy a management fee for such a service.

There should be user customizable fields to amend or update parameters as shall be dictated by business needs.


44

4.0 CREDIT DEPARTMENT

4.1 LOAN REGISTRATION

The system should be able to capture the following details from the Loan Form (online form or submitted form):

• Name of applicant;

• Loan Amount applied;

• Selected Guarantors;

• Repayment duration requested; and

• Type and purpose of loan.

Loans Officer

The system should be able to access the following member details from the data stored in the system :

• Signature specimen ;

• Image of applicant ;

• Loan history ; and

• Guarantor history.


The system should be able to attach scanned documents received by the applicant and assign it to the record created in the system.

The system should be able to provide an online portal for a customer to make an online loan application.

The system should be able to display a checklist of all items required for the loan application process.

The system should be able to display the members’ signature specimen for verification against loan form.


45

The system should be able to verify if all listed guarantors are eligible by use of the following criteria :

• Guarantor is not dormant or inactive;

• Has not guaranteed more than X (Variable) loans;

• Has not defaulted on any of his/her current loans; and

• Guarantor shares are sufficient to cover the proposed guarantee amount.

• All fees, commissions and insurance payable should be listed

The system should be able to notify guarantors via SMS of the loan amount they have guaranteed and member whom they have guaranteed.

The system should allow for a loan application to be rejected at any stage and allow for reject comments.

The system should allow for a loan application to be placed in 'PENDING' state and allow for comments on reasons.

The system should prompt officers to action loans that have been in 'PENDING' State past a specified duration of time.

The system should only submit a loan application for appraisal / Processing if it has met all conditions stipulated and checklist has been verified as

submitted.

The system should have a customizable workflow and be able to show the current state of the Loan processing and action being performed

dependent on the loan product e.g. Emergency loan, normal loan etc.

The system should be able to track all the approvals done on a loan as per the lending policy and authority matrix before the loan account is

created.

System should not allow creator of a loan to approve or disburse the loan. It should require an approval by an authorized person before

disbursement of the loan.

The system should be able to enforce a minimum shares contribution amount

The system should be able to adjust pro rata contributions automatically depending on the loan applied by the member and consent obtained from

the member in the application form.


46

The system should be able to generate unique loan account numbers based on set algorithm.

Reports

Ability to generate reports on all loans applied, approved, pending, rejected including comments and categorisable region, officer or period.

List of all loan applications received compared to applications successfully vetted categorisable by region, officer or period.

4.2 LOAN APPRAISAL

The system should be able to capture the Vetted Loan application.



The system should be able to allow appraisal officer to modify the following :

• The repayment period/schedule ;and

• The Loan Amount

The system should be able to notify the members if the loan appraised is less than (variable e.g. 75%) of the applied amount.

The system should allow for the online approval of the loan applied by the appraiser.

The system should allow the appraiser to reject, insert comments and / or send back the loan application for correction if need be.

The system should be able to vary the levels of approval required depending on the loan amount requested.

The system should be able to send an auto notification to the disbursement officer after approval.

The system should allow the appraiser to view all of the applicants’ liabilities with Viktas Sacco. i.e. Business Loans, FOSA liabilities, contribution history,

Back Office loans , loans guaranteed, guarantor details etc.


47

The system should generate a repayment schedule based on loan amount, repayment period, interest rate and type of loan.

All actions on a loan application should be tracked via workflow - clearly showing what stage the application has reached and the pending action.

All actions on a loan applications should be recorded and available on the audit trail.

The system should facilitate approval of loans to be distributed based on requested amounts to allow for senior officers to concentrate on high risk

and other strategic operations

Modification to the repayment schedule should after approval should require extra approval.

Reports

Approved Loan application.

Periodic report of all loans approved, rejected, deferred, rerouted for correction.

4.3 LOAN DISBURSEMENT

The approved loan applications are the inputs of this process.

The system should allow the approver to view all approved loans.

The system should allow for individual and batch disbursement of approved loans.

The system should disburse loans to member accounts on the click of a button.

The system should be able to notify the member on disbursement of the loan via SMS/ email/letter.

The system should be able to disburse loans against an allocated vote head.

The system should be able to capture the time taken for a whole loan process - this will be used for internal assessment of efficiency and turnaround

time between processes and milestones the application goes through at any particular time.

The approver should not be the same person disbursing the loans.

The person disbursing the loan should not have any rights to amend the approved details


48

Loans should be disbursed against a vote head to allow the Sacco to generate reports on monies allocated for loans, disbursed and committed.

This will also prevent over disbursement of funds.

Reports

The system should be able to provide a report of all the loans written off

The system should be able to provide reports on risk concentration of loans by credit officer and by product or business (e.g. classify defaulted

loan by officer/region etc.)

Report on loans disbursed ordered by Type of loan, period disbursed, gender , repayment period etc.

4.4 DEBT COLLECTION

The system should be able to obtain the following information from the payments posted to MPA from a payment schedule :

• Amount Posted and corresponding cheque/receipt number;

• By Product Identifier / Code ;

• Employer ID; and

• Date posted.

The system should be able to obtain the following information from the updated cash book :

• Cheque Number / Deposit ID / receipt number;

• Cheque Amount;

• Employer Name / ID ; and

• Date posted.




49

The system should be able to compare cash received for loan repayments vis-à-vis expected payments and customers advised accordingly.

The system should be able to prioritize interest and principal repayments when cash is received at the teller. The distribution of such cash should be

automated, and can be customizable.

The system should be able to compare the total value of the amounts posted to MPAs from a payment schedule submitted by an employer with the

Total value of the Cheque in the cash book. This applies to check-off members

The system should be able to identify by products that have no corresponding cheque deposits / entries in the cash book.

The system should be able to identify cheques/ entries in the cashbook that have been over / under allocated to member accounts.

Reports

• Report of deposits missing from cash book;

• Report of Cheque Under allocation; and

• Report of Cheque Over allocation.

4.5 RECOVERY OF DEFAULTED LOANS

The system should facilitate sending of warnings via sms/email/ mail to :

• the defaulter in the first month;

• the defaulter and the guarantors in the second month of default; and

• the defaulter and the guarantor when the loan has been attached for repayment in the third month.

The system should be able to re-amortize the loan balance remaining and distribute it to the selected guarantors in the specified proportions per

guarantor or evenly to all guarantors.

The system should retain evidence of a defaulted loan in a members account even after it has been attached to guarantors for repayment.

The system should flag the members account as a defaulter across all modules.


50

The system should allow for a returning defaulter to resume repayment of a defaulted loan.

The list of guarantors should be readily available in the system.

The system should allow Each guarantor to be enrolled with a specific percentage according to their shares and the system should recalculate how

much of the remaining loan amount is allocated to them or be able to assign the whole amount to the guarantor..

The system should allow for guarantors to be refunded after member has resumed repayment for 3 consecutive months.

The system should allow monitoring of defaulted loans and generate Reports on defaulted loans which are not being repaid by the guarantors.

Reports

• Defaulted loans report;

• Activity on Defaulted Loans;

• Attached loans report; and

• Arrears Reports.

Prepaid loans report

Loan transactions list

4.6 BRIDGING OF LOANS/REFINANCING/RESCHEDULING

The system should be able to capture the following details from the loan form:

• The name of the Individual;

• ID Number

• Member number;

• The previous loan amount and reference number;

• The type and amount of loan applied for;


51

• The loan balance after clearing;

• loans interest rate; and

• Finance/Credit Approval.



The system should be able to clear the previously held loan at a fee of (X %( adjustable)) of the loan amount.

The system should be able to bridge member loans automatically.

The system should allow for refinancing / rescheduling of existing loans (any SACCO loan/advance) at a fee (adjustable) in respect to the value of the

loan.

The system should be able to update the loan balances in the MPA after relevant computation of loan balances and the interest rates on the loans

automatically during refinancing/ rescheduling or bridging of loans.

Reports

The system should provide a report on all the loans cleared with the following details:

•The name of person taking the loan;

•The Members number;

• Loan type;

• Loan amounts; and

• Date of loans.

The system should provide a report on the new loan balances of each member after the bridging. The report should have the following details:

•The Name of person taking the loan;

•The Members number;


52

•New loan balance ; and

•Date of loans.

The system should be able to give bridging reports per member, loan type etc.

The system should be able to provide a report showing the reasons for rescheduled loans, and who approved it.

4.7 CHATTELS REGISTRATION

Register chattels with fields to capture : chattel type, serial number, value, depreciation, net value, amount charged, insurance policy number

Attach files pertaining registered chattels


53

5.0 FOSA & OPERATIONS

5.1 CASH DEPOSITING PROCEDURES.

The system should be able to capture the following additional details regarding cash deposits from the customers:

• Member names;

• Member number;

• Deposit date and time;

• Type of deposit;

• Amount deposited;

• Currency;

• Cashier name;

• Cashier staff number; and

• Authorizations (if any).



The system should be able to check if the cash deposit is within the allowed teller limit.

The system should be able to trigger an alert to chief cashier/ FOSA manager for approval before the transaction proceeds if cash deposit is not within

teller limit.

The system should be able to give teller cash deposit limits at individual or user group level.

The system should be able to provide for chief cashier/ FOSA manager authorization of a transaction that is above the teller limit and revert back the

limit to prior state.


54

The system should be able to facilitate ATM cash deposits.

The system should be able to display/ show relevant customer verification information online e.g. signature, images, Customer photograph, other

biometric details.

The system should be able to update and display updated account balances immediately after every posting.

The system should be able to specify charges per account and per cash management product.

The system should be able to waive / exempt charges with appropriate user access levels (eg for staff accounts).

The system should be able to allow tellers to view cash transfers on screen.

Reports

The system should be able to provide a report of cash deposits over a given period of time, amounts with the following details:

• Member names;

• Member number;

• Type of deposit;

• Deposit date;

• Deposit amount;

• Currency;

• Authorizations (if any); and

• Cashier staff number.

The system should be able to provide summarized reports such as cash deposits per cashier, deposits exceeding certain amounts.

5.2 CASH WITHDRAWAL PROCEDURES

The system should be able to capture the following details regarding cash withdrawals by the customers:


55

• Member names;

• Member number;

• Withdrawal date and time;

• Amount withdrawn;

• Cashier name;




Ability of the system to show customer photograph and other identification details on screen upon calling the account.

The system should be able to allow a teller to post withdrawal amounts into customer accounts, and automatically update all the other relevant

accounts.

The system should be able to check if the amount being withdrawn is within the teller limit for withdrawal.

The system should be able to trigger an alert to Operations/Branch manager for approval if withdrawal is above a teller limit.

The system should be able to send alert to customer on any withdrawal or activity on his account through SMS, email etc.

The system should be able to enforce, minimum balances, number of maximum withdrawals and withdrawal limits.

The system should be able to generate an alert if a payment will result in account balance being below the set minimum.

The system should be able to prompt for authorization if the withdrawal amount is more than KES xxxxx (Variable to be specified)

The system should not allow overdrafts unless it has been authorized.

The system should be able to automatically generate a voucher/receipt indicating the amount withdrawn.

Reports

The system should be able to provide a report of the cash withdrawals made with the following details:


56

• Member name;

• Member number;

• Date and time of withdrawal;

• Amount withdrawn;

• Authorization (if any); and


The system should be able to provide reports such as withdrawals made per cashier etc.

5.3 ATM CARD PROCESSING

The system should allow for the update of the member record to indicate that the ATM card for that member is ready to be collected.

The system should be able to send SMS messages to the customer indicating that their ATM card is ready for collection.

The system should allow for the update of the member record to indicate that the ATM card has been collected by the member.

Reports

The system should allow the generation of a report providing details of new account holders who have applied/require ATM Cards. The report is then

sent to the ATM card provider. The report should contain the following details:

• Member Name;

• Account number;

• ID number; and

• Request date.


57

5.4 ATM WITHDRAWALS SETTLEMENT PROCEDURES

The system should allow the capture of ATM accounts within the organization's chart of accounts.

The system should allow for withdrawal transaction bill details from partner Bank to be captured within the system. The following details should be

captured.

• Member name;

• ATM number;

• Date; and

• Amount withdrawn.

ATM withdrawals should trigger an SMS notification to the member



The system should be able to update ATM account balances with the figures presented by partner Bank

The system should facilitate the creation of a payment voucher with the amounts used from the ATMs.

Reports

The system should be able to generate reports indicating the ATM billing amounts received from partner Bank, as well as the repayments made by

Viktas Sacco to the bank. The report should contain the following fields:

• Amount billed;

• Amount refunded; and

• Date of billing.


58

5.5 REFUND PROCESSING PROCEDURES.

The system should be able to capture the following details regarding from the refund payment sheet:

• Member number;

• Member names;

• Customer Account number; and

• Refund amount.

The system should be able to capture the following refund payment details:

• Payment date;

• Customer Account number;

• Cheque number;

• Amount paid; and

• FOSA officer staff number.



The system should be able to automatically credit the customers’ account with the refund amount indicated.


The system should be able to reconcile the cheque /amount received from finance with the refund schedule amounts posted.

Every refund payment shall be associated with a FOSA officer enhancing accountability.

The system should be able to inform the member via text or email after refund processing is complete.

Reports


59

The system should be able to provide a report of the refunds payments made (per member, per period, per FOSA staff member) with the following

details:

• Member name;

• Member number;

• Refund amount;

• Date of payments;

• Cheque number;

• Account number; and

• FOSA officer staff number.

5.6 STANDING ORDER PROCESSING PROCEDURES

The system should be able to capture the following details regarding standing order request:

• Member details(Names, Member number);


• Standing order details;

• Amount to pay;

• Execution date;

• Account number to pay; and

• Frequency of payments.




60

The system should be able to debit the standing order amount in the customer’s account after every payment.

The system should be able to automatically process the standing order in the frequency specified by the member(e.g. monthly, weekly etc)

The system should be able to stop the standing order payments on instruction from the customer.

The system should be able to facilitate the payments to the various accounts as indicated In the standing orders(e.g. repaying internal loan / advance/

external loans etc.)

The system should be able to allow the customer to submit standing order instructions through an online portal.

The system should be able to set standing orders and automatically charge the specified fees on every transaction.

The system should be able to notify the member of a failed standing order and reason of failure via SMS.

Standing orders should not be processed in case there is no money in the members account.

Reports

The system should be able to provide a report of the standing orders made(e.g. per customer, per month) with the following details:

• Member name;

• Member number;


• Standing order amount;

• Payment date;

• Cheque number;

• Frequency of payments; and

• Charges amount.

The system should be able to provide a report of the standing orders that have been unsuccessful and reasons for failure.


61

5.7 FOSA LOANS PROCESSING PROCEDURES

The system should be able to capture the following details regarding the FOSA advance applicant:

• Name of applicant;

• Member number;

• Account number;

• Amount of advance applied;

• Reason for the advance;



The system should be able to compute the customer’s ability based on the advance applied for.

The system should be able to accept or reject the advance application based on the customer's ability.

The system should be able to post the FOSA advance amounts in the customer’s MPA account and populate the affected accounts with the correct

balances

Reports

The system should be able to produce a report of the advances granted per customer with the following details;

• Name of customer;

• Member number;

• Date of advance;

• Amount advanced;

• Approved by.


62

The system should be able to provide a report of the rejected FOSA advances.

5.8 DIVIDEND PROCESSING PROCEDURES.

The system should be able to capture the following details regarding the dividends to be paid to members:

• Amount due;

• Member number; and

• Account number;



The system should be able to calculate dividends due to members.

The system should be able to credit the members’ MPA account and debit the Dividends control account.

The system should be able to recover dividend in advance where applicable.

The system should be able to facilitate the payments of the dividends to the customers.

Reports

The system should be able to provide a report of the dividend processing per customer with the following details;

• Full names;

• Member number;

• Dividend processing details;

• Dividend in advance recovered;

• Dividend processing fee;

• Amount of dividend paid; and


63

• Payment date.

The system should be able to generate an exception reports when processing dividends and the reasons for failure.

5.9 FIXED DEPOSIT PROCESSING PROCEDURES.

The system should be able to capture the following details regarding fixed deposits from the customers:


• Member number;

• Fixed deposit amount ;

• Agreed period;

• Interest rate;

• Roll over details (if any);

• FOSA officer's name; and

• Staff number.



The system should be able to raise a fixed deposit receipt certificate having the terms and conditions upon successful processing of a fixed deposit.

The system should be able to deduct any interest earned on a fixed deposit if it is withdrawn before maturity;

The system should be able to roll over the principal amount plus the interest (by default) when no instructions are received from the customer.

The system should be flexible enough to allow the modification of interest rates, penalties and fixed deposit accounts upon authorization by higher

management.


64

The system should be able to facilitate fixed deposits inform of cash or transfer of the amount to be fixed from savings account to fixed deposit

account.

The system should not allow modifications to the fixed deposit account parameters (e.g. interest rates, minimum periods) before the maturity of the

deposit.

The system should not allow deposits or regular withdrawals to be made to the fixed deposit account before the maturity of the deposit unless relevant

approval is obtained

Reports

The system should be able to provide a report of all the fixed deposits made by the customers:

• Customer names;

• Member number ;

• Amount;

• Agreed Period;

• Interest rate;

• Roll over details (if any);

• FOSA officers name; and

• Staff number.

The system should be able to provide a report of the number of fixed deposit account holders.

5.10 DEFAULTED FOSA LOAN PROCESSING PROCEDURES

The system should be able to capture the following details regarding defaulted advances:



65

• Member number;

• Customer address;

• Customer phone number;

• Advance number;

• Advance allocated ;

• Advance balance;

• Repayments details/schedule;

• Guarantor names; and

• Guarantor contacts.



The system should be able to send the first defaulter’s notice to the loanee immediately after the default.

After one month the system should be able to send the second notification to both the loanee and the guarantors.

At the end of 2nd month, the system should be able to send the third and final notification to both the loanee and Guarantors.

In case of a default the system should be able to transfer liability to the guarantors

After a default the system should be able to flag the customer as a defaulter.

The system should be flexible to facilitate the repayment of advance defaults by the guarantors e.g. by cash ,payroll deductions

Each advance/defaulted advance should have a unique number /identifier to enable tracking of the repayments.

Reports

The system should be able to provide a report of the guarantors repayments of the defaulted advances with the following details:

• Guarantor names;


66

• Guarantor member number ;

• Repayment details;

• Advance balance;

• Defaulter name; and

• Defaulter member number.

The system should be able to provide a report of all the advance defaulters

5.11 BANKERS’ CHEQUE PROCESSING PROCEDURES.

The system should be able to capture the following details regarding the bankers cheque processing:

• Member names;

• Member number;

• Member account number;

• Cheque amount; and

• Payee name.



If funds are available in the members account the system should be able to automatically debit the members’ account and credit the bankers’ cheque

control account.

The system should facilitate the purchase of a banker’s cheque using cash.

The system should be able to monitor the amounts that a customer is transacting for detection of exceptional activities or behaviors.

The system should be able to reject any banker’s cheque processing in case there is insufficient funds in the members’ account.


67

The system should be able to process the relevant charges in bankers Cheques transactions.

Reports

The system should be able to provide a bankers cheque transactions report with the following details:

• Member number;

• Member name;

• Member account number;

• Cheque number;

• Cheque amount; and

• Payee name.

The system should be able to provide a report of the rejected/ failed bankers cheque transactions

5.12 POSTING OF CHEQUES

The system should be able to capture:

• Cheque deposited; and

• Payment schedule.



The system should be able to accept Cheques deposited by members via the Cashier.

The system should have the ability to capture cheque details exhaustively- MICR details, amount, account name, date etc.

The system should have the ability to track the status of a cheque online.

System should be able to generate a receipt as an acknowledgement to the customer that cheque has been received.


68

The system should have the ability to provide an interface to allow counterchecking details of cheques captured and provide appropriate approvals.

For institutional cheques, the system should be able to use attached payment schedules to apply breakdown of the amount to the respective member

accounts.

The system should not allow over allocations of cheque amounts.

Cashier should be able to deposit funds from personal cheques into member accounts.

The system should prompt for unallocated cheques to be actioned on after a specified duration of time.

Reports

• Under posted cheque report;

• Non Cleared cheque report.;

• Daily Cash received report;

• Total Cheques received and banked; and

• Cheque allocation report.

5.13 TELLER’S CASH REPLENISHMENT PROCEDURES.

The system should be able to capture the following details when a teller is given a cash float.

• Cashier name;

• Cashier staff number;

• Time of request;

• Current float;

• Amount given;

• New float amount;


69



The system should be able to facilitate online cash replenishments by the tellers

At every end of day, the cashier's balances should be zero.

The system should be able to send an alert to the teller and also the main cashier/ Fosa manager when a teller exceeds a specified amount of float.

The system should be able to provide triggers on reorder level limit to both the teller and chief teller/Fosa Manager.

The system should be able to allow online request and approvals of cash float.

The system should be able to trigger reviews and approvals of cash float request.

The system should be able to allow continued transactions even after triggers on reorder levels.

The system should be able to block the teller from transacting beyond their float limit

Reports

The system should be able to provide a report of cash deposits and withdrawals by the cashier and should give a net position of the teller's float to

help determine whether the teller needs replenishment.

The system should be able to provide a report of the cash replenishments by cashier with the following details:

• Cashier name;

• Cashier staff number;

• Replenishment details;

• Time of replenishment;

• Amount replenished;

• New float amount.


70

5.14 CHEQUE RECEIVING AND PROCESSING PROCEDURES.

The system should be able to capture the following additional details regarding cheque deposit by the customer:

• Member number;

• Member names;

• Transaction date and time;

• Cheque number;

• Date of the cheque;

• Cheque amount;

• Payee details;

• Drawee details;

• Payee account number;

• Cashier name;





Ability of the system to show customer photograph and other identification details on the customer's profile.

The system should be able to automatically generate a receipt to acknowledge cheque receipt.


The cheque amount deposited should be suspended until the cheque matures and is cleared.


71

Reports

The system should be able to provide a report of the cheque deposits made with the following details:

• Member name;

• Member number;

• Date and time of transaction;

• Cheque number;

• Cheque amount;

• Payee details;

• Drawee details;

• Payee account number;

• Cashier name; and


The system should be able to provide reports such as cheque deposits made per cashier, per customer , cheque deposits exceeding certain amounts

etc.

5.15 VERIFICATION OF TELLER TRANSACTION PROCEDURES.

The system should be able to automatically reconcile the cash balance as per the GL and the teller’s accounts at every close of day.

The system should be able to note and give an alert of any variances in the reconciliation.

System to allow tellers to make electronic requests for close out with difference after day end balancing with the appropriate approvals.

The system should be able to post the discrepancy transactions to relevant GLs with the appropriate approvals.


72

Reports

The system should be able to provide reconciliation reports of the teller transactions.

The system should be able to generate report on list of discrepancies and correction actions taken.

The system should be able to keep track of the variances in the reconciliation and the corresponding corrective action.

5.16 MOBILE BANKING

The system should be able to capture the following details about the member to enable activation of the Mobile service:

• Full names;

• Member number; and

• Phone number.



The system should be able to provide the following services to the members:

• Balance inquiries;

• Cash deposits / withdrawals; To and from MPESA

• Funds transfer; to internal accounts or EFT/RTGS

• Bills / utility payments; and

• Changing of pin.

• Airtime purchase

• Mini statement requests


73

• cheque book requests

• Loan balances

• Apply for e-loans

The system should be able to update and display updated account balances immediately after every posting done.

Reports

The system should be able to integrate with mobile banking and provide summary reports to the management on all the transactions done including:

• Balance enquiry summary reports;

• Cash deposits / withdrawals summary reports;

• Funds transfer reports;

• Utility payment reports; and

• Number of users.

5.17 TERM DEPOSITS

The system should be able to send SMS/email alerts 1 week (or any other defined period) prior to maturity of term deposits to relevant personnel.

A report on all matured term deposits with no renewal instructions

A daily update on rates the front officers should use for term deposits as set by the Finance Dept daily – automated process.


74

5.18 UNCLEARED EFFECTS ADVANCES

The system should be able to advance a percentage of the value of uncleared cheques from specific drawers/issuers

Control

Create a database of all issuers against whom such advances can be considered

Such a list can only be updated/edited from the Finance Dept

The system should automatically confirm from this list when an application/request is received from a branch officer

There should be a clear authorization level from the branch before disbursement

The system should be able to use a predefined criteria on the pre-approved membership application process.

The system should have customizable user fields to suit the Sacco business requirements

5.19 MANAGING DECEASED MEMBERS/WITHDRAWALS

The system should be able to manage the process from when a member dies, to when the next of kin lodges a claim.

The process

Notification of death to the Sacco

List of kin(s) or beneficiaries

Dates on when claims have been lodged with the Insurance company

Tracking SLA of claims lodged with insurance company

Track all payments from the insurer payable to the next of kin

Create and manage all insurance/welfare schemes payable to members on death.


75

There should be a functionality where there is a checklist created to assist Sacco officers handle claims that have all duly attached requirements to

fulfill all legal requirements and reduce risk and payment to ineligible beneficiaries.

Payments should only be done to legally acknowledged next of kin

There should be a functionality where the next of kin can be a registered members so that all benefits payable are transferable

Reports

All claims made to the Sacco

All claims to the insurer outside the SLA


76

6.0 HUMAN RESOURCE MANAGEMENT

6.1 STAFF PERSONAL DETAILS (BIO DATA)

The system should be able to capture the following details in regard to staff:

• Full Names;

• National ID Number;

• Gender;

• Employee passport photos;

• Age/Date of birth;

• Date of employment;

• Phone Number;

• Physical Address;

• Job title and grade;

• Nature of employment(Contract/permanent);

• Department;

• Academic/Professional Qualifications;

• NHIF details;

• NSSF details;

• Employee PIN Number;

• Next of kin details(Names, ID Numbers/Birth certificate); and



77


The system should be able to automatically produce a list of all the available vacancies in all the departments based on any employee dismissal or

department needs.

The system should be able to issue a staff number automatically after all the member details have been captured and verified in the system.

The system should be able match the employees’ age and match it with the retirement age of 60 years to ensure that all employees retire at the

required time.

The system should maintain ex-staff (Staff who have left the Sacco) list and be able to reference against the list during enrolment of new staff.

Reports

The system should provide a report of all the newly employed staff as at a particular date or period specified.

Employee reports based on grades and qualifications attained:

Employee reports based on the Sacco departments.

A report on the standard establishment per department including unfilled positions (gaps)

The system should be able to provide a report of Next of kin:

The system should be able to provide employee reports:

• By department; and

• By position.

The system should be able to provide ex staff reports.


78

6.2 PAYROLL PROCEDURE

The system should be able to capture the following details for use within the payroll:

• Full names;

• Staff numbers;

• Job titles;

• Job groups;

• Staff remuneration details;

• Loans and their repayment details;

• Details of advances;

• Bank Account changes;

• Details of basic salaries;

• Details of Allowances; and

• Details of deductions.

The system should be able to capture the adjustments in staff remunerations and benefits as indicated in the collective bargaining agreement and to

accommodate legal changes:

• Changes to the basic salary;

• Changes to allowances; and

• Taxation changes.




79

The system should be able to produce printed and soft copy pay slips for all the staff members based on the information captured about the staff.

The system should be able to backdate the staff salaries and benefits.

The system should be able to print a particular staff's pay slip at the staff’s discretion

The system should be able to restrict changes to staff pay details only to authorized personnel.

The system should be able to limit the remunerations of the staff members based on the assigned job groups. The system should allow exceptions in

the case of negotiated salaries.

The payroll should be integrated with the GL and require reconciliation, approval and verification prior to effecting the period's/month's payroll.

The system should be able to restrict the amount of basic salary committed to no more than 2/3 of the basic pay. However exemptions should be

provided upon approval by higher authority.

The system should be able to effect statutory deductions and prepare remittances to relevant authorities e.g NHIF, NSSF, KRA etc

Reports

The system should be able to provide a summary of the changes to the payroll and details of each change.

The system should be able to provide a list of all the earnings and deductions per department with the following details;

• Department Name;

• Department code;

• Total earnings;

• Total deductions; and

• Net amount.

The system should be able to provide a pay slip report with a breakdown of all the amounts for each of the staff based on the information captured by

the system. It should have the following details:

• Full Names;


80

• Staff Number;

• Job title and designation;

• Job group

• Basic Pay;

• Allowances details;

• PAYE Amounts;

• Deductions details(e.g. loans interests);

• Relief; and

• Net Pay amount.

6.3 PERFORMANCE APPRAISAL

The system should be able to capture the following details from the staff plan:

• The period Involved;

• Name of the department; and

• Specific targets details.

The system should be able to capture the following appraisal details of every staff member:

• Staff full names;

• Staff number;

• Job title;

• Targets set


81

• Appraisal details/appraisal ratings;

• Appraiser name; and

• Appraiser staff number.

The system should be able to capture the appraisal ratings and recommendations for promotion/demotion/commendation/reprimand for every staff

at the end of the appraisal process

Reports

The system should be able to generate appraisal reports per department with the following details:

• Name of the department;

• Date of Appraisal;

• Appraisee Name;

• Appraisee staff Number;

• Appraisal details;

• Appraiser Name; and

• Appraiser staff Number.

The system should be able to generate monthly, quarterly and annual appraisal reports.

6.4 TIME MANAGEMENT

The system should be able to interface with the biometric/ IP addressing system to extract the following details:

• The Name of employee;

• Staff number;


82

• Job title

• Daily Entry time;

• Daily Leave time; and

• Overtime hours.



The system should be able to interface with others systems (the Sacco already has a biometric system) for tracking time management.

The system should be able to allow payments overtime hours based on the CBA (collective bargaining agreement) after approval by the head of

department.

The system should allow the option of converting of the overtime hours into leave days.

Reports

The system should be able to give time reports for the staff members having the following details:

• Full Names;

• Staff Number;

• Job Title;

• Total hours worked; and

• Overtime hours.

The system should be able to give an exception report on the staff members who have not achieved the required office time with the following details:

• Full Names;

• Staff Number;

• Job title;


83

• Total Hours Worked; and

• Deviation from the expected time.

6.5 ACTING APPOINTMENT

The system should be able to capture the following details regarding acting appointment:

• Full names;

• Staff number;

• Acting department;

• Acting position;

• Acting start date;

• Acting end date; and

• Acting allowance.



The system should be able to give an acting appointment notification to the relevant head of department when a staff member applies for leave for

more than 30 continuous days.

Once the appraisal for confirmation has been accepted by the board, the change should be effected in the system and the status of acting appointment

is removed.

Reports

The system should be able to give a report of all the people acting at particular time with the following details:


84

• Full names;

• Staff number;

• Department;

• Job title;


• Acting duration; and

• Acting history.

The system should be able to give a report of all the Acting positions at any time:


• Acting staff name;

• Acting staff member number;

• Department; and

• Acting duration.

The system should be able to give a summary of all the people who have acted and how many times the staff has acted. The report should have the

following details:

• Full names;

• Staff number;

• Acted positions; and

• Frequency of acting.


85

6.6 PROMOTION AND UPGRADING

The system should be able to capture the following details regarding promotion and upgrading:

• Full names;

• Staff number;

• The new position after promotion;

• The new job group; and

• The new salary.

The system should be able to capture the following details:

• Exceptional/ Poor performance by the staff members; and

• Corresponding rewards or retributions.



Upon selection of the staff name/staff number the system should be able to retrieve the staff’s details.

The system should be able to update the staff’s salary to reflect the new position with relevant approval stages.

Reports

The system should provide a report on the staff members who have been promoted with the following details:

• Full Names;

• Staff Numbers;

• Previous Position;

• Previous Job Group;


86

• New position; and

• The New Job group.

The system should be able to give a report on the minimum qualifications per job post. The report should have the following details:

• Job Position;

• Job Position code;

• Job group category;

• Minimum Qualifications; and

• Job responsibilities.

6.7 STAFF TRAINING

The system should be able to capture the following on the staff training:

• The staff training needs;

• Names of the staff approved for training;

• Names of staff who have not been approved; and

• Training calendar

The system should be able to capture the details of trainings done by all the staff:

• Staff full names;

• Staff number;

• Training attended;

• Institution name;


87

• Training start date;

• Training end date; and

• Training cost.



Reports

The system should be able to produce a report of the staff who have undergone training with the following details;

• Full Names;

• Staff Number;

• Department;

• Training Attended;

• Duration of the training;

• Institution of training; and

The system should be able to produce a report of the staff members who fail to be approved for training with the following details;

• Full Names;

• Staff Number;

• Department;

• Name of training; and

• Duration of training.

The system should be able to produce a historical report of all the training attended with the following details;

• Training Name;


88

• Training Duration;

• Full names of staff trained; and

• Staff numbers.

6.8 LEAVE MANAGEMENT

The system should be able to capture the following details regarding leave applications:

• Full names;

• Staff number;

• Type of leave (i.e. Annual leave, sick leave, maternity leave and paternity leave, compulsory leave)

• Leave description;

• Number of Leave days Applied for;

• Reason for Leave;

• Date of Commencement; and

• Date of leave termination.

The system should be able to create new leave types and allow users to edit existing leave types:

• Leave name;

• Leave type description;

• Leave type gender restriction (i.e. Male Only, Female Only or Both);

• Maximum number of leave days allowed for that Leave type.



89


The system should be able to calculate the balance of leave for the staff members after every staff leave granted.

The system should be able to convert any overtime hours into leave days upon request from the staff.

The system should be able to compute the leave allowance for the staff that who been members of the Sacco for more than 3 months.

The system should be able to accrue leave days at the mid of every month based on the various accrual rates of the different grades of staff.

The system should be able to provide a report to the HR after a staff goes for a sick leave for more than 6 months, after which the staff salary should

be halved. After 12 months the staff should not receive any pay.

The system should not allow male staff to go for maternity leave or female staff going for Paternity Leave

There should be clear approval levels as per Sacco policy

Reports

The system should be able to provide leave reports by each leave category with the following details:

• Type for leave;

• Full Names;

• Designation;

• Staff number;

• Leave start date;

• Leave end date;

• No of leave days; and

• Leave balance.

• Rejected leave report.

The system should be able to provide a report of the number of staff on leave at a particular time.


90

The system should be able to provide costing reports of the leave days to help the Sacco in effective leave management.

The system should be able to provide a sick leave report by the number of days the staff has been out of office.

The system should be able to provide a report the leave accumulations/balances per staff member.

6.9 STAFF LOANS AND ADVANCES

The system should be able to capture the following details from the loan application form:

• Full names;

• Staff number;

• Loan type;

• Amount of loan applied;

• Repayment amounts;

• Repayment period; and

• Guarantor details;

Reports

The system should be able to provide a loan report by staff member with the following details:

• Full names;

• Member number;

• Designation;

• Department;

• Principal loan;


91

• Interest accrued;

• loan balance; and

• Repayment details.

The system should be able to provide a report of the loan defaulters and those underpaying their loans.

The system should be able to give a report of cumulative loan amounts taken by the loan products/types.

The system should be able to provide a historical report of the advances and loans given to staff member.

The system should be able to provide a loans/advance report per staff member.

6.10 DISCIPLINARY AND GRIEVANCE HANDLING

The system should be able to capture the following details on disciplinary and grievance cases:

• Staff names;

• Staff number;

• Date of offence;

• Offence description;

• Offence category (predefined); and

• Board's decision.



The system should be able to alert the CEO or any other official of any repeated cases by the same employee.

Reports


92

The system should be able to provide historical disciplinary report by staff member with the following details:

• Full names;

• Staff number;

• Designation;

• Department;

• Offence description; and

• Boards decisions.

6.11 EXIT PROCESS

The system should be able to capture the following details on the exit process:

• Staff number;

• Staff names;

• Exit date;

• Exit Type (i.e. Resignation, Summary Dismissal, Termination of service in the society's interest);

• Exit interview screen/platform

• Reason for exit/description; and comments section

• Clearance status.



The system should be able to provide the relevant information to enable computation of the staff final dues.


93

The system should be able to exclude the employer’s benefits from the final dues in the case of a summary dismissal.

The system should be able to transfer any outstanding liabilities to the guarantors upon staff member's exit.

The system should be able to deactivate all the staff accounts whose members have left the Sacco.

The system should be able to log any activity from a deactivated account.

Activation of any deactivated account should require authorization by the management.

Reports

The system should be able to provide a report of all the resigned staff with the following details:

• Full names;

• Staff number;

• Designation;

• Department;

• Date of resignation;

• Reason of resignation; and

• Total dues paid.

6.12 RETIREMENT

The system should be able to capture the following details regarding staff retirement:

• Full names;

• Staff number; and

• Retirement date.



94


The system should be able to compute the period remaining before retirement and display it on the staff pay slip when retirement date is less than

(variable e.g 12 months).

The system should be able to provide the relevant information to the HR about the staff to enable computation of the final dues.

The system should be able to flag the staff account as retired and deactivate it after the retirement process is complete.

Reports

The system should be able to provide a retirement summary report by staff member with the following details:

• Full names;

• Staff number;

• Designation;

• Department; and

• Period remaining before retirement.

The system should be able to provide a report of staff who have already retired with the following details:

• Full names;

• Member number;

• Designation;

• Retirement date;

• Years of service; and

• Dues payment details.

The system should be able to provide a dues payment report by staff member.

The system should be able to provide a report of staff retiring on a particular date.


95

6.13 DEATH IN SERVICE

The system should be able to capture the following details about the death In service:

• Full Names;

• Staff number;

• Date of death; and

• Description.



The system should be able to deactivate the staff account upon confirmation of the death flag the staff account as death in service.

The system should facilitate the payment of the diseased person's next of kin/nominees.

After the nominees/next of kin are paid the system should be able to flag them as paid.

The system should be able to provide all the relevant information on the staff to enable computation of the final dues and payments to the

nominees/next of kin.

Reports

The system should be able to provide a report of all the staff members who have passed away with the following details:

• Full names;

• Staff number;

• Designation;

• Department;


96

• Date of death; and

• Amount paid to nominees.

The system should be able to provide a nominee/next of kin report by staff member:

• Full names;

• Member number;

• Department;

• Nominee/next of kin details;

• Full names;

• Id number/birth certificate number;

• Contact details; and

• Allocations.


97

6.14 MEDICAL INSURANCE CLAIMS

The system should be able to capture the following details about the insurance details per staff:

• Full Names of staff;

• Staff number;

• annual limit entitlement;

• Description of medical claim.

• institution staff has been treated

• claim amount

• Clarification whether claimant is staff of beneficiary (beneficiary should be in member bio data on official records)

The system should be able to provide statistics on claims management.

They system should allow user customizable fields to allow for scalability.

There should be clear authorization levels.

Reports

The system should be able to provide a report of all the staff members who have passed away with the following details:

• Running balances; ad-hoc

• Monthly, quarterly, annual reports.

• Cost benefit analysis.

• Trends in claims performance/management.


98

7.0 ICT AND SYSTEM ADMINISTRATION

7.1 SYSTEM INTEGRATION

The system should have ability to offer the following capabilities:

• All teller and FOSA operational support services including cash/cheque deposit, withdrawal and ability to support all retail /customer banking;

The System should have workflow capabilities i.e. presence of an end-to-end workflow

System should have the ability to generate triggers and alerts for both exceptional events and milestones within the workflow

The system should have a maker- checker for all transactions in the workflow

• Workflow management capabilities to support loan processing, account opening process and electronic approvals;

• Full financial analysis reporting module including accounts payable, receivables, profit and loss, balance sheet etc;

• Automated reconciliation capabilities/module;

• Credit scoring capabilities/module;

• Sales management capabilities/module;

• Business intelligence capabilities/module with ability to report cost/revenue/profitability/activities in various dimensions e.g.

profitability/cost/revenue per customer, per product, per segment, department etc;

• Cash management capabilities;

• Internet banking capabilities/module including integration to social media;

• Mobile banking capabilities/ module.

The should be able to provide full integration with the following systems:

• RTGS;

• Bank ATMs , VISA ;


99

• External standard audit and continuous monitoring applications;

• Microsoft exchange server;

• Network printers;

• mobile banking, M-Pesa (mobile Money services);and

• Online portal.

The system should be able to support XML technology that will facilitate integration with other systems.

The system should be able to maintain a unique member number included in the account number such that through the member number one can call

the different accounts/products embedded in it within the group. The customer can have several accounts but only a unique member number.

The system should be able to support remote access by staff members i.e. access member information/ register new members and to initiate

transactions through the internet, mobile or telephone with security consideration in place.

Ability of the system to support business growth in number of members, accounts and product range. The system should be scalable to accommodate

growth in customers’ numbers.

Ability of the system to be easily deployed to new workstations.

The system should be fully integrated to provide for:

• Real time and automated update of all transactions into accounts including fees and charges;

• Batch processing; and

• Both online and offline processing incase links are down ability of processing and synchronization of data, simultaneous on-line and batch processing.

The ability to be accessed and operated through a web browser (web based)using a PC, laptop, smart phone, ipad etc.

Multi-channel capabilities of the system and its ability to allow access using a large variety of mobile devices such as Ipad, phones, blackberry, laptops

etc and the internet securely.

The system should have the ability to support parameter driven settings including:


100

• Interest behavior and nature per account type;

• Creating and maintaining product group/ type definition;

• Service charges - account-based;

• Nature/ behavior of accounts;

• Menu and system security levels; and

• Service level agreements.

Ability of the system to allow product parameter set up including:

• Product code;

• Name;

• Expiry date;

• GL account code for the related balance sheet/P&L items;

• Interest accrual frequency;

• Minimum/maximum loan amount;

• Interest rates;

• Statement frequency;

• Type of security required;

• Collateral review frequency;

• Maximum/minimum installments;

• Allowed repayment modes;

• Appropriation sequence;

• The sequence in which funds credited; and


101

• The loan account shall be appropriated to the various arrears buckets etc.

The system should have the ability to generate an offer letter for each product with the relevant terms and conditions for that product.

Ability of the system to auto-schedule database maintenance tasks depending on defined parameters.


102

7.2 AUDIT TRAIL

The system should be able to log all events in the system and timestamp on them with no capability of switching off the functionality.

The system should be able to generate an exception report for any attempts to turn off the audit trail.

The system should have capability to allow filtering the logs e.g. by date, activity, username.

The system should be able to download data to other applications such as audit software (e.g. IDEA) in international standard formats.

The system should be able to provide audit trails that allow transactions to be traced from source documents, original input, other systems, system

generated transactions, and internal assignment transactions through the entire system.

The system's ability to show transaction details to support account balances.

The archiving facility should be able to store archived information as per the Sacco Policy and should have the ability to view archived or historical data

without editing.

The system should be able to correct out-of-balance conditions discovered during reconciliation process and maintain an audit trail of any such

corrections.

The system should have audit trails that allow complete tracing of data errors as well as results of the various operations of the system.

The system should be able to record the number, type, and amount of transactions received from each customer, including those transactions

generated by other systems.

The system should have an audit trail that will show changes made to the system's parameters and tables that would affect the processing or

reprocessing of any financial transactions and sending triggers on the same.

The system should be able to provide management with statistics to determine the functions, operations performed, and reports generated or

accessed by specific users.

The system should allow for fine grain auditing at the database level.


103

The system's backend audit module should be outside the core such that it does not affect performance of the core database i.e. capacity of updating

audit trails on tables outside core system in order to avoid clogging the system but at the same time have the best on audit trails.

7.3 SYSTEM BACKUP AND DATA RECOVERY

The system is to incorporate three environments - Live environment, Data Recovery environment and Test/development environment.

Ability of the system to support data recovery within a short period of time.

Ability of the system to support offsite back-up tools such as tapes and restoration back to live within a very short time.

Support for on-line backup.

Support for incremental & full backups.

System support / availability/ change control

The support should be able to support an uptime requirement of 99.999%.

The system should be able to support a 24/7/366 operational model with online capabilities throughout.

The system should be available for the ATM transactions on a continuous basis.

The system should be able to send alerts via email/SMS in case of unexpected events in the system.

The system should have a monitoring tool for its entire infrastructure such as application servers, UPS, databases, system availability and performance.

The system should be able work with various redundancy links and automatic failovers (two way).

The system should be able to support different types of network technologies such as fibre optic and Wimax.

The vendor is required to sign a software escrow agreement.

The system should have an alert function to notify management when licenses are about to expire.


104

7.4 SYSTEM UPDATES

The system should be able to support click-once technology for updates.

The system should be able to support a roll-back to a previous version in case a need arises.

The system update approach should ensure that updates do not result in distortion of existing modules.

The system should be able to allow database updates but with very stringent controls.

7.5 ACCESS RIGHTS

The system should only be accessible to duly authorized users, both at application and DB level. Access to the system will be limited to users with

defined user ids and passwords.

The system should be able to allow creation of users and assignment of the users to groups.

The application software should have a centralized code management and control system to ensure data integrity and uniformity throughout all the

application modules.

The system should allow the definition of a user ID that uniquely identifies a specific user e.g. first name. last name.

The system should allow the definition of user passwords with a minimum length, alphanumeric and special characters and password validity period.

The password should be encrypted so that it is not viewed when entered or stored.

The passwords should comply with best practice e.g. prompting of password expiration at least five (5) days before actual expiration.

The system should be able to maintain a record of all passwords used by users and ensure that any subsequent passwords are not too similar to earlier

ones.


105

The system should be able to establish a time-out limit. If a user has logged into the system and has not used the system for an established time frame,

the user’s session should be terminated. This time-out will require the user to re-enter their password before continuing.

When a user logs out, the system should be able to terminate any active processes that are associated with that user.

The ability for system administrator to log out users when necessary to perform maintenance or other activities that require users to leave the system.

Such log-outs should provide for an orderly shutdown of the client workstation.

The system should be able to disable log-on capabilities if unsuccessful password entry is attempted after a parameter-driven number of unsuccessful

attempts and provide for automatic notification to the system Administrator.

The system should be able to limit log-on of user IDs to one workstation at a time. If such functionality is enforced and the user attempts to log onto

a workstation while already logged on another, the system should provide a message that the user ID is already in use.

The system menus should not display application module, function and screen options for which the user does not have access.

A full log of all system activity and attempted security breaches.

Ability of the system to enforce changing of passwords upon demand.

The system should be able to allow the Sacco to define the customers’ IDs whose accounts can be accessed remotely, accounts whose transactions

cannot be accessed without approvals or controls to access any account in the Sacco.

The system should be able to provide straight through log-in to minimize duplicate maintenance of user-ids and passwords across systems.

The system should have the ability to support other security tools / modules e.g. tokens for internet access.

The system should be able to restrict user access (read only, read and write) depending on user login, to certain modules, functions, screens, fields.

The systems should be able to create user groups, and modify user accounts within certain controls.

The system should be able to support secure remote access.

The system should allow users to be assigned to groups. No user should exist without belonging to a group.


106

The system should be able to incorporate intrusion detection systems that send automated alerts via SMS and email when an attempted unauthorized

access occurs.

The system should be able to terminate user connections in case of network interruption.

The system should have a system Administrator, who shall be responsible for defining users and security access levels within the system, creation of

users and issuing of rights and should be under dual control.

The system Administrator should be able to define the time and days when the system is available to the user.

The system should have multi-level security controls to prevent unauthorized use of system and corruption of data, restrict access to the database,

maintain database process controls, and log all database transactions. The system should support access restriction capability.

7.6 SYSTEM FLEXIBILITY

The system should be able to ensure that each product has following status:

• Active;

• Passive (Inactive);

• Under-establishment (unfounded, Incomplete); and

• Cancelled (Closed).

The system should be menu driven such that all functions within the application are executed by use of menu options.

The system should have hierarchical menu options that can be easily changed by authorized officers at FOSA and head office level. The user defined

hierarchical transaction authorization level and reminder should prompt users incase specified activities are not carried out within specified period of

time.

The system should have automated event and activity triggers, escalation pop up screens that display account name and number during input,

processing and querying.


107

Ability of the system to refer transactions automatically to authorized approvers and be able to re-route transactions when the transaction is not

authorized after a user interval (across both FOSA and head office).

The system should be able to automatically alert the initiator of the transaction on approval/rejection/status of the transaction in all processes and

escalate further if no action is taken.

The system should be able to support easy and quick implementation of future internal, regulatory or market driven changes.

The system should be able to support hot keys for access to common functions.

The system should be able to support:

• Multi-windowing capability;

• Multi-session capability;

• On-line help facility;

• Context-sensitive help facility (Data input and validation at source);

• Tutorial and self-help;

• Error / action messages for wrong entries;

• Graphic capability; and

• The system should have consistent screen layouts, messages, keystroke handling and other elements of the user interface throughout the system.

The system should have flexibility to accommodate different rates for different products, countries etc.

Ability of the system to prompt for different levels of authorization on change of any system parameter.

The system should be able to support launching of new products with ease in a modular form as and when need arises.

The system should allow Additional fields in system modules when need arises.

The system should be able to compress/zip files.

The system should be flexible to allow loyalty program support (e.g. loyalty points accumulation).


108

The system should be able to support sending of bulk SMS.

The system should be able to schedule job and user tasks.

The system should allow the export of files to various formats e.g. txt, pdf, excel.

The system should be able to support built in International Calendar and the definition of:

• Generate future years based on current year;

• Holidays;

• Define business, non-Business day in a Calendar;

• Define posting rule for a given type of transaction in relation to the calendar; and

• Define holidays as regional, national, or local.

The system should be able to automatically allow for peer escalation or approval by a member within a group in case one member does not act within

required time.

The system should be able to generate a report on number of escalations, attempted escalations over a defined period of time.

7.7 REPORTING

Ability of the system to incorporate report builders e.g. crystal reports that are easy to use. The contents of a document/report including data items

and the layouts can be defined by the end-users.

For Ad hoc reports, the report utility shall allow the user to create new report logic and to save, modify, and delete pre-existing logic for data extraction

and printing. The mechanics of the report utility should be straightforward and easily learned.

The report writer should have a wizard to guide the users through report building steps.

The system should be able to generate reports in various formats e.g. pdf, word, excel.

The system should be able to generate accurate account statements at any time with the right controls in them.


109

The system should be able to generate reports automatically according to pre-defined criteria and frequencies.

The system should have a facility to view reports online before printing to any available printer and with quick report response time.

The system should be able to send alerts for reports not generated within a specified period of time.

The system should have the capability to extract and print selected information, with user control of the content and format of the extract file and/or

report.

The system should have the capability to accommodate both on-line/real time and batch report processing, so that time-consuming reports can be

generated after official working hours to avoid impact on computer performance during business hours.

The system should be able to generate reports on business performance. This includes profitability, revenue, cost per customer, per product, per

department.

The system should be able to support centralized and remote printing capabilities. The system should be able to print work over a low bandwidth

network or dial up connection.

The system should be able to create and support a standard reporting/inquiry library to meet routine reporting and analysis needs.

The system should be able to generate reports automatically immediately after the completion of a transaction, and/or according to criteria specified

by the end-users.

The system should be able to allow the users to decide whether to generate a document/report for a transaction or not.

The system should allow user to preview documents on the screen before printing.

The system should have the capability to print results of any inquiries.

The System should have the capability of printing system generated receipts that are prenumbered as well as banker’s cheques.

Reports to be structured in a way that allows for discretion on who can print certain reports and who can not.

The system should be able to print exceptional reports on unauthorized transactions for the day.

The system should allow for multiple or “select all” field selection for inquiry criteria.


110

Any field in the database shall be accessible by the report utility for extract and printing with the right controls.

The report utility should be able to support simple arithmetic functions (Addition, subtraction, multiplication, division) and calculation of percentages.

It shall also support grouping, maximum, minimum, average, mode median etc and ability to sort by ascending and descending order.

The system should be able to perform report formatting .The report utility should be able to provide both a report format default and manual override

that allows the user to control column headings and data arrangement on the report. The system should be capable of building an extract file based

on report utility selection and sort criteria, for easy loading to other software packages (e.g. word processing or spreadsheets).

The system should be able to allow access to reports according to the access groups.

The system should be able to define reporting schedules as required by users.

7.8 POSTING OF TRANSACTIONS

The system should be able to post transactions into the correct accounts.

The system should be able to allow posting overpayments into accounts.

The system should be able to send alerts on posting of transactions that are above or below the average transaction amount.

The system should only allow backdating of transactions on approval by the relevant officials.

7.9 SECURITY AND SYSTEM CONTROLS

Implementation of system logs to monitor the system activities.

Proper backup and recovery procedures.

Proper access rights assignments and monitoring.

Fine grain auditing at the database level.

Generation of Exception reports of unauthorized activities/transactions.


111

7.10 BRIDGE MANAGEMENT

The system should

The status should always be visible.

Admin should get SMS alerts when it’s not working properly

Admin should be able to track ISO messages to help in troubleshooting.

Error logs to assist in troubleshooting.


112

8.0 RECORDS DEPARTMENT

8.1 REGISTRATION OF MEMBERS

The system should be able to capture the following information from the member registration form:

• Member full names, Gender;

• Member Number;

• Current employer name and contacts;

• Current address;

• email address;

• mobile number;

• mandatory passport photo (scan or integrate camera with system);

• National ID number /Passport number;

• Introduced by; and

The system should provide an auto generated member number and enroll member in benevolent fund

The system should be able to capture the following information from the next of kin registration form:

• Name of kin as appears in the National ID / Birth Cert;

• Date of birth of kin; and

• Birth Certificate details / National ID number.

The system should allow the relation of the next of kin to be selected from a drop down menu indicating (In-Law, Child, Parent, Spouse).

The system should be able to capture the following information from the nominee form:


113

• Name of Nominee;

• Relation of Nominee to Member (drop down);

• National ID number /Passport number;

• Percentage of entitlement (all nominee entitlement to tally up 100%);

• Current address / email / mobile phone number; and

• Special instructions as advised by member.

The system should enable attachment of captured images hence merging the scanned information with the member register.



Each application is stored in 'pending' state until a complete list of required documents is forwarded to registry for verification and later,

Account activation.

The system should be able to facilitate updates to the member details

Historical information of the member should be viewable e.g. old address, old email etc.

The system should be able to have an audit trail of historical information keeping a record of :

• National identity card;

• pf no ;

• Address and all the changes made; and

• Issue date of id and the serial nos.

The system should be able to verify the Member Number / Birth certificate number / passport number / national ID number used for the

member is not already in the system.


114

The system should be able to alert the new member once the account has been successfully activated by Records department via , sms /

email or print a certificate for mailing.

The system should be able to define codes for cases for all categories i.e.:

• Active;

• Dormant;

• Deceased;

• Suspended / under investigation;

• Withdrawn; and

•Closed.

Each registration form should be linked to a physical file - the system should be able to generate a file number / name that will be linked to

the physical file for tracking purposes.

The system should be able to retain details of the current open volume and status of the earlier closed file volumes e.g. Archived or in SACCO

premises.

The system should be able to generate a daily membership report

The system should be able to limit access to nominee details to specific staff e.g CEO only.

The system should be able to enforce restrictions on BF details access and update and should not allow overwriting of the previous

information captured.

The system should be able to compare and validate the member details in the loan form with the details in the member register

The System should validate all identification information is unique upon entry.

The System should alert a user during customer profile creation if the customers’ profile already exists.


115

The system should be able to capture the details of the relationship officer /manager involved in the creation of a new account such as staff

name, staff number, date, time, workstation number (capture user activities in the creation process)

File numbers, BF Member numbers and Sacco Membership numbers should be generated from the system.

The system should restrict activation of member accounts to particular individuals e.g Only Records department

Changing of member identification information e.g. Name, Member Number, Bank account number should be limited to few staff and

require maker-checker approval.

The system should be able to send bulk SMS from the records desk to registered members.

The system should be able to send an alert to the customer as a text/ email when the customer's static data is changed with both the old

and the new values

Reports

Reports generated from the member registration include the following:

• Report of member registration per specified period grouped by various categories such as , Region, Member introduced by , gender etc.

Report on admissions received and worked on daily

The system should be able to provide reports on any activity or changes made on the member register/file.

8.2 MANAGEMENT OF FILES AND CORRESPONDENCE- RECEIVING

The system should be able to capture the following details about correspondence received:

• Intended Recipient (department / staff member etc.);

• Source of document (e.g. a member number, supplier name etc.);

• date of delivery;

• Summary of content; and


116

• Delivery method.



The system should allow correspondence/documents/files to be tracked :

• Indicate recipient;

• indicate status (received / pending / forwarded / closed);and

• indicate action taken by recipient.

The system should have a module for policy file tracing and mails tracking.

The system should be able to support a document management system hence documents captured and scanned can be viewed and

retrieved

Reports

The system should enable generation of reports on mails worked on per member .

Report on number of correspondences received weekly and actioned/closed/pending.

8.3 REQUISITION OF FILES FROM RECORDS

The system should be able to capture the following information from the requisition form:

• Member Number of file requested;

• File number / volume requested;

• Purpose of requisition;

• Date of requisition;

• Released (to be filled by registry); and


117

• Date returned.



System should allow for Users to fill in a requisition form and submit to Records department.

The system should allow Records department to issue a file / document within the system and assign it to the requestor

The system should allow recipient to acknowledge receipt of the file online

The system should assign each file a duration of time to be out of Records department and allow for alerts to be sent when time elapses

before return.

Reports

Report of files past due date.

Report of files issued and not received.

Report of staff and files in their custody.

Monthly report of files issued grouped by file type, staff issued etc.

8.4 CLOSING OF FILES

The system should allow Records department to query the member number and verify if the account has nil balances, risk payments have

been made and member marked as withdrawn or deceased.

The system should allow a file to be marked as closed and include a description field.

The system should allow for maker-checker in closure of files.

If a file has exceeded allowable size, the system should allow for a new volume number to be generated and added to the member record.


118

Each file that is closed should be flagged for archiving within a specified period of time.

Reports

Report of deceased / withdrawal cases vs. File Status.

Monthly report of files closed.

Report of files due for archiving.

8.5 CHEQUE DISPATCH

The system should be able to register cheque details after verification i.e source, destination , amount, purpose.

The system should allow a user to select the dispatch method (courier, hand delivery, collection).

The system should allow Records department to indicate when cheque has been delivered and notify the sender department.

Any cheque signature should be verified online against staff specimens.

The system should allow the sender department to query the current status of the cheque.

Reports

Report on cheques received and dispatched.

Cheque movement reports.

8.6 ARCHIVE MANAGEMENT

The system should be able to allocate a batch number/ archive location to each file sent to the archive.

The number should identify the type of file and specific storage location in the archive.

The system should allow for online requisition of archived files.

The system should be able to automatically archive all files for withdrawals, deceased and nil balances.


119

The system should be able to self-update itself on bank codes when they are installed by the finance office


120

9.0 INTERNAL AUDIT & CONTROLS

9.1 AUDIT FEATURES

System should create a group in the system and add users to the group.

System should have a maker / checker especially when assigning user rights, creating user groups and changing any system parameter.

System should allow filtering the audit log by date, activity, username etc.

System Should be able to download data to other applications such as audit software e.g. ACL (refer to Sacco for more details)

System should integrate with continuous auditing and continuous monitoring (CA/CM) tools

Should issue an alert when a staff member tries to view unauthorized information e.g. when a user tries to view dormant / restricted accounts

It should have enhanced password management structure and authentication e.g. password ageing and expiry, two factor authentication,

biometrics etc.

The system should run end of day process in the background with minimum system interruption of other processes

The system should have features such as accessibility through a web portal that allows member self-service such as loan applications – this

should have stringent security controls such as use of SSL certificates and 2 factor authentication

It should be scalable in order to allow for growth e.g. in increased transaction volumes

The system should allow for parameterized configurations to cater for product innovation and development

System should be able to carry out business intelligence functions e.g. trend analysis

System should allow for parameterization of mandatory/optional KYC/AML requirements

System should maintain an error log for both business errors and technical errors

System should support other modern channels such as online portal and mobile banking.


121

9.2 ACCOUNT CONTROLS

System should restrict access to dormant and restricted accounts to authorized users only.

System should be able to auto-post charges for restricted accounts.

System should be able track user access/attempted access to dormant/restricted accounts and generate report for the same.

The system should seek approval for any exceptional charges to be levied on accounts and send alerts to management

The system should monitor transactions affecting sanctioned entities or individuals and ability of the system to track the payee details

against various AML lists.

The system should be able to classify dormant accounts as per policy or regulators

9.3 USER RIGHTS

Systems administrators should not have any posting rights in the system

User creation and rights allocation should have maker-checker controls between IT and respective HOD

System should alert respective HOD when user is created under their departments and allow review of rights allocated before approval

The system should allow creation users in the system and assign them to groups with different rights

The system should incorporate an authority matrix and an automated escalation process in the system.

The system should allow creation of groups with certain rights in the system.

The system should be able to capture all activities with necessary automated approvals by all users and keep a detailed audit trail.

system should restrict view of certain product information based on user rights

9.4 INCIDENT REPORTING

System should integrate with third party audit software in use by the Sacco eg ACL


122

It should allow recording of incidents/ fraud and generate Suspicious Activity Transactions Report (SATR) from account activities

It should automatically escalate incident/ fraud reports if not resolved within a pre-defined period of time.

It should allow logging of customer complaints through an online interface/portal and linking them to a database in the system.

IT should generate alerts and escalate them to relevant users if any unexpected event occurs in the system.

The system should allow 2nd approval for all processes. This should be captured as a parameter that can be disabled for any process at the

discretion of the business (ability to have maker -checker in all activities as a parameter).

The system should have a systems controls manual that details the levels of security in the system, recommended roles segregation and in-

built admin rights.

The system should be able to detect and send automated alerts on control violations

The system should be able to provide a report of all the deleted transactions

The system should be able to provide exception reports of exited staff user accounts that have been activated.

Reports

Generate user defined custom reports in addition to the standard reports

Generate reports in different formats e.g. excel, PDF etc

• Leave application reports, leave days arrears reports, leave approval process reports

• Payroll reports, statutory reports, casual reports

• Loan reports per branches

• Fixed Asset Register, access rights, maintenance, updating and content

Audit trails to trace transactions from their initial source through all stages of related system processing.

• Track and report on the date and nature of a change in the status of a creditor and debtor


123

9.5 AUDIT PROCESS

System should be able to have a workflow for the Internal Auditor to do an audit of the department

It should allow for audit plans/schedules/program uploads

It should allow for auditor to raise queries and the system to automatically assign the auditee department head to answer queries

It should allow for audit reports to be automated from the process flow

9.5 RISK ASSESSMENT

System should be able to have a workflow for the Internal Auditor to do an audit risk mapping

It should allow for internal auditor to develop a risk assessment matrix

It should provide risk reports from customizable fields


124

10.0 MARKETING DEPARTMENT

10.1 MEMBER REGISTRATION AND LOAN APPLICATIONS

The system should be able to capture the following information and create a pending registration form:

• Names of applicant (in separate fields for Surname, First name, middle name, gender);

• ID No / Passport Number;

• member Number;

• Current Address;

• Current employer

• mobile number ;

• email address;

• Date of registration / application (automatic);

• photo of the applicant; and

• Product applied for.



A completed registration form should be allocated to the customer service department for verification against submitted documents.

System should be able to retain the registration form at a 'pending' state until all required documents are submitted.

The system should be able to provide up to date and accurate balances of member accounts and also allow registration for new products.

The system should be able to link any application made to the originator (marketer, customer service etc.)


125

Level of access to direct marketers should be restricted to information entry and high level member information e.g. balances query etc.

All applications logged by marketers should be reviewed by customer service and verified against documents received prior to processing by registry.

The system should send an automatic alert (email/sms) to member upon successful registration

Reports

System should be able to generate a report of all enrolments made by Marketers.

System should be able to generate a report comparing all registrations captured to all successful enrolments.

System should be able to group reports generated by:

• Status (pending / in progress / Complete);

• Enrolling marketer.

10.2 CUSTOMER COMMUNICATION

System should allow sending of email to member directly from the e-mail captured during registration

It should also be possible to PDF certain reports and send directly via e-mail to members. These include:

Loan repayment schedules

Member statements

The above reports can be sent either periodically (weekly, monthly, quarterly etc.) or upon request

For children accounts, the system should automatically identify a child’s birthday (by comparing current date with Date of birth) and automatically

send a predefined (customizable) birthday message to the holder (via email and/or SMS).

The system should be in a position to send predefined (customizable) e-mail to members upon completion of certain pre-defined transactions e.g.

purchase of shares (say in case of a share drive)


126

The system should send SMS alerts to members on certain predetermined transactions such as change of static data (name, address, email, phone

number etc.), loan guarantee, benevolent fund claim etc.

Reports

Client’s status Reports- specifications of the active accounts, Dormant accounts, Deceased accounts and closed accounts.

Production Report- New accounts that have been opened daily and a summary of the accounts monthly per branch.

Product performance

Sales code to track individual sales team/all staff performance


127

11.0 INVENTORY & ASSETS MANAGEMENT

11.1 STOCK CONTROL PROCEDURES

The system will allow the creation of an unlimited number of stores within the system.

The system should be able to pick details of the LPO from the procurement and disposal module based on the reference number assigned.

The System should be able to capture the following details for a goods received note:

• LPO reference number - this is a numeric field;

• Name of the supplier and supplier code - these fields can be picked from the LPO;

• Date of goods delivery - [dd/mm/yyyy];

• Description of goods - this should be an editable field to allow capture of details of the goods purchased;

• Quantity of goods received;

• Unit of measure [Each, Carton, Liter, Rim, Box];

• Unit cost;

• Total amount; and

• Signature from the head of stores; the system should permit online approvals.

The system should have a stock take input form which will allow the capture of the number of items counted in the stores for each individual item.

The form should contain the following details:

• Item code;

• Item name;

• Original quantity;

• Counted quantity;


128

• Original value;

• New value;

• Difference;

• Counting date; and

• Inventory expense gain(loss) account.

The System should permit the capture of details into the inventory stock module:

• Date of received goods;

• Intended user department;

• Description of goods;

• Delivery note reference number;(Automatically generated)

• Goods Received note reference number - numeric field;(Automated)

• Amount - numeric field;

• Local Purchase Order- alphanumeric field;

• Quantity delivered;

• Vendors’ details - picked from the vendors table in the procurement and disposal module.



The system should be able to :

Maintain a stock register which may be updated with any change in stock and also should be able to provide the location, category of stock, and the

cost center for the stock.

Provide details to conduct a comprehensive periodic stock review


129

The system should be able to convert items received in units such as boxes to be counted as individual items as well as in the receiving unit of measure

e.g. 1 box of pens or 50 pens.

The system should allow online approval after verification of goods by the stakeholder.

The system should allow capture of the following details for items that are requested by the user departments. These items are often referred to as

fast moving.

• Item release date;

• Item reference code;

• GRN reference code;

• Name of requester

• Name of the user department;

• Description of the item - picked from the GRN records;

• Expense account;

• Unit cost;

• Quantity issued; and

• Total cost, this amount reduces with the reducing stock.

The system should send an automatic notification to the head of the user department with the details of the items released to them by the stores

office with the following details:

• Item release date;

• Item reference code;

• GRN reference code;

• Name of requester;


130

• Name of the user department; and

• Description of the item.

A provision for capturing regulatory requirements for stock which have regulatory requirements for movement and storage should be available in the

system.

Reports

The system should be able to print an inventory of all items in stock. Details of the fields required are:

• Item code;

• Item description;

• Date received;

• GRN reference code - picked from GRN table;

• Physical count number - numeric field;

• Last requisition date - the date when the user department last requested for the item;

• Unit cost;

• Total cost;

• Folio reference number. E.g. S11 to refer to sticker papers; and

• Warranty or AMC details.

The system should be able to produce a stock aging report indicating items that have not moved either in or out of the stores for [X] number of days.


131

11.2 PROCUREMENT

Purchase requisition forms that capture:

• Procurement reference number;

• Subject of Procurement;

• Date required;

• Requesting unit;

• Location of Delivery

• Item Number;

• Item Description;

• Quantity;

• Unit of measure;

• Estimated Unit Cost; and

• Estimated Total Cost.

The system should allow the capture of the following quotation details:

• Supplier/Bidders Name;


• Email address;

• Postal Address;

• Telephone number

• Description of good/ service;


132

• Unit Price;

• Quotation number;

• Quotation Date;

• RFQ Reference Number;

• Material unit price and cost;

• Quantity; and

• Material total cost.



The system should be able to :

Help Heads of Department raise payment requests online and seek all approvals on the system itself

Provision an approval area where all outstanding payments may be approved

Provide an end to end view of the procurement request

The system should allow for online approval of the successful quotation and subsequent creation of an LPO based on based on the quotation..

The system will ensure that Local Purchase Orders (LPO) will remain on the system until the user indicates that each order line is complete and the

corresponding invoice has been authorized. Orders may be deemed complete before the full order quantity is received.

Upon submitting an LPO for approval the system should have a provision for a notification to the approver that an LPO requires his/her attention

/approval.

The system should provide the following functionality to facilitate approval of the LPO:

• Commitment Requisition (yes/no) - confirming existing commitment requisition;


133

• Funds available as per Vote Book;

• Commitment Amount - the system should display the amount from the commitment requisition;

• Approved and authorized in vote book (yes/no) - option buttons to approve or reject commitment requisition; and

• Narration / comment (reasons if commitment is rejected).

Upon the approval of a commitment requisition, the system should update the available balance on the budget line by reducing it by the committed

amount.

Upon approval of the commitment requisition the system should update it with the following information:

• Authorized by: (Budget controller /Accounting Officer);

• Position; and

• Date.

The system will provide functionality for validation of the total value of the purchase order against the approval thresholds.

The system should notify the requester when a procurement transaction is approved or rejected. If a transaction is rejected, the system should have a

mandatory field to capture details for rejection.

The system should allow automatic routing of approval to the next in line if no action is taken by the current approver after a pre-defined period of

time.

The system should allow a Goods Received Note (GRN) to be matched with the LPO on one of the following fields:

• Order number;

• Supplier code; and

• Product code.


134

When invoices are authorized they will be posted automatically to the purchase ledger, and relevant journals for goods value and VAT will be posted

to the general ledger.

Goods received will be posted to the stock system. Goods values from purchase invoices will update the item value in the stock system.

The system should notify the requester when a procurement transaction is approved or rejected. If a transaction is rejected, the system should have a

mandatory field to capture details for rejection.

The system should allow the capture of foreign currency transactions and allow tracking in local currency.

The system should ensure key data elements on a LPO are 'locked' after approval for example:

• Item quantities;

• Unit prices; and

• Delivery date.

Maintain a vendor directory with vendor feedback ratings, tax details etc.

In the event of any automatic updates to be sent out, the security of personal information of customers such as phone numbers, bank account numbers

etc must be securely stored using techniques such as: 2 factor authentication, encryption etc.

Segregation of duties must be maintained between those creating requests for procurement, approving such payments and those responsible for

releasing payments

Reports

All payments made must be available in the system and a report for the same should also be available which contain details such as departments.

Provide comparisons on how the procurement department is performing as compared to the allocated budget


135

The system should be able to print out the Local Purchase Order (LPO) with the following details:

• Supplier/Bidders Name;


• Postal Address;

• Telephone number

• PIN;

• Description of good/ service;

• Unit Price;

• Quotation number;

• Quotation Date;

• RFQ Reference Number;

• Material unit price and cost;

• Quantity;

• Material total cost;

• VAT;

• Verified by; and

• Approved by.

Basic purchasing reports such as open LPO/GRN/Invoice report, closed LPO/GRN/Invoice report.

Basic accounts payable reports such as payments to supplier, Open AP report, Cheque Register, Cash Requirements, Vendor information report.


136

The system should provide a purchase analysis report by supplier with the following details:



• Invoice dates;

• Invoiced amounts;

• Paid amounts.

The system should provide a purchase analysis report by item to with the following details:

• Item code and name;


• Invoice dates;

• Supplier code and name; and

• Unit costs.

Provide a vendor database which renders details on vendor performance, price points etc.

11.3 ASSETS MANAGEMENT

The system should be able to provide the following asset register;

• List all assets of the Sacco with their respective tags

• Track location of all assets

• Track movement of the various assets.

• Insurance details of each asset


137

• Monitor due dates for insurance renewals

• Calculate depreciation based on preset parameters

• Direct linking with GL to track depreciation schedules

11.4 FIXED ASSETS REGISTER

The system should capture whether an asset was purchased or constructed (in the case of buildings).

The system should capture the cost of purchased assets as follows:

• Asset purchase price;

• Financing and borrowing costs;

• Any directly attributable costs of bringing the asset to its intended working condition.

The system should capture the cost of self-constructed assets as follows

• Costs that relate directly to the specific asset e.g.

• Professional fees;

• Any directly attributable costs to construction/modification of the asset.

If Asset type is leasehold land, then the system should capture the remaining lease period.

The following details will be captured for each asset:

• Asset reference code;

• Asset description;

• Depreciation type;

• Addition date;


138

• Disposal date where applicable;

• Asset category (Land/Building/Motor Vehicles/Fixtures & Fittings/Computer equipment);

• Asset life;

• Remaining life (if not automatically computed);

• Asset purchase/construction cost;

• Expected final written down value (WDV);

• Depreciation amount;

• Adjustments;

• Written down value to date;

• Insurance value;

• Disposal proceeds;

• Vendor;

• Invoice number;

• Invoice date;

• Vendor reference;

• Location;

• Department;

• Serial number;

• Whether the item has been acquired as a finance lease, hire purchase, ordinary purchase item or grant.

The system should capture asset Transfer details i.e. a description of the asset and the location the asset has been transferred to.



139


The fixed assets register will integrate with the purchase ledger.

The system should allow assets to be grouped together to form a larger asset, e.g. a PC and a printer to form a computer system.

The system should provide the following depreciation methods:

• Straight line life in years; and

• Reducing balance percentage per year.

The system should capture the following depreciation details based on the Fixed Asset category

• Depreciation rate %; and

• Expected useful life.

It is intended that the depreciation history for each asset will be held indefinitely, but it should be possible to purge this information selectively by

asset type.

The system should allow assets to be allocated to departments

The system should allow subsequent expenditure on an asset to be added to its Net Book Value(NBV)

The system should maintain fixed asset control accounts for each class type of the asset.

The fixed asset control accounts should interface with the following accounts:

• Purchases day ledger for purchases against invoices;

• Cash book for direct payments;

• Petty Cashbook for direct petty cash payments; and

• Journal entries for transfers from capital work In progress account.


140

Depreciation as an expense should be charged to the profit and loss account in the period to which it relates.

The system should allow users to charge depreciation in full in the year of acquisition or completion and no depreciation charge will be made in the

year of disposal.

Maintain depreciation control accounts for each class of fixed assets for:

• Depreciation expense; and

• Accumulated depreciation.

The system should provide online authorizations for asset transfer detailing a description of the asset and the location the asset has been transferred

to and other necessary information.

The system should allow online acknowledgement of the asset transfer receipt.

The system should allow the capture of the following details after items to be disposed of are valued by Sacco approved valuers:

• Asset number;

• Asset name;

• Date of valuation; and

• Comments on condition of the item.

The system should allow an item to be flagged for disposal.

The system should print out a schedule of items flagged for disposal with the following details:

• Circulation details i.e. asset number, general description of the asset, location, condition;

• Method of disposal i.e. sold or Written off;

• Year of purchase;


141

• Asset number;

• Description;

• Condition; and

• Disposal value (if sold).

The System should be able to perform the following:

• Mark an asset in the register as disposed and deactivate it preventing further transactions from being carried out on the asset.

• Automatic removal of the asset value from the ledger account.

• Online authorization of assets to be disposed off as relates to their value.

• Automatic update of the profit and loss account with a loss entry for any destroyed assets.

• The system should allow the revaluation of fixed assets.

• It should be possible to run the depreciation calculation:

• Monthly;

• Quarterly;

• Annually.

The system should be able to facilitate approval of the transfer of assets from one department to another.

The system should be able to relate the assets returned vs. the assets issued.

The system should be able to report fully depreciated assets.

The system should ensure that for all transactions there is a maker - checker mechanism to confirm that new transactions or changes to master records

are approved.


142

Reports

The user will be able to view the full details on any asset by means of entering:

• The reference number; and

• The short name.

The system should provide a listing of all assets per department.

The user will be able to view a listing of all assets in an asset category by means of entering the category code, and will display for each asset:

• Short name;

• Date when asset was added to register;

• Cost;

• Written down value.

The reports required include:

• Asset register- an audit list of all assets giving full details of each one;



• Depreciation type;

• Addition date;

• Disposal date where applicable;

• Asset category (Land/Building/Motor Vehicles/Fixtures & Fittings/Computer equipment);

• Asset life;


143

• Remaining life (if not automatically computed);

• Asset purchase/construction cost;

• Expected final written down value (WDV);

• Depreciation amount;

• Adjustments;

• Written down value to date;

• Insurance value;

• Disposal proceeds;

• Vendor;

• Invoice number;

• Invoice date;

• Vendor reference;

• Location;

• Department;

• Serial number;

• Additions audit trail - for the additions in the period or year;



• Date added;

• Location

• User department


144

• Adjustment audit trail -listing all assets where there has been an adjustments posting in the period or year, including the adjustment values and

reasons;



• Date of adjustment;

• Original value;

• Adjustment amount;

• Adjusted value; and

• Comment on adjustment.

• Disposal audit trail - listing all assets disposed in the period or year;



• Date of disposal;

• Written down value;

• Disposal value; and

• Gain (loss) on disposal.

• Period depreciation report- giving the depreciation for the period and cumulative for each asset;



• Asset category;

• Depreciation period;


145

• Period depreciation amount; and

• Accumulated depreciation amount.

• Depreciation history report summarizing the depreciation by period for the year per asset category;

• Asset category;

• Depreciation period

• Period depreciation amount; and


• General ledger distribution report - giving the values to be posted for the period per general ledger account;

• Asset category;

• Depreciation period

• Depreciation expense general ledger account

• Period depreciation amount;

• Accumulated depreciation general ledger account


• Fixed asset value;

• Fixed asset general ledger account

• Forecast depreciation report - showing the expected depreciation over a given number of user-defined periods;



• Date of disposal;

• Period;


146

• Depreciation forecast; and

• Forecast written down value.

• Insurance valuation report - showing the insurance value by asset category.

• Asset category;

• Insurance policy number;

• Date of valuation;

• Insurance value; and

• Insurance claims.

It should be possible to sort/filter the following reports by department:

• Asset register;

• Additions audit trail;

• Adjustments audit trail;

• Disposals audit trail;

• Period depreciation report;

• Depreciation history report;

• General ledger distribution report;

• Forecast depreciation report;

• Insurance valuation report.

The system should be able to produce control totals of each class of asset shown in Asset Group control summary.

The system should be able to provide a report of the fully depreciated assets.


147

12.0 DATA ANALYTICS

12.1 ROLE-BASED DASHBOARDS

The system will allow the creation of customizable data dashboards based on a user’s role

The System should be able to:

Present the data in graphs, pie charts, etc.

Automatically update the dashboard as the database changes - real-time

The dashboards can be turned off/on at a user’s discretion

Access should be restricted to a user’s predefined role at the Sacco

12.2 BUSINESS INTELLIGENCE

The system shall have a comprehensive Data Analytics capabilities that shall allow the Sacco to generate high-level management reports for better

business decisions

The data analytics capabilities should be customizable, and shall be in addition to the normal reports that are required for a comprehensive Sacco

system.

The System should be able to mine data from the database for analytical purposes

The data should be presentable in graphs, pie charts, etc.

A key functionality should be the ability to determine trends and be able to forecast models based on these trends


148

13.0 OTHER REQUIREMENTS

13.1 CHEQUE MANAGEMENT

The system should provide a suitable cheque management system that shall:

Order cheque books from member requests

Keep track of all such requests

Request for cheque books from the issuing bank in a preset format

Keep track of all such requests to the bank

Receive and record all received cheque books from the bank

Issue cheque books to members

Keep track of all cheque leaf usage through the Sacco network as they are presented

Keep track of SLA

Ability to stop fraudulent cheques

Clearing module as per SLA with clearing bank

Reports

All cheques ordered, pending, issued to customers

Alert when cheque numbers are skipped

All cheques ordered, pending and received from the bank


149

13.2 PAYBILL AUTOMATION

The system should provide a suitable Paybill automation that enables real-time fetching and posting of PAYBILL transactions done by customers to the SACCO Pay bill number using API

Features

The solution shall fetch all unposted PAYBILL transactions.

Check to verify that the customer indicated a valid and existing destination account as well as a correct prefix. A specified prefix shall be

appended to the account number to specify destination account.

For transactions with correct details, the system shall post the cash appropriately. Those with incorrect details shall await edition on the

management window.

An authorized user shall later access the management view, consider hanging transactions and apply required edition. Once edited, the

transaction shall be posted to respective accounts.

Management interface

Should be accessed through a name and password.

Allow setting up of Paybill tariffs and operating parameters.

Allow viewing of fetched PAYBILL transactions with their respective status

Allow filtering of items by date and status

The solution shall notify the admin either through SMS or email when it’s down.

It shall maintain a log of errors encountered to assist in effective monitoring.

Reports

Transaction log that can be filtered according to date and status.

Edited transactions and the maker.


150

14 DOCUMENT MANAGEMENT SYSTEM

The system should provide a suitable document management platform to digitize Sacco records

Features

Documents to be scanned at source and attached to records/transactions

Tracking of all changes to the document

Approvals and comments can be made and tracked in the system

All documents to be archived once a process is complete

Workflows done with various approval levels. Maker/checker setup

15 INVESTMENT COMPANY

The system should provide a suitable module that shall manage the investment subsidiary of the Sacco:

Membership recruitment

Share capital recruitment

Manage the acquisition, distribution and capital gains of assets

Manage a GL and books of accounts for the investment company

Track investments and profitability

Data analytics and forecasting for prudent financial management


151

16 ADDITIONAL REQUIREMENTS

16.1 Loans and Advances

Ability to produce a loan collection register on daily basis.

Ability to monitor loan performance on daily basis

Ensure there is maker checker process

Ability to allocate a loan portfolio to a Sacco staff

Ability to show prepaid loans

Ability to generate the guarantors pledges

Ability to generate loan transactions list > 5yrs

Ability to generate an up to date guarantors register

Ability to produce appraisal notes

Ability to capture supporting documents used as security

Ability to generate the list of applied loans

Ability to capture loan purpose

16.2 Accounts Section Specifications

Ability to produce a 5 yr trial balance

Ability to generate assets register

Ability to separate various bank accounts

Ability to produce a real time reconciliation


152

Ability to capture branch/satellite performances

Ability to capture the budget and produce variances

Ability to accommodate import or export of reports or payments

16.3 Additional Customer Information

Ability to record deceased persons ,withdrawal of membership, transfer of shares

Business location should be included.

Customer occupation to be detailed.


153

12.0 CONCLUSION

This document provides the detailed system specifications that Viktas Sacco requires. This

document forms the core part of the Terms of Reference in the Request for Proposal (RFP)

document to be accessed by specific system vendors in their tender proposal to provide the

Sacco with a comprehensive Core Banking System and ERP.

All solutions proposed by the vendors shall be measured by their ability to match these system

requirements.

FUNCTIONAL SPECIFICATION DOCUMENT 2018 · PMS Performance Management System PPOA Public Procurement...

Documents

Transcript of FUNCTIONAL SPECIFICATION DOCUMENT 2018 · PMS Performance Management System PPOA Public Procurement...