Accounting requests and settlements prototype design

Status: written specification approved on 2026-10-13; the initial implementation, operator handover, and verification completed on 2026-10-13. The approved responsibility-location correction completed on 2026-10-13 with 244 / 244 regression tests, desktop and narrow browser proof, and independent specification and quality reviews. That correction changes where business users create and track requests, while preserving the approved financial model, lifecycle, reservations, settlements, allocations, and history. The approved minimal source-led request correction completed on 2026-10-13 with 259 / 259 regression tests, desktop and narrow HTTP browser proof, and independent review. It simplifies request presentation and closes contextual-action coverage gaps without changing the financial engine or the 244-test baseline behavior. The approved accounting-queue and batch-action correction completed on 2026-10-14 with 273 / 273 regression tests, 14 / 14 focused tests, desktop and narrow HTTP browser proof, and independent bounded specification and quality review. The targeted settlement-completion affordance correction completed on 2026-10-14 with 276 / 276 regression tests, 3 / 3 focused tests, desktop and narrow HTTP browser proof, and bounded independent review. It separates approval from settlement in the Accounting workspace and adds guarded multi-select actions without changing the request, reservation, or actual-money model.

Outcome

All customer and supplier money movements pass through accounting. Product operators describe the business need and submit a request; accounting reviews it, approves it, and records the actual settlement. There is no separate manager-approval role in this prototype. A request is an instruction and reservation, while a settlement is the evidence that money actually moved. Only actual settlements and explicit allocations of previously settled advances or unmatched receipts change paid, received, refundable, available-advance, delivery, or order-close balances. An allocation moves existing settled value to a business obligation without creating another money movement.

The workflow covers customer receipts, customer refunds, after-sales service-fee receipts, factory payments, stone or material payments, packaging payments, and certificate payments. It also covers outbound advances before a bill or item exists and incoming receipts that cannot yet be allocated to an order.

Scope

Extend the standalone in-memory prototype at docs/product-reference/workflow-discussion/product-workspace-design-option.html, its regression tests, and the operator handover documentation. The prototype demonstrates responsibilities, review, reservation, settlement, allocation, and history. It does not add production routes, persistence, permissions, identity integration, bank or payment-provider integration, notifications, or real money movement. Refresh continues to clear prototype data.

Completed-settlement reversal, chargeback, supplier refund, and accounting-ledger correction are outside this iteration. The prototype preserves completed transactions so those future workflows can be discussed without rewriting history.

Business objects

Obligation

An obligation is an amount already supported by a business record. Examples are an accepted customer price, an after-sales service fee, a customer refund target tied to an original receipt, a factory-item total, a purchased material line, a packaging purchase, or a certificate charge. An obligation retains its existing business scope and rules. In particular, customer receipts remain order-level, supplier costs remain line-level, and refunds remain tied to both their case and original receipt.

Request

A request records what an operator asks accounting to receive or pay. It has one direction, one counterparty, one destination or receiving account, and one currency. It may contain multiple lines across orders and across the supported categories when every line uses that same direction, counterparty, account, and currency. This supports a monthly request containing several factory, material, packaging, or certificate lines for one legal counterparty without losing each line's category and source reference.

Each request records:

• Direction: incoming or outgoing.
• Counterparty and selected or proposed account.
• Currency and requested settlement date.
• Optional statement or billing period.
• Request basis: recorded obligation or advance.
• One or more lines with category, linked order, item, case, receipt, cost, certificate, packaging, or other applicable source, and requested amount.
• Purpose and supporting evidence.
• Requester and creation, submission, and revision timestamps generated by the prototype.

An invoice or formal statement is useful but not mandatory. A contextual request may rely on its truthful linked business-source reference and must identify that basis as a registered business record rather than an invoice. A source-less advance may use a written explanation when no invoice exists, and the request must make that absence visible to accounting. The request total equals the sum of its current lines.

The request object retains these fields even when the source-led operator form does not expose each one as an editable control. For a contextual request, the prototype may derive a factual purpose from the category and linked source and may use the immutable linked-source reference as evidence of the business basis. That source reference does not claim that an invoice exists, does not verify an account, and is never settlement evidence that money moved. A new advance has no linked obligation, so its operator must still enter a concise purpose and provide honest supporting evidence or a written explanation.

