Camnjbhjvh

Integrated Central Banking System Central Accounts Management

Software Requirement Specification Document

ICBS – Central Accounts Management System

Royal Monetary Authority

Version 1.3

06/01/2007

Document Number: ICBS/CAM/STDSRS/SRS-CAM-003:

CAM – SRS Ver. 1.3 of 139


Notice:

This document and any revised pages are subject to document control. Please keep them up-to-date using the release notice from the distributor of the document.

This is a hard copy of a document maintained on electronic media. It may not be the latest version. Ascertain the latest version from the Document Master List available with the Project Leader.

Authored by Mr. Rajarshi Roy Date: 15-05-2005

Updated by Mr. Pradip Dutta Date: 30-06-2006Mr. Chirantan Mukherjee Date: 30-06-2006Mr. Somnath Lahiri Date: 30-06-2006

Revised by Mr. Chirantan Mukherjee Date: 06-01-2007

Revised by Mr. Somnath Lahiri Date: 10-10-2007

Approved by _______________________________ Date:

Authorized by _______________________________ Date:



DOCUMENT RELEASE NOTICE

Notice Number : ICBS/SRS/ CAM/1/3

Client : Royal Monetary Authority

Project : ICBS - CAM

Document Details : Software Requirement Specification for Central Accounts Management System

Name Version No. Description

Software Requirement Specification Document 1.3 Software Requirement Specification for Central

Accounts Management System

Revision details:

Action taken(add/del/chg)

PrecedingPage No.

NewPage No.

RevisionDescription

Described in the Document Revision List

Change Register serial numbers covered: The documents or revised pages are subject to document control. Please keep them up-to-date using the release notices from the distributor of the document. These are confidential documents. Unauthorised access or copying is prohibited.

Approved by : Date:

Authorised by : Date:



DOCUMENT REVISION LIST

Notice Number :

Client : Royal Monetary Authority

Project : ICBS - CAM

Document Name : Software Requirement Specification for Central Accounts Management System

Release Notice Reference (for release):

Rev.No

Rev.Date

RevisionDescription

PageNo.

Prev.Page No

ActionTaken

Agenda / New page

ReleaseNotice

Ref.1.

2.

3.

4.

5.

6.

7.

06/01/2007

06/01/2007

06/01/2007

06/01/2007

06/01/2007

06/01/2007

06/01/2007

BK Account Mapping

FOREX Reverse Voucher

Budget Release/ Receipt

Prepare Holding Rate, Revaluation Voucher

Sale of Bullion

Telex/SWIFT Messaging

FOREX Reserve Type Master

21

67

80

88,92

97

100

28

Removed

Removed

Removed

Removed

Removed

Removed

Removed

The functions are handled using Currency Master and a configuration table.

Reverse Voucher performs the functions of this interface. There are ‘Reverse’ buttons in BK Vouchers also.

The function is handled in AAM as per Section 3.1.2.1 of AAM SRS 1.3

Merged with Table of Conversion

Handled through BK01

Business Owners do not require this

No usage in CAM. Will be done in RMM (Ref. Section 3.1.1.1.1 and 3.1.1.1.2 of RMM SRS Ver. 1.2)

As per revised design.



As per discussion.

As per discussion.

As per discussion.

CAM – SRS Ver 1.3 of 139


TABLE OF CONTENTS

1 INTRODUCTION................................................................................................................................. 81.1 PRODUCT PERSPECTIVE.........................................................................................................81.2 SCOPE........................................................................................................................................ 81.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS.................................................................91.4 REFERENCES............................................................................................................................ 91.5 OVERVIEW.................................................................................................................................. 9

2 GENERAL DESCRIPTION................................................................................................................112.1 PRODUCT PERSPECTIVE.......................................................................................................112.2 PRODUCT FUNCTIONS...........................................................................................................132.3 USER CHARACTERISTICS......................................................................................................13

2.3.1 System Analyst................................................................................................................132.3.2 System and Database Administrator................................................................................132.3.3 Maintenance Team..........................................................................................................142.3.4 End User.......................................................................................................................... 14

2.4 GENERAL CONSTRAINTS.......................................................................................................142.5 ASSUMPTIONS AND DEPENDENCIES...................................................................................15

3 SPECIFIC REQUIREMENTS............................................................................................................163.1 DESCRIPTION OF FUNCTIONS COVERED........................................................................................17

3.1.1 CAM Master set-up and Configuration.............................................................................173.1.1.1 Currency Master..........................................................................................................................183.1.1.2 Commemorative Coin Master......................................................................................................203.1.1.3 Contact Master............................................................................................................................223.1.1.4 Dispatch Document Master.........................................................................................................243.1.1.5 Contact Account Master..............................................................................................................253.1.1.6 Bill Calendar................................................................................................................................273.1.1.7 Holding Rate Master....................................................................................................................283.1.1.8 Buying/Selling Rate Master.........................................................................................................303.1.1.9 Financial Year Master..................................................................................................................31

3.1.2 Transactions....................................................................................................................333.1.2.1 Staff Salary Saving......................................................................................................................33

3.1.2.1.1 Internal Deposit.......................................................................................................................333.1.2.1.2 Withdrawal..............................................................................................................................353.1.2.1.3 Deposit (Cash/Cheque)..........................................................................................................373.1.2.1.4 Calculate Interest....................................................................................................................40

3.1.2.2 Ngultrum Vouchers......................................................................................................................433.1.2.2.1 General Transaction (Nu).......................................................................................................433.1.2.2.2 Reverse Voucher (Nu)............................................................................................................43

3.1.2.3 Foreign Currency Accounting......................................................................................................433.1.2.3.1 General Foreign Currency Voucher........................................................................................453.1.2.3.2 General Ngultrum Voucher.....................................................................................................473.1.2.3.3 Debit Advice Voucher (BK01).................................................................................................493.1.2.3.4 FOREX Receipt Voucher (BK02)............................................................................................523.1.2.3.5 Currency Swapping Voucher (BK07)......................................................................................563.1.2.3.6 FOREX Purchase Voucher (BK08).........................................................................................593.1.2.3.7 Process FOREX Sale Voucher (BK09)...................................................................................613.1.2.3.8 FOREX Settlement Voucher (BK10).......................................................................................633.1.2.3.9 Note Serial Number Tracking..................................................................................................65

3.1.2.4 Discount Bill.................................................................................................................................683.1.2.4.1 Sale of Discount Bill................................................................................................................683.1.2.4.2 Redemption of Bill...................................................................................................................70

3.1.2.5 Interest Accrued/Received From Bank........................................................................................723.1.2.5.1 Interest Received From Bank.................................................................................................723.1.2.5.2 Investment Information...........................................................................................................73



3.1.2.5.3 Interest Accrual.......................................................................................................................753.1.3 Bank Reconciliation.........................................................................................................78

3.1.3.1 Bank Reconciliation (Nu).............................................................................................................803.1.3.2 Bank Reconciliation (FC).............................................................................................................80

3.1.4 Foreign Currency Revaluation.........................................................................................843.1.4.1 Table of Conversion.....................................................................................................................84

3.1.5 Issue Division Transactions.............................................................................................883.1.5.1 Currency Chest Transaction........................................................................................................88

3.1.5.1.1 Deposit....................................................................................................................................883.1.5.1.2 Withdrawal..............................................................................................................................89

3.1.6 Day End Process.............................................................................................................923.1.6.1 Day End Process.........................................................................................................................92

3.1.7 Annual Closing of accounts..............................................................................................943.1.7.1 Provisional Account Closing........................................................................................................943.1.7.2 Final Account Closing..................................................................................................................953.1.7.3 Year End Voucher for AAM.........................................................................................................973.1.7.4 Year End Nu. Voucher for CAM...................................................................................................973.1.7.5 Year End FC Voucher for CAM...................................................................................................97

3.1.8 Reports............................................................................................................................ 983.1.8.1 Cash Book...................................................................................................................................983.1.8.2 Bank Book...................................................................................................................................993.1.8.3 Journal Register...........................................................................................................................993.1.8.4 Currency-wise Journal Register.................................................................................................1013.1.8.5 Certificate of Cash Balance.......................................................................................................1023.1.8.6 General Ledger..........................................................................................................................1023.1.8.7 Currency-wise General Ledger..................................................................................................1033.1.8.8 Sub-Ledger................................................................................................................................1043.1.8.9 Trial Balance..............................................................................................................................1053.1.8.10 Currency-wise Trial Balance......................................................................................................1063.1.8.11 Income and Expenditure Statement..........................................................................................1063.1.8.12 Schedules of Income and Expenditure Statement.....................................................................1073.1.8.13 Balance Sheet...........................................................................................................................1083.1.8.14 Schedules of Balance Sheet......................................................................................................1093.1.8.15 Monthly Statement: Domestic Commercial Banks.....................................................................1103.1.8.16 Monthly Statement: Government Agencies...............................................................................1103.1.8.17 Salary Journal Register.............................................................................................................1113.1.8.18 Salary Account Balance Statement...........................................................................................1123.1.8.19 Voucher Printing........................................................................................................................1133.1.8.20 List of Vouchers.........................................................................................................................1143.1.8.21 Denomination Summary............................................................................................................1163.1.8.22 Denomination Details.................................................................................................................1173.1.8.23 Bill Calendar..............................................................................................................................1183.1.8.24 Details of Sale............................................................................................................................1183.1.8.25 Details of Outstanding Amounts................................................................................................1193.1.8.26 Prepaid Interest Expenses.........................................................................................................1193.1.8.27 Nu Bank Statement....................................................................................................................1203.1.8.28 Nu Bank Reconciliation..............................................................................................................1203.1.8.29 Nu Daily Reconciliation Statement............................................................................................1213.1.8.30 Nu Monthly Reconciliation Statement........................................................................................1223.1.8.31 FC Bank Statement...................................................................................................................1233.1.8.32 FC Bank Reconciliation.............................................................................................................1233.1.8.33 FC Daily Reconciliation Statement............................................................................................1243.1.8.34 FC Monthly Reconciliation Statement........................................................................................1253.1.8.35 Nu Not Responded by RMA......................................................................................................1263.1.8.36 Nu Not Responded by Bank......................................................................................................1273.1.8.37 FC Not Responded by RMA......................................................................................................1273.1.8.38 FC Not Responded by Bank......................................................................................................1283.1.8.39 Year End Journal Statement......................................................................................................1293.1.8.40 Year End Trial Balance..............................................................................................................1303.1.8.41 Year End Income & Expenditure Statement..............................................................................1313.1.8.42 Year End Balance Sheet...........................................................................................................132

4 INTERFACE REQUIREMENTS......................................................................................................133



4.1 GENERAL................................................................................................................................... 1334.2 INTERACTION WITH OTHER MODULES...........................................................................................133

4.2.1 Interaction with FOREX Operations Module..................................................................1334.2.2 Interaction with Administrative Accounts Module...........................................................1344.2.3 Interaction with Currency Management Module.............................................................1354.2.4 Interaction with Reserve Management Module..............................................................1364.2.5 Interaction with Statistical Information Module...............................................................1374.2.6 Interaction with FIRMA...................................................................................................138



1 INTRODUCTION

1.1 PRODUCT PERSPECTIVE

Under the RMA act 1982, the RMA acts as banker to government and banks. In order to shoulder the responsibilities, the Banking Division of the RMA is entrusted to execute daily transactions with the commercial banks and the government and provides depository services with international financial institutions.

The ultimate goal of the Central Accounts Module (CAM) is to strengthen the central accounts operational capacity by allowing an efficient recording, computation and retrieval of required accounting information by authorized users and managers and decision makers at any point of time.

1.2 SCOPE

The typical CAMS process includes the following phases:

a. Master filesb. Ngultrum Accountingc. Bank Cheque Maintenanced. Staff Saving Schemee. Foreign Currency Accounting f. Foreign Currency Revaluationg. Bank Reconciliation h. Regular Reportsi. Account Statementsj. MIS/Time Series Reportsk. Linkage with other modules



1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

A list of abbreviations used in this document is given below:ADM Administration DivisionAIMS Asset and Inventory management SystemsBD Banking DivisionFISD Financial Institutions Supervision DivisionFM Financial Manual 1998FxRMD Foreign Exchange and Reserve Management

DivisionIAD Internal Audit DivisionIDS Interview documentsID Issue DivisionRMS Reserve Management UnitREM RMA Expenditure ManualRFP Request for Proposal of RMARPM RMA Procurement ManualRSD Research and Statistics DivisionSRS Software Requirement SpecificationCAM Central Accounting ModuleCMM Currency management Module

1.4 REFERENCES

This SRS has been prepared based on the preliminary study conducted by IT Division of RMA, current computerized system and Discussion with the business owners. Some of the references for this document are as follows:

1 RFP2 FM – Procurement manual 19983 Accounting Manual- Appendix H14 Preliminary Software Requirement Study Document prepared by Mr. Jambey Tshering5 CAM SRS- ICBS/AAM/STDSRS/SRS-CAM-0016 Interview documents7 Various inputs gathered from various Banking and other related divisions8 Existing computerized accounts system

Central Accounts Staff Salary Saving Foreign Currency Account Bank Reconciliation Foreign Currency Revaluation

1.5 OVERVIEW

This document is organised into two sections excluding this section.

Section 2 - General Description describes the functionality of the Central Accounts Management System. The details specified are:



Product Perspective

CAM Product Functions CAM User Characteristics CAM General Constraints CAM Assumptions and Dependencies

Section 3 - Specific Requirements provides a detailed description of the functions of the CAMS in terms of:

Inputs Processing Outputs

Section 4 – Interfaces with other modules are also described



2 GENERAL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

The ultimate goal of the Central Accounts Module (CAM) is to strengthen the central accounts operational capacity by allowing an efficient recording, computation and retrieval of required accounting information by authorized users, managers and decision makers at any point of time.

This module will also have interfaces with other functional areas of ICBS such as Administrative Accounts Module, Currency Management Module, and Foreign Exchange Operation Module etc. The major functions under CAM module are as below:



Note: AMM = Administrative Account Module, CMM = Currency Management Module, FOM = Foreign Exchange Operation Module, SIM=Statistical Information Module, FIRMA=Financial Institutions Ratio Management Analysis, RMM=Reserve Management Module


Central Account ManagementModule

NgultrumAccounts

ReconcileAccounts

ChequeBookMaint.

Staff SalaryCurrencyAccount

Revalue Forex Cy

Process Voucher

ReverseVoucher

ProcessJournal

Record Chq. Book

CancelCheque

Reports

RegularReports

SalaryDeposit

Withdraw

Deposit

CalculateInterest

Reports

Bank Statements

AutomaticReconcile

ManualReconcile

Reports

NormalVoucher

BK01Voucher

BK02Voucher

BK07Voucher

BK8/9/10Vouchers

Reports

Holding Rates

TOCSheet

Rev Voucher

Rev. Journal

Linkage

AAM Module

CMM Module

FOMModule

SIMModule

FIRMAModule

RMMModule

A/cStatement

MIS/Time Series SWIFT/

Clearing


2.2 PRODUCT FUNCTIONS

The different functions of the CAM module are:

a. Master filesb. Ngultrum Accountingc. Bank Cheque Maintenance d. Staff Salary Savinge. Bank Reconciliation f. Foreign Currency Accountingg. Interest Receipth. RMA Bills i. Revaluationj. Budget Releasek. Currency Chest Transactionl. General Reportsm. MIS/Time Series Reportsn. Linkage with other modules

2.3 USER CHARACTERISTICS

The users of the CAM module can be categorized as:

a. System Analystb. System and Database Administratorc. End Users

2.3.1 System Analysta. System Analyst is fully responsible to conduct periodical system requirements study and

come up with proposal. b. Also responsible to conduct gap analysis, draw up SRS, Design and communicate the same

to programmers. c. Testing and approvald. Conduct system auditinge. Planning periodical training for users

2.3.2 System and Database Administrator

The System and Database Administrator at RMA production site is responsible for the proper functioning of the complete system. His / her responsibilities can be summarized as follows:

a. System start-up and shut-downb. Providing operational assistance to end usersc. Creating new user accounts and deleting defunct user details while monitoring system

usaged. Allocating hardware and computer timee. Ensuring satisfactory performance of all hardwaref. Periodic backing up of information to prevent data loss / corruptiong. Maintaining the system data to ensure data integrity and securityh. Establishing and applying data recovery normsi. Maintenance of master data



j. Executing batch jobs, if anyk. Executing batch report printingl. Implementing program enhancements at the production sites

For performing these duties, the System and Database Administrator should be conversant with Linux, Oracle, JSP, Serves, Jonas Apps Server, EJB, Windows, and Eclipse IDE and should be knowledgeable about the design of the database, the organization of the data objects and the relationships between the different data objects. Further, the Administrator should have the ability to carry out basic trouble-shooting activities.

2.3.3 Maintenance Team

DBA/Programmers at the RMA IT Division will carry out all maintenance work. They are also responsible for the preparation of any ad-hoc queries / reports required for operational purposes after the system is implemented. For carrying out these activities, they should be conversant with the database design, three-tier configuration, and interface details.

The responsibilities of the analyst are as follows:

a. Basic trouble shooting for softwareb. Ad-hoc report / query preparationc. Developing, testing, and documenting applicationsd. Consolidating data received from various unitse. Assessing new requirementsf. Maintaining the application softwareg. Data backup/Restore and security responsibilitiesh. Application and network error logbook maintenance

The DBA/Programmers should be conversant with Linux, ORACLE, JSP, Servlets, Core Java, DOS, Windows, and the CAM module.

2.3.4 End User

The end users’ main responsibility will be transaction data entry and modifications. Also, their work will be initiation of batch processes and generation of reports. The end users’ jobs can be summarized as follows:

a. Transaction data-entryb. Updating / Modificationc. Report generationd. Maintain Application logbook

End users should be conversant with the functionality of the CAM Module.

2.4 GENERAL CONSTRAINTS

The following issues need to be resolved or decided upon:

Report formats need to be frozen before the completion of HL designInter Connectivity with the SWIFT system (Import/Export of Data from Swift to CAM and vice versa, is not required)



2.5 ASSUMPTIONS AND DEPENDENCIES

a. All users are assumed to be equipped with GUI terminals.b. All master data entry will be undertaken jointly by RMA.c. All CAM users have undergone user training.d. Reports which are not freeze must be freeze before the completion of High level design.e. All the data requirement section given in all process will be given during the High level

design stagef. Input parameters for report needs further discussion with the end users.



3 Specific Requirements

The details of the functionalities and major use case covered in the CAM module are:

a. Master File Maintenanceb. Ngultrum Accounting

Normal Voucher Preparation Normal Voucher Authorization Reverse Voucher Preparation Reverse Voucher Authorization Process Journal Report

c. Staff Salary Saving Withdrawal of salary Deposit Interest Calculation

d. Bank Cheque Maintenance

Record new cheque book Control Cancel Cheque

e. Bank Reconciliation Bank Statements Entry Bank Statements Authorization Reconcile accounts

