Inside Dashboard
Dashboard contains compact Overview and Financial Timeline tabs, so users can move between summary analysis and chronological activity without adding another primary navigation section.
Switch from Dashboard Overview to Financial Timeline and follow permitted financial activity by date without changing the underlying records or calculations.
Financial Timeline is a read-only Dashboard view built from the signed-in user's permitted workspace records. The existing Dashboard Overview remains available as the default analytical view.
Financial Timeline is Triplem VIP's chronological activity stream. It organizes important operational and Accounting events by date, while leaving the source records, balances and posting rules unchanged.
Dashboard contains compact Overview and Financial Timeline tabs, so users can move between summary analysis and chronological activity without adding another primary navigation section.
The timeline requires Dashboard access and includes module activity only when the current signed-in user is permitted to view that module.
The timeline reads existing records. Opening or filtering it does not rewrite expenses, loans, installments, Accounting entries or balances.
Supported timeline entries can open the original Triplem VIP record overlay, preserving the underlying module as the source of truth.
The timeline merges meaningful events while avoiding duplicate wallet legs when another module already represents the authoritative event.
Pure expenses appear as outflows. Add Money/Receiving appears as inflow. Internal Transfers are classified separately rather than being treated as operating expense or income.
Loan Given, Loan Taken, Received Back and Loan Returned events preserve their financial direction and relationship context.
Bought and Sold plan creation is visible, while actual installment payments or receipts carry the corresponding cash-flow direction.
Inventory purchases and sales appear as dated operational activity without duplicating linked wallet movements as separate timeline events.
Asset purchases, sales, revenue and asset expenses can be followed as part of the wider financial history.
Accounting documents, payments and bank transactions are surfaced as formal Accounting events while remaining distinct from operational records.
Existing note activity can appear as contextual timeline events where the user has Notes access. The Notes feature itself is unchanged.
Permitted Bitcoin wallet activity can appear in the chronology without exposing private keys, recovery phrases or signing secrets.
Daily totals are currency-aware, and internal movement is kept distinct from genuine inflow and outflow.
The Timeline does not combine unlike currencies into a synthetic total. AED, SAR, PKR, USD and BTC remain separately identified where an event carries an amount.
Internal wallet transfers are emitted once as transfer activity and are not counted again as both an outgoing expense and incoming revenue. Plan creation and other non-cash events can remain neutral until actual money moves.
The Timeline is designed for fast scanning first, then focused inspection.
Search the timeline for matching activity without manually opening each finance module.
Limit results to Expenses, Loans, Installments, Inventory, Assets, Accounting, Notes or Bitcoin.
Focus on one supported currency when comparing activity and daily totals.
Use period controls to narrow the chronology instead of loading an unbounded history at once.
Events are grouped by date with event counts and currency-specific net movement summaries.
Load-more behavior keeps the initial timeline compact while older activity remains available when required.
No. It is a cross-module chronological Dashboard view. Formal double-entry ledger reporting remains inside Accounting ERP.
No. Internal wallet movement is identified as transfer activity rather than being counted as operating income and expense.
No. Timeline retrieval is read-only. Editing remains governed by each source module's existing record controls.
No. Timeline retrieval checks the signed-in user's module permissions before including that module's events.