Document Report — Turning a Payment Tree into a Finance Workspace

The finance specialist's real question is never “show me the document tree.” It is “for this deal, what has been produced, what is still missing, and let me open it.” The source material — a branching diagram of every possible document — answered a modeling question, not a work question.

I reframed the screen around the deal identifier (pre-invoice code for sales, entry-receipt code for purchasing), not around the shape of the tree. The result is a master–detail finance workspace: a scannable table of deals with a KPI strip on top, and a per-deal vertical document trail that renders the payment branch as a parent node with nested sub-documents, exposes every document's status as a colored chip, and makes missing documents as visible as existing ones — because in a sell-first business, a missing document is a financial risk, not an empty cell.

What changed: the specialist goes from hunting across a horizontal tree with no status to scanning a queue, selecting a deal, and reading its trail top-to-bottom — the most common task drops from several clicks and a mental cross-check to one click and a glance.

SivanLand runs on one defining constraint: sell-first, source-later. The company collects payment before it procures the goods. When cash arrives ahead of inventory, documents are the load-bearing structure of trust — each step of a deal emits a record (a payment log, a promissory note, a warehouse-exit voucher, a waybill, a final invoice), and the chain of those records is what proves that money taken in has a real, sourced, delivered order behind it.

So the finance specialist isn't browsing files. They are auditing the integrity of the paper trail across dozens of live deals — confirming that every step that should have produced a document actually did, and chasing the ones that didn't.

These two worlds have different keys, different lifecycles, and no shared rows — a distinction that drove the top-level navigation decision.

The starting point was a lifecycle diagram: every document a deal can emit, and the prerequisite order between them. It's an excellent domain artifact and a poor interface — it answers “what is the space of all documents?” when the user needs “what's the state of this deal?” The branching is real: payment forks into cash vs. credit, each with its own sub-documents, then everything reconverges into the fulfillment chain.

SALES LIFECYCLE                          PURCHASING LIFECYCLE
فروش (Sale)                                بازرگانی (Purchasing)
  → کد پیش‌فاکتور (pre-invoice code)          → کد رسید ورود (entry-receipt code)
  → سند 191 (document)                        → دستور پرداخت (payment order)
     ├─ واریز نقدی (cash)                     → فیش واریزی (deposit slip)
     │    ├─ درگاه پرداخت (gateway)             → فاکتور فروش تأمین‌کننده (supplier invoice)
     │    └─ لاگ (log)                          → بارنامه (waybill)
     └─ اعتباری (credit)
          ├─ سفته (promissory note)
          ├─ چک (check)
          └─ دستخط (signature)
  → حواله خروج انبار (warehouse-exit voucher)
  → بارنامه (waybill)
  → سند تحویل (delivery doc)
  → فاکتور نهایی (final invoice)

• The dominant relationship is sequence / prerequisite, not hierarchy — a left-to-right tree draws this as branching, which hides the thing that actually matters: how far down the chain has this deal gotten?
• The payment step is the only true branch — cash (gateway, log) vs. credit (promissory note, check, signature). Everything else is a straight line.
• Every node is the same kind of thing — a document that either exists or doesn't, that can be viewed and downloaded. That uniformity means one component can represent the whole tree.

Persona — Finance Specialist (کارشناس مالی). Sits between sales and the warehouse. Owns the question “is this deal's paperwork complete and correct?” Works across many open deals a day, under audit pressure, in a sell-first model where a missing document = exposed cash.

Job ③ is the insight the source diagram completely ignored: the specialist's most valuable task is finding the gaps, and a raw document tree has no concept of a gap — an un-generated document simply isn't drawn.

I ran the naïve “just render the diagram interactively” concept against the core dashboard heuristics before drawing anything. The findings, biggest impact first:

• Critical — No overview layer. Violates Shneiderman's mantra (“overview first, zoom and filter, then details on demand”). A pure tree drops the user straight into one deal's details with no way to scan how things are going across all deals — Job ③ becomes impossible.
• Critical — Organized by data model, not mental model. The tree is grouped by document type and branch shape. The specialist thinks in deals: “PF-14198 — what's its status?” Grouping by the question the user asks is the single highest-leverage move on the page.
• Major — Missing documents are invisible. In a sell-first business the empty node is the signal. A tree that only draws what exists hides exactly what the user is auditing for.
• Major — Status encoded as nothing. Nodes were plain labels — “generated,” “pending” and “not yet created” looked identical.
• Major — Horizontal tree fights RTL and the real relationship, visually encoding branching over sequence — the opposite of the user's mental model of progress.
• Minor — High interaction cost. No search, no “download all,” no designed empty/loading/error states.

Conclusion: the diagram is the right content and the wrong container. Keep the lifecycle truth; throw away the tree-as-UI.