f. Foreign Currency Accounting Normal Voucher Preparation Normal Voucher Authorization Normal Reserve Voucher Preparation Normal Reverse Voucher Authorization BK01 Voucher Preparation BK01 Voucher Authorization BK02 Voucher Preparation BK02 Voucher Authorization BK03 Voucher Preparation BK03 Voucher Authorization BK04 Voucher Preparation BK04 Voucher Authorization BK07 Voucher Preparation BK07 Voucher Authorization BK08 Voucher Preparation BK08 Voucher Authorization BK09 Voucher Preparation BK09 Voucher Authorization BK10 Voucher Preparation BK10 Voucher Authorization

g. Revaluation



Forex Holding Rates Prepare Table of conversion Generate Revaluation Vouchers Revaluation Journal

h. Linkage with other modules

Issue Division Forex Division Personnel and Administration Division Research and Statistical Division Financial Institution Supervision Division Payment and Settlement System

i. General Reportsj. MIS/Time Series Reports

3.1 DESCRIPTION OF FUNCTIONS COVERED

Given below are functions along with their descriptions.

3.1.1 CAM Master set-up and ConfigurationThis function maintains setup/configuration master used by this module. This is the first function that users must carry out during the initial setup of this module at proposed installation site. The generic setup parameters are likely to be organisation name, address, financial year, number format, currency format, number of decimal places, voucher initial values (both for Local Accounts and Currency Accounts etc.Following are the masters from AAM module, which are in common with the CAM module

General Ledger Class General Ledger Group General Ledger Sub Group General Ledger General Ledger Sub Head General Ledger Head Type General Ledger Sub Head Type Bank master Bank Branch Master Bank Account Chequebook Master Cancellation of Cheque Transaction Type Schedule Type



3.1.1.1 Currency Master

DescriptionThis function maintains details of various currencies. The currency master links two GL Codes with every Currency for the GL Codes that will be affected on the ledger/final accounts for mixed currency transactions. Note that bullion (gold and silver) will also be treated as currency as their nature in transaction is same as other currencies. The only difference is that apart from the value these will have a stock also (not maintained through this screen). For every currency the details of their applicable denominations will be maintained in the detail section.

Actors or ParticipantsUser of Banking Division

Pre Conditions N/A

Exception The currency master will also maintain Ngultrum (Nu), the default currency. This being

the local currency and will not be initiated in any mixed currency transactions, no GL Codes need to be linked with ONLY this currency.

Even for bullion the detail for denomination is mandatory/required. Each ‘denominations’ of bullion like 10 gms Gold Bar, 20 gms Gold Bar, are treated as separate currencies to provide flexibility of the system to allow different rates (holding/buying/selling) for different ‘denominations’ of Bullion.

Screen Layout

InputsThe contents of Currency Master data store are:



Currency Code* Currency Code e.g. 00-Ngultrum, 01-Dollar, 02-British Pound

Currency Abbreviation* Currency short name like Nu, USD, GBPCurrency Name* Currency Name e.g. US DollarBullion* If Bullion then YLocal* To mark which currency is the local, it will be against Nu

only. This mark will be internally used (in queries) for transactions where only foreign currencies are applicable.

Our Account * When this currency is involved in mixed currency transaction the logical FC value will be debited/credited against this account Eg. OUR USD, OUR GBP

FC Account* When this currency is involved in mixed currency transaction the actual currency value will be debited/credited against this account, only if the transaction mode is Cash. E.g. CASH IN HAND USD, CASH IN HAND GBP etc.

Inputs for detail

Code* Denomination Code Eg. Rs. 5 Rupee NoteAbbreviation* Denomination short name Eg. 5Name* Denomination Name e.g. Five Rupee NoteMultiplicity Factor* This is to signify how many units of that currency this

denomination is for. This field is useful for calculations (in total value etc) against denomination usage.

Active Whether this denomination is active. In case a particular denomination is taken off. It has to be marked as Inactive. (Eg. One Rupee Note for INR)

Data StoreCurrency Master Data storeThe following inputs will be stored in the Currency Master data store:

- Currency Code- Currency Abbreviation- Currency Name- Bullion- Local- Our Account - FC Account

The following inputs will be stored in the Currency Master Detail data store- Code- Abbreviation- Name- Multiplicity Factor- Active

Business Logic The Currency Code, Abbreviation and Name should be Unique.



For a Currency Code, the Denomination Code, Denomination Abbreviation, Denomination Name is unique.

For the local currency (Local is checked), Ngultrum, the Ngultrum Account GL Code and Foreign Currency GL Code are not required.

Process Enter and update Currency Master data store.

Example (Header):Currency Code 00 01 02 51Currency Abbreviation Nu USD GBP GOLDCurrency Name Ngultrum US Dollar Pound GOLD – 10 gmsBullion N N N YLocal Y N N NOur Account OUR USD OUR GBP OUR GOLD BAR

– 10 gmsFC Account CASH IN

HAND USDCASH IN

HAND GBP

GOLD BAR – 10 gms

Example (Detail) for Nu:Denomination Code Nu 5 Nu 10 Nu 100Denomination Abbreviation 5 10 100Denomination Name Ngultrum 5 Ngultrum 10 Ngultrum 100Unit Value 5 10 100Active Y Y Y

Verification and Validation NA

Analytical / Calculation NA

Application ErrorNA

3.1.1.2 Commemorative Coin Master

DescriptionThis function maintains the details of gold, silver and commemorative coins and acts like a ‘Coin Album’. These coins will/may be sold against foreign/local currencies. Different sets of the same coin may be manufactured and sold against different currencies. For that, the same coin code may exist against different sets.

Screen Layout



InputsThe contents of commemorative coin Master data store are:

Coin Code* User defined code to identify coinsCoin Name* Coin nameSet* Set of the coinMinted Year Year in which the set was mintedName of Minting Press Name of the press which had minted the set.Type* Whether this is a gold coin or silver or Others.Manufacturing Cost* Marked as mandatory, so that MIS reports like

Manufacturing Cost Vs Selling price may be taken.Initial Cost Price (in Ngultrum)* The initial cost price in Ngultrum.Selling Price* Selling price of the Coin[User entered]Forex Rate as on* This date field will mark that the selling price was

calculated based on the FOREX rate of which date Selling Currency* The currency in which the coin will be/is sold. Eg. USDUnit* Eg. G-Grams or P-Pieces, coming from Unit of

Measurement Master (IMM)Stock in hand* Current Balance in unitLedger A/c * GL Account code

Data StoreCommemorative Coin Master Data storeThe following inputs will be stored in the Commemorative Coin Master data store:

- Coin Code- Coin Name- Set



- Minted Year- Name of Minting Press- Type- Manufacturing Cost- Initial Cost Price (in Ngultrum)- Selling Price- Forex Rate as on- Selling Currency- Unit- Stock in hand- Ledger A/c

Business Logic FOREX rate should be the latest provided (only approved are to be considered). Combination of code and set, name and set has to be unique.

Process Enter and update commemorative coin Master data store.

Example:Coin Code 01 01 02Coin Name Sertrum Setrum SetrumSet Set 0 Set 521 Set 435Minted Year 1998 2004 2006Name of Minting Press Press 1 Press 2 Press 1Type Gold Gold SilverManufacturing Cost 400.00 588.01 588.01Initial Cost Price in Nu 2871 15732.38 15732.38Selling Price 200 500 0FOREX Rate as on 01/02/2005 21/11/2005 05/03/2006Selling Currency 01 00 00Unit P P PStock in hand 1000 2000 600Ledger Ac 21211 21213 21214



Application ErrorNA

3.1.1.3 Contact Master

DescriptionThis function stores all the contact information for External contacts (govt. department or any other organisation) for sending different reports. A data store, ‘Contact Type Master’ is referred to segregate whether a contact is a government department, financial institution (required in FISD Module) or any other.



Screen Layout

InputsThe contents of Contact Address Master are:

Contact Code* Unique code for department/agenciesContact Name* Department/ Agencies name[user will select from a list]Contact Type* Whether the dept is govt/financial inst./OtherContact Person Name Name of the contact person [User entered]Address line 1* Address Detail [User entered]Address line 2 Address Detail [User entered]Address line 3 Address Detail [User entered]Email Email Id of that contact person [User entered]Phone No* Phone Number [User entered]Fax No Fax Number [User entered]Parent Contact Parent contact should be selected from a view link.

Data StoreContract Address Master Data storeThe following inputs will be stored in the Contract Address Master data store:

- Contact Code- Contact Name- Contact Type- Contact Person Name- Address line 1- Address line 2- Address line 3- Email- Phone No- Fax No- Parent Contact



Business LogicContact Code, Name must be unique.

ProcessEnter and update Contact Address Master data store.

Example:Contact Code DADM BNBContact Name Department of AID & Debt Mngmnt. Bhutan National BankContact Type GOVT FIN INSTContact Person Name Director General Managing DirectorAddress line 1 Department of AID & Debt Mngmnt. XXXXAddress line 2 Thimphu ThimphuAddress line 3Email DADM@------PhoneFax



Application ErrorNA

3.1.1.4 Dispatch Document Master

DescriptionThis function stores file number of the document issued from banking division. It may dispatch documents to external contacts or internal divisions, for both - the file numbers has to be maintained through this master.


Pre Conditions N/A

Screen Layout



InputsThe contents of Dispatch Document Master are:

Contact * To select a contact [user will select form a view]External Division To enter the division of selected contact (non

mandatory)Internal Division To select a division [user will select form a view]File Name* Name of the file [user entered]

Data StoreDespatch Document Master Data storeThe following inputs will be stored in the Despatch Document Master data store:

- Contact - External Division- Internal Division- File Name

Business Logic Either the code or external division (non mandatory) or internal division needs to

be mentioned. The same file cannot refer to external contact as well as internal division.

The prefix of the filename will be auto-generated as RMA/External Division-Contact Code/Fin Yr Code/ or RMA/Division Code/Fin Yr Code/ depending upon the selection.

Since the filename (prefix) is auto-generated and dependent on selection of division, editing will cause mismatch of data. As such there should not be any edit mode.

ProcessEnter and update Dispatch Document Master data store.

Example:Contact 01 02

External Division DADMInternal Division BD

FileName RMA/01/0506/001 RMA/BD/0506/002


Analytical / CalculationCAM – SRS Ver 1.3 of 139


NA

Application ErrorNA

3.1.1.5 Contact Account Master

DescriptionThis function stores account information for local govt agencies/department. Each Govt. department (from the contact master data store whose contact type is Govt Dept.) is mapped against one or more GL Codes (and SL Codes) applicable. This information will be required for generating different reports on local govt account. This screen may be used for any other contact type (for instance financial institutions) if so required by any other module.

Screen Layout

InputsThe contents of Govt Account Master data store are:

Contact Code* Unique code for departments/agencies[User will select from a view]

Contact Name* Name of the department /agencies[Display Automatically]

GL Code* GL account code from GL Head Master [User will select from a view]

SL Code SL Account code (if any) from SL head Master [User will select from a view]

Data StoreGovt Account Master Data storeThe following inputs will be stored in the Govt Account Master Data store:

- Contact Code- Contact Name- GL Code- SL Code

Business LogicNone

ProcessEnter and update Govt Account Master Data store.



Example:Contact Code ADB PFD RICBContact Name ADB World Bank Provident Fund

DepartmentRoyal Insurance

Corporation of BhutanGL Code 20701 20702 20703SL Code



Application ErrorNA

3.1.1.6 Bill Calendar

DescriptionThis function stores the yearly discount bill calendar. This will maintain the various Discount Bills offered by RMA.


Pre Conditions N/A

Screen Layout

InputsThe contents of Bill Calendar data store are:

Bill Number Auto generatedDuration (Days)* Duration in terms of daysPlan Auction Date* The date on which the bill is planned to be auctionedPlan Settlement Date* The date on which the bill is planned to be settledPlan Maturity Date* The date on which the bill is planned to be matured



Cancelled It’s a check Box(Flag)

Data StoreBill Calendar Data storeThe following inputs will be stored in the Bill Calendar data store:

- Bill Number- Duration (Days)- Plan Auction Date- Plan Settlement Date- Plan Maturity Date- Cancelled

Business Logic Bill number generation logic: It will be RMA/ <incremental number> Settlement date has to be greater than Auction date and Maturity date has to be

greater than settlement date. Settlement Date is 1 day greater than Auction Date, and Maturity date is

(Duration) days after Settlement Date. User may change in exceptional cases.

ProcessEnter and update Bill Calendar data store.

Example:Bill Number RMA/1Duration 91Plan Auction Date 27/04/2005Plan Settlement Date 28/04/2005Plan Maturity Date 27/07/2005Cancelled No



Application ErrorNA

3.1.1.7 Holding Rate Master

DescriptionThis function stores the information about holding rates for every currency. The holding rates are maintained for a period of date range. This function may be extended when Reserve Management Module (RMM) is developed.

Actors or ParticipantsUser of Banking Division/Reserve Management

Pre Conditions N/A



Screen Layout

InputsThe contents of Holding Rate Master (Header) are:

From Date* Effective range from dateTo Date* Effective range to date

The contents of Holding Rate Master (Detail) areCurrency Code The code of the currencyCurrency Abbreviation The abbreviation of the currencyCurrency Name The name of the currencyHolding Rate Actual Holding rate per unit of the currency

Data StoreHolding rate master storeThe following inputs will be stored in the Holding Rate Master (Header) data store:

- From Date- To Date

The following inputs will be stored in the Holding Rate Master (Detail) data store:- Currency Code- Currency Abbreviation- Currency Name- Holding Rate

Business Logic Range of From Date and To Date has to be unique.

ProcessEnter and update Holding Rate Master data store.

Example (Header):From Date 01/01/2006To Date 06/01/2006

Example (Detail):Currency Code 01 03Currency Abbreviation USD GBP



Currency Name US Dollar British PoundHolding Rate 54 63



Application ErrorNA

3.1.1.8 Buying/Selling Rate Master

DescriptionThis function stores the information about holding rates for every currency. The buying and selling rates are maintained for a date and instrument. This function may be extended when Reserve Management Module (RMM) is developed.

Actors or ParticipantsUser of Banking Division/Reserve Management

Pre Conditions N/A

Screen Layout

InputsThe contents of Buying/Selling Rate Master (Header) are:

Effective Date* Effective DateInstrument* Instrument for which the rates are entered.

The contents of Buying/Selling Rate Master (Detail) areCurrency Code The code of the currencyCurrency Abbreviation The abbreviation of the currency



Currency Name The name of the currencyBuying Rate Actual buying rate per unit of the currencySelling rate Actual selling rate per unit of the currency.

Data StoreBuying/Selling rate master storeThe following inputs will be stored in the Buying/Selling Rate Master (Header) data store:

- Effective Date- Instrument

The following inputs will be stored in the Buying/Selling Rate Master (Detail) data store:- Currency Code- Currency Abbreviation- Currency Name- Buying Rate- Selling Rate

Business Logic Range of From Date and To Date has to be unique.

ProcessEnter and update Holding Rate Master data store.

Example (Header):Effective Date 01/01/2006Instrument Telegraphic Transfer (TT)

Example (Detail):Currency Code 01 03Currency Abbreviation USD GBPCurrency Name US Dollar British PoundBuying Rate 54 63Selling Rate 56 64



Application ErrorNA

3.1.1.9 Financial Year Master

DescriptionThis function stores the different financial years of the system. This and other modules as well as report generation require this information.

Actors or Participants



User of Banking Division

Pre Conditions N/A

Screen Layout

InputsThe contents of Financial Year Master are:

Financial Year Code* Code of the financial yearFinancial Year Name* Descriptive Name of the financial YearStart Date* Start date of the financial yearEnd Date* End date of the financial yearActive Whether the financial year is active

Data StoreFinancial Year Master Data storeThe following inputs will be stored in the Financial Year Master data store:

- Financial Year Code- Financial Year Name- Start Date- End Date- Active

Business Logic Code and name has to be unique. Only one financial year may be active at a time.

ProcessEnter and update Financial Year Master data store.

Example:Financial Year Code 0405 0506 0607Financial Year Name Year 2004-2005 Year 2005-2006 Year 2006-2007Start Date 01/06/2004 01/06/2005 01/06/2006End Date 31/05/2005 31/05/2006 31/05/2007Active N Y N

Verification and Validation NACAM – SRS Ver 1.3 of 139



3.1.2 Transactions

3.1.2.1 Staff Salary Saving

This functionality will manage the Staff Salary Saving scheme of RMA maintained by banking division to deposit monthly net salary of the RMA staff and to allow subsequent withdrawal. Further, this function shall have feature to allow authorized user to make deposits (both cash and cheque/draft) other than usual monthly salary, calculate interest and produce necessary queries and regular reports.

3.1.2.1.1 Internal Deposit

DescriptionThis function manages the deposit of employee salary/loans/advances or any other deposits initiated from ADM and have to be deposited into employee’s salary savings account maintained with banking division. The information like employee, amount, etc for these deposits will be retrieved from the reference voucher generated from ADM. By this function the deposit amount of individual employee will be credited to their salary savings account.It is the voucher generated through this screen that will actually deposit the salary amount into the respective accounts of the employees. The Voucher generated through AAM will thus act more like a credit booking against the employees and does not mean the disbursement of their salaries.

Actors or participants User of the Banking Division

Pre ConditionsReference voucher has to be completed and authorised from AAM module

Screen Layout



InputsThe contents of Internal Deposit Header data store are:

Voucher No* The voucher prepared for this deposit in BDADM Voucher No.* The Reference voucher number created in ADM Value Date* The transaction date to be entered.Debited Gl Head* The bank account where the cheque issued by ADM

has been deposited[User will select form a view Link]Ref. No. Unique NumberParticulars* Default narration from ADM voucher

The contents of Internal Deposit Detail data store areEmployee Code* Employee Code selected from the referenceEmployee Name Name of the employeeAmount Total Amount

Data StoreInternal Deposit Data Store

The following inputs will be stored in Internal Deposit Header data store:- Voucher No- ADM Voucher No.



- Value Date- Debited GL Head- Ref. No.- Particulars

The following inputs will be stored in Internal Deposit Detail data store- Employee Code- Employee Name- Amount

OutputCreation of Internal deposit transactions in General Transaction (Nu) Data store

Post conditionsVoucher has to be verified and approved

Flow of Events ADM department will issue a cheque with a deposit advice stating deposit

amount of each employee and the reference voucher number to Banking Division The individual deposit information will be retrieved from AAM module User will then verify or authorised through “verify” and “authorised” button. Banking Division will pass a voucher (on authorization) as bellow

Debit Bank Account (BOB)Credit Salary Savings Accounts (Employee)

Business Logic On selection of reference voucher, system will show the list of employee and the

amount to be deposited



Application ErrorNA

3.1.2.1.2 Withdrawal

DescriptionThis function manages the withdrawal of money from salary savings account

Actors or participantsBanking Division Teller

Pre ConditionsN/A

Screen Layout



InputsThe contents of Withdrawal data store are:

Voucher No* The voucher prepared for this withdrawal in BDValue Date* Value Date of the transaction[user entered]Slip Number* Withdrawal slip number [User entered]Employee * Employee Code, NameSaving A/C No* Salary savings a/c no. linked with the employee codeWithdrawal Amount* Amount to be withdrawn [User entered]

Denomination Type Type of denomination [User Selection]Denomination Number Denomination NumberValue Amount/Value [User entered]Total Value Total Value

Data StoreWithdrawal data Store

The following inputs will be stored in Withdrawal data Store data store:- Voucher No.- Value Date- Slip Number- Employee Code- Saving A/C No- Withdrawal Amount

The following inputs will be stored in Withdrawal detail data Store data store- Denomination Type



- Denomination Number - Value - Total Value

Post conditions Voucher has to be verified and approved

Flow of Events Employee will submit the duly filled withdrawal slip Teller will verify the account number, signature from the system and balance available On acceptance of the withdrawal form, Banking Division will pass a voucher as bellow

Debit Salary Savings Accounts (Employee)Credit Cash

Business Logic If withdrawal amount is more than available balance, withdrawal will not be

allowed On putting the employee code, savings account number has to be fetched from

employee master. System will also retrieve the image and signature of employee. The photo and signature will be stored as a image file in the server and the path of those files will be stored in database

Reference of the voucher has to be linked with the withdrawal process

Verification and Validation Employee must have a salary deposit account Withdrawal amount cannot be more than available balance


Application ErrorNA

3.1.2.1.3 Deposit (Cash/Cheque)

DescriptionThis function manages the deposit of money in form of cash or cheque into salary savings account

Actors or participantsBanking Division Teller

Screen Layout



InputsThe contents of Deposit data store are:

Voucher Number* Corresponding voucher No prepared for this transaction in BD

Value Date* Value Date of the transactionSlip Number* Withdrawal slip numberEmployee Employee CodeSaving A/C Number* Salary savings a/c no. linked with the employee codeDeposit Amount* Amount to be depositedTransaction Mode C-Cash deposit, Q-Cheque Deposit, [Mode of

Transaction]

Corresponding to the above input there will be Deposit (cash/cheque) detail input as followsDenomination Type Type of denomination [User selection]Denomination Number Number of Denomination[User entered]Value ValueBank Name of the Bank[User will select form the view Link]Cheque Draft No Cheque or Draft Number[User Entered]Amount Amount



Data StoreDeposit Data Store

The following inputs will be stored in Deposit Data Store Header data store:- Voucher No- Value Date- Slip Number- Employee- Saving A/C Number- Deposit Amount- Transaction Mode

The following inputs will be stored in Deposit Data Store Detail data store:- Denomination Type - Denomination Number - Value - Bank- Cheque Draft- Amount

Output Creation of salary deposit transactions in General Transaction (Nu) Data store Report for list of deposits

Flow of Events Employee will submit the duly filled deposit slip Teller will verify the account number, signature and also authenticate (manual) the

cheque in case of cheque deposit. Once the teller is satisfied, an appropriate proof sheet shall be generated by the system,

verify it and sign on the “Prepared by:” column and forward to Approving Officer. The employee will be issued an acknowledgement and the proof sheet will be generated

for deposit information If it is cash deposit the voucher will be prepared, verified and approved at the time of

deposit by the teller but for outside (ex-RMA) cheque deposit the voucher will be pending till the cheque is cleared/collected

Once the cheque is cleared through clearing, the authorizer will verify and authorised the same by assigning new voucher number effective form authorised date.

The nature of the transaction will be as followsCash

Debit CashCredit Salary Savings Account (Employee)

ChequeDebit RMA Account with BankCredit Salary Savings Account (Employee)

Business Logic NA


Analytical / Calculation



NA

Application ErrorNA

3.1.2.1.4 Calculate Interest

DescriptionThis function manages the calculation of interest using daily product method on the balance of salary savings account

Actors or participantsBanking Division Users

Pre ConditionsN/A

Screen Layout

InputsThe contents of Calculate Interest Header data store are:

Voucher No. Corresponding Nu voucher NumberRate of Interest (%)* Rate of interest for the period in percentageFrom Date* Interest Calculated From DateTo Date* Interest Calculated To DateDebit GL Head Debited GL A/c [User will select form a view ]



Ref. No. Unique Reference NumberParticulars Particulars of transaction

Inputs (Details)Employee Code Employee Code (List will be displayed)Employee Name Name of EmployeeAmount Interest Amount

Data StoreCalculate Interest header

The following inputs will be stored in Calculate Interest Header data store:- Voucher Number- Rate of Interest (%)- From Date- To Date- Debit GL Head- Ref. No.- Particulars

The following inputs will be stored in Calculate Interest Detail data store- Employee Code - Employee Name- Amount

Output Creation of interest calculation record Creation of salary Interest transactions in General Transaction (Nu) Data store Report for interest journal

Post conditions Interest Journal is printed for verification and approval After verification, interest vouchers are approved

Flow of Events At the end of the month (or any period) interest will be calculated on daily product basis

based on monthly basis. Banking Division will generate interest calculation on monthly basis and send to the

ADM division. ADM will then verify it online and write a cheque to the banking division. On receiving this cheque, the banking division will raise a voucher and authorised it. Print the interest journal and get approval The nature of the transaction will be as follows

Debit Interest Expense AccountCredit Salary Savings Account (Employee)

Business Logic Input date range for interest calculation. Base on the date range collect the transactions required to calculate interest from the

individual saving sub-ledgers. Within each sorted individual account, calculate number of days for each change of

balances as below.

Date Particulars Amount Balance No. Of Days30/06/2002 BBF – from June 3003 129,208.14 DR 129,208.14DR 31CAM – SRS Ver 1.3 of 139


31/07/2002 Deposit for July 02 3,000.00 CR 126,208.14DR 2323/07/2002 Deposit for Aug 02 3,000.00 CR 123,208.14DR 32

Calculate the interest as (balance*no_of_days*rate)/36500 as shown below: -

Date Particulars Amount Balance No. Of Days

Interest

30/06/2002 BBF – from June 3003 129,208.14 DR 129,208.14DR 31 548.6931/07/2002 Deposit for July 02 3,000.00 CR 126,208.14DR 23 397.6423/07/2002 Deposit for Aug 02 3,000.00 CR 123,208.14DR 32Total Interest 946.33

Verification and Validation There should not be more than one interest calculation for same period All Mandatory fields are marked by “*”.

Analytical / CalculationInterest For a period (Days)= (balance*no_of_days*rate)/36500

Application ErrorNA



3.1.2.2 Ngultrum Vouchers

3.1.2.2.1 General Transaction (Nu) This functionality will maintain the normal Ngultrum vouchers maintained by Banking Division. The process and business logic is same as with the general transaction of AAM module. Refer the following Use Cases of AAM module

General Transaction (Section 3.1.2.2.1 of Document ICBS/AAM/STDSRS/SRS-AAM-003)

3.1.2.2.2 Reverse Voucher (Nu) Refer the following Use Cases of AAM moduleCAM will use the same reversal voucher interface used by the AAM to reverse the authorised voucher.

Reverse Journal (Section 3.1.2.2.2.1 of Document ICBS/AAM/STDSRS/SRS-AAM-003)

3.1.2.3 Foreign Currency Accounting

This function will manage all the transactions where foreign currency is involved. For the foreign currency vouchers where foreign currency is booked against Ngultrum, the equivalent Ngultrum amount is booked under the value of currency (VOC) account against the ‘Our Currency’ account for equivalent FC value. Therefore for any such type of voucher there will be two parts – one for Ngultrum Accounting and other for FC accounting.The provision for currency wise VOC account is dependent on how the Chart of Account is defined by RMA. Each of these VOC accounts is tagged with the corresponding currency in currency master. All the vouchers will go thru the following common steps.

Preparation of VoucherAll monetary transactions either payments advise or receipts pertaining to the Division has to be dully approved or endorsed by the management before it is passed on to the Approving Officer except for certain transactions which is in line with the existing standing instructions. Any authorized users of the Banking Division can prepare the voucher directly on the system, view it on screen, print necessary copies of the voucher and carry out the verification. The user preparing the voucher is required to initialise on the documents for accountability purpose. Next the same voucher copies are submitted to the verifying officer who conducts further checks. If the entry is found correct, it is further passed to the approving officer for final verification and approval. Once the approving authority verifies, signs on the documents and approves online, then only the necessary accounts will be updated.

Process: The process will have the following steps:

a. Make sure that there is a proper authorization and all supporting documents necessary to raise any voucher.

b. Voucher number must be system generated (as discussed in AMM module).c. Input the transaction date, narration, value date and other information required at voucher

header level. d. In the detail section input debit/credit amount, assign appropriate accounts codes for the

transaction, particular of the account transaction, and further bifurcate the voucher record into denomination (if applicable/cash related voucher).



e. For debit record allow only debit amount field to enter. Similarly for the credit record allow only credit field to enter.

f. System shall automatically check and remind the users if the total amount of debits is not equals to total of credits on completion of entry.

g. System shall not allow posting voucher to unopened or closed period (previous financial period or future financial period).

h. At the time of preparing voucher, verification and approval fields should be kept blank. Until and unless the voucher is not verified and approved by the authorized users, no accounts shall be updated.

i. View the voucher on the screen to make sure that everything is gone correctly.j. Print the voucher, check it thoroughly, sign on the “Prepared by:” column and submit along

with other supporting document(s) to the verifying Officer for verification and signing. Once verified, the voucher shall be sent to the Approving officer for final approval

Verification of Voucher

This process will allow Verification Officer to view the voucher on screen, verify it, leave pending/reject or authorize the voucher. Approval of such voucher at this stage shall not affect the corresponding accounts. Process:

a. Once the Verifying Officer receives the voucher copies, the computer generated voucher reference number is keyed in the system that will search the record and display on the screen.

b. If the required record is unable to find, the system will display all pending voucher(s) due for verification, sorted by date of entry on the separate voucher search screen. User can pick from the list and display it on the main voucher preparation screen/interface. Once the verification is over and found correct, the verifying officer shall be given option to approve/reject or leave pending.

c. Following the approval of Verifying Officer, the voucher will be made available for the Approving Officer to verify further and give final approval or reject it.

d. If the voucher is found correct, then Verifying Officer shall sign on the voucher copies against the “Verified by:” column and authorize the voucher online.

e. The voucher copies along with the necessary documents shall be forwarded to the approving officer for final verification and approval.

Approve Voucher

This process will allow an Approving Officer to view the voucher on screen, verify it, and approve/reject it. Process:

a. The separate authorization screen/interface shall be provided in the new system for the approving officer to check and accord final approval of voucher.

b. The system will display all the current vouchers lying pending for approval. The Approving Officer shall select the particular voucher requiring final verification and approval.

c. The approving officer is required to check the displayed record thoroughly. Once the verification is over the approving officer shall be given an option to Approve or Reject. Once approved online, the voucher shall update the corresponding accounts automatically.



d. The Approving Officer is also required to sign on the voucher copies following the online approval process.

e. If the voucher is found unacceptable by the Approving Authority, then such remarks shall be noted on the voucher (hardcopy) and send back to the concerned user responsible for preparation.

f. If voucher is rejected then the history of rejection with remarks will be stored

3.1.2.3.1 General Foreign Currency Voucher

DescriptionThis function will manage the normal currency voucher where the currency used is same for all the account heads. This function is similar to the General Transaction (Nu) with foreign currency involved.


Screen Layout

InputsThe contents of General FC Voucher data store are:

Voucher No* System generated unique no of voucher.Voucher Date System dateValue Date* The date that this Transaction takes effect.Voucher Type* The unique ID number of the transaction type in which

this Transaction would be documented.TDS Applicable Tax Deduction at Source [User will select form a list]External Reference Physical Document no for this TransactionDivision The Division to which this entry is relevant.Particulars* A plain text description of this Transaction



Reason of Rejection Remarks for rejection

Corresponding to the entry above the following attributes will be entered in detail.

Currency/ Mode * Currency of transaction, and there will be master for Bank Reference type which are basically Cheque, Pay Order, Draft etc.

GL Code* Unique Code for GLGL Head* The unique ID number of the General Ledger Head to be

debited or credited. Bank A/C No /SL Type The unique ID number of the Sub-Ledger Head to be

debited or credited or Bank A/C No.SL Code Unique Code for GLSL Head SL DescriptionAmount Dr* The amount to be debited. Amount Cr* The amount to be creditedRef No. Existing no of Bank Reference (Cheque no/Draft No.).

System will automatically put the available unused cheque number against the bank account

Note An alphanumeric text description for this entry.Budget Balance Budget Balance

Data StoreThe above mentioned inputs will be stored in the following data stores:

General FC Voucher Header General FC Voucher Detail

Post conditionsNA

Flow of Events Authorised user will prepare the voucher by entering the details as described in the data

stores Once voucher is prepared user will print it and sign on as “Prepared By” and submit for

verification and authorisation Once voucher is verified it will be ready for authorisation Once authorised, voucher will be locked and balances will be updated

Business Logic Each Transaction has to be marked by a voucher type Voucher Number will be system generated, voucher number will be reinitialised every

year There can be one debit-many credit, one credit-many debit and one debit-one credit Users will be able to both select and enter a/c code or description While searching for an account filtering facility will be made available The current unused cheque number against the selected bank account will come

automatically Cheque number will be cancelled automatically when the voucher using the cheque

number is reversed

Verification and ValidationCAM – SRS Ver 1.3 of 139


Voucher type, Date, Number, amount, particular/narration, currency code can not be null User can’t put both debit and credit amount for a GL/SL entry If for a GL/SL entry the debit and credit amount is 0 then it will be discarded All Mandatory fields are marked by “*”.


Application Error NA

3.1.2.3.2 General Ngultrum Voucher

DescriptionThis function will manage the normal currency voucher where the currency used is same for all the account heads. This function is similar to the General Transaction (Nu) with foreign currency involved.


Screen Layout

InputsThe contents of General Ngultrum Voucher data store are:

Voucher No* System generated unique no of voucher.Voucher Date System dateValue Date* The date that this Transaction takes effect.Voucher Type* The unique ID number of the transaction type in which

this Transaction would be documented.CAM – SRS Ver 1.3 of 139


TDS Applicable Tax Deduction at Source [User will select form a list]External Reference Physical Document no for this TransactionDivision The Division to which this entry is relevant.Particulars* A plain text description of this TransactionReason of Rejection Remarks for rejection

Corresponding to the entry above the following attributes will be entered in detail.Mode * There will be master for Bank Reference type which are

basically Cheque, Pay Order, Draft etc.GL Code* Unique Code for GLGL Head* The unique ID number of the General Ledger Head to be

debited or credited. Bank A/C No /SL Type The unique ID number of the Sub-Ledger Head to be

debited or credited or Bank A/C No.SL Code Unique Code for GLSL Head SL DescriptionAmount Dr* The amount to be debited. Amount Cr* The amount to be creditedRef No. Existing no of Bank Reference (Cheque no/Draft No.).

System will automatically put the available unused cheque number against the bank account

Note An alphanumeric text description for this entry.Budget Balance Budget Balance


General Nu. Voucher Header General Nu. Voucher Detail

Post conditionsNA

Flow of Events Authorised user will prepare the voucher by entering the details as described in the data

stores Once voucher is prepared user will print it and sign on as “Prepared By” and submit for

verification and authorisation Once voucher is verified it will be ready for authorisation Once authorised, voucher will be locked and balances will be updated

Business Logic Each Transaction has to be marked by a voucher type Voucher Number will be system generated, voucher number will be reinitialised every

year There can be one debit-many credit, one credit-many debit and one debit-one credit Users will be able to both select and enter a/c code or description While searching for an account filtering facility will be made available The current unused cheque number against the selected bank account will come

automatically



Cheque number will be cancelled automatically when the voucher using the cheque number is reversed

Verification and Validation Voucher type, Date, Number, amount, particular/narration, currency code can not be null User can’t put both debit and credit amount for a GL/SL entry If for a GL/SL entry the debit and credit amount is 0 then it will be discarded All Mandatory fields are marked by “*”.



3.1.2.3.3 Debit Advice Voucher (BK01)

DescriptionThis function will manage the BK01/Debit Advice Voucher BK01 voucher is used in following transactions

Foreign Currency Payment/Release Sale of Bullions


Screen Layout



InputsThe contents of BK01 data store are:

Voucher No. Voucher NumberVoucher Date Voucher DateValue Date Effective Date [By Default System Date but user can

edit it]Individual/Bank User will select between this two

option[Individual/Bank/Bullion]Name Name of the person Number Unique Number of voucherReference

Corresponding to the entry above the following attributes will be entered in FC Voucher detail.

Receipt Mode Mode of Receipt [user will select form list]Debit GL Head Debited Bank Name[User will select form a list]Reference Number Reference Number Payment Mode Mode of Payment[Cash/Bank] Currency Currency [User will select form a view link]Holding Rate Holding Rate[User entered]Selling/Middle Rate Selling /Middle Rate[user entered]Foreign Currency Amount Amount of Foreign Currency[user entered]Amount in (gms) Amount in Grams[User entered]Equivalent Nu Amount(s) Equivalent NU AmountCommission Amount Commission Amount[System Generated but user can

edit ]Gain/Loss Gain/Lose Amount[calculated by system]Net Receivable Total AmountPurpose Purpose of transaction[User will select form a list]Particular Particulars of transactionReason for Rejection Remarks for rejection


BK01 Data store General FC Voucher Header General FC Voucher Detail General Nu Voucher Header General Nu Voucher Detail

OutputPopulation of BK01 Data store, General FC Voucher Header, General FC Voucher Detail, General Nu Voucher Header, General Nu Voucher Detail data store, printing of vouchers

Post conditions1. None

Flow of EventsForeign Currency Payments and Release



1. Forex division will issue a authorization letter to the banking division for Foreign payment/releases

2. Upon receipt of the authorization letter from the Forex Division the banking division will check the date, currency code, amount, beneficiary account and other details

3. Swift Message is prepared and send to swift operator4. On the basis of the above information system will generate following:

Total of TCs/Notes Commission Amount Calculated from Selling rate and holding rate Equivalent in Nu. = Total of TCs & Notes * Hold Rate Total = Total of TCs & Notes * TT Sell Rate Commission Amount = Total – Equivalent in Nu

5. Prepare the voucher and print and sign on ‘Prepared By’6. Go thru the normal verification and authorization process7. Once voucher is prepared any modification on the Forex authorization letter has

to be manually effected on voucher8. Once it is approved any modification on the Forex authorization cannot be

implemented. In that case the current voucher has to be reversed and a new voucher has to be prepared

9. The nature of accounting for this voucher is given as bellow:

Ngultrum AccountingDebit Bank/CashCredit VOC (Cy)If Income from Exchange/CommissionCredit Commission Income If Expense for Exchange/CommissionDebit Commission Expense

FC AccountingDebit Our Cy (Cy)Credit TC Account or Cash In Hand (CY)

Bullion Bar SaleThe BK01 voucher is also used for selling of Bullion bars at RMA. Selling of bullion bar requires management instructionThe steps for selling bullion bar are as follows:

1. Upon receipt of the instruction from the Management the banking division will check the date, Bullion Type, amount, beneficiary account and other details

2. On the basis of the above information system will generate following: Exchange gain/loss Calculated from Selling rate and holding

rate Equivalent in Nu. = (Total of Bullions) * Hold Rate Bank Total = Gain/(-Loss) in Nu. + Total of Bullions * Sell Rate

3. Prepare the voucher and print and sign on ‘Prepared By’4. Go thru the normal verification and authorization process5. The Issue division will access the voucher from their system and will prepare

their voucher motif wise6. The information which are common to BK01 and issue division voucher will

automatically reflected when they prepare their voucher7. The nature of accounting for this voucher is given as bellow:

Ngultrum Accounting



Debit Foreign Exchange Current AcCredit VOC (Gold or Silver)Credit Income from other sources

Bullion accounting in gramsDebit Our Gold/Silver BarCredit Gold/Silver Bar

Business Logic For each entry to BK01 data store there will be corresponding entry in Nu Voucher data

store and FC voucher data store Verification and authorisation information will be copied from BK01 voucher data store to

Nu and FC voucher data store If Cash is selected system will automatically debit the cash related GL head If Bank is Selected ,System will allow to enter/select Bank related GL head Gain/loss is calculated from(Holding Rate*Exchange Amount)-(Selling rate*Exchange

Amount) If (Holding Rate*Exchange Amount) > (Selling Rate* Exchange Amount) then the

difference is consider as a lose and Vice- versa Commission is required for some high level remittances decided by the management,

and calculated at 1% of the total NU amount. Commission Charges: 1% of the total amount between 500 to 10000 is charge as

commission. If 1 % of commission comes above Nu 10000 then the commission is limited to Nu

10000 only Calculated Commission is appropriately rounding off

Verification and Validation Account head debited and credited has to be validated from account mapping data store All Mandatory fields are marked by “*”.

Analytical / Calculation Commission Amount= (Total of TCs & Notes) * Holding Rate - (Total of TCs & Notes) *

selling Rate Nu. Equivalent = (Total of TCs & Notes) * Holding Rate Bank Total = Commission in Nu. + Total of TCs & Notes * TT Sell Rate


3.1.2.3.4 FOREX Receipt Voucher (BK02) DescriptionThis function will manage the BK02/FOREX Receipt Voucher. BK02 voucher is used when Foreign Currency is received in terms of Notes/TC/Cheque/Drafts against Ngultrum. These are generally received from the local banks but in some special cases these are also received from the individualsThere are two types of foreign currency receipt

Foreign Currency Receipts in terms of CashPresently 12 types of foreign currencies are accepted by RMA. When some individual brings these currencies the cash-buying rate is applied for exchange. But for the cases



of commercial banks the middle rate (Average of cash buying and selling rate for the day) is applied. In order to keep track of these currencies, the serial number of notes, name & address of the depositor, date of deposit are registered.

Foreign Currency Receipts in terms of TC/Cheque/Drafts The Instruments are accepted on a collection basis or immediate payment basis. There is a collection charge of .75% of the value of TCs and to maximum of Nu 10,000 are deducted from the payment.


Pre conditionsIn case of payment on collection corresponding collection transaction has to be performed

Screen Layout


Voucher No. Voucher NumberVoucher Date Voucher DateValue Date Effective Date [By Default System Date but user can

edit it]Individual/Bank User will select between this two

option[Individual/Bank/Bullion]Depositor’s Name Name of the depositorDepositor Address Address of the depositor


Receipt Mode Mode of Receipt [user will select form list]



Payment Mode Debited Bank Name[User will select form a list]Reference Number Reference Number Currency Code Currency Code[User will select form a view link]Buying/Middle Rate Middle RateForeign Currency Amount Amount of Foreign Currency[user entered]Equivalent Nu Amount Equivalent NU AmountCommission Amount Commission Amount[System Generated but user can

edit ]Net Payable Total AmountPurpose Purpose of transaction[User will select form a list]Particular Particulars of transactionReason for Rejection Rejection Remarks


BK02 Data store General FC Voucher Header General FC Voucher Detail General Nu Voucher Header General Nu Voucher Detail

OutputPopulation of BK02 Data store, General FC Voucher Header, General FC Voucher Detail, General Nu Voucher Header, General Nu Voucher Detail data store

Post conditionsNone

Flow of EventsForeign Currency Receipts in terms of Cash8. The physical notes brought by individual or bank are checked for genuineness of the

notes, serial number of the notes etc.9. After satisfactory checking Cash is received from individuals or bank along with the list of

serial number and individual voucher is prepared for each currency 4. Prepare the voucher and print and sign on ‘Prepared By’5. Go thru the normal verification and authorization process6. Once the voucher is approved, the counter value is paid either in cash

or by crediting the current account of the commercial banks, which is advised to them in the form of credit advice. There is also option for cheque payment.


Foreign Currency AccountingDebit Cash in Hand, Convertible Currencies (Cy Code)Credit Our Currency (Cy Code)

Ngultrum AccountingDebit VOC (Cy Code)Credit Bank Current Account (In case of Credit Advice)

Or Bank Account (In case of Cheque)Or Cash in Hand, Nu (in case of Cash)



Foreign Currency Receipts in terms of TC/Cheque/Drafts1. The Instruments brought by individual or bank are verified

Immediate Payment2. If it is an immediate payment Prepare the voucher and print and sign on

‘Prepared By’3. Go thru the normal verification and authorization process4. Once the voucher is approved, the counter value is paid either in cash or by

crediting the current account of the commercial banks, which is advised to them in the form of credit advice. There is also option for cheque payment.


Foreign Currency AccountingDebit Bill/TCs for collection (42611)Credit Our Currency (Cy Code)

Ngultrum AccountingDebit VOC (Cy Code)Credit Foreign Exchange Current Ac (24109)

Or specified by userOr Cash in Hand, Nu (in case of Cash Payment)

Payment on Collection6. The depositor is issued an acknowledgement receipt7. Before preparing the BK02 Voucher following transactions are done

At the time of ReceiptForeign Currency Accounting

Debit Bills/TCs for collection account (42611)Credit Sundry Deposit Account (30911)

At the time of sending the TCs for collection to BankForeign Currency Accounting

Debit Foreign Exchange Suspense Ac (47801)Credit Bills/TCs for collection account (42611)

At the time of CollectionForeign Currency Accounting

Debit Sundry Deposit Account (30911)Credit Foreign Exchange Suspense Ac (47801)

At the time of Payment (Bk02)Foreign Currency Accounting

Debit AMEX BankCredit Our Currency (Cy Code) (18201)

Ngultrum AccountingDebit VOC (Cy Code) (18101)Credit Foreign Exchange Current Ac (24109)Credit Commission & Fees (71103)

8. Go through the normal verification and authorization process



9. The counter value is paid either in cash or by crediting the current account of the commercial banks, which is advised to them in the form of credit advice. There is also option for cheque payment.

10. In case of FC Cash-user will enter foreign currency by denomination wise from the denomination interface and the total submission of the denomination will be automatically display in the FC amount field in read only mode.

11. In case of NU cash-user will local currency by denomination wise from the denomination interface and the total submission of the denomination will cross check with the total NU.

12. In some cases if commission is waived off, user will put commission rate as 0



Nu and FC voucher data store Minimum Commission Charge of 0.75% of the total value of TC and Maximum charges

up to Nu. 10000


Analytical / Calculation Commission Amount= Total Nu Amount * Commission Rate


3.1.2.3.5 Currency Swapping Voucher (BK07) DescriptionThis function will manage the BK07/Currency swapping Voucher. BK07 interface will support following Voucher.FC Deposit of Foreign Bank.Govt Remittance to Other Bank.Individual FC cash exchange to RMA


Pre conditionsCurrency has been sent for swapping and the transaction has been booked against Suspense Account OR the swapping is being done in cash over the RMA counter.

Screen Layout




Voucher No. Voucher NumberVoucher Date Voucher DateValue Date* Effective Date [By Default System Date but user can

edit it]


Payment Mode* Mode of paying sold currencyReceipt Mode* Mode of receiving purchased currencySold Currency* Currency that is soldPurchased Currency * Currency that is purchasedExchange Rate* Exchange rate provided by foreign bank, which is to be

inputSold Amount Amount of sold currencyPurchased Amount Amount of purchased currencyPurpose Purpose of transaction[User will select form a list]Particular Particulars of transactionReason for Rejection Rejection Remarks


BK07 Data store General FC Voucher Header General FC Voucher Detail

OutputPopulation of BK07 Data store, General FC Voucher Header, General FC Voucher Detail data store

Post conditionsCAM – SRS Ver 1.3 of 139


BK09 Voucher for exchange loss

Flow of Events10. RMA send a SWIFT to the Bank from where the currency has to be purchased advising

the amount of foreign currency to be purchased against a specified amount of foreign currency (e.g. USD, GBP)

11. The bank will send RMA the details of its account maintained with Foreign Bank and specify the date when RMA have to make the foreign currency payment

12. Upon receipt of the foreign currency payment deposited at foreign bank’s account with US Fed Reserve Bank, Bank credits the counter value in exchanged currency into RMA’s account maintained with it

5. Prepare the voucher, print and sign on ‘Prepared By’6. Go thru the normal verification and authorization process7. The nature of accounting for this voucher is given as bellow:

When currency sent for exchange1st Currency

Debit Suspense account in foreign CurrencyCredit Foreign Currency In Hand

When equivalent amount is credited in Foreign Bank1st Currency

Debit Our Currency (1st Cy Code)Credit Suspense account in foreign Currency

2nd CurrencyDebit Foreign Bank AcCredit Our Currency (2nd Cy Code)

8. If there is exchange loss then BK09 voucher will be prepared as bellow:

Ngultrum AccountingDebit Commission & Fees ExpenseCredit Value of our Currency (Cy code)

FC AccountingDebit Our Currency (Cy code)Credit Suspense account in foreign Currency



Nu and FC voucher data store While creating voucher apply the corresponding value date to the vouchers


Analytical / CalculationNA




3.1.2.3.6 FOREX Purchase Voucher (BK08)

DescriptionThis function will manage the BK08/FOREX purchase Voucher. BK08 voucher is used for foreign currency receipts via correspondent banks but no charges are levied on beneficiaries. This voucher is generally used when funds are deposited by external agencies like the ADB, World Bank etc or interest is received in FC. This Voucher is also use for -Purchase of Foreign Currency without Commission-For Interest Income


Pre conditionsFunds are deposited by external agencies into foreign currency account abroad and RMA has got that information

Screen Layout


Voucher No. Voucher NumberVoucher Date Voucher DateValue Date* Effective Date [By Default System Date but user can

edit it]Government/RMA Internal Transaction

Whether the transaction is for Government or is RMA’s internal Transaction



Depositor’s Name Name of the depositorDepositor’s Address Address of the depositor


Receipt Mode* Mode of receiptPayment Mode* Mode of PaymentCurrency* CurrencyHolding Rate* Holding RateBuying Rate* Buying RateForeign Currency Amount Foreign Currency AmountEquivalent Nu Amount Equivalent amount in NgultrumNet Payable Total Amount PayablePurpose Purpose of transactionParticular Particulars of transactionReason for Rejection Rejection Remarks



OutputPopulation of BK08 Data store, General FC Voucher Header, General FC Voucher Detail data store

Post conditions None

Flow of Events1. Funds are deposited by the external agencies into foreign currency account

abroad or interest received2. Prepare the voucher and print and sign on ‘Prepared By’3. Go thru the normal verification and authorization process4. Print Credit Advice for bank, Gov. department of Aid and Debt management,

Gov. Account holder5. The nature of accounting for this voucher is given as bellow:

FC accountingDebit Foreign Bank AccountCredit Our Currency

Nu AccountingDebit Value Our CurrencyCredit Foreign Exchange Current Account



Nu and FC voucher data storeCAM – SRS Ver 1.3 of 139


Holding rate used for calculating Interest Income. TT Buying rate used for calculating Govt remittance.


Analytical / Calculation None


3.1.2.3.7 Process FOREX Sale Voucher (BK09) DescriptionThis function will manage the BK09/FOREX Sale Voucher. BK09 voucher is used for foreign currency sale via correspondent banks but no charges are levied (Sale of FC without Commission). This voucher is generally used when foreign payments are done


Pre conditionsNA

Screen Layout


Voucher No. Voucher NumberVoucher Date Voucher Date



Value Date* Effective Date [By Default System Date but user can edit it]

Government/RMA Internal Transaction

Whether the transaction is for Government or is RMA’s internal Transaction


Receipt Mode Mode of receiptPayment Mode Mode of PaymentCurrency Currency of transactionHolding Rate Holding RateSelling Rate Selling RateForeign Currency Amount Foreign Currency AmountEquivalent Nu Amount Equivalent Nu AmountNet Receivable TotalPurpose Purpose of TransactionParticulars Particular of TransactionReason of Rejection Reason of Rejection

Data StoreBK09 Data store, General FC Voucher Header, General FC Voucher Detail data store

OutputThe above mentioned inputs will be stored in the following data stores:

Population of BK09 Data store General FC Voucher Header General FC Voucher Detail

Post conditions None

Flow of Events1. Swift receipt for Payment received by bank2. Prepare the voucher and print and sign on ‘Prepared By’3. Go thru the normal verification and authorization process4. The nature of accounting for this voucher is given as bellow:

FC accountingDebit Our Currency Credit Foreign Bank Ac

Nu AccountingDebit Telex charges/Fees PaidCredit Value Our Currency

Business Logic

For each entry to BK09 data store there will be corresponding entry in Nu Voucher data store and FC voucher data store

Verification and authorisation information will be copied from BK09 voucher data store to Nu and FC voucher data store

TT Selling Rate or Holding Rate is used for calculating Govt remittance.






3.1.2.3.8 FOREX Settlement Voucher (BK10) DescriptionThis function will manage the BK10/FOREX Settlement Voucher. BK10 voucher is used when foreign currency is deposited in correspondent bank overseas especially on behalf of V.V.I.Ps and payment is done in Ngultrum from local banks. Bank charges decided by RMA are applied on beneficiary.


Pre conditionsNA

Screen Layout


Voucher No. Voucher NumberVoucher Date* Voucher Date (System Date)Value Date* Effective DateIndividual/Bank Whether the transaction is for individual or Bank



Received For/From Received From/For whomIn Account With Reciever’s Bank nameExternal Reference External reference number


Receipt Bank Receipt Bank GL HeadPayment Mode Mode of paymentCurrency Currency of transactionTT Buying/Middle Rate TT Buying/Middle rate, whichever applicableForeign Currency Amount Total Amount of Foreign CurrencyNu Counter Value Counter Value in NgultrumBank Charges Charges for BankNet Payable Total AmountPurpose Purpose of TransactionParticulars Particular of TransactionReason of Rejection Reason of Rejection



Post conditionsNA

Flow of Events1. Banking division checks details of the transaction like Bank Account, Currency,

Amount, beneficiary etc.2. Based on the above input following are calculated

Counter Value in Nu=FC amount * Exchange RateNet Amount in Nu=Counter Value-Bank Charges.

3. Prepare the voucher and print and sign on ‘Prepared By’4. Go thru the normal verification and authorization process5. Print Credit Advice for bank and beneficiary6. In Case of individual Cheque is prepared7. Payment can be Made in cash/Cheque, and in case of cheque, automatic

cheque will generated by the system.8. The nature of accounting for this voucher is given as bellow:

Example: 1FC accounting

Debit Foreign Bank Account (e.g. 25215)Credit Our Currency

Nu AccountingDebit Value Our CurrencyCredit Foreign Exchange Current Account CD1173 (24109)

Or BOB Misc. Ac (24106)Credit Fees & Commission





Nu and FC voucher data store




3.1.2.3.9 Note Serial Number TrackingDescriptionThis is function will be used to store information regarding notes received by the Banking Division so that they can backtrack to the source in case of counterfeit/spoilt/un-acceptable notes.


Pre conditionsNA

Screen Layout



InputsThe contents of Note Serial Tracking data store are:

Date* Date (System Date, User may change)Received From* Name of Individual/Bank from where the same is

received.Address/Comment Address of the receiver or any other comment.Currency Currency of the notes received.

Corresponding to the entry above the following attributes will be entered in Note Serial Tracking detail.

Denomination Denomination of the selected currencySerial Number Serial Number of the note received.Remarks Any remarks against the note received.


Note Serial Tracking data store

Post conditionsNA



Business Logic Combination of Date, Received From and Currency should be unique.

Verification and Validation All Mandatory fields are marked by “*”.





3.1.2.4 Discount Bill

3.1.2.4.1 Sale of Discount Bill This function manages the sale of discount bill from RMA.


Pre conditions Bill Calendar is prepared at the beginning of year On Last Wednesday of each month report is prepared for latest liquidity position,

variation with last month of local banks and total bill outstanding. The report is presented to Monitory Operation Committee Monitory Operation Committee decides on auctioning of bills

Screen Layout

InputsFollowing are the input in Sale of Bill:

Voucher No Nu Voucher NumberValue Date Effective DateBill No.* From Bill CalendarAuctioned Date* Any external reference numberSettlement Date* Date of settlementMaturity Date* Period for which bill is issuedDuration DurationFace Value Per Unit* Value which will be returned at maturityNo. of Participants Number of participants finalized in the bidding processTotal Offered Total bid offeredTotal Sold Amount in Nu. of total soldTotal Discount Amount in Nu. of total discount.Particulars* Details of Bill

Following are the input in Sales of Discount bill Details



Name Name GL Code Unique Code for General LedgerGL Name GL Head DescriptionSL Code Unique Code for Sub LedgerSL Name SL Head DescriptionDiscount Rate Rate of discount in percentageAmount Amount offered to selected contact.Discounted Amount Amount discountedTotal Amount Net amount received from the selected contactParticulars Particular of transaction

Data StoreSales of Bill Data Store

The following inputs will be stored in Sales of Bill data store:- Voucher No- Value Date- Bill No.- Auctioned Date- Settlement Date- Maturity Date- Duration- Face Value per Unit- No. of participants- Total Offered- Total Sold- Total Discount- Particulars

The following inputs will be stored in Sales of Bill detail data store- Name- GL Code - GL Name- SL Code - SL Name- Discount Rate- Amount- Discounted Amount- Total Amount- Particulars

Post conditions

Verification and approval of voucher generated from Bill Sale

Flow of Events1. Committee decides on auctioning of Bill2. Nu voucher is automatically created against this sale3. Normal verification and approval process is done against the voucher4. Following is an example of the accounting nature against a bill sale

Debit BOB Miscellaneous AcDebit BOB Miscellaneous Ac (for RICB)Debit BNB Miscellaneous AcDebit Discount on RMA Bills Ac



Credit RMA Discount Bill AcException

Single bill can be divided to more than one party

Business Logic There can be single bill sold to multiple parties There can be un sold bills though it is scheduled in calendar

Verification and Validation Bills sold has to be validated from calendar for bill number, scheduled date for auction

and settlement All Mandatory fields are marked by “*”.



3.1.2.4.2 Redemption of Bill This function manages the redemption of discount bill from.


Pre conditionsRedemption letter issued

Screen Layout

InputsThe contents of Bill Redemption data store are:

Voucher No. Unique Voucher NumberValue Date Effective Date[By default System Date but user can edit

it]Bill No.* From Bill Calendar[User will select form a view link]Contact Contact DescriptionGL Head GL Head Description



SL Head SL Head DescriptionFace Value* Value which will be returned at maturityDiscount Rate Rate of discount.Amount AmountParticulars* Details of Bill

Data StoreBill Redemption Data Store

The following inputs will be stored in Bill Redemption data store:- Nu Voucher Number- Value Date- Bill No.- Contact- GL Head- SL Head- Face Value- Discount Rate- Amount- Particulars

Post conditions Verification and approval of voucher generated from Bill Redemption

Flow of Events1. Redemption letter issued by RSEB is presented2. Nu voucher is created against this sale3. Normal verification and approval process is done against the voucher4. Following is an example of the accounting nature against a bill sale

Credit BOB Miscellaneous AcCredit BOB Miscellaneous Ac (for RICB)Credit BNB Miscellaneous AcDebit RMA Discount Bill Ac

Business LogicNA

Verification and Validation Bills redeemed has to be validated from Bill Sale Information and calendar for bill

number, Face value, Maturity date





3.1.2.5 Interest Accrued/Received From Bank

3.1.2.5.1 Interest Received From Bank DescriptionThis function manages the received of income from bank accounts


Pre conditionsNA

Screen Layout

InputsFollowing are the input in Interest Received From Bank is:

Voucher No Corresponding BK08 voucher noBank Account* Bank account against which interest is received[User

will select form a view Link]Value Date* Date on which interest was received[By default System

Date but user can edit it]Currency Code* Currency in which interest is received [User will select

form a view Link]FC Amount* Interest amount in foreign currencyHolding Rate Holding rate of the currency.Equivalent Nu. Amount* Interest amount in Nu Interest Rate Rate of interest.Debit A/C Debit Account Number[User will select from a view link]Credit A/C Credit Account Number[User will select from a view link]Particulars Particulars about this transaction.

Data StoreInterest Received Data Store

The following inputs will be stored in Interest Receive data store:- Voucher No.- Bank Account- Value Date- Currency Code



- FC Amount- Holding Rate- Equivalent Nu Amount- Interest Rate- Debit A/C- Credit A/C- Particulars

Post conditions Verification and approval of voucher generated from Interest Received

Flow of Events1. Information about interest is received thru bank statement/swift2. BK 08 Voucher will be generated based on the information given3. Normal verification and approval process is done against the

voucher4. Accounting Nature against this process will be as follows:

Debit Foreign Investment Ac/Current Account/Overnight AccountCredit Our Currency

Debit VOCCredit Interest on Foreign Investment Ac (70103)

Business LogicNA

Verification and ValidationNA



3.1.2.5.2 Investment Information

DescriptionThis function will store the detail about different foreign investments. This function is used as a driver interface and may be re-worked during RMM development.


Pre conditionsNA



Screen Layout

InputsFollowing are the input in Investment Information

Investment No.* Unique No. to identify the investmentInvestment Bank Bank in which the investment is made.Invested From Date* Investment Start DateDuration Duration of the investment in daysInvested To Date Investment To DateCurrency* Currency of Investment.Principle Amount* Amount to be received at endInterest Rate* Rate of interestInterest Days (per year) Days of year for interest calculation.Interest Amount * Interest amount to be received for the investment

period.Maturity Amount Amount receivable on maturityRemarks Remarks for the investmentRollback Date Date on which the investment is rolled back, if at all.Rollback Amount Amount receivable from the investment, if rolled back.

Data StoreInvestment Information Data Store

The following inputs will be stored in Investment Information data store:- Investment No.- Investment Bank- Invested From date- Duration- Invested To date- Principle Amount- Interest Rate- Interest Days (per year)- Interest Amount- Maturity Amount- Remarks- Rollback Date- Rollback Amount



Post conditionsNA

Flow of EventsNew Investment User will enter the details about investments Corresponding voucher was raised. Once the voucher is authorised, no further modification on this information should be

allowed. Re-Investment User will select the existing investment Mark as reinvested Reinvestment can not be done if the existing investment is not matured The period of reinvestment will be calculated from the existing investment period and

maturity date Existing investment will be marked as reinvested and a new investment record will be

createdRollback In case of rollback user will input the rollback date and the rollback value For a rollback investment interest receipt/accrual can not be done

Validation and VerificationNA



3.1.2.5.3 Interest Accrual

DescriptionThis function will create the accrual voucher at the end of year (any period) for the interest receivable from different investment/current account


Pre conditionsNA

Screen Layout



InputsFollowing are the Input in Interest Accrual:

Voucher No Unique Number Value Date Value date for interest accrualInvestment/Current Account Bank account against which interest is received[User

will select form a view link]Accrual FC Amount Accrual Amount CalculatedEquivalent Nu Amount Equivalent Nu amount for accrual amount.Debit A/c Debit GL HeadCredit A/c Credit GL HeadParticular Particular of transaction

Data StoreInterest Accrual Data Store

The following inputs will be stored in Interest Accrual data store:- Voucher No.- Value Date- Investment/Current Account- Accrual FC Amount- Equivalent Nu. Amount- Debit A/c- Credit A/c- Particulars

Post conditions Verification and approval of voucher generated from Interest Received



Flow of Events1. At the end of year (or any specified period) user will create the accruals for

interest receivable2. User will select a bank account and enter accrual date3. Based on the interest received during the year (for current account) or

investment period (for foreign investment), system will calculate the accrual amount4. General Ngultrum voucher will be created by the system5. Normal verification and approval process is done against the voucher6. Accounting Nature against this process will be as follows:

Debit Foreign Investment Ac/Current Account/Overnight AccountCredit Interest Accrued, Investment

7. The Vouchers both the post voucher and Reverse Voucher, should post unauthorised vouchers

Business Logic If Account is current account accrual amount will be calculated based on

the interest received during the year If Account is foreign investment, accrual amount will be calculated based

on the interest frequency, amount from the investment information


Analytical / Calculation For Current Account:Accrual Amount=(Total Interest received during the year/No of months) For Investment Account:Accrual Amount=(Total Interest Receivable/Interest Period in days)*(Accrual date-Investment Date)




3.1.3 Bank Reconciliation

In order to keep up to date track of all receipts and payments of funds as well as to monitor and reconcile the balance in the account, it is necessary to carry out reconciliation exercise daily, weekly or monthly as require by the users. In order to facilitate easy and immediate reconciliation of transactions between RMA and its correspondent banks and to prevent any reconciliation complications, every transaction has to be responded singly by RMA as well by its correspondent banks.

For ease of reconciliation, both the RMA and the banks shall always try to reflect the transaction individually and there should not be more than one entry from the RMA side corresponding to single entry from bank side and vice-versa.

The whole purpose of the exercise is to keep track of all the outstanding transactions i.e. not responded either by the banks or the RMA. Common steps for the Bank Reconciliation Process are:

Bank Statement EntryPrior to reconciliation process, it is necessary to input bank statement which is required to compare against the RMA ledgers.

Process: This process will carry out the following steps:

a. On receipt of bank statements from the correspondent banks, the concerned user shall verify the transactions listed therein and input the following information into the system, bank account wise on header/parent part of the form as below:

1. Reconciliation Record ID (System generated)2. Net balance of the bank statement account wise. 3. Specify DR or CR4. RMA Ledger balance (System generated)5. Account Number 6. Transaction/record date7. Bank Statement Date

b. The details of the bank statement shall be entered in the child/details part of the form as below: Debit amount Credit Amount Reconciliation reference number (Check No/Clearing Number/Advice No etc) Match Date (This date field will be null if not reconciled. Reconciled Date will be written

whenever reconciled by the system and therefore this field is not visible to user). Transaction date of each statement records.

c. Once the statement is entered into the system, a copy of bank statement as a proof sheet shall be printed.

d. User responsible for preparation shall verify it and sign on the “Prepared by:” column and forward to Verifying Officer along with the original bank statement received from bank.

Verify/Approve Bank Statement

Process: This process is required to verify and approve the Bank Statement entered into the system prior to beginning of conciliation process. The steps involved are as below:



a. Upon receipts of the proof sheet along with the original bank statement from the concerned user, the Approving/Verifying Officer shall input the unique bank statement reference number assigned by the system to the proof sheet.

b. Once the required record is searched and displayed on the screen, the Verifying/Approving Officer shall approve or reject depending on the correctness of the entry.

c. Following the approval of the proof sheet by singing on the “Approved/Verified by:” column, it is also necessary to complete online approval process.

d. The proof sheet and the necessary documents shall be properly signed and passed back to the user responsible to reconcile the accounts.

Automatic Reconciliation

Process: This process shall carry out the following steps:

a. Prior to reconciliation process all bank related transactions are accumulated into a separate working table during data entry phase.

b. Once the statement is key-in, the system shall perform following matching of the bank statement records with that of corresponding bank records being maintained in the RMA ledgers. Matching of amounts Matching of cheque/advice/ instruction numbers Debit verses credit matching

c. Any transactions, which do not agree to the above criteria, are left un-reconcile. The matching transactions are flagged as reconciled by recording the matching date and/or flagging both accounts date and the reconciliation records.

d. The unmatched transactions shall be displayed on screen and/or printed to printer to allow user verify again. Sometimes the matching is failed due to merging of more than one transactions into single transaction, mistakes in data entry and/ or inconsistency in assigning references in case of draft, charges and transfer etc.

e. User shall print both the lists (Annex I and Annex II) for not reconciled entries and make necessary correction.

f. Should there be any mistake due to data entry, or mistakes in bank statement such mistakes shall be first corrected on the paper lists and then updated accordingly in the respective tables using appropriate form/interface.

g. Once the corrections are made into the system, reconciliation process shall be re-run once again.

Manual Reconciliation

Process: Any records failing to reconcile automatically due to non-availability of one-to-one matching reference number, shall be matched manually as below:

a. User shall input bank statement entry date, bank account number and/or proof sheet reference number into the system. Accordingly, system shall search for the matching record (un-reconcile records) and display on manual reconciliation screen.

b. Using such screen user shall match the records manually on screen. However, user must be

extra careful and match only those records which system failed to match automatically due to non-availability of one one-to-one matching reference number.



c. Once the reconciliation process is completed it is ready to generate following reports: Daily Reconciliation Register Daily Reconciliation Statement Monthly Reconciliation Summary Annex – I (List of transaction not responded by the Bank) Annex – II (List of transaction not responded by the RMA)

3.1.3.1 Bank Reconciliation (Nu)

Bank Reconciliation process for Nu accounts are common for the Administrative Division and the Banking division. This process is already described in Administrative Accounting Module (AAM). Refer the following Use Case of AAM module

Bank Reconciliation (Section 3.1.2.3 of Document ICBS/AAM/STDSRS/SRS-AAM-003)

3.1.3.2 Bank Reconciliation (FC)

Description

This function will enable user to enter the bank statements for different bank accounts where foreign currency is involved and then reconcile the bank transactions. This function is similar to the Nu reconciliation process. Only difference is, here foreign currency is involved

Actors or participants

Banking division users

Screen LayoutBank Statement:



Bank Reconciliation:

Inputs

The following are inputs into the FC Bank Transaction when any bank transaction has been posted

Date* Date of the payment or receipt entry of General LedgerRef Date* A date of Cheque/Draft that identifies the date of bank

reconciliation.Foreign Currency Code* Foreign currency involved in this transactionReconciled [Y/N] if reconciled or not Bank Statement* Bank statement against which it has been reconciledReconciled Statement Reference to the reconciliation statementTransaction Mode* This attribute identifies the Bank Reference Type for which

this bank transaction is relevant.Bank Account* Bank Account which identifies the Bank Account No.Amount Dr* The amount that indicates the debit amount of the bank entry. Amount Cr* The amount which indicates the credit amount of the bank

entry

The following are inputs into the Bank Statement HeaderBank Account* Bank Account which identifies the Bank Account No.Statement Date Bank statement DateStatement Opening Balance Opening balance as recorded in the Bank StatementStatement Closing Balance Closing balance as recorded in the Bank Statement

Corresponding to the Bank Statement Header following are inputs into the Bank Statement Detail CAM – SRS Ver 1.3 of 139


Ref No The Cheque No/Draft No in the systemRef Date* A date of Cheque/Draft Transaction Mode This attribute identifies the Bank Reference Type for which

this bank transaction is relevant.Date* Transaction date in bank statementReconciled [Y/N] if reconciled or not Amount Dr* The amount that indicates the debit amount of the bank entry. Amount Cr* The amount which indicates the credit amount of the bank

entry Currency Code* Code for the foreign currency involvedNote An alphanumeric text description for this entry. Input to the Reconciliation statementReconciliation Date* The date on which the statement has been preparedReconciled Balance* Balance after reconciliation

Data StoreForeign Currency Transaction Data Store

The following inputs will be stored in Foreign Currency Transaction data store:- Date- Ref Date- Foreign Currency Code- Reconciled- Bank Statement- Reconciled Statement- Bank Account- Amount Dr- Amount Cr

The following inputs will be stored in Bank Statement Header data store- Bank Account- Statement Date- Statement Opening Balance- Statement Closing Balance

The following inputs will be stored in Bank Statement Detail data store- Ref No- Ref Date- Transaction Mode- Date- Reconciled- Amount Dr- Amount Cr- Currency Code- Note

The following inputs will be stored in Reconciliation statement data store- Reconciliation Date- Reconciled Balance



OutputPopulating FC Bank Statement Header, FC Bank Statement Detail, FC Updating Bank Entry

Flow of Events As described above (Section 3.1.3)

Business Logic The system will reconcile the transaction by matching the cheque number (DocID) of

Bank entries and transaction from Bank Statements. Additionally there can be option for matching the entries by cheque date, reference number and debit, credit amount

Transactions which are not reconciled by above process will be reconciled by the user from the user interface

When a Bank Entry is reconciled against a bank statement its reconciled flag will be true and the corresponding BankStatementID of Bank Statement will update BankStatementID field. Also the reconciled statement id will be updated by the corresponding reconciled statement id from the reconciled statement data store

Verification and Validation All Mandatory fields are marked by “*”.

Analytical / Calculation None

Application Error / MessagesValidation document mentioned at references (1.4)



3.1.4 Foreign Currency Revaluation

A Revaluation Reserve Account is being maintained which holds all gains arising from any change in valuation of the RMA’s assets or liabilities in, or denominated in, gold, foreign currencies or other units of account as a result of alterations in the value of the Ngultrum or of any exchange movements of such assets with respect to the Ngultrum. The gains or losses so arising shall remain in the Revaluation Reserve account and are not part of the profit and loss computation.

Foreign Currency Revaluation function shall conduct periodical revaluation of the RMA’s foreign assets/liabilities holding and update the central accounts accordingly.

3.1.4.1 Table of Conversion

DescriptionThis function prepares and approves the currency conversion table for each currency account (Our Currency) by calculating equivalent Nu amount from individual currency balance.


Pre conditions Revaluation Holding Rate has been prepared

Screen Layout



InputsThe following are the input into Prepare Table of Conversion is:

Voucher No Corresponding Voucher reference no.Revaluation From From DateRevaluation Date* The date on which revaluation is being doneValue Of Currency Currency ValueValue Difference

The following are the input into Prepare Table of Conversion details is:Currency Code Corresponding Voucher reference no.Currency Abbrev Abbreviation of currency Currency A/c The date on which revaluation is being doneFC Balance FC Balance i.e. Foreign Currency balanceHolding Rate Holding RateNu Equivalent Nu equivalent of currencyTotal Value Total Value

Data StorePrepare Table of Conversion

The following inputs will be stored in Prepare Table of Conversion data store:- Voucher No- Revaluation From- Revaluation Date- Value Of Currency- Value Difference- Voucher No

The following inputs will be stored in Prepare Table of Conversion detail data store- Currency Code- Currency Abbrev- Currency A/c- FC Balance- Holding Rate- Nu Equivalent- Total Value

OutputPopulation of Currency Conversion Data store

Flow of Events1. Input currency revaluation date. 2. Select all the currency accounts (Our Currencies)3. Calculate individual balances of these accounts currency wise.4. Calculate Ngultrum equivalent using respective holding rates. 5. Write the following information into conversion table:

Currency Code Account Code (from Currency Master) Individual balance of each currency (amount in currency) Holding rate for the currency Equivalent in Ngultrum (amount in Ngultrum)



6. Select Value of Our Currency from Central accounts and calculate individual balance of these accounts and also update in the “VOC” field of the conversion table as below: VOC Account Code Balance of VOC (Currency wise) Gain/loss of a particular currency (Difference)

7. Print Table of Conversion report, verify it and sign on “Prepared by:” column and forward the report to approving officer.

8. Based on the computer generated reference number printed on the report, the Approving Officer can search and display the same report on the screen.

9. Verify the report and sign on the “Approved by:” column and return the report to the user responsible to begin revaluation process.

10. Voucher Posting on Authorisation:If Value Difference amount>0 (Gain)

Detail Serial Number: 1Account: VOC AccountDebit Amount: Value Difference from conversion tableCredit Amount: 0Note: Gain on revaluation

Detail Serial Number: 2Account: Revaluation Reserve AccountDebit Amount: 0Credit Amount: Value Difference from conversion tableNote: Gain on revaluation

If Value Difference amount<0 (Loss)Detail Serial Number: 1Account: VOC AccountDebit Amount: 0Credit Amount: Value Difference from conversion tableNote: Loss on revaluation

Detail Serial Number: 2Account: Revaluation Reserve AccountDebit Amount: Value Difference from conversion tableCredit Amount: 0Note: Loss on revaluation

Business Logico Rates will be coming from FOREX rate data store






3.1.5 Issue Division Transactions

3.1.5.1 Currency Chest Transaction

3.1.5.1.1 Deposit

DescriptionThis function generates the Currency Chest Transaction voucher for currency deposit by banksThis process will actually create BK08 voucher with reference to the issue division’s transaction for deposit


Pre conditions Issue Division transaction prepared

Screen Short

InputVoucher No Voucher IdVoucher Date Date in which the voucher will generateValue date Effective DateChest Slip No Number for Chest SlipAmount Total AmountCurrency Code for Currency.[User will select form a List]Credit Bank A/c Name of The credited bank .[User will select form a List]Debit FCFC Debit A/c (FCFC)Particulars Particulars about this transaction

Data StoreCAM – SRS Ver 1.3 of 139


Currency Chest Transaction

The following inputs will be stored in Currency Chest Transaction data store:- Voucher No- Voucher Date- Value date- Chest Slip No- Amount- Currency- Credit Bank A/c- Debit FCFC- Particulars

Flow of Events1. The Banking Division decodes all the incoming chest slips from the Bank of Bhutan and

Bhutan National Bank and forwards them to the Issue Division for the necessary entries. 2. Based on the chest slip, Issue Division shall prepare the voucher denomination wise.3. Produce Currency Transfer Statement bank-wise showing the net deposits and submit to

the BD along with voucher.4. Upon receipt of the voucher by the BD from Issue Division, it is necessary to type

computer-generated voucher on the screen and have corresponding voucher prepared for BD based on the Issue voucher. However, user at BD shall input additional information required.

5. BD shall prepare voucher by crediting respective bank’s Current Account and debiting FCFC account.

6. Once verified and approved a copy of such voucher shall be sent to ID for updating accounts.

7. Follow normal procedures for verification and approval.

Business Logic On selection of Issue Division Voucher, System will show the required information to

prepare BK08 voucher There can be option for creating such voucher without selecting issue division voucher

(required until Currency Management and Operation module is developed)




3.1.5.1.2 Withdrawal

DescriptionThis function generates the Currency Chest Transaction voucher for currency withdrawal by banks. This process will actually create BK09 voucher with reference to the issue division transaction for withdrawal




Pre conditions Issue Division transaction prepared

Screen Layout

InputsVoucher No Voucher IdVoucher Date Date in which the voucher will generateValue date Effective DateChest Slip No Number for Chest SlipAmount Total AmountCurrency Code for Currency.[User will select form a List]Debit Bank A/c Name of The debited bank .[User will select form a List]Credit FCFC Credit A/c (FCFC)Particulars Particulars about this transaction

Data StoreWithdrawal Data store

The following inputs will be stored in Withdrawal Data Store:- Voucher No- Voucher Date- Value date- Chest Slip No- Amount- Currency- Debit Bank A/c- Credit FCFC- Particulars

Flow of Events1. The Banking Division decodes all the incoming chest slips from the Bank of

Bhutan and Bhutan National Bank and forwards them to the Issue Division for the necessary entries.



2. Based on the chest slip, Issue Division shall prepare the voucher denomination wise.

3. Produce Currency Transfer Statement bank-wise showing the net deposits and submit to the BD along with voucher.

4. Upon receipt of the voucher by the BD from Issue Division, it is necessary to type computer-generated voucher on the screen and have corresponding voucher prepared for BD based on the Issue voucher. However, user at BD shall input additional information required.

5. BD shall prepare voucher by debiting respective bank’s Current Account and crediting FCFC account.

6. Once verified and approved a copy of such voucher shall be sent to ID for updating accounts.


Business Logic On selection of Issue Division Voucher, System will show the required information to

prepare BK09 voucher There can be option for creating such voucher without selecting issue division voucher

(required until Currency Management and Operation module is developed)






3.1.6 Day End ProcessDay End Process is to control the day ending scenario. After the day is ‘ended’, that is locked, no more vouchers are to be posted from either AAM or CAM.

3.1.6.1 Day End Process

DescriptionThis function can be used to lock and unlock a day so that posting of vouchers from AAM and CAM may be controlled. In order to ‘end’ and lock a day, it is necessary that the user matches withy the physical balances and check all matched values.

PurposeThis function can be used to lock and unlock a day so that posting of vouchers from AAM and CAM may be controlled.

Screen Layout

InputsReceived from vault The amount that is received from vault for staff salary

cash a/cSalary Account Balances Matched

Whether Salary account balances are matched

Bullion & Cash Balances Matched

Whether Bullion and Cash balances are matched.

Bank Balances Matched Whether Bank Balances are matched

Data StoreDay End Data store

The following inputs will be stored in Withdrawal Data Store:- Process Date- Received from Vault



- Salary Account Balances Matched- Bullion & Cash Balances Matched- Bank Balances Matched

Flow of Events1. At Day Beginning, the amount received from the vault for the Staff Salary Cash

Account will be entered.2. At Day End, the Banking Division will match the individual system provided

balances and match them with the physical balances.3. Then they will Lock the day for no further vouchers.4. A day may be unlocked again to post further vouchers, if the need arises.

Business Logic The Day Cannot be ‘Locked’ if all the balances are marked as matched. The day may be unlocked at any time by authorized users.






3.1.7 Annual Closing of accounts

Annual Account closing is common for both Administrative Division and Banking Division.

The annual closing of accounts will be done in two phases - Provisional Account Closing Actual Account Closing

3.1.7.1 Provisional Account Closing

DescriptionThis process will not actually close the account but will calculate the provisional balance sheet, income & expenditure statement and other related financial statements; and will carry forward to the next financial. However, final financial statements will be completed upon external auditing process.

PurposeIn order to run the system in the new financial year without actually closing the accounts and posting the year ending journals, this process will calculate the provisional balance and carry forward to the new financial year

Screen Layout

InputsThe following are inputs into the GL Balance data store

Financial Year* Financial Year for which year ending is being doneMonth Code* Number specifying the month ex: 01 for January, 02 for

FebruaryGL Code/SL Code* GL account Code Closing Balance* Closing Balance for that month

Following are the inputs to financial year data storeFinancial Year* Financial Year for which year ending is being doneStart Month Code* Financial Year Start MonthEnd Month Code* Financial Year End MonthYear End Flag* Y/N whether year has been closed or not



Data storeGeneral Transaction, General FC transaction, GL Balance, Financial Year Data Store

Process Description: The process will have the following steps:1. Calculate the balances of Assets and Liabilities accounts and carried forward to new

financial year as probationary balances.

2. Unlike the existing system, the adjustment vouchers for June month can be entered into the system at anytime instead of accumulating into batches.

3. Update the probationary balances as and when adjustments vouchers are booked for the June.

4. Process all report required before closing of accounts5. The system should generate a provisional report

Post conditionsPreparing various financial report

Special requirements Security

Only authorize user who will be given rights to access this function will be able to do the year ending process

Business rules Calculate the provisional profit and loss amount from income and

expenditure transactions Add the amount to the closing balance of Profit and Loss account for

the year ending month Make the balance 0 for income and expense heads for the year

ending month Create a new financial year and update the current financial year as

closed Update the closing balance for Asset and liabilities for the year ending

month




3.1.7.2 Final Account Closing

DescriptionThis process will pass a year ending journal

PurposeTo close a financial year



Pre Conditions All the adjustment entries has been passed All the provision vouchers has been passed Auditors has finalised and board has approved the financial statements

Screen Layout

InputsThe following are inputs into the GL Balance data store Financial Year* Financial Year for which year ending is being doneGL Code* GL account Code Closing Balance* Closing Balance for that financial yearCurrency Currency of closing balance

Data storeGeneral Transaction, GL Balance, Financial Year Data Store

OutputPopulating GL Balance

Post conditionsNA

ProcessFinal adjustment vouchers are entered into the system, and the accounts for the current financial year are closed.

Special requirements Security

o Only authorize user who will be given rights to access this function will be able to do the year ending process

Business ruleso Create a journal voucher by reversing the income /expenses transaction

(if Debit then credit and vice versa) and posting the balance amount (Total Income- Total Expenses) to the Profit & Loss account



o Update the Balance of all asset and liabilities for the year ending and accordingly update the balances up to the current month

o Make the balance 0 for income and expense heads for the year ending month




3.1.7.3 Year End Voucher for AAM

This functionality will maintain the normal Ngultrum vouchers maintained by Administrative Division, with a difference that they can change the Voucher Date (which is by default display field). The process and business logic is same as with the general transaction of AAM module. Refer the following Use Cases of AAM module

General Transaction (Section 3.1.2.2.1 of Document ICBS/AAM/STDSRS/SRS-AAM-003)

3.1.7.4 Year End Nu. Voucher for CAM

This functionality will maintain the normal Ngultrum vouchers maintained by Banking Division, with a difference that they can change the Voucher Date (which is by default display field). The process and business logic is same as with the general transaction of CAM module. Refer the following Use Cases of CAM module

General Transaction (Section 3.1.2.2.1 of Document ICBS/CAM/STDSRS/SRS-CAM-003)



3.1.7.5 Year End FC Voucher for CAM

This functionality will maintain the normal Foreign Currency vouchers maintained by Banking Division, with a difference that they can change the Voucher Date (which is by default display field). The process and business logic is same as with the general transaction of CAM module. Refer the following Use Cases of CAM module

General Foreign Currency Voucher (Section 3.1.2.3.1 of Document ICBS/CAM/STDSRS/SRS-CAM-003)



3.1.8 Reports 3.1.8.1 Cash Book

DescriptionThis process is to generate the Cash Book

PurposeThe purpose of this report is to the check and verifies the listing of transaction for a day or period

Input Parameters From Date To Date GL Code (Must be Cash Related)

Data ElementsThis report will contain the following data elements.Elements DescriptionAccount No Account Code from Transaction DetailAccount Name Account Head from Chart of Account for the Account CodeVoucher Number Voucher Number Value Date Date of the line transactionParticulars Line details for the transactionDebit Amount Amount debited on the GL/SL headCredit Amount Amount credited on the GL/SL headBalance Cash Balance

At the end of the day the Accounts department can print the Cash Book and tally with the physical cash balances.

Report Layout

Royal Monetary Authority of BhutanCash Book

For the period of 01/04/2006 – 02/04/2006Account No.: 1201001Account Head: Cash in Hand

Value Date Voucher No. Particulars Amount Debit Amount Credit BalanceOpening Balance

15000.00 DR

01/04/2006 AAM\PV\0607\1 Pay to J D Enterprise

5000.00 10000.00 DR

02/04/2006 AAM\RV\0607\2 Received from Digital Shangrila as an Earnest Money Deposit

25000.00 35000.00 DR



3.1.8.2 Bank Book

DescriptionThis process is to generate the Bank Book

PurposeThe purpose of this report is to the check and verifies the listing of transaction for a day or period

Input Parameters From Date To Date GL Code (Must be Bank Related)

Data ElementsThis report will contain the following data elements.Elements DescriptionAccount No Account Code from Transaction DetailAccount Name Account Head from Chart of Account for the Account CodeVoucher Number Voucher Number Value Date Date of the line transactionParticulars Line details for the transactionDebit Amount Amount debited on the GL/SL headCredit Amount Amount credited on the GL/SL headBalance Bank Balance

At the end of the day the Accounts department can print the Bank Book and tally with the physical bank statements.

Report Layout

Royal Monetary Authority of BhutanBank Book

For the period of 01/04/2006 – 02/04/2006Account No.: 1201001Account Head: BNB Current A/c

Value Date Voucher No. Particulars Amount Debit Amount Credit BalanceOpening Balance

15000.00 DR

01/04/2006 AAM\PV\0607\1 Pay to J D Enterprise

5000.00 10000.00 DR

02/04/2006 AAM\RV\0607\2 Received from Digital Shangrila as an Earnest Money Deposit

25000.00 35000.00 DR

3.1.8.3 Journal Register

DescriptionThis process is to generate daily journal



Purpose

The purpose of this view/print journal transaction

Input ParametersDate

Data ElementsThis report will contain the following data elements.Elements DescriptionVoucher Number Running serial number of the journal voucherVoucher Date Current of the voucherVoucher Narration User given voucher narration of voucherGL code General ledger code of each transactionGL Head General Ledger Head of each transactionParticulars Earning/Deduction Heads against each GL CodeDebit Amount Transaction amount in debit sideCredit Amount Transaction amount in credit sidePrepared by Name of the user who prepared/run the process

Report LayoutRoyal Monetary Authority of Bhutan

Daily Journal for the 11/05/2006

Voucher No.

Value Date

GL Code GL Head Particulars Amount Debit

Amount Credit

CAM/1 11/05/2006

4701001 Salaries – Regular Staff

Basic Pay 40000.00 0.00

CAM/2 11/05/2006

4701002 Salaries – Wage Worker

Basic 25000.00 0.00

CAM/3 11/05/2006

4702001 Cash Handling Allowance

Cash Handling Allowances

1000.00 0.00

CAM/4 11/05/2006

4704002 Provident & Pension Fund

Employer’s PF Contribution

10000.00 0.00

CAM/5 11/05/2006

1202001 Administrative Expense Current Account

Total GPF 0.00 20000.00

CAM/6 11/05/2006


Total GIS 0.00 4000.00

CAM/7 11/05/2006


Total Vehicle Loan Recovery

0.00 10000.00

CAM/8 11/05/2006

1302004 Salary Advance Salary Advance Recovery

0.00 20000.00

CAM/9 11/05/2006

1302009 Housing Loan House Loan Recovery

0.00 22000.00

CAM/10 11/05/2006

2309006 Salary Deposit Account

Net Salary Credited the month

0.00 24000.00

CAM/11 11/05/2006

1202002 Foreign Exchange Current Account

Net Salary debited the month

24000.00 0.00

Total 100000.00 100000.00



3.1.8.4 Currency-wise Journal Register

DescriptionThis process is to generate Currency wise daily journal

Purpose

The purpose of this view/print Currency wise journal transaction




Daily Journal for the 11/05/2006Currency: 01, USD

Voucher No.

Value Date


Amount Credit

CAM/1 11/05/2006


Basic Pay 40000.00 0.00

CAM/2 11/05/2006


Basic 25000.00 0.00

CAM/3 11/05/2006



1000.00 0.00

CAM/4 11/05/2006



10000.00 0.00

CAM/5 11/05/2006


Total GPF 0.00 20000.00

CAM/6 11/05/2006


Total GIS 0.00 4000.00

CAM/7 11/05/2006



0.00 10000.00

CAM/8 11/05/2006


0.00 20000.00

CAM/9 11/05/2006


0.00 22000.00

CAM/10 11/05/2006



0.00 24000.00

CAM/11 11/05/200 1202002 Foreign Net Salary debited 24000.00 0.00



6 Exchange Current Account

the month

Total 100000.00 100000.00

3.1.8.5 Certificate of Cash Balance

DescriptionThis process is to generate the certificate of Cash balance

PurposeThe purpose of this report is to the see the certificate of cash balance for a day or period

Input Parameters From Date To Date

Data ElementsThis report will contain the following data elements.Elements DescriptionDenomination DenominationQuantity No. of PiecesValue Denomination * Quantity

Report Layout

Royal Monetary Authority of BhutanCertificate of Cash Balance

Denomination Pieces Value10 5 Nu. 50.0050 10 Nu. 500.00

100 20 Nu. 2000.00

3.1.8.6 General Ledger

DescriptionThis process is to generate the General Ledger

PurposeThe purpose of this report is to the see the GL head wise transactions for a day or period

Input Parameters From Date To Date GL Head

Data ElementsThis report will contain the following data elements.Elements DescriptionValue Date Date of the line transaction



Voucher Number Voucher Number Cheque/Draft No. Cheque or Draft NumberParticulars Line details for the transactionDebit Amount Amount debited on the GL headCredit Amount Amount credited on the GL headBalance balance of the account after transaction

Report Layout

Royal Monetary Authority of BhutanGeneral Ledger

For the period of 01/04/2006 – 02/04/2006

GL Code : 1201001GL Head: BOB FOREX Current A/c

Value Date Voucher No. Cheque/Draft No.

Particulars Debit Credit Balance

Opening 1000.00 Dr01/04/2006 CAM\CV\0607\1 Receipt

materials from J D Enterprise

2000.00 3000.00 Dr

02/04/2006 CAM\GV\0607\2 Account Adjustment

3500.00 500.00 Cr

Closing 500.00 Cr

3.1.8.7 Currency-wise General Ledger

DescriptionThis process is to generate the Currency wise General Ledger

PurposeThe purpose of this report is to the see the Currency wise GL head wise transactions for a day or period

Input Parameters From Date To Date GL Head

Data ElementsThis report will contain the following data elements.Elements DescriptionValue Date Date of the line transactionVoucher Number Voucher Number Cheque/Draft No. Cheque or Draft NumberParticulars Line details for the transactionDebit Amount Amount debited on the GL headCredit Amount Amount credited on the GL headBalance balance of the account after transaction

Report Layout



Royal Monetary Authority of BhutanGeneral Ledger

For the period of 01/04/2006 – 02/04/2006Currency : 01, USD

GL Code : 1201001GL Head: Cash in Hand USD

Value Date Voucher No. Cheque/Draft No.

Particulars Debit Credit Balance

Opening 1000.00 Dr01/04/2006 CAM\CV\0607\1 Receipt

materials from J D Enterprise

2000.00 3000.00 Dr

02/04/2006 CAM\GV\0607\2 Account Adjustment

3500.00 500.00 Cr

Closing 500.00 Cr

3.1.8.8 Sub-Ledger

DescriptionThis process is to generate the Sub Ledger Report

PurposeThe purpose of this report is to the see the SL head wise transaction details under a particular GL Head for a day or period

Input Parameters From Date To Date GL Head SL Head

Data ElementsThis report will contain the following data elements.Elements DescriptionValue Date Date of the line transactionVoucher Number Voucher Number Particulars Line details for the transactionDebit Amount Amount debited on the SL headCredit Amount Amount credited on the SL headBalance balance of the account after transaction

Report Layout

Royal Monetary Authority of BhutanSub Ledger

For the period of 01/04/2006 – 02/04/2006GL Code and Description: 2308002, Sundry Creditor

Party Code & Name: JD001, J D Enterprise



Value Date Voucher No. Particulars Debit Credit BalanceOpening 1000.00 Dr

01/04/2006 CAM\CV\0607\1 Receipt materials from J D Enterprise

2000.00 1000.00 Cr

02/04/2006 CAM\PV\0607\2 Account Adjustment

2000.00 1000.00 Dr

Closing 1000.00 Cr

3.1.8.9 Trial Balance

Description This process is to generate the Trial Balance.

PurposeThe purpose of this report is to the see the Trial Balance for the specified period.

Input Parameters Financial Year From Date To Date

Data ElementsThis report will contain the following data elements.Elements DescriptionAccount Name Account Head from Chart of Account for the Account

CodeOpening Balance Debit Amount Amount debited on the GL headOpening Balance Credit Amount

Amount credited on the GL head

Current Debit Amount Amount debited on the GL head for current monthCurrent Credit Amount Amount credited on the GL head for currentClosing Balance Debit Amount Amount debited on the GL headClosing Balance Credit Amount Amount credited on the GL headTotal Total of debit amount and credit amount

Report Layout

Royal Monetary Authority of BhutanTrial Balance

of the financial year 2005-2006For the Period of 01/04/2006 – 30/04/2006

GL Code GL Head Opening Current ClosingDebit Credit Debit Credit Debit Credit

1202002 ADMINISTRATIVE EXPENSE ACCOUNT

15000.00 0.00 0.00 12000.00 3000.00 0.00

4101001 Printing & Stationeries

0.00 0.00 12000.00 0.00 12000.00 0.00

Total 15000.00 0.00 12000.00 12000.00 15000.00 0.00



3.1.8.10 Currency-wise Trial Balance

Description This process is to generate the Currency wise Trial Balance.

PurposeThe purpose of this report is to the see the Currency wise Trial Balance for the specified

period.






Report Layout

Royal Monetary Authority of BhutanTrial Balance

of the financial year 2005-2006For the Period of 01/04/2006 – 30/04/2006

Currency: 01, USD



15000.00 0.00 0.00 12000.00 3000.00 0.00


0.00 0.00 12000.00 0.00 12000.00 0.00

Total 15000.00 0.00 12000.00 12000.00 15000.00 0.00

3.1.8.11 Income and Expenditure Statement

DescriptionThis process is to generate Income and Expenditure Statement



PurposeThe purpose of this report is to the see the Income and Expenditure Statement for a financial year

Input Parameters Financial Year

Data ElementsThis report will contain the following data elements.Elements DescriptionGL Group Head General Ledger Group HeadGL Sub Group Head General Ledger Sub Group HeadSchedule No. Schedule NumberCurrent Fin Year Amount Summation of Current Fin Year against the GL Sub GroupPrevious Fin Year Amount Summation of Previous Fin Year against the GL Sub GroupReport Layout

Royal Monetary Authority of BhutanIncome & Expenditure Statement

Financial Year: 2005-2006(Amount in Nu.)

Particulars Schedule June 30, 2006 June 30, 2005Income

Interest Income 01 5000.00 4000.00Interest Expenses 02 6000.00 5000.00

Net Interest Income 11000.00 9000.00Total Operating Income

11000.00 9000.00

ExpensesPrinting & Publication 04 3000.00 2500.00

Power & Water 05 3500.00 3000.00Total Operating Expenses

6500.00 5500.00

Net Income 4500.00 3500.00Prior Period Adjustment

500.00 400.00

Surplus Payable to Government

4000.00 3100.00

3.1.8.12 Schedules of Income and Expenditure Statement

DescriptionThis process is to generate Schedule to the Income and Expenditure Account

PurposeThe purpose of this report is to the see the schedule to the Income and Expenditure Account for a financial year




Data ElementsThis report will contain the following data elements.Elements DescriptionSchedule No. Schedule NumberGL Sub Group Head General Ledger Sub Group HeadGL Head General Ledger HeadCurrent Fin Year Amount Summation of Current Fin Year against the GL Sub GroupPrevious Fin Year Amount Summation of Previous Fin Year against the GL Sub Group

Report Layout

Royal Monetary Authority of BhutanSchedule to the Income & Expenditure Account


Schedule No. Particulars June 2006 June 200501 Interest Income 5000.00 4000.00

Interest on Foreign Investment

2000.00 1500.00

Interest on Staff Loans 3000.00 2500.00

02 Interest Expenses 6000.00 5000.00RMA Bills 3500.00 3000.00

Other Deposits 2500.00 2000.00

3.1.8.13 Balance Sheet

DescriptionThis process is to generate Balance Sheet



Data ElementsThis report will contain the following data elements.Elements DescriptionGL Group Head General Ledger Group HeadGL Sub Group Head General Ledger Sub Group HeadSchedule No. Schedule NumberCurrent Fin Year Amount Summation of Current Fin Year against the GL Sub GroupPrevious Fin Year Amount Summation of Previous Fin Year against the GL Sub Group

Report Layout



Royal Monetary Authority of BhutanBalance Sheet


Particulars Schedule June 30, 2006 June 30, 2005Asset


Total Asset 11000.00 9000.00LiabilityPrinting & Publication 04 3000.00 2500.00

Power & Water 05 3500.00 3000.00Total Liability 6500.00 5500.00

3.1.8.14 Schedules of Balance Sheet

DescriptionThis process is to generate Schedule to the Income and Expenditure Account

PurposeThe purpose of this report is to the see the schedule to the Income and Expenditure Account for a financial year


Data ElementsThis report will contain the following data elements.Elements DescriptionSchedule No. Schedule NumberGL Sub Group Head General Ledger Sub Group HeadGL Head General Ledger HeadCurrent Fin Year Amount Summation of Current Fin Year against the GL Sub GroupPrevious Fin Year Amount Summation of Previous Fin Year against the GL Sub Group

Report Layout

Royal Monetary Authority of BhutanSchedule of Balance Sheet


Schedule No. Particulars June 2006 June 200501 Aseet 5000.00 4000.00

Interest on Foreign Investment

2000.00 1500.00

Interest on Staff Loans 3000.00 2500.00

02 Liability 6000.00 5000.00RMA Bills 3500.00 3000.00

Other Deposits 2500.00 2000.00



3.1.8.15 Monthly Statement: Domestic Commercial Banks

DescriptionThis process is to generate monthly statement for domestic commercial banks.

Purpose

The purpose of this view/print monthly statement for domestic commercial banks.

Input ParametersGL HeadMonthYear

Report LayoutRoyal Monetary Authority

Banking DivisionMONTHLY STATEMENT OF DOMESTIC COMMERCIAL BANK

FROM TO Royal Monetary Authority The Managing Director Post Box No.:154 BOB Thimphu Thimphu Bhutan Thimphu, Tel No. :22540, 23111,23112 Telex No.:206 RMATPU BT Fax No.:22847

Statement from 01/01/2007 to 31/01/2007A/C No : 1202009A/C Name : BOB FOREX CURRENT ACCOUNT

Date Particulars Reference Transaction Balance Debit Credit Opening Balance 0.00 DR 01/01/2007 usd rel for ida loan #

3310 1,912,291.00 0.00 1,912,291.00 DR

01/01/2007 Remitted for adb loan # 3915 dated dec.4,2006

488,897.24 0.00 2,401,188.24 DR

01/01/2007 Remitted for adb loan #@ 3911

4,913,797.63 0.00 7,314,985.87 DR

01/01/2007 Remitted for ida loan # 3309

2,058,216.00 0.00 9,373,201.87 DR

01/01/2007 Remitted for Noredea 368,889.74 0.00 9,742,091.61 DR Total 9,742,091.61 0.00

3.1.8.16 Monthly Statement: Government Agencies

DescriptionThis process is to generate monthly statement for government agencies.

Purpose

The purpose of this view/print monthly statement for government agencies.

Input Parameters



GL HeadMonthYear

Report LayoutRoyal Monetary Authority

Banking DivisionMONTHLY STATEMENT OF GOVERNMENT AGENCIES

Statement from 01/01/2007 to 31/01/2007A/C No : 1202009A/C Name : BOB FOREX CURRENT ACCOUNT

Date Particulars Reference Transaction Balance Debit Credit Opening Balance 0.00 DR 01/01/2007 usd rel for ida loan #

3310 1,912,291.00 0.00 1,912,291.00 DR

01/01/2007 remitted for adb loan # 3915 dated dec.4,2006

488,897.24 0.00 2,401,188.24 DR

01/01/2007 remitted for adb loan #@ 3911

4,913,797.63 0.00 7,314,985.87 DR

01/01/2007 remitted for ida loan # 3309

2,058,216.00 0.00 9,373,201.87 DR

01/01/2007 remitted for Noredea 368,889.74 0.00 9,742,091.61 DR Total 9,742,091.61 0.00

3.1.8.17 Salary Journal Register

DescriptionThis process is to generate monthly salary journal against calculated payroll.

Purpose

The purpose of this view/print salary journal transaction


Data ElementsThis report will contain the following data elements.Elements DescriptionYear & Month Processing Year and MonthVoucher Number Running serial number of the journal voucherVoucher Date Current of the voucherVoucher Narration User given voucher narration of voucherGL code General ledger code of each transactionGL Head General Ledger Head of each transactionParticulars Earning/Deduction Heads against each GL CodeDebit Amount Transaction amount in debit sideCredit Amount Transaction amount in credit sidePrepared by Name of the user who prepared/run the process




Salary Journal for the month of May’2006-05-23


Amount Credit


Basic Pay 40000.00 0.00


Basic 25000.00 0.00


Cash Handling Allowances 1000.00 0.00


Employer’s PF Contribution 10000.00 0.00


Total GPF 0.00 20000.00


Total GIS 0.00 4000.00



0.00 10000.00

1302004 Salary Advance Salary Advance Recovery 0.00 20000.001302009 Housing Loan House Loan Recovery 0.00 22000.002309006 Salary Deposit

AccountNet Salary Credited the month

0.00 24000.00



24000.00 0.00

Total 100000.00 100000.00

3.1.8.18 Salary Account Balance Statement

DescriptionThis process is to generate monthly salary journal against calculated payroll.

Purpose

The purpose of this view/print salary journal transaction


Data ElementsThis report will contain the following data elements.Elements DescriptionYear & Month Processing Year and MonthVoucher Number Running serial number of the journal voucherVoucher Date Current of the voucherVoucher Narration User given voucher narration of voucherGL code General ledger code of each transactionGL Head General Ledger Head of each transactionParticulars Earning/Deduction Heads against each GL CodeDebit Amount Transaction amount in debit sideCredit Amount Transaction amount in credit sidePrepared by Name of the user who prepared/run the process




Salary Journal for the month of May’2006-05-23


Amount Credit


Deposited 40000.00 0.00


Deposited 25000.00 0.00

Total 100000.00 100000.00

3.1.8.19 Voucher Printing

DescriptionThis process is also to generate the one or multiple Voucher(s) against the selection criteria

PurposeThe purpose of this report is to View and Print the vouchers depending on the selection criteria

Input Parameters From Date To Date Voucher Type Document Type

Data ElementsThis report will contain the following data elements.

Elements DescriptionVoucher Type Type of the Voucher Voucher Number Voucher NumberVoucher Date Transaction DateValue Date Voucher Preparation DateDocument Type Type of the DocumentDocument No Document NumberAmount Amount of the VoucherExternal Reference No.Division Name of the DivisionReason for Rejection Any Reasons for RejectionParticulars Narration of the vouchersTransaction Mode Mode of the TransactionGL Code General Ledger CodeGL Name General Ledger NameBank Account No.SL Type Sub Ledger TypeSL Code Sub Ledger CodeSL Name Sub Ledger NameDebit Amount Debited



Credit Amount CreditedReference No.Note Remarks of the each transaction rowPrepared by Name of the person who will prepare the voucherVerified by Name of the person who will verify the voucherRejected by Name of the person who will reject the voucherApproved by Name of the person who will authorise the voucher

Report Layout

Royal Monetary Authority of BhutanVoucher Detail Report

For the period of 01/04/2006 – 02/04/2006

Voucher Type : Credit Voucher Amount : 5000.00Voucher Number: AAM\CV\0607\1 External Reference: Voucher Date : 01/07/2006 Division : ITDValue Date : 01/07/2006

Document Type : Purchase Order

Document No. : RMA\PO\0506\59

Reason for Rejection

Particulars: Received Materials from J D Enterprise against the PO No.: RMA\PO\0506\59 dated 10/06/2006 Transaction

ModeGL Code

&G L Name

Bank A/c No.&

SL Type

SL Code&

SL Name

Debit Credit ReferenceNo

Note

Other 1101010Printing &

Stationeries

5000.00

Other 2010203Sundry

CreditorsParty

J001J D

Enterprise

5000.00

Prepared By Verified By Rejected By Authorised By

3.1.8.20 List of Vouchers

DescriptionThis process is to generate List of Vouchers

PurposeThe purpose of this report is to the check and verifies the listing of transaction for a day or period on voucher type

Input Parameters From Date To Date Voucher Type



Data ElementsThis report will contain the following data elements.Elements DescriptionVoucher Number Voucher Number of the selected criteriaValue Date Date of the line transaction against the voucherGL Code General Ledger Code of the voucherGL Head General Ledger Head against the GL CodeBank A/c No. Bank Account Number (if any) of the voucherReference No. Cheque Number (Applicable for Bank Payment)Amount Debit Amount debited on the GL/SL headAmount Credit Amount credited on the GL/SL headParticulars Narration of the TransactionStatus Status of the Voucher (It may be prepared, verified,

approved etc.)Total No. of Voucher Total number of vouchersPrepared by Name of the person who prepared the vouchersChecked by Name of the person who checked the vouchersCertified by Name of the person who certified the voucher

At the end of the day, Accounts section can print the same for rechecking the transactions for that day. The process for List of Vouchers printing and checking will be as follows:

i) The user who has the rights for the same will print the reportii) Once the report is printed, for the individual transactions appearing in that report the

