Namma ServiceCash Tracking System

Discussion on requirements, issues with data sources, technical design for a flexible data holding framework, and work-in-progress

plans for a reconciliation engine.

Wednesday, January 31, 2007Kiran Jonnalagadda <kiran.j@comat.com>

Requirements Channelling Data Blue Sky PlanWhat’s wanted, what’s needed Dealing with available information Dreaming up what may be…

Requirements

Cash Flow Diagram

Refer to the printed copy

Via TC

2pm next day

Within 2!

days since

transaction

Invoic

e (M

onth

ly)

Transaction Update (Daily)

Net MTC minus IDTC (Monthly)

TC

BB

TelecentresTC

BankBranches

BB

BB

TC

BB

TC

BB

TC

BB

Comat Records

RDS/Bhoomi Records (SDC)

TC

TC

TC

PR

PR

PR

Bank

Auditor Totals

Amount CollectedIDTCRecd.

PenaltiesIncurred

PaperRecords

GoK

Share

TA

Share

Back Office

3i Bank Account

GoKGoK Bank Account

DMArea/District Manager

BankGuarantee

Performance Bank Guarantee

IDTC (Daily)

Enhancement (Quarterly)

Cash Tracking

CMC Account

3% to CMC

Legend:

TC

TC

(Monthly)

Transaction Flow

Primary Information Flow

Reconciliation Information Flow

Cash Flow

TC Telecentre (physical structure)

TC Records of telecentre (information structure)

Central Bank

Accounts

Maintenance (monthly)

Requirements Analysis UsingUser Stories

Defining system requirements via actors and their

activities, expressed as “stories”

Actors Activities Stories

Available Data

Current Data Collection ProcessesTransaction Reports installed at the State Data Centre provide a running stream of transactions, but are unreliable: if a certificate fails to print, it is still recorded as a successful transaction.

At least we’re assured they didn’t miss anything.

Type of data:individual transactions.

Current Data Collection ProcessesOperators use the Intranet to file daily reports.

Details are limited to what we can expect to receive with a reasonable level of accuracy.

Operators may not recall the number of successful transactions on a busy day, for example, but can count the cash at hand or the number of wasted sheets.

Type of data:daily totals and errors.

{

Current Data Collection ProcessesThe IDTC Transfer Grid, part of the existing Transaction Reports, records our transfer to GoK and GoK’s transfer back to us, with GoK’s Bank validating the claimed figures.

What we need is similar cooperation from our banks at the individual branch level.

Any errors in transaction data are propagated here.

Type of data:daily total for per region.

Current Data Collection ProcessesOur operations staff call operators and area managers every day to get an update. While this gives us a better sense of ground-level activity than any automated system, it is a laborious process.

Any machine parseable data currently being collected by this process should be replaced by software.

Type of data:non-machine parseable detail on operations.

Making Sense of It AllPutting Data on Rails

LedgerCash Collection

(Current Asset)

TransactionSplit

TransactionRecord

LedgerRTC Service

(Income)

Double Entry Accounting

TransactionRecord

(Sum of Splits: Zero)

TransactionSplit

(Rs +15)

TransactionSplit(Rs -15)

Well Defined From Data Streams To Be Calculated

Sample Ledger

LedgerCash Collection

(Current Asset)

LedgerRTC Service

(Income)

Missing Data Streams

TransactionRecord

(Sum of Splits: Zero)

TransactionSplit

(Rs +15)

TransactionSplit(Rs -15)

There is no data stream for the second split, so that must be calculated and marked as such, for later reconciliation

LedgerImbalance

(To maintain integrity)

Creating Balancing Splits

LedgerCash

Collection(Current Asset)

LedgerRTC Service (Unreliable)

(Income)

LedgerRDS Services

(Reliable)(Income)

TransactionsTra

nsactio

ns

Operator’s Stationery Error

Report

Reco

ncile

Operator’s Collection

Report

Reconcile

LedgerWasted

Stationery(Monthly Collections)

Reconcile

Non-cash inventory ledger!

Ledger/Group Value/Count

TotalAbsolute or Period Totals

Ledger

Well Defined Data Types

There are more, but these are the most critical data types

TransactionTransaction

SplitReconciliation

Split+ Flags

Reconciliation Set

Ledger Group

Group Membership

Blue Sky PlanThe Reconciliation Engine

Transactions and Deposits

Rs 0

Rs 2,125

Rs 4,250

Rs 6,375

Rs 8,500

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Transactions Deposits

3-Day Moving Average

Rs 0

Rs 1,000

Rs 2,000

Rs 3,000

Rs 4,000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Transactions Deposits

SecurityCareful with the Details

Typical Security ModelSecuring the Perimeter

The User Interface is the Perimeter

Once inside the Perimeter,there’s no security. A single insecure entry

point compromises the entire system

User & Machine Interface

Extended API

Core API

Core Data

Recommended ModelSecurity at the Core

Core API

Core Data

Recommended ModelIndependent Modules Manage Their Own Security

Reconciliation Engine

User InterfaceWeb Services + Cache

SecurityFramework

Security is defined in terms of Users, Roles,

Permissions and Actions. Users have

Roles in specific Contexts and Roles have Permissions to

perform Actions.

Users Roles Permissions

Contexts are Ledgers and

Ledger GroupsUsers are assigned roles in particular contexts, such as

kiosk operators acquiring the “Operator” role only in their

kiosk’s ledgers.

Actions are Pieces of

Code

Each code function requires a specific permission to be

used. Permissions are given to roles, which in turn are

given to users.