README

Caesar — flows

Per-persona interactive builds for Caesar. Each persona gets a folder with an index.html canonical flow once designed: flows/<persona-slug>/index.html.

Status: planning. No flows built yet. The personas below are derived from the BRD — §12 (roles & segregation of duties), §7 (command centre) and §8 (functional requirements). They are provisional: confirm role boundaries and the screen set against the live Zoho Books configuration (demo) before building. Caesar is web / desktop (1440px) — see DESIGN.md.

Segregation of duties (BRD §12)

Caesar enforces separation between requisition → approval → payment → posting. No single persona spans the whole chain; the personas below are drawn along those lines plus the read-only command centre.

Provisional personas

Persona (slug)	Owns	Key surfaces
Command centre / Executive (command-centre)	The real-time financial situation; the board pack. Read-only.	The single-pane dashboard (BRD §7): swap revenue vs SRRR, money in bank, liabilities, fixed-asset register, open requisitions, receivables, consolidated position + D:E / covenant headroom. Entity / cluster / consolidated switching via the segment spine.
Controller / CFO (controller)	The books: journal posting, period close per subsidiary, group roll-up & parent/opco elimination, approvals at the top of the matrix, consolidated reporting.	Journal entry & posting (immutable once posted), period-close workspace, group roll-up, statements (P&L / BS / CF), board pack.
Accountant / GL operator (accountant)	Day-to-day ledger: journals, bank reconciliation, fixed-asset register, intercompany entries, close support.	Journal grids, bank-feed reconciliation, fixed-asset sub-ledger (capitalisation from Hermes deployment events, depreciation), inventory→asset conversion.
AP clerk (accounts-payable)	Payables: vendor master, vendor bills, payments, two-way match.	Vendor master, bill entry, payment runs, AP ageing.
Requisitioner / Budget owner (requisitioner)	Raising requisitions and watching committed spend by department / cluster.	Requisition creation, committed-but-unbilled spend view, requisition status tracking.
Approver (approver)	The amount- and entity-based approval matrix for requisitions, POs and journals.	Approval queue, requisition→PO→bill lifecycle timeline, approve/reject (.dlg confirmations).

Cross-cutting surfaces (shared across personas)

• Segment & entity pickers — Subsidiary / Location (cluster→station) / Class / Department. These slice nearly every view (BRD §6) and should be one shared component.
• Settings / admin — chart of accounts, subsidiary tree, vendor terms, approval-matrix config, Nigerian-tax (VAT/WHT) setup. Likely a controller/admin-scoped area, not its own persona.

Build order (suggested)

1. Command centre first — it is “the view you asked for” (BRD §7) and the clearest demo artifact.
2. Requisition → PO → bill — the approval-chain workflow that touches three personas.
3. Journal posting + period close — the audit-grade core.
4. Fixed-asset register incl. the inventory→asset conversion (BRD §8.5–8.6, the most MocX-specific flow).