“Prepared By” will be recorded as the user id of the user who is printingiii) Next time when any authorized user see the report it will show the status as

“Prepared and pending for Checking” iv) At this stage authorized users can check the report for correctness and mark it as

“Checked”. The Id of the user will be recorded as “Checked By”v) The status of the report at this stage will be “Checked and Pending for Certification”vi) The Certifying authority will further check the report and mark it as “Certified”. The

user id of the certifying authority will be recorded as “Certified By”

Report Layout

Royal Monetary Authority of BhutanFor the period of 01/04/2006 – 02/04/2006

List of VouchersRun Date: 02/04/2006

Voucher No. Value Date

GL Code

GL Head Bank Accoun

t

Reference No.

AmountDebit

AmountCredit

Particulars Status

AAM\PV\0506\1 01/04/2006

1010101

Cash in Hand

5000.00 Pay to J D Enterprise

Authorized

4010101

Printing & Stationeries

5000.00

AAM\PV\0506\2 02/04/2006

1010102

Bhutan National Bank

256741 700156 15000.00

Pay to Digital Shangrila for supplying the Database

Prepared



Server1020210

Computer & Accessories

15000.00

Total Vouchers: 2

Prepared By Checked By Certified By

3.1.8.21 Denomination Summary

DescriptionThis process is to generate Denomination Summary