Settlement

A settlement is an immutable record of an actual incoming or outgoing money movement. It records actual amount, date, method, account, per-line allocation, and evidence. Evidence requires at least one transaction reference, attachment, or explicit cash acknowledgement. The allocation total must equal the settlement amount and cannot exceed the request's unsettled amount or any source's currently available balance.

One request may have multiple settlements. A partial settlement changes the request to partial, preserves every earlier settlement, and leaves only the unpaid or unreceived remainder actionable. Completion occurs only when the request has no unsettled amount.

Failed attempts record attempted date, method, account, and failure reason, but create no settlement and change no money balance.

Advance and unmatched receipt

An outbound advance may be requested before a bill, order item, or other payable line exists. It still requires direction, counterparty, category, account, currency, purpose, target date, and evidence or written explanation. After actual settlement it becomes an available advance balance, not a paid bill. Accounting later applies an eligible advance amount to a recorded bill through an explicit allocation. That allocation reduces both the available advance and the bill balance without creating a second payment.

Accounting may record an incoming receipt whose order or receivable is not yet known. It remains an unmatched receipt balance under its counterparty, receiving account, and currency. Accounting later allocates it explicitly to one or more eligible customer receivables or after-sales fees. An unmatched receipt does not mark an order paid, permit delivery, or permit order closure until allocation occurs.

Responsibilities and accounts

Product operators select an existing counterparty account or propose a new account with the request. They own the business purpose, linked records, requested amounts, category, target date, period, and supporting explanation. They create, edit, submit, withdraw, revise, and resubmit those requests from the operational section that owns the underlying business work. They do not author requests from the Accounting workspace.

Accounting maintains and verifies counterparty payment accounts. An account includes the legal recipient or payer name, payment method, account holder, masked account identifier, and verification status or note. A proposed account may travel with a submitted request, but no settlement can use it until accounting verifies it. Certificate type remains a service category; the actual certificate institution or payee account is the counterparty.

Accounting never edits the operator's business fields directly. If the counterparty, category, source links, requested amounts, purpose, or other business detail is wrong, accounting returns the request with a reason. The operator revises and resubmits a new retained revision. Accounting may add review notes and owns approval, account verification, failed-attempt records, settlement details, and allocations. Accounting receives submitted requests in its own review queue and has no draft, edit, monthly-request, advance-request, or resubmission controls.

Lifecycle

The successful path is draft → submitted → approved → partial → completed. An approved request may move directly to completed when one settlement covers it in full.

• A draft reserves nothing and may be edited by its operator.
• Submission freezes that revision and reserves its requested obligation or refund amounts.
• Accounting may approve, return, or reject a submitted request and must record a reason when returning or rejecting it.
• A returned request releases its unpaid reservation and can be revised and resubmitted by the operator.
• A rejected request releases its unpaid reservation and remains closed in history.
• The operator may withdraw a submitted request before approval, releasing its reservation.
• After approval, accounting may cancel only the unsettled remainder and must record a reason.
• Cancellation never removes or changes settlements already recorded against the request.
• Partial and completed requests retain all revisions, review decisions, failed attempts, settlements, and allocations.

If a linked obligation or selected account changes after submission, the request is marked as requiring review before approval or another settlement. Its previous settlements remain final. The unsettled revision returns through accounting review, and accounting must explicitly confirm that the remaining lines, account, and reservations are still valid.

Reservations and balance rules

Submission reserves each linked obligation or refundable amount immediately. Source views distinguish the original amount, settled amount, amount reserved by open requests, and amount still available to request. No new request line may exceed the still-available amount. This prevents duplicate monthly requests from independently claiming the same balance.

Returning, rejecting, withdrawing, or cancelling releases only the unsettled reservation. Amounts already settled remain settled. Partial settlement converts the settled portion into actual money and keeps the remainder reserved.

Approval and every settlement revalidate the source balances and account. A changed cost, another allocation, a changed refund pool, or an account change must block further settlement until the request is reviewed. The prototype never silently reduces, reallocates, or redirects a request to make it fit changed source data.

Money-specific rules

