Namma service cash tracking system (January 2007)
0 likes728 views
The document discusses the requirements and design for a cash tracking system, addressing data source issues and outlining a plan for a reconciliation engine. It highlights the processes for collecting transaction data and emphasizes the need for reliable records and improved data handling systems. Additionally, it covers security models and the assignment of user roles and permissions within the system.
Namma service cash tracking system (January 2007)
- 1. Namma Service Cash 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, 2007 Kiran Jonnalagadda <kiran.j@comat.com> Requirements Channelling Data Blue Sky Plan What’s wanted, what’s needed Dealing with available information Dreaming up what may be…
- 2. Requirements
- 3. Cash Tracking Tra n sa RDS/Bhoomi Records (SDC) Telecentres Cash Flow Diagram cti on Up d TC Bank Branches ate (D ail y) Comat Records TC TC TC 2pm next day Paper PR Records BB BB TC TC TC PR BB BB TC TC TC PR BB BB Bank Auditor Back Office Totals Amount Collected Via T onthly) ce (m Maintenan IDTC (Daily) Penalties Incurred ) in 2! With since days action s tran (Monthly 3i Bank Account Central Bank Accounts IDTC Recd. Invoice Refer to the printed copy DM TA Share Area/District Manager GoK Share C Net MT C min us IDT C (Month ly) Legend: Transaction Flow Primary Information Flow Reconciliation Information Flow Cash Flow Enhancemen t TC Telecentre (physical structure) TC Records of telecentre (information structure) (Quarterly) GoK Bank Account Bank Guarantee Performance Bank Guarantee GoK 3% t (M o C on MC thl y) CMC Account
- 4. Requirements Analysis Using User Stories Actors Activities Defining system requirements via actors and their activities, expressed as “stories” Stories
- 6. Current Data Collection Processes Transaction 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.
- 7. Current Data Collection Processes Operators 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. {
- 8. Current Data Collection Processes The 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.
- 9. Current Data Collection Processes Our 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.
- 10. Making Sense of It All Putting Data on Rails
- 11. Double Entry Accounting Ledger RTC Service Transaction Split (Income) (Rs -15) Transaction Record (Sum of Splits: Zero) Ledger Cash Collection Transaction Split (Current Asset) (Rs +15) Well Defined Transaction From Data Streams Split To Transaction Be Calculated Record
- 12. Sample Ledger
- 13. Missing Data Streams Ledger RTC Service Transaction Split (Income) (Rs -15) Transaction Record (Sum of Splits: Zero) Ledger Cash Collection Imbalance Transaction Split (To (Current Asset) maintain integrity) (Rs +15) There is no data stream for the second split, so that must be calculated and marked as such, for later reconciliation
- 14. Creating Balancing Splits Ledger RDS Services (Reliable) Ledger RTC Service (Unreliable) n tio (Income) Tran s c sa n Tra ile acti ons Re co nc Ledger Cash Collection Operator’s Stationery Error Report Re (Current Asset) con cile Non-cash inventory ledger! s (Income) Ledger Wasted Stationery (Monthly Collections) Re con cile Operator’s Collection Report
- 15. Well Defined Data Types Ledger Ledger Group Group Membership Ledger/Group Value/Count Total Absolute or Period Totals Reconciliation Set Transaction Transaction Split Reconciliation Split + Flags There are more, but these are the most critical data types
- 16. Blue Sky Plan The Reconciliation Engine
- 17. Transactions and Deposits Transactions Rs 8,500 Deposits Rs 6,375 Rs 4,250 Rs 2,125 Rs 0 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
- 18. 3-Day Moving Average Transactions Rs 4,000 Deposits Rs 3,000 Rs 2,000 Rs 1,000 Rs 0 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
- 19. Security Careful with the Details
- 20. Typical Security Model Securing 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
- 21. Recommended Model Security at the Core User & Machine Interface Extended API Core API Core Data
- 22. Recommended Model Independent Modules Manage Their Own Security Core API +C Web Services ache Core Data Reconciliation Engine User Interface
- 23. Security Framework Users Roles Security is defined in terms of Users, Roles, Permissions and Actions. Users have Roles in specific Contexts and Roles have Permissions to perform Actions. Permissions
- 24. Contexts are Ledgers and Ledger Groups Actions are Pieces of Code Users are assigned roles in particular contexts, such as kiosk operators acquiring the “Operator” role only in their kiosk’s ledgers. Each code function requires a specific permission to be used. Permissions are given to roles, which in turn are given to users.