PurposeThe purpose of this report is to see the denomination wise cash transaction for a day only

Input Parameters Date GL Code (Must be Cash Related)

Data ElementsThis report will contain the following data elements.Elements DescriptionValue Date Date of the line transaction against the voucherParticulars Narration of the TransactionDenomination – Nu. 1 No. of pieces on Nu. 1 for each transactionDenomination – Nu. 2 No. of pieces on Nu. 2 for each transactionDenomination – Nu. 5 No. of pieces on Nu. 5 for each transactionDenomination – Nu. 10 No. of pieces on Nu. 10 for each transactionDenomination – Nu. 20 No. of pieces on Nu. 20 for each transactionDenomination – Nu. 50 No. of pieces on Nu. 50 for each transactionDenomination – Nu. 100 No. of pieces on Nu. 100 for each transactionDenomination – Nu. 500 No. of pieces on Nu. 500 for each transactionDenomination – Nu. 1000 No. of pieces on Nu. 1000 for each transactionValue Total Value of Each TransactionBalance Balance (on Value) after each transaction

Report Layout

Royal Monetary Authority of BhutanDenomination Summary

As of: 01/04/2006

Value Date

Particulars Denomination Value Balance

1 2 5 10 20 50 100 500 1000

01/04/2006 Tour Advance – Roshan Sharma