Customer receipt requests allocate only to accepted order receivables or after-sales fees. Pending or approved receipt requests do not count as customer money. Only allocated settlements affect delivery and order-close rules.

Customer refund requests retain the cancellation or after-sales case and the original customer receipt on every line. Submitted refund requests reserve the refundable pool so another request cannot claim it. A failed refund attempt consumes no refundable amount.

Factory, material, packaging, and certificate requests retain their existing source identity even when combined in one request. Unknown costs cannot be requested as bill payments, but they may be represented by a separately identified advance when the approved advance rules apply. Existing inventory references do not create a new payable request.

Settlement does not change production, QC, custody, packaging movement, certificate progress, or supplier completion state. Supplier settlement continues not to block customer delivery or order closure.

Business request surfaces and Accounting workspace

The prototype uses visible responsibility labels rather than pretending to implement authentication or permissions. Business request creation and request ownership stay in the operational surfaces that own the underlying customer, supplier, certificate, or exception work. Accounting receives submitted requests and owns review and actual settlement.

订单收付款总览 is the cross-order business home for request authoring. It provides monthly unpaid-line selection, advance-request creation, and an own-request tracker for the current operator's drafts, returned requests, submitted status, source links, revision, resubmission, and withdrawal. The operator first selects a counterparty, account, direction, currency, and optional statement period, then selects eligible still-requestable lines across supported categories and orders. Lines that would mix a different counterparty, account, direction, or currency are unavailable for that request.

The contextual 客户收款, 工厂成本与付款, 石料成本与付款, 包装与付款, 证书付款, and 取消与售后 surfaces provide prefilled request actions and filtered own-request trackers for their business category and linked sources. A request saved from one of these surfaces returns to that same business surface and tracker. A monthly or advance request saved from 订单收付款总览 returns to that overview and its tracker. Saving a business request never redirects the operator to Accounting.

The top-level Accounting workspace is an accounting responsibility surface and contains five views:

1. Pending approval / 待审核 shows submitted requests only. It shows no operator drafts and offers no request-authoring, edit, revision, monthly-request, advance-request, withdrawal, or resubmission actions.
2. To settle / 待结算 shows approved and partially settled requests with a positive remaining amount.
3. Settlement history / 结算记录 separates immutable actual settlements and failed attempts from read-only returned, rejected, withdrawn, cancelled, and completed request context.
4. Advances & unmatched receipts shows settled advances, their later bill applications, unmatched incoming receipts, and their later receivable allocations.
5. Payee accounts shows existing, proposed, verified, and unusable counterparty accounts.

Request detail shows counterparty, account verification, direction, currency, target date, optional period, purpose, evidence, requester, revision history, linked records, source amount, settled amount, reserved amount, remaining request amount, review history, and settlement history. Accounting may approve, return, reject, explicitly re-review stale submitted work, cancel an approved unsettled remainder, record a failed attempt, and record or allocate actual settlements under the existing lifecycle rules. Returned requests and closed history remain visible there only as review context.

Role checks apply both when opening a modal and when submitting it. An operations actor cannot invoke an accounting review or settlement save path, and an accounting actor cannot invoke a business request authoring or resubmission save path, even if the visible responsibility changes while a modal is open.

The deterministic accounting demo-data append control belongs on 订单收付款总览 and in 试用说明, where the business exercise starts. It is not an Accounting request-authoring action and must not appear in Pending approval / 待审核 or To settle / 待结算.

Existing business surfaces no longer let product operators record actual money directly. Accounting completion remains the exclusive path that creates actual receipt, payment, refund, or service-fee settlement records.

Accounting queues and batch actions

Approval and settlement remain two separate accounting decisions. Approval confirms that a submitted business request may proceed and creates no money movement. Settlement records a transfer that has already occurred outside the prototype and creates one immutable actual settlement per request. The prototype does not initiate, combine, or confirm bank transfers.

Pending approval / 待审核 contains only submitted requests. Requests that need explicit re-review remain visible with their blocker and corrective action but cannot be selected for approval. A compatible proposed account does not block approval under the existing rules, but it remains visibly unverified and will block later settlement until Accounting verifies it. Return and reject remain single-request decisions because each requires a request-specific reason.

