| Area | What existed earlier | What’s new |
|---|---|---|
| 1. Cash Tracking Model | Cash was tracked through sessions tied to a user and device. The focus was on shift-level drawer balance. | Cash is tracked through registers and cash movement flows, reflecting how physical cash actually moves inside a store. |
| 2. Register Types | Only session-based cash drawers linked to cashier/device were available. | Cash is now managed through clearly defined registers: 1. Sales Register– Individual cashier counters 2. Store Deposit Register– Central cash pool of the store 3. Petty Register– Long-running register for expenses 4. Bank Deposit– Formal record of cash deposited into the bank |
| 3. Store-Level Cash Visibility | No single view of how much cash the entire store held; merchants had to infer from sessions. | Store Deposit Register gives real-time visibility of total physical cash available in the store. |
| 4. Opening Cash Flow | Opening balance was entered directly at the session level without a defined source. | Sales registers draw opening cash from the Store Deposit Register, ensuring a clear and traceable cash source. |
| 5. Cash In / Cash Out Logic | Cash could be added or removed during a session, but source and destination were not strictly enforced. | Every cash movement has a defined source and destination (e.g., Sales → Store Deposit), with automatic counter-entries. |
| 6. Inter-Register Transfers | Transfers between registers were informal and hard to audit. | Cash transfers between registers are system-controlled and auto-balanced on both sides. |
| 7. Expense Handling | Expenses were recorded as generic cash-outs from sessions. | Expenses are handled through a dedicated Petty Register, keeping sales cash and expense cash clearly separated. |
| 8. Petty Cash Lifecycle | Petty cash was session-bound and short-lived. | Petty Registers are long-running, can span multiple days, and maintain a complete transaction history. |
| 9. Bank Deposit Recording | Bank deposits were logged but loosely connected to registers’ balances. | Bank deposits must originate from the Store Deposit Register, ensuring deposits never exceed available cash. |
| 10. Discrepancy Handling | Mismatches were identified at session closure, with limited configurability. | Admins can define maximum discrepancy limits; small differences auto-log, larger ones require manager approval. |
| 11. Role-Based Access Control | Access to Cash Management was based only on Admin and Store Associate roles. | Clear role-based permissions: • Store Associate – Own sales register only • Store Manager – All store registers • Admin – Configuration & multi-store visibility |
| 13. Audit & Traceability | Audit trails existed but were fragmented across sessions. | Unified audit trail across all register types, showing who moved cash, why, and where it went. |
| 14. Store Lifecycle Coverage | Focused mainly on daily sessions and shifts. | Covers the entire store lifecycle: store opening, daily operations, expenses, deposits, and store shutdown. |
| 15. Store Closure Handling | No structured process for closing a store permanently. | Defined closure flow ensuring all registers are closed and store cash reaches zero before shutdown. |
Store OS
/- POS & mPOS
- Features
/
What’s New & Improved
Last updated