-3 -3 3150 3150 CR



01/04/2006 Receipt from Tender Sale Document

100 100 10 10 21000 17850 DR

Total 100 97 10 7

3.1.8.22 Denomination Details

DescriptionThis process is to generate Denomination Details

PurposeThe purpose of this report is to see the denomination wise cash transaction for a day or period

Input Parameters From Date To Date GL Code (Must be Cash Related)

Data ElementsThis report will contain the following data elements.Elements DescriptionValue Date Date of the line transaction against the voucherParticulars Narration of the TransactionDenomination – Nu. 1 No. of pieces on Nu. 1 for each transactionDenomination – Nu. 2 No. of pieces on Nu. 2 for each transactionDenomination – Nu. 5 No. of pieces on Nu. 5 for each transactionDenomination – Nu. 10 No. of pieces on Nu. 10 for each transactionDenomination – Nu. 20 No. of pieces on Nu. 20 for each transactionDenomination – Nu. 50 No. of pieces on Nu. 50 for each transactionDenomination – Nu. 100 No. of pieces on Nu. 100 for each transactionDenomination – Nu. 500 No. of pieces on Nu. 500 for each transactionDenomination – Nu. 1000 No. of pieces on Nu. 1000 for each transactionValue Total Value of Each TransactionBalance Balance (on Value) after each transaction

