feat(opportunity): the 立项 gate leaves Will Bid open — it holds only a stage change and a new won/lost request (#2004)

.changeset/1995-qualification-approval-gate.md

@@ -3,9 +3,10 @@
 ---
 
 An opportunity can now require **qualification approval (立项)** before it is committed:
-until the deal is approved, its stage cannot move, *Will Bid* cannot be recorded, and it
-can be neither closed won/lost nor asked to be. Everything else stays open, so a new deal
-can still be worked while it waits. **The gate ships off** (REQ-0006 step 11:
+until the deal is approved, its stage cannot move, and it can be neither closed won/lost
+nor asked to be. Everything else stays open, *Will Bid* included, so a new deal can still
+be worked, and its bid intent recorded for the approver, while it waits. **The gate ships
+off** (REQ-0006 step 11:
 「销售立项需走审批流程；新增商机可跟进，立项通过后方可更新阶段、投标、赢丢单操作。」).
 
 **How it works, once armed.** The rep ticks *Request Qualification Approval* in the deal's
@@ -19,8 +20,8 @@ is the customer's own 「新增商机可跟进」.
 
 **Off by default, bit for bit.** The switch is the field default on *Qualification
 Approval*, shipped as *Not Required*: no deal is ever born pending, the new flow
-(*Opportunity Qualification Approval*) opens nothing, and moving the stage, *Will Bid* and
-closing behave exactly as before. An install arms the gate by changing that one default
+(*Opportunity Qualification Approval*) opens nothing, and moving the stage and closing
+behave exactly as before. An install arms the gate by changing that one default
 to *Pending*; deals that already exist keep *Not Required*.
 
 **With the status-change gate armed too, qualification comes first.** A deal that is not

.changeset/2004-will-bid-before-qualification.md

@@ -0,0 +1,19 @@
+---
+'hotcrm': patch
+---
+
+Qualification approval (立项) leaves *Will Bid* open
+
+While a deal waits for qualification approval, or after an approver rejects it, the rep can
+now record and change *Will Bid*. Whether you intend to bid is part of what the approver
+decides on: REQ-0006 step 8 has the rep fill 是否投标 as input to 立项, so holding it until
+approval had the approver decide without it. Step 11's 投标 is the act of bidding, which
+HotCRM does not model.
+
+The gate still holds the two acts that commit the deal: moving its stage (which includes
+closing it directly), and asking for won or lost with *Requested Status*. Both are refused
+`409 RECORD_LOCKED` until the deal is approved, and the refusal sentence now names only what
+was held. The gate still ships off; nothing changes for an install that has not armed it.
+
+This narrows the qualification-approval gate that ships in this same release; its entry
+above now describes the gate as it ships.

content/docs/administration/automation.mdx

@@ -70,7 +70,7 @@ A flow fires one of three ways, set by its start node:
 | **Large Deal Approval** | Record change (update) | Tiered sign-off via approval nodes — Sales Manager ≥ $100K, Sales Director > $500K |
 | **Large Deal Approval (on create)** | Record change (insert) | The same intake for opportunities *created* at or above the threshold |
 | **Opportunity Status Change Approval** | Record change (update) | Sign-off a deal needs before it is declared won or lost. Ships switched OFF — it opens nothing until an install arms the gate on the opportunity's **Status Change Approval** field; armed, the rep sets **Requested Status** and the stage moves only when the request is approved |
-| **Opportunity Qualification Approval** | Record change (update) | The qualification (立项) sign-off a new deal needs before its stage, its bid decision or its won/lost call may change. Ships switched OFF — it opens nothing until an install arms the gate on the opportunity's **Qualification Approval** field; armed, the rep ticks **Request Qualification Approval**, and everything else on the deal stays editable while it waits |
+| **Opportunity Qualification Approval** | Record change (update) | The qualification (立项) sign-off a new deal needs before its stage or its won/lost call may change. Ships switched OFF — it opens nothing until an install arms the gate on the opportunity's **Qualification Approval** field; armed, the rep ticks **Request Qualification Approval**, and everything else on the deal stays editable while it waits |
 | **Lead Conversion Approval** | Record change (insert) | Sign-off a lead needs before it can be converted. Ships switched OFF — it opens nothing until an install arms the gate on the lead's **Conversion Approval** field |
 | **Account Approval** | Record change (insert) | Sign-off a newly created account needs before it counts as established data. Ships switched **ON** — a new account starts *Pending* and is decided in the approval inbox; an install that wants no account sign-off changes the default on the account's **Approval Status** field |
 | **Large Deal Won Alert** | Record change (update) | When an opportunity of $100K or more turns *Closed Won*, notify the owner — the owner alone, not their manager |
@@ -111,7 +111,7 @@ Since ObjectStack 7.4, approvals are modeled as **`approval` nodes inside a flow
 
 HotCRM's built-in **Opportunity Approval** flow chains two approval nodes for tiered sign-off (manager → director). See [Revenue › Approvals](/docs/revenue/approvals) for thresholds, what approvers see, and the audit trail.
 
-A second, independent gate — **Opportunity Status Change Approval** — asks for sign-off before a deal is declared won or lost. It ships switched off and keeps its verdict in its own field, so arming it never changes the amount-based sign-off. A third, **Opportunity Qualification Approval**, is the qualification (立项) sign-off a new deal needs before its stage, bid decision or won/lost call may change; it too ships off, and with both armed it comes first. See [Sales › Opportunity Qualification](/docs/sales/opportunity-qualification).
+A second, independent gate — **Opportunity Status Change Approval** — asks for sign-off before a deal is declared won or lost. It ships switched off and keeps its verdict in its own field, so arming it never changes the amount-based sign-off. A third, **Opportunity Qualification Approval**, is the qualification (立项) sign-off a new deal needs before its stage or won/lost call may change; it too ships off, and with both armed it comes first. See [Sales › Opportunity Qualification](/docs/sales/opportunity-qualification).
 
 ## Order of operations
 

content/docs/administration/automation.zh-Hans.mdx

@@ -70,7 +70,7 @@ description: 验证规则、流程、计划作业与审批 —— 无需你动
 | **大额商机审批** | 记录变更（更新） | 通过 approval 节点分级签核 —— 销售经理 ≥ $100K，销售总监 > $500K |
 | **大额商机审批（新建时）** | 记录变更（插入） | 同一套受理逻辑，用于*创建时*金额已达到阈值的商机 |
 | **商机状态变更审批** | 记录变更（更新） | 商机宣布赢单或丢单之前需要的签核。出厂默认是**关闭**的：在商机的**状态变更审批**字段上打开闸门之前，它不会发起任何审批；打开之后，销售填写**申请变更状态**，请求获批后阶段才会变更 |
-| **商机立项审批** | 记录变更（更新） | 新建商机在更新阶段、决定是否投标或赢丢单之前需要的立项签核。出厂默认是**关闭**的：在商机的**立项审批**字段上打开闸门之前，它不会发起任何审批；打开之后，销售勾选**申请立项审批**，等待审批期间商机的其他内容照常可以编辑 |
+| **商机立项审批** | 记录变更（更新） | 新建商机在更新阶段或赢丢单之前需要的立项签核。出厂默认是**关闭**的：在商机的**立项审批**字段上打开闸门之前，它不会发起任何审批；打开之后，销售勾选**申请立项审批**，等待审批期间商机的其他内容照常可以编辑 |
 | **线索转化审批** | 记录变更（插入） | 线索转化前需要的签核。出厂默认是**关闭**的：在线索的**转化审批**字段上打开闸门之前，它不会发起任何审批 |
 | **客户审批** | 记录变更（插入） | 新建客户在成为正式数据之前需要的签核。出厂默认是**打开**的：新客户以**待审批**状态创建，并在审批收件箱中裁定；不需要客户签核的安装，改掉客户**审批状态**字段的默认值即可 |
 | **大额商机赢单提醒** | 记录变更（更新） | 金额 $100K 及以上的商机转为 *Closed Won* 时，通知负责人 —— 只通知负责人本人，不通知其经理 |
@@ -111,7 +111,7 @@ description: 验证规则、流程、计划作业与审批 —— 无需你动
 
 HotCRM 内置的 **商机审批** 流程串联两个 approval 节点实现分级签核（经理 → 总监）。关于阈值、审批人所见以及审计轨迹，参见 [营收云 › 审批](/zh-Hans/docs/revenue/approvals)。
 
-另有一道独立的闸门 —— **商机状态变更审批** —— 在商机宣布赢单或丢单之前要求签核。它出厂默认关闭，并把结论记在自己的字段里，因此打开它不会改变按金额分级的签核。第三道 —— **商机立项审批** —— 是新建商机在更新阶段、决定是否投标或赢丢单之前需要的立项签核；它同样出厂关闭，两道都打开时它排在前面。参见[销售云 › 商机资格评估](/zh-Hans/docs/sales/opportunity-qualification)。
+另有一道独立的闸门 —— **商机状态变更审批** —— 在商机宣布赢单或丢单之前要求签核。它出厂默认关闭，并把结论记在自己的字段里，因此打开它不会改变按金额分级的签核。第三道 —— **商机立项审批** —— 是新建商机在更新阶段或赢丢单之前需要的立项签核；它同样出厂关闭，两道都打开时它排在前面。参见[销售云 › 商机资格评估](/zh-Hans/docs/sales/opportunity-qualification)。
 
 ## 操作顺序
 

content/docs/administration/automation.zh-Hant.mdx

@@ -72,7 +72,7 @@ description: 驗證規則、流程、排程作業與審批 —— 無需你動
 | **大額商機審批** | 記錄變更（更新） | 透過 approval 節點分級簽核 —— 銷售經理 ≥ $100K，銷售總監 > $500K |
 | **大額商機審批（新建時）** | 記錄變更（插入） | 同一套受理邏輯，用於*建立時*金額已達到閾值的商機 |
 | **商機狀態變更審批** | 記錄變更（更新） | 商機宣布贏單或丟單之前需要的簽核。出廠預設是**關閉**的：在商機的**狀態變更審批**欄位上打開閘門之前，它不會發起任何審批；打開之後，銷售填寫**申請變更狀態**，請求獲批後階段才會變更 |
-| **商機立項審批** | 記錄變更（更新） | 新建商機在更新階段、決定是否投標或贏丟單之前需要的立項簽核。出廠預設是**關閉**的：在商機的**立項審批**欄位上打開閘門之前，它不會發起任何審批；打開之後，銷售勾選**申請立項審批**，等待審批期間商機的其他內容照常可以編輯 |
+| **商機立項審批** | 記錄變更（更新） | 新建商機在更新階段或贏丟單之前需要的立項簽核。出廠預設是**關閉**的：在商機的**立項審批**欄位上打開閘門之前，它不會發起任何審批；打開之後，銷售勾選**申請立項審批**，等待審批期間商機的其他內容照常可以編輯 |
 | **線索轉化審批** | 記錄變更（插入） | 線索轉化前需要的簽核。出廠預設是**關閉**的：在線索的**轉化審批**欄位上打開閘門之前，它不會發起任何審批 |
 | **客戶審批** | 記錄變更（插入） | 新建客戶在成為正式資料之前需要的簽核。出廠預設是**打開**的：新客戶以**待審批**狀態建立，並在審批收件匣中裁定；不需要客戶簽核的安裝，改掉客戶**審批狀態**欄位的預設值即可 |
 | **大額商機贏單提醒** | 記錄變更（更新） | 金額 $100K 及以上的商機轉為 *Closed Won* 時，通知負責人 —— 只通知負責人本人，不通知其經理 |
@@ -113,7 +113,7 @@ description: 驗證規則、流程、排程作業與審批 —— 無需你動
 
 HotCRM 內建的 **商機審批** 流程串聯兩個 approval 節點實作分級簽核（經理 → 總監）。關於閾值、審批人所見以及稽核軌跡，參見 [營收雲 › 審批](/zh-Hant/docs/revenue/approvals)。
 
-另有一道獨立的閘門 —— **商機狀態變更審批** —— 在商機宣布贏單或丟單之前要求簽核。它出廠預設關閉，並把結論記在自己的欄位裡，因此打開它不會改變按金額分級的簽核。第三道 —— **商機立項審批** —— 是新建商機在更新階段、決定是否投標或贏丟單之前需要的立項簽核；它同樣出廠關閉，兩道都打開時它排在前面。參見[銷售雲 › 商機資格評估](/zh-Hant/docs/sales/opportunity-qualification)。
+另有一道獨立的閘門 —— **商機狀態變更審批** —— 在商機宣布贏單或丟單之前要求簽核。它出廠預設關閉，並把結論記在自己的欄位裡，因此打開它不會改變按金額分級的簽核。第三道 —— **商機立項審批** —— 是新建商機在更新階段或贏丟單之前需要的立項簽核；它同樣出廠關閉，兩道都打開時它排在前面。參見[銷售雲 › 商機資格評估](/zh-Hant/docs/sales/opportunity-qualification)。
 
 ## 操作順序
 

content/docs/sales/opportunity-qualification.mdx

@@ -10,7 +10,7 @@ An opportunity already says what the deal is worth and where it stands in *your*
 - **Qualification** — should we pursue this deal at all, and how hard?
 - **The customer's calendar** — when the buyer plans to start, tender and sign, and for how much.
 - **Deal Narrative** — the written case for the deal, in parts a reviewer can read one at a time.
-- **Qualification Approval** — whether a new deal has to be approved (立项) before its stage, its bid decision or its won/lost call may change. **Off unless your admin turns it on.**
+- **Qualification Approval** — whether a new deal has to be approved (立项) before its stage or its won/lost call may change. **Off unless your admin turns it on.**
 - **Status Change Approval** — whether somebody has to sign off before a deal is declared won or lost. **Off unless your admin turns it on.**
 
 All of it sits on the opportunity's **Details** tab, in the **Qualification**, **Sales Process** and **Deal Narrative** sections.
@@ -53,24 +53,24 @@ Attachments still go on the record's files, as they always have.
 
 ## Qualification approval
 
-Some organisations approve a deal as a project — 立项 — before anyone commits to it. Until that approval, a new deal can be **worked**: log calls and meetings, write the narrative, record the customer's calendar and the amount. What waits is **committing** it: moving its stage, recording **Will Bid**, and the won/lost call — whether that is closing it directly or asking for it with **Requested Status**. The **Qualification Approval** field records where that stands:
+Some organisations approve a deal as a project — 立项 — before anyone commits to it. Until that approval, a new deal can be **worked**: log calls and meetings, write the narrative, record the customer's calendar, the amount and **Will Bid**. What waits is **committing** it: moving its stage and the won/lost call — whether that is closing it directly or asking for it with **Requested Status**. **Will Bid** stays open on purpose: whether you intend to bid is part of what the approver decides on, so record it before you ask. The **Qualification Approval** field records where that stands:
 
 | Qualification Approval | What it means |
 | --- | --- |
 | **Not Required** | No qualification approval is asked for. This is how HotCRM ships, and it is what every deal shows unless your admin has turned the gate on. |
 | **Pending** | The gate is on for this deal and it has not been approved yet. |
-| **Approved** | The deal is qualified. Its stage, Will Bid and won/lost call are open from now on. |
+| **Approved** | The deal is qualified. Its stage and won/lost call are open from now on. |
 | **Rejected** | The approver said no to the last request. The deal stays held. |
 
 You never set this field yourself — it is filled in by the approval, and it is read-only.
 
-**While a deal is Pending or Rejected, its stage, Will Bid and Requested Status cannot change.** To have it approved:
+**While a deal is Pending or Rejected, its stage and Requested Status cannot change.** To have it approved:
 
 1. Tick **Request Qualification Approval** in the deal's **Qualification** section.
-2. An approval request opens in the approval inbox. The deal is **not** locked while it waits: everything other than those three stays editable, so keep working it.
+2. An approval request opens in the approval inbox. The deal is **not** locked while it waits: everything other than those two stays editable, so keep working it.
 3. If it is approved, the deal is qualified for good. If it is rejected, the box is unticked and the deal stays held — tick it again when something changes to ask again.
 
-> **Nothing changes for you unless your admin arms the gate.** Out of the box every deal reads *Not Required*, and moving the stage, Will Bid and closing work exactly as they always have. Deals created before the gate was turned on are never held by it.
+> **Nothing changes for you unless your admin arms the gate.** Out of the box every deal reads *Not Required*, and moving the stage and closing work exactly as they always have. Deals created before the gate was turned on are never held by it.
 
 **When both approvals are on, qualification comes first.** A deal that is not yet qualified cannot ask for a status change either; once it is approved, closing works as the next section describes.
 
@@ -100,8 +100,8 @@ You never set this field yourself — it is filled in by the approval, and it is
 - ✅ Fill in **Will Bid** as soon as you have decided, and leave it empty until then. A pipeline review reads the empty ones as the decisions still to make.
 - ✅ Record the customer's tender date the day you hear it. It is the date your bid team plans against, and **Tender This Quarter** can only list the deals that carry one.
 - ✅ If closing is refused, look at **Status Change Approval** before asking anyone: *Pending* means set **Requested Status** instead, *Rejected* is a decision to talk about.
-- ✅ Fill in the narrative and the customer's calendar before you request qualification approval. They are what the approver reads.
-- ✅ If a stage move or **Will Bid** is refused, look at **Qualification Approval**: *Pending* means tick **Request Qualification Approval** (or wait for the request already open), *Rejected* is a decision to talk about.
+- ✅ Fill in the narrative, the customer's calendar and **Will Bid** before you request qualification approval. They are what the approver reads.
+- ✅ If a stage move is refused, look at **Qualification Approval**: *Pending* means tick **Request Qualification Approval** (or wait for the request already open), *Rejected* is a decision to talk about.
 - ⛔ Don't move **Close Date** to match the tender date. The two are different events, and the forecast depends on the close date being yours.
 
 ## Tips for admins