• Summary first, details on demand — a KPI strip and a deal table answer “how are things going?” in three seconds; the trail answers “what about this one?” on click.
• Group by mental model — everything hangs off the deal code, the object the specialist actually reasons about.
• Tables over cards for data-dense content — deals are multi-attribute, sortable, comparable rows.
• Status is a chip, not a word — color and a status dot, so it survives grayscale and color-blindness.
• Make the gap first-class — un-generated documents render as an explicit empty state, not an absence.
• Sequence beats hierarchy — a top-to-bottom trail expresses how far a deal has progressed.
• Respect the system-of-record boundary — the ERP owns orders, payments and the catalog; this screen reads and annotates those as events, and never becomes a second source of truth.

Entry points: left nav → Financial Panel → Document Report; or a deep link from a specific deal elsewhere in the CRM. One primary question per screen: “what is the document state of my deals, and let me act on any one of them?”

The two worlds — Sales and Purchasing — have different keys and zero comparable rows, so this is the rare, correct case for a segmented control rather than tabs hiding comparable data.

Document Report
│
├─ [ Sales docs | Purchasing docs ]   ← segmented mode switch (default: Sales)
│
├─ KPI strip .................. overview layer ("how are things going?")
│
└─ Master–detail
   ├─ Deal table (right, RTL) ... scan & select — the work queue
   │     row = one deal code + progress + status
   │
   └─ Document trail (left) ..... the selected deal, top-to-bottom
         node = one document · status chip · view · download
         payment node = parent → nested sub-documents (cash/credit branch)

Overview and detail coexist, so the specialist scans a queue and reads a deal without ever navigating away and back — the pattern audit-heavy tools (Stripe, Linear) use for exactly this “list of things with rich per-thing state” problem.

┌─ [ Sales docs ▸ | Purchasing docs ]                   🔍 search code ─┐   ← toolbar
├─ Deals: 42   Complete: 34   Docs generated: 16/24   ⚠ Awaiting: 8 ─┤   ← KPI strip
├───────────────────────────┬────────────────────────────────────┤
│ DEAL CODE       PROGRESS  ●   │   PF-14198 · Credit    ⬇ Download all │
│ ───────────────────────── │   ───────────────────────────────────┐
│ ▸ PF-14198   ▓▓▓▓▓░░  ⚠ 8/24  │   ●─ Document ............. ✅ view ⬇ │
│   PF-14201   ▓▓▓▓▓▓▓  ✅ done  │   │                                   │
│   PF-14205   ▓▓░░░░░  ⚠ 3/24  │   ●─ Payment (credit)                 │   ← parent node
│                                │   │   ┄·· Promissory note  ✅ view ⬇ │
│                                │   │   ┄·· Check ........... ⏳ awaiting│   ← nested
│                                │   │   ┄·· Signature ....... ✅ view ⬇ │      sub-docs
│                                │   │                                   │
│                                │   ●─ Warehouse-exit ....... ✅ view ⬇ │
│                                │   ●─ Waybill .............. ⏳ awaiting│
│                                │   ○─ Delivery doc ......... — not yet  │   ← gap = empty
│                                │   ○─ Final invoice ........ — not yet  │      state, visible
└───────────────────────────┴──────────────────────────────────────┘
       ↑ work queue (scan & select)        ↑ document trail (read top-to-bottom)

Status is never carried by color alone — each chip pairs a hue with a status dot / glyph, so meaning survives grayscale printing (which finance teams do) and color-blind vision.

Good screens for complex domains are usually a thin, honest surface over a well-factored model. Three ideas from A Philosophy of Software Design shaped decisions the user never sees but feels:

• Deep module, simple interface. The whole lifecycle — two worlds, a payment fork, prerequisite ordering, three per-document states — is hidden behind one node abstraction: a document that is generated / awaiting / not-yet-created, viewable and downloadable.
• Information hiding at the system-of-record boundary. The ERP owns orders, payments and the catalog; the Document Report ingests and annotates those as events — it never becomes a second, diverging ledger.
• Organize by knowledge, not by time. The tempting decomposition is temporal (cash flow, then credit flow, then fulfillment); instead the screen is organized around the object that owns the knowledge — the deal — so everything about one deal lives in one place, in order.

The payoff of getting the model right: the interface has almost no special cases. One node, one trail, one mode switch, three states. Simplicity on the surface is earned by structure underneath.

• RTL-native, not RTL-retrofitted — reading order flows right-to-left, the timeline descends, the segmented control's default sits on the right, KPI priority runs right→left.
• Type: Yekan Bakh / Vazirmatn; Persian numerals in prose, Latin numerals in codes and URLs.
• Tokens from the live system — primary green #7BB721, green tint #E5F2D3, table header #242429, border #E5E7EB, muted #6B7280.
• Status = color + shape, meeting non-color-reliant contrast guidance.
• Text labels over ambiguous icons for the core actions (view / download) — clarity beats cleverness on an audit surface.

This is an internal tool, so impact is framed as interaction-cost reduction against the specialist's four jobs, with live validation as the next step:

Qualitative wins already visible in review: gaps are now impossible to miss; the two document worlds never bleed together; a new specialist can read the screen without training because it maps to how they already think about deals.