Report Layout

Royal Monetary Authority of BhutanDenomination Details

For the period of: 01/04/2006 – 02/04/2006

Value Date

Particulars Denomination Value Balance

1 2 5 10 20 50 100 500 1000

01/04/2006 Tour Advance – Roshan Sharma

-3 -3 3150 3150 CR



02/04/2006 Receipt from Tender Sale Document

100 100 10 10 21000 17850 DR

Total 100 97 10 7

3.1.8.23 Bill Calendar

DescriptionThis process is to generate report of Bill Calendar.

PurposeThe purpose of this report is to view and print the Bill Calendar.

Input ParametersYear

Data ElementsThis report will contain the following data elements

Elements DescriptionBill No.Auction DateSettlement DateMaturity DateTotal Amount

3.1.8.24 Details of Sale

DescriptionThis process is to generate report of Details on the sale of RMA Bills.

PurposeThe purpose of this report is to view and print the Details on the sale of RMA Bills.

Input ParametersFrom Date, To Date


Elements DescriptionBill No.No. of Days Number of DaysAmount of Bills soldDetails on sale of BillsBNB BidBNB SoldBOB Bid



BNB SoldOthers BidOthers SoldRate of discount

3.1.8.25 Details of Outstanding Amounts

DescriptionThis process is to generate report of Details on outstanding amount of RMA Bills.

