Product certificate prototype design

Status: design approved in the 2026-10-13 discussion, including default completion before delivery and an explicit customer-agreed later-certificate exception.

Scope

Extend the standalone in-memory prototype at docs/product-reference/workflow-discussion/product-workspace-design-option.html and its operator documentation. This does not add production routes, persistence, migrations, institution integrations, bank transfers, or automatic messages. Refresh continues to clear prototype data.

Requirement and actual work

Each item has one optional current finished-product certificate requirement: 普通证书, IGI 证书, or 國檢证书. An empty choice means no requirement recorded and creates no payable. This is distinct from a main stone's existing certificate details. Initial multi-item creation gives each item an independent copy of the requirement. Operators may add, change, or remove the requirement at any stage, retaining the changes in history. Changing a requirement does not rewrite an actual submission, custody, receipt, cost, or payment. Show an explicit mismatch when an existing job does not satisfy the current requirement.

Workflow and custody

The normal workflow is 待提交 → 已提交 → 可取回 → 已取回. Pending submission explains whether manufacturing, warehouse return, or final QC still blocks submission. Submission requires all manufacturing routes complete, current final QC passed, the product physically in-house, and no other active institution job for that item. The job snapshots the submitted certificate type; no institution name is entered. Submitted and ready-for-pickup jobs mean the product remains with the institution unless a separate actual return has been recorded. Neither a ready notification nor a payment returns the product to the warehouse. Normal pickup confirms actual product return and certificate checking, with date, evidence, and a certificate number for each selected item. Physical institution custody blocks customer dispatch and another factory or institution handover.

Keep physical return and certificate fulfillment distinct for the approved later-certificate exception. A separately recorded actual product return without the certificate must not falsely complete certificate work. The unresolved certificate remains visible after product delivery and order closure. An exception records customer agreement, the outstanding certificate requirement, agreement date, operator, and evidence or follow-up arrangement. Changing the requirement must not silently reuse agreement for a different requirement. Default customer delivery requires the current required certificate to be collected. Recorded customer agreement may waive that certificate-completion gate, but never the physical-return gate or existing quote, final-QC, and customer-payment gates. Institution unpaid balances do not themselves block delivery or customer order closure.

Cross-order batches and receipts

A dispatch batch can contain multiple items from multiple customer orders, all sharing one certificate type. Validate every selected item before mutating any item so an invalid selection cannot partially submit a batch. Preserve per-item job identity and submitted type, plus shared batch reference, actual date, and handover evidence. Generate the batch name from certificate type, dispatch date, and a unique batch sequence. Progress is per item; a batch displays counts rather than forcing all items through one state together.

Select submitted items covered by an institution receipt and open a popup. Show customer, order, item, and certificate type on the left, with a right-aligned numeric certificate-cost input for each item on the right. Record receipt reference, date, optional image, and a sum of known row costs. Blank cost remains unknown; explicit zero means confirmed zero cost. The receipt form automatically includes every submitted item in the batch, with enabled cost inputs and no row-selection checkboxes. Saving marks all those items ready for pickup and creates their own cost records without creating payment. Already receipted items are excluded so their original costs remain intact. Receipt handling must not create duplicate charges when repeated; already-recorded costs use explicit revision with retained history. Pickup also supports a selected subset, leaving all other item states intact.

Money

Certificate cost belongs to each actual certificate job, not to the current requirement or the whole dispatch batch. Use the prototype's existing minor-unit money conventions and per-row allocations. Preserve cost versions and all payment allocations when requirements change, orders cancel, or costs are revised. A lower revised cost can expose overpayment; it does not manufacture refunds or offset another item's debt. Same-type certificate items may be paid together across orders and dispatch batches. Reject duplicate allocations, mixed certificate types, unknown-cost payment, non-positive allocations, and amounts above each item's outstanding balance. Certificate payments remain separate from factory, stone, and packaging payments even when names match.

Surfaces

No requirement/history, requirement without a bill, and actual work with unknown cost must display distinctly. Historical unpaid jobs remain visible even after requirement deletion or cancellation. Cancelled orders cannot begin new institution work; already-sent products can still return and their bills remain actionable.

Operator documentation

Update the request field table, navigation map, final-QC/delivery narrative, overview, and four-to-five payment-track explanation. Add a certificate procedure with batch dispatch, per-item receipt costs, whole-batch readiness, partial pickup, separate payment, and the customer-agreement exception. Update the current guide’s embedded Mermaid workflow; legacy diagrams remain explicitly historical. Include operator exercises for blocked early submission, three certificate types, cross-order batches, partial progress, costs versus payments, changed requirements, cancellation, and institution custody.

Validation expectations

Extend the standalone Node test suite with state guards and money invariants before implementing the behavior. Exercise the real HTML in a browser, including the right-aligned row inputs and partial-batch workflow. Check the readable operator guide against actual button labels and tested behavior. Do not claim successful production integration from standalone prototype verification.