Accounting may select several eligible submitted requests and choose Approve selected / 批量批准. Select-all applies only to visible eligible rows under the current filters. The confirmation lists every request, counterparty, amount, account state, and any shared approval note before save. The batch rechecks Accounting responsibility, submitted status, stale-review state, account compatibility and version, and source capacity for every selected request. If any request is ineligible at the initial check, none is approved and the modal lists every blocker. Factual stale flags may latch during that check, but no approval status or approval review record is added. If an unexpected domain failure occurs after approval begins, the standalone prototype restores the selected requests' approval statuses and approval review entries so approval remains all-or-nothing. Every successful request still receives its own ordinary approval review record; there is no aggregate approval record that replaces request history.

To settle / 待结算 contains only approved or partial requests with a positive remainder. Rows that need re-review or lack a verified compatible account remain visible with the reason and corrective action, but their selection control is disabled. Single-request partial settlement, failed-attempt recording, and cancellation of an unpaid remainder remain available from request detail. Eligible rows show Mark settlement completed / 标记结算完成 directly, with request detail as a secondary action. The row action opens the existing full-remainder completion confirmation for that request without requiring a checkbox or replacing unrelated selections on open or cancel. The batch toolbar says Mark selected completed / 标记所选结算完成. Completion still requires the existing actual amount, date, verified account, per-line allocation, and real reference or other supported evidence. A completed request leaves To settle and its separate actual record appears in Settlement history.

The minimal batch settlement path records the full remaining amount for each selected request. It shows one shared actual date defaulted to today, each request's verified selected account, a payment method defaulted from that account, the full per-line remaining allocation, and separate actual evidence fields for every request. The amount and allocations are fixed to the full remainder in this batch path. An operator who needs a partial amount or different line allocation uses the existing single-request settlement action. The final confirmation states that the listed transfers have already occurred and that the prototype will create one separate settlement record for each request. It never copies one transaction reference across requests silently, and each request must independently satisfy the existing reference, attachment, or cash-acknowledgement evidence rule.

Batch settlement performs an initial save-time recheck of Accounting responsibility, request state, positive remainder, stale-review state, verified compatible account, source capacity, date, method, evidence, and full per-line allocation for every selection. If any request is initially invalid, it records no settlement and shows the blockers. After a clean preflight, it records requests sequentially in their visible selected order through the existing settlement function. Two valid requests may share one stable business source, and replacing reserved value with settled value does not by itself change that source's business version or make the later request stale. If an explicit business-source change occurs between ordinary settlement writes, such as a factory total revision, the existing source-version latch must mark the affected later request for review. If that or another domain guard stops the sequence, every already appended actual settlement and its request status remain final, processing stops, and the result names the recorded requests and every unprocessed request that now needs review or correction. The batch never rolls back actual-money history, silently confirms stale review, creates a failed-attempt record for an unprocessed request, or retries it automatically.

Settlement history / 结算记录 remains distinct from both work queues. It shows each successful batch result as its own immutable settlement with request, account, amount, evidence, and allocations, and continues to distinguish failed attempts as zero money moved. Closed or returned request context is read-only and visually separate from actual settlement records.

Changing queue, filter, or prototype responsibility removes hidden or ineligible rows from the current selection. Batch controls appear only under Accounting responsibility, and every modal rechecks responsibility when saving. When the Accounting workspace is viewed under Product operations responsibility, a visible notice explains that the queues are read-only and that approval, settlement, and account maintenance require Accounting responsibility. The notice provides an explicit Switch to Accounting responsibility / 切换至会计处理 action that changes only this page's prototype responsibility and keeps the current Accounting view. It does not represent login, permission escalation, or a production authorization bypass.

Minimal source-led request presentation

The ordinary contextual request is a small confirmation form built from the source the operator was already viewing. It must not ask the operator to select business identities that the source already establishes. The stored request remains complete, reviewable, and subject to all existing reservation, stale-review, account, and settlement rules.