PurposeThe purpose of this report is to view and print the Details on outstanding amount of RMA Bills.

Input ParametersFrom Date, To Date


Elements DescriptionBill No.No. of Days Number of DaysAmount of Bills Rate of InterestDetails amount of Bills outstandingTotalBOBBNBOthers

3.1.8.26 Prepaid Interest Expenses

DescriptionThis process is to generate report of Prepaid Interest Expenses on RMA Discount Bills.

PurposeThe purpose of this report is to view and print the Prepaid Interest Expenses on RMA Discount Bills.



Elements DescriptionSl. No. Serial NumberBill No. Bill NumberCAM – SRS Ver 1.3 of 139


Terms Period of BillTotal Discount Paid Total discount for the periodDays Days from issued date/total daysDiscount Expenses Discount amount for daysPrepaid Discount Remaining discountTotal

3.1.8.27 Nu Bank Statement

DescriptionThis process is to generate the reports for Bank Statement

PurposeThe purpose of this report is to see the entered bank statement against a particular Bank

Input Parameters Bank Statement Date Bank Account Number

Data ElementsThis report will contain the following data elements.Elements DescriptionOpening Balance Opening Balance of the Statement DateDate Bank Statement DateParticularsReference Cheque/Draft/Pay Order NumberAmount Dr Amount DebitAmount Cr Amount CreditClosing Balance Closing Balance of the bank statement Date

Report Layout

Bank of BhutanBank Statement

Bank Account No.:- 24513For 07/06/2006

Opening Balance: 0.00Date Particulars Reference No. Amount

Debit Credit07/06/2006 ABCD BOB11 10000.0007/06/2006 XYZ 1234 20000.00

Closing Balance 30000.00

3.1.8.28 Nu Bank Reconciliation

DescriptionThis process is to generate reports for Reconciliation Register

