namma service cash tracking system (january 2007)
Post on 08-Jul-2015
177 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.
top related