The ordinary contextual path therefore asks only for the requested amount, plus an account choice when the source does not resolve one compatible usable account. Target date defaults to today and remains editable under the collapsed details. The form must not manufacture a payee, purpose, invoice, account verification, or attachment. Its primary action is 提交会计请求, with 保存草稿 as a secondary action. The primary action must behave as one guarded user operation: if field validation, source capacity, shared refund capacity, role validation, or submission fails, it must not leave a submitted request, reservation, accidental draft, partial edit, or failed revision behind. For an existing draft or returned request, failure restores the pre-action request and revision state while preserving all earlier reviews, settlements, and history.

A monthly request remains a separate cross-order flow. It asks for one direction, legal counterparty, explicit compatible account, optional statement period, target date, eligible line selection, and per-line amounts. Its factual purpose and source-reference evidence may be derived from the selected lines, and it must not add manual order, item, category, or certificate selectors.

An advance remains a separate source-less flow. It fixes direction to outgoing and currency to CNY, and asks for supplier category, legal counterparty, compatible or proposed account, amount, target date, concise purpose, and honest evidence or written explanation.

Every actionable money source has a contextual request entry point governed by the same domain rules:

The own-request tracker separates scanning from acting. Each summary row shows request status and revision, counterparty, short category and source label, order and item counts, requested, settled and remaining amounts, target date, and one 查看详情 action. Rows do not repeat edit, submit, withdraw, revise, resubmit, or other lifecycle actions. The selected full-width detail renders those actions once in a stable heading action bar and groups de-duplicated related order, item, case, and source links once below it. Table cells are top-aligned, monetary values use right-aligned tabular numerals, and the details column keeps one consistent button width. At approximately 390 pixels wide, the tracker uses stacked cards or labeled rows, keeps the details action full width, and creates no page-level horizontal overflow. Full identifiers belong in detail rather than the scanning row.

Actual settlement may use the same compact visual language, but it still requires actual amount, date, method, verified account, per-line allocation, and settlement evidence.

Prototype defaults and future integration

The approved requirement records currency on requests, advances, unmatched receipts, and settlements. The existing prototype is RMB-only, so this iteration uses RMB as its only selectable currency and performs no foreign-exchange calculation. Multi-currency and exchange-rate policy remain future product decisions.

Counterparties and account identities are local prototype records. Formal integration must later connect them to authenticated users, customer and supplier masters, verified account ownership, permissions, audit, and the production financial ledger.

The prototype records transaction references and attachments as evidence but does not contact a bank, WeChat Pay, or another payment provider. Completed means accounting recorded supported settlement evidence in the prototype, not that the prototype moved money itself.

Operator handover

The operator guide must replace direct-money instructions with request submission and accounting completion. It must explain request versus settlement, reservation versus actual balance, mixed-category monthly requests, partial settlement, account verification, returns for revision, advances, unmatched receipts, and later allocation. It must continue to distinguish customer order-level receipts from item-level supplier costs and show that only allocated customer receipts affect delivery and closure. It must direct business users to 订单收付款总览 or the relevant contextual business tracker for creation, draft work, revision, resubmission, withdrawal, and status checks. It must describe Pending approval / 待审核 and To settle / 待结算 as separate accounting-only work queues, explain that batch approval moves no money, and explain that batch settlement records separate transfers that already occurred. It must show the Product operations notice and explicit prototype-responsibility switch, the full-remainder boundary of batch settlement, the existing individual partial path, and the distinct read-only settlement and request history. It must show the source-led contextual form, explain which fields are derived, document the distinct monthly and advance forms, identify every contextual entry point including the order or item packaging panel, and show that lifecycle actions appear once in the selected request detail.

Acceptance scenarios