PurposeThe purpose of this report is to see the matching/mismatching Record listing for RMA against a particular Bank



Input Parameters Enter the Reconciliation Date Bank Account Number

Data ElementsThis report will contain the following data elements.Elements DescriptionRMA – Date Date of transaction – LedgerRMA - Debit Amount Amount debit - LedgerRMA - Credit Amount Amount Credited – LedgerRMA - Reference Cheque / Draft No. – LedgerRMA - Recon Date Reconciliation DateBank – Date Statement Date - Bank StatementBank – Debit Amount Amount Debit – Bank StatementBank – Credit Amount Amount Credit – Bank StatementBank - Reference Cheque / Draft No. – Bank StatementBank - Recon Date Reconciliation Date

Report Layout

Royal Monetary Authority of BhutanReconciliation Register

Bank A/c No.:24153As on 30/04/2006

RMA BankDate Debit Credit Reference Recon.

DateDate Debit Credit Reference Recon.

Date07/06/2006

30000 BOB11 12/06/2006

07/06/2006

300000 BOB11 12/06/2006

07/06/2006

20000 12345 12/06/2006

07/06/2006

20000 12345 12/06/2006

3.1.8.29 Nu Daily Reconciliation Statement

DescriptionThis process is to generate reports for Daily Reconciliation Statements

PurposeThe purpose of this report is to see the daily ledger entries which are not responded by RMA vis-à-vis which are not responded by a particular bank

Input Parameters Enter Reconciliation Date Bank Account

Data ElementsThis report will contain the following data elements.Elements DescriptionDate Date of transactionLedger Balance Balance as per RMA’s LedgerDebit Amount (not responded by RMA) Amount debited



Credit Amount (not responded by RMA) Amount CreditedDebit Amount (not responded by Bank) Amount debitedCredit Amount (not responded by Bank) Amount CreditedDaily Bank Balance Balance as per Bank

Report Layout

Royal Monetary Authority of BhutanDaily Reconciliation Statement

Bank A/c No.: 24153As on 07/06/2006

Date Ledger Balance Not Responded By RMA Not Responded by Bank

Daily Bank Balance

Debit Credit Debit Credit07/06/2006 56800.00 DR 58900.00 CR07/06/2006 56800.00 DR 0.00 2000.00 0.00 100.00 58900.00 CR07/06/2006 58800.00 DR 58800.00 CR

3.1.8.30 Nu Monthly Reconciliation Statement

DescriptionThis process is to generate reports for Monthly Reconciliation Statements

PurposeThe purpose of this report is to see the ledger entries for a month which are not responded by RMA vis-à-vis which are not responded by a particular bank

Input Parameters Financial Year Month Bank Account

Data ElementsThis report will contain the following data elements.Elements DescriptionReconciliation Date Date of ReconciliationLedger Balance Balance as per RMA’s LedgerBank Balance Balance as per Bank ReconciliationDebit Amount (not responded by RMA) Amount debitedCredit Amount (not responded by RMA) Amount CreditedDebit Amount (not responded by Bank) Amount debitedCredit Amount (not responded by Bank) Amount Credited

Report Layout

Royal Monetary Authority of BhutanMonthly Reconciliation Statement

As on 30-Jun-2006



Balance as per Bank: 52050.00 CRDate Bank Dr Bank Cr07/06/2006 0.00 100.0012/06/2006 16000.00 0.00Total 16000.00 100.00Closing Balance as per Bank: 67950.00 CR

Balance as per Ledger: 68050.00 DRDate Bank Dr Bank Cr07/06/2006 0.00 2000.0011/06/2006 0.00 2000.00Total 0.00 4000.00Closing Balance as per Ledger: 72050.00 DR

3.1.8.31 FC Bank Statement

DescriptionThis process is to generate the reports for Bank Statement

PurposeThe purpose of this report is to see the entered bank statement against a particular Bank

Input Parameters Bank Statement Date Bank Account Number

Data ElementsThis report will contain the following data elements.Elements DescriptionOpening Balance Opening Balance of the Statement DateDate Bank Statement DateParticularsReference Cheque/Draft/Pay Order NumberAmount Dr Amount DebitAmount Cr Amount CreditClosing Balance Closing Balance of the bank statement Date

Report Layout

Bank of BhutanFC Bank Statement

Bank Account No.:- 24513For 07/06/2006

Opening Balance: 0.00Date Particulars Reference No. Amount

Debit Credit07/06/2006 ABCD BOB11 10000.0007/06/2006 XYZ 1234 20000.00

Closing Balance 30000.00

3.1.8.32 FC Bank Reconciliation

DescriptionCAM – SRS Ver 1.3 of 139


This process is to generate reports for Reconciliation Register

PurposeThe purpose of this report is to see the matching/mismatching Record listing for RMA against a particular Bank

Input Parameters Enter the Reconciliation Date Bank Account Number

Data ElementsThis report will contain the following data elements.Elements DescriptionRMA – Date Date of transaction – LedgerRMA - Debit Amount Amount debit - LedgerRMA - Credit Amount Amount Credited – LedgerRMA - Reference Cheque / Draft No. – LedgerRMA - Recon Date Reconciliation DateBank – Date Statement Date - Bank StatementBank – Debit Amount Amount Debit – Bank StatementBank – Credit Amount Amount Credit – Bank StatementBank - Reference Cheque / Draft No. – Bank StatementBank - Recon Date Reconciliation Date

Report Layout

Royal Monetary Authority of BhutanFC Reconciliation Register

Bank A/c No.:24153As on 30/04/2006

RMA BankDate Debit Credit Reference Recon.

DateDate Debit Credit Reference Recon.

Date07/06/2006

30000 BOB11 12/06/2006

07/06/2006

300000 BOB11 12/06/2006

07/06/2006

20000 12345 12/06/2006

07/06/2006

20000 12345 12/06/2006

3.1.8.33 FC Daily Reconciliation Statement

DescriptionThis process is to generate reports for Daily Reconciliation Statements

PurposeThe purpose of this report is to see the daily ledger entries which are not responded by RMA vis-à-vis which are not responded by a particular bank

Input Parameters Enter Reconciliation Date Bank Account



Data ElementsThis report will contain the following data elements.Elements DescriptionDate Date of transactionLedger Balance Balance as per RMA’s LedgerDebit Amount (not responded by RMA) Amount debitedCredit Amount (not responded by RMA) Amount CreditedDebit Amount (not responded by Bank) Amount debitedCredit Amount (not responded by Bank) Amount CreditedDaily Bank Balance Balance as per Bank

Report Layout

Royal Monetary Authority of BhutanFC Daily Reconciliation Statement

Bank A/c No.: 24153As on 07/06/2006

Date Ledger Balance Not Responded By RMA Not Responded by Bank

Daily Bank Balance

Debit Credit Debit Credit07/06/2006 56800.00 DR 58900.00 CR07/06/2006 56800.00 DR 0.00 2000.00 0.00 100.00 58900.00 CR07/06/2006 58800.00 DR 58800.00 CR

3.1.8.34 FC Monthly Reconciliation Statement

DescriptionThis process is to generate reports for Monthly Reconciliation Statements

PurposeThe purpose of this report is to see the ledger entries for a month which are not responded by RMA vis-à-vis which are not responded by a particular bank

Input Parameters Financial Year Month Bank Account

Data ElementsThis report will contain the following data elements.Elements DescriptionReconciliation Date Date of ReconciliationLedger Balance Balance as per RMA’s LedgerBank Balance Balance as per Bank ReconciliationDebit Amount (not responded by RMA) Amount debitedCredit Amount (not responded by RMA) Amount CreditedDebit Amount (not responded by Bank) Amount debitedCredit Amount (not responded by Bank) Amount Credited



Report Layout

Royal Monetary Authority of BhutanFC Monthly Reconciliation Statement

As on 30-Jun-2006

Balance as per Bank: 52050.00 CRDate Bank Dr Bank Cr07/06/2006 0.00 100.0012/06/2006 16000.00 0.00Total 16000.00 100.00Closing Balance as per Bank: 67950.00 CR

Balance as per Ledger: 68050.00 DRDate Bank Dr Bank Cr07/06/2006 0.00 2000.0011/06/2006 0.00 2000.00Total 0.00 4000.00Closing Balance as per Ledger: 72050.00 DR

3.1.8.35 Nu Not Responded by RMA

DescriptionThis process is to generate reports for Monthly transaction not responded by RMA

PurposeThe purpose of this report is to see the bank entries for a month which are not responded by RMA for a particular bank

Input Parameters As on Date Bank Account Number


Elements DescriptionBalance as per Bank Balance as per bankDate Date of transactionReference Cheque/Draft/Pay Order/Letter No.Debit Amount Amount debitedCredit Amount Amount Credited

Report Layout

Royal Monetary Authority of BhutanBank of Bhutan – Misc. Account

Bank A/c No.:24153Reconciliation Statement as on 07/06/2006

Balance as per Bank Statement: 58090.00



Bank Entry Not Responded by RMA

Date Reference No. Debit Credit07/06/2006 Qqqqq 0.00 2000.00

Total 0.00 2000.00

3.1.8.36 Nu Not Responded by Bank

DescriptionThis process is to generate reports for Monthly transaction not responded by Bank

PurposeThe purpose of this report is to see the RMA entries for a month which are not responded by a particular bank


Data Elements

This report will contain the following data elements.

Elements DescriptionBalance As per Ledger Balance as per RMA ledgerDate Date of Debit transactionReference Cheque/Draft/Pay Order/Letter No.Debit Amount Amount debitedCredit Amount Amount Credited

Report Layout



Balance as per Ledger: 68050.00

RMA Entry Not Responded by Bank

Date Reference No. Debit Credit07/06/2006 1234 0.00 100.00

Total 0.00 100.00

3.1.8.37 FC Not Responded by RMA

DescriptionThis process is to generate reports for Monthly transaction not responded by RMA

Purpose



The purpose of this report is to see the bank entries for a month which are not responded by RMA for a particular bank



Elements DescriptionBalance as per Bank Balance as per bankDate Date of transactionReference Cheque/Draft/Pay Order/Letter No.Debit Amount Amount debitedCredit Amount Amount Credited

Report Layout


Bank A/c No.:24153FC Reconciliation Statement as on 07/06/2006

Balance as per Bank Statement: 58090.00

Bank Entry Not Responded by RMA

Date Reference No. Debit Credit07/06/2006 Qqqqq 0.00 2000.00

Total 0.00 2000.00

3.1.8.38 FC Not Responded by Bank

DescriptionThis process is to generate reports for Monthly transaction not responded by Bank

PurposeThe purpose of this report is to see the RMA entries for a month which are not responded by a particular bank


Data Elements

This report will contain the following data elements.

Elements DescriptionBalance As per Ledger Balance as per RMA ledger



Date Date of Debit transactionReference Cheque/Draft/Pay Order/Letter No.Debit Amount Amount debitedCredit Amount Amount Credited

Report Layout



Balance as per Ledger: 68050.00

RMA Entry Not Responded by Bank

Date Reference No. Debit Credit07/06/2006 1234 0.00 100.00

Total 0.00 100.00

3.1.8.39 Year End Journal Statement

DescriptionThis process is to generate daily journal

Purpose

The purpose of this view/print journal transaction




Daily Journal for the 11/05/2006

Voucher No.

Value Date


Amount Credit

AAM/1 11/05/2006


Basic Pay 40000.00 0.00



AAM/2 11/05/2006


Basic 25000.00 0.00

AAM/3 11/05/2006



1000.00 0.00

AAM/4 11/05/2006



10000.00 0.00

AAM/5 11/05/2006


Total GPF 0.00 20000.00

AAM/6 11/05/2006


Total GIS 0.00 4000.00

AAM/7 11/05/2006



0.00 10000.00

AAM/8 11/05/2006


0.00 20000.00

AAM/9 11/05/2006


0.00 22000.00

AAM/10 11/05/2006



0.00 24000.00

AAM/11 11/05/2006



24000.00 0.00

Total 100000.00 100000.00

3.1.8.40 Year End Trial Balance

Description This process is to generate the Trial Balance.

PurposeThe purpose of this report is to the see the Trial Balance for the specified period.






Report Layout

Royal Monetary Authority of BhutanCAM – SRS Ver 1.3 of 139


Trial Balanceof the financial year 2005-2006

For the Period of 01/04/2006 – 30/04/2006



15000.00 0.00 0.00 12000.00 3000.00 0.00


0.00 0.00 12000.00 0.00 12000.00 0.00

Total 15000.00 0.00 12000.00 12000.00 15000.00 0.00

3.1.8.41 Year End Income & Expenditure Statement

DescriptionThis process is to generate Income and Expenditure Statement



Data ElementsThis report will contain the following data elements.Elements DescriptionGL Group Head General Ledger Group HeadGL Sub Group Head General Ledger Sub Group HeadSchedule No. Schedule NumberCurrent Fin Year Amount Summation of Current Fin Year against the GL Sub GroupPrevious Fin Year Amount Summation of Previous Fin Year against the GL Sub GroupReport Layout

Royal Monetary Authority of BhutanIncome & Expenditure Statement


Particulars Schedule June 30, 2006 June 30, 2005Income


Net Interest Income 11000.00 9000.00Total Operating Income

11000.00 9000.00

ExpensesPrinting & Publication 04 3000.00 2500.00

Power & Water 05 3500.00 3000.00Total Operating Expenses

6500.00 5500.00

Net Income 4500.00 3500.00Prior Period 500.00 400.00CAM – SRS Ver 1.3 of 139


AdjustmentSurplus Payable to Government

4000.00 3100.00

3.1.8.42 Year End Balance Sheet

DescriptionThis process is to generate Balance Sheet



Data ElementsThis report will contain the following data elements.Elements DescriptionGL Group Head General Ledger Group HeadGL Sub Group Head General Ledger Sub Group HeadSchedule No. Schedule NumberCurrent Fin Year Amount Summation of Current Fin Year against the GL Sub GroupPrevious Fin Year Amount Summation of Previous Fin Year against the GL Sub Group

Report Layout

Royal Monetary Authority of BhutanBalance Sheet


Particulars Schedule June 30, 2006 June 30, 2005Asset


Total Asset 11000.00 9000.00LiabilityPrinting & Publication 04 3000.00 2500.00

Power & Water 05 3500.00 3000.00Total Liability 6500.00 5500.00



4 Interface Requirements

4.1 GENERALThe CAM system interacts with all other modules of ICBS. In most of the interactions with other modules, information flows both ways with the CAM system but along with the AAM it can also be used as a stand-alone system.

4.2 INTERACTION WITH OTHER MODULES

The following are the details of the interaction between AAMS and other modules of ICBS

4.2.1 Interaction with FOREX Operations Module

The FxRMD is the authority that can authorize all types of foreign exchange payments, either government or public in general, for which the actual payments will be routed through the concerned commercial banks. However, the Forex payments pertaining to the Debt Service payments, Diplomatic releases, VIP payments, and other special transfers on the instruction of Government are routed through the Banking Division of the RMA.

Following are some of the steps required to receive Forex Release Authorization Letter online, input additional information and accordingly update banking accounts and generate SWIFT advice. a. The FxRMD shall first receive the release order or payments instruction from the respective

authorized agency or Government and after processing it in their Foreign Exchange Release Authorization Format; shall pass a copy to the Banking Division for updating central accounts and producing remittance/SWIFT advice.

b. The Foreign Exchange Account section of the Banking Division shall now input the same Forex Release reference number on the Debit Advice processing screen. Accordingly the system shall search the record and display on the screen.

c. User shall input additional information required to process Debit Advice voucher and remittance advice.

d. Print both the Debit Advice and SWIFT Advice, verify it and if it is found correct sign on the “Prepared by Column and submit for final verification and approval.

e. Once the final verification and approval process are completed, the SWIFT advice shall be sent to SWIFT section.


FOREX

CAM

FOREX Payment/Release Information


4.2.2 Interaction with Administrative Accounts Module

The AAM sub-module will broadly access the following from CAM:

Budget Release Information Financial Reports

The CAM sub-module will broadly access the following from AAM System:

Chart Of Accounts Budget Information Employee Salary information ADM financial transactions


CAM

AAM

Budget Release

Financial Reports

Budget info

Chart of accounts

Salary Information

ADM Financial Reports


4.2.3 Interaction with Currency Management Module

The CAM module will broadly access the following from CMM:

Currency Chest Transaction Bullion Reports Financial Reports

The CMM module will broadly access the following from CAM System:

Bullion Transactions

The Issue Division as a custodian maintains only the physical gold, silver, and commemorative coins, while the Banking Division is maintaining the actual accounts.

1. For sale proceeds of the bullion, cash/cheque/letter is first deposited to the BD and prepares the voucher by debiting cash/bank/suspense and crediting bullion (gold, silver etc) and submits the voucher to ID.

2. Upon production of the voucher; the custodian delivers the items to the customers.

3. Issue Division also required to prepare its own voucher based on voucher passed by the BD. To prepare such voucher, an authorized user shall type computer generated voucher reference number on the screen and have corresponding voucher prepared for ID based on the BD voucher. As the BD voucher shall not have all the information required to prepare ID voucher, additional information shall be fed and apportion the amount denomination wise.



CAM

CMM

Bullion Transaction

Currency Chest Transaction

Bullion Information

ISSUE Division Financial Reports


4.2.4 Interaction with Reserve Management Module

The Foreign Exchange Section of the Banking Division maintains the foreign exchange Cash in Hand, Current Accounts, Investment Accounts and Indian Rupees etc. There is no set systematic or standard means of sharing of information between the Banking Division and the RMS. The RMS collects reports on foreign exchange expenditure and receipts, including the currencies in hand, either on an ad-hoc basis or at the end of month from the Banking Division. Based on the fund balances information obtained from the Banking Division, the RMS compiles reports and submits to the Monetary Operations Committee and the RMS invests the idle funds either on a short-term or long-term basis. The RMS issues office memos to the Banking Division on actual investments, and reinvestments for the necessary adjustments in the accounts. As such, the Banking Division is actively involved in the fund management processes, as well the maintenance of the accounts. The RMS also provides Daily Exchange Rates for convertible currencies and Reuters Rates for the calculation of daily bullion rates, which the BD publishes on the RMA website for public information. These rates are also being used by other divisions for converting the Forex value into Ngultrum equivalent, for statistical purposes and revaluation of Forex.


RMM

CAM

FOREX Rates

Investment Information

Report on Foreign Expense

Report on Investment/Reserves


4.2.5 Interaction with Statistical Information ModuleThe Banking Division provides the following financial reports to RSD:

a. Monthly Financial Statementsb. Audited Annual Financial Statements


RSIM

CAM

Monthly Financial Statements

Audited Annual Financial Reports


4.2.6 Interaction with FIRMA

The Banking Division also provides the following financial reports to FISD:

a. Monthly Financial Statementsb. Audited Annual Financial Statements


FIRMA

CAM

Monthly Financial Statements

Audited Annual Financial Reports

Camnjbhjvh

Documents

Transcript of Camnjbhjvh