• Create and save a monthly or advance request from 订单收付款总览, remain on that overview, and continue the request from the current operator's own-request tracker without visiting Accounting.
• Create a contextual receipt, supplier, certificate, refund, or after-sales request, return to the originating business surface after save, and see only the relevant linked requests in its tracker.
• Open Pending approval / 待审核 and prove it contains submitted requests only, then open To settle / 待结算 and prove it contains only approved or partial requests with a positive remainder.
• Return a submitted request from Accounting, then revise and resubmit it from its business tracker while Accounting retains the returned revision as read-only history.
• Change the visible responsibility while an authoring, stale-review, or settlement modal is open and prove the save-time role guard rejects the wrong responsibility.
• Append deterministic demo data from 订单收付款总览 or 试用说明 and prove the control is absent from Accounting.
• Submit one monthly outgoing request for one counterparty and verified account containing factory, material, packaging, and certificate lines from several orders, then settle it in two transactions and preserve both allocation histories.
• Submit two operators' requests against the same obligation and prove the second cannot reserve the amount already reserved by the first.
• Return a request for an incorrect business line, revise and resubmit it, and retain the original revision and reason without accounting editing it.
• Change a linked cost or selected account after partial settlement and prove the completed settlement remains while further settlement waits for review.
• Propose a new account, approve the business request, and prove settlement remains blocked until accounting verifies the account.
• Reject, withdraw, and cancel requests and prove only unsettled reservations are released.
• Record a failed settlement attempt and prove balances and request progress do not change.
• Pay an advance before a bill exists, later apply part of it to an eligible bill, and prove no second money movement is created.
• Record an unmatched customer receipt, later allocate it across eligible receivables, and prove no order is treated as paid before allocation.
• Submit and settle a refund tied to its case and original receipt, and prove its open request reservation prevents another refund request from exceeding the refundable pool.
• Complete a customer receipt request and prove only its allocated settlement, never submission or approval, can satisfy delivery or close conditions.
• Open every customer receipt, factory, material, packaging, certificate, refund, and after-sales source entry and prove its request action carries the correct source, party, order, item, category, case, receipt, cost, or certificate identity without manual identity selectors.
• Open the order or item packaging panel for a known purchased cost and create a contextual request; for a pending cost, confirm or revise the cost before requesting; for stock, see the original-ledger explanation and no new payable action.
• Open an ordinary contextual request and see only amount and a conditional compatible-account choice before the collapsed optional details, with today's date, a factual purpose, and a truthful linked business-source reference supplied from the source.
• Use the primary 提交会计请求 action without a save-find-submit detour, use the secondary 保存草稿 action when needed, and prove an over-reserved source or exhausted shared refund pool leaves no submitted request, reservation, accidental draft, partial edit, or failed revision.
• Edit a draft or returned request and prove collapsed advanced purpose, evidence, explanation, and proposed-account values are preserved.
• Create a monthly request with its line picker and a source-less advance with its required purpose and honest support, without turning either flow into a generic manual source selector.
• Scan the own-request tracker at desktop and narrow widths and prove each row has one details action, lifecycle actions appear once in the selected detail action bar, amounts align consistently, and the page does not overflow horizontally.
• View Accounting under Product operations responsibility and use the visible explanation and explicit switch action to enter Accounting responsibility without changing the current queue or any financial data.
• Select several eligible submitted requests, approve them together, and prove every request receives its own approval record while approval changes no settlement or money balance.
• Include one stale or otherwise ineligible submitted request in batch approval and prove none is approved, every blocker is shown, and factual stale state remains visible for explicit re-review.
• Select several settlement-ready requests, confirm the full remaining amount and allocation for each, provide separate actual evidence, and prove the batch creates one immutable settlement record per request rather than one combined transfer.
• Force an initial settlement blocker and prove the batch records no money; then prove two valid requests against a stable shared business source both settle without false staleness.
• In a controlled test, revise the business source between the first and second ordinary settlement writes and prove the first settlement remains final while the later request is reported for explicit review and receives no automatic review or failed-attempt record.
• Use the individual settlement action for a partial amount and prove the request remains in To settle / 待结算 with its reduced remainder.
• Open Settlement history / 结算记录 and prove actual settlements, failed attempts, and read-only closed or returned request context remain visibly distinct.

Customer collection eligibility

New order collections require an active order and explicit acceptance of its current numeric quote, consistently across contextual requests, monthly requests, unmatched-receipt applications, and settlement save-time validation. Termination, closure, or a newer unaccepted quote blocks further order collections and latches explicit re-review for submitted, approved, or partially settled requests with remaining order-collection lines. Re-review cannot override ineligibility; eligibility must first be restored and accounting must explicitly confirm the review before settlement resumes. Historical obligations, actuals, applications, revision snapshots, and fully settled lines remain intact; refunds and separately established after-sales fees retain their existing rules.