L2C V2 · State model

L2C 核心实体状态机

按生命状态、分配状态、业务阶段、审批状态和派生状态拆分核心对象迁移。

版本 2026-08-19 · V2 权威来源 L2C 业务流程图 归档方式 本地 Markdown 转换

来源与优先级

本文由本地 V2 业务建模材料转换为站内 HTML。流程、审批、角色和跨域事件以 L2C 业务流程图为准；未决内容在确认前不得固化为实现约束。T79 继续作为 Object Workbench / Ontology 架构基线，两者回答的问题不同。

本文是核心实体状态与迁移的独立确认板块。权威口径以《L2C业务流程图.html》及 2026-08-19 最终业务确认规则为准；2026-08-18 状态调研仅补充 HTML 未定义的状态语义。调研与当前基线冲突时保留当前基线，并将未决细节列入“集中待确认项”，确认前不得固化为数据库枚举、审批流或接口契约。

状态按维度拆分。生命状态、分配/跟进状态、业务阶段、审批状态和派生统计状态不得共用一个字段。

一、资料与口径

编号	资料	采用范围	位置
S1	《L2C业务流程图.html》	权威流程、审批、角色、跨域事件	阶段一至九、第四节、第八部分待办及附录 A 已确认规则
S2	钉钉听记《08-18 业务流程与状态管理讨论》（原始链接仅保留在私有归档）	状态语义、当前系统操作和回收规则调研	“线索状态管理”至“开票与回款管理”；逐字稿 00:36-08:29 覆盖线索及联系人讨论
S3	`《状态机调研手工记录》（源目录外本地材料，未归档）`	状态枚举复核	线索第 5-24 行；联系人第 29-35 行；客户第 37-58 行；商机第 62-78 行；订单/开票第 81-103 行
S4	《L2C业务字段确认表.xlsx》	字段是否存在及字段命名参考	各实体工作表；不替代 S1 的流程权威性

1.1 状态维度定义

维度	含义	示例
生命状态	对象是否可作为有效业务记录使用	未生效、正常、作废
分配/跟进状态	对象当前由谁处理、处理到哪一步	未分配、待处理、跟进中
业务阶段	销售或履约进程中的当前位置	需求&方案、招投标、商务谈判
业务结果	一段业务进程的宏观结果	进行中、赢单、输单、无效
审批状态	某次审批实例的执行结果	审批中、通过、驳回
派生统计状态	由关联事实计算，不允许人工直接改写	成交状态、开票状态、合同归档状态

1.2 通用规则

“作废”是不可逆逻辑删除：普通用户不可见，仅管理员可查，不允许恢复。非测试数据原则上不作废，优先保留历史并采用业务终止或金额置零等方式处理。出处：S2“关键决策与共识”。
审批驳回不是业务终态。驳回后回到可修改状态，修改后重新提交；审批记录保留，不覆盖原审批实例。出处：S1 阶段四至九各审批流；S2“报价与合同管理”。
已审批对象发生变更时必须保留审批和变更审计。订单审批已确认按“商机 → 最新有效报价（last）→ 订单”回溯校验；其他对象如何生成业务版本或审批实例按实体分别确认。出处：S1 阶段五、阶段八；S2“字段与系统优化建议”。
AI 识别、金额校验、查重和异常提示是动作或守卫条件，不是业务状态。出处：S1 阶段二、三、六。

二、线索

2.1 生命状态

状态	含义	可执行动作
未生效	创建过程中保存的草稿	编辑、提交保存、放弃草稿
正常	创建完成，可分配、跟进、转化	分配、跟进、转客户/联系人、作废
作废	不再使用的逻辑删除记录	仅管理员查询

stateDiagram-v2
    direction LR
    state "未生效（草稿）" as Draft
    state "正常" as Active
    state "作废" as Voided
    [*] --> Draft: 开始创建
    Draft --> Active: 保存完成
    Draft --> [*]: 放弃草稿
    Active --> Voided: 销管执行作废
    Voided --> [*]

变更中不作为当前生命状态。线索转客户/联系人期间是否需要独立审批状态，S2 与 S3 表述不完全一致，列入 SM-01。出处：S2“线索状态管理”；S3 第 5-10 行。

2.2 分配/跟进状态

状态	含义	进入条件	离开条件
未分配	无当前负责人，等待分配	市场线索入池、主动退回、超时回收	销管分配负责人
待处理	已分配，尚未开始首次跟进	分配负责人并记录领取时间	销售主动开始跟进；或超时回收
跟进中	销售已开始跟进	录入首次有效跟进记录	转化、判无效、超时回收
已转换	已成功转为客户；可同时创建联系人/商机	转客户流程成功	终态
无效	销售反馈无效并填写原因	无效原因完整	终态

stateDiagram-v2
    direction LR
    state "未分配" as Unassigned
    state "待处理" as Pending
    state "跟进中" as Following
    state "已转换" as Converted
    state "无效" as Invalid
    [*] --> Unassigned: 市场线索进入部门线索池
    [*] --> Pending: 销售自建进入销售拓展池且归属本人
    Unassigned --> Pending: 销管分配负责人
    Pending --> Following: 录入首次有效跟进记录
    Pending --> Unassigned: 超过首次跟进时限，回收
    Following --> Unassigned: 超过持续跟进保有期，回收
    Following --> Converted: 转客户成功
    Pending --> Invalid: 反馈无效并填写原因
    Following --> Invalid: 反馈无效并填写原因
    Converted --> [*]
    Invalid --> [*]

部门线索池与销售拓展池分别管理、参数可独立配置：部门线索池保有期当前为 14 天，销售拓展池可以不限期；当前持续跟进判断统一按可配置的 14 天执行。回收后的池位置统一为“回收线索池”，状态重置为“未分配”；再次分配后进入“待处理”。出处：S1 阶段一、阶段二；S2“线索池管理”；S3 第 15-24 行。

2.3 迁移与非法迁移

当前状态	事件	触发条件	目标状态	业务动作
未分配	`LeadAssigned`	负责人有效	待处理	记录负责人、分配时间和来源池
待处理	`LeadFollowStarted`	首次跟进记录有效	跟进中	记录首次跟进时间
待处理	`LeadReclaimed`	分配后超过可配置时限；当前暂定 24H	未分配	清空负责人，进入回收线索池
跟进中	`LeadReclaimed`	超过可配置持续跟进保有期无有效新记录；当前为 14 天	未分配	清空负责人，进入回收线索池
待处理/跟进中	`LeadInvalidated`	主动选择无效原因	无效	保存无效原因，进入无效线索池
跟进中	`LeadConverted`	转客户流程成功	已转换	记录目标客户、联系人及可选商机 ID

非法迁移	原因
未分配 -> 跟进中	必须先完成负责人分配；销售自建也应生成一次待处理事实
已转换/无效 -> 任一处理中状态	两者为跟进终态，恢复能力未定义
作废 -> 正常	作废不可恢复
AI 判定“跟进无效”直接 -> 无效	AI 只提示异常，业务无效需销售/销管确认

AI 的无效标记仅作为销管核验信号，不自动改变线索状态；销管根据异常汇总人工决定调出、干预或保留。

三、联系人

3.1 生命状态

状态	含义
未生效	手工录入未完成，或 AI 识别后等待人工确认的草稿
正常	查重通过并提交完成
作废	手工作废后的逻辑删除记录

stateDiagram-v2
    direction LR
    state "未生效（草稿）" as Draft
    state "正常" as Active
    state "作废" as Voided
    [*] --> Draft: 手工创建或 AI 生成草稿
    Draft --> Active: 查重通过且人工提交
    Draft --> Active: 命中已有联系人并建立关联/补齐信息
    Draft --> [*]: 放弃草稿
    Active --> Active: 直接修改信息
    Active --> Voided: 手动作废
    Voided --> [*]

审核中和变更中当前不启用；联系人修改无需审批。在职状态由用户维护，是属性枚举，不参与生命状态迁移。出处：S1 阶段三；S2“联系人状态管理”；S3 第 29-35 行。

非法迁移	原因
正常 -> 审核中/变更中	当前未启用联系人审批和变更审批
作废 -> 正常	作废不可恢复
AI 草稿 -> 正常且无人确认	HTML 要求 AI 草稿必须人工确认后提交

查重命中已有联系人时，不创建重复记录；销售可关联已有联系人并补充其缺失信息。

四、客户

4.1 生命状态

状态	含义
未生效	草稿，或创建审批驳回后等待修改
审批中	创建审批正在执行
正常	创建审批通过并生效
变更中	已生效客户修改或作废申请正在审批
作废	作废审批通过后的逻辑删除记录

stateDiagram-v2
    direction LR
    state "未生效" as Draft
    state "审批中" as Creating
    state "正常" as Active
    state "变更中" as Changing
    state "作废" as Voided
    [*] --> Draft: 新建客户
    Draft --> Creating: 提交创建审批
    Creating --> Active: 审批通过
    Creating --> Draft: 审批驳回
    Active --> Changing: 修改任一内容或申请作废
    Changing --> Active: 变更通过或驳回后撤销变更
    Changing --> Voided: 作废审批通过
    Voided --> [*]

销管运营免审批特例允许“未生效 -> 正常”；是否同样免除变更/作废审批需在 SM-03 确认。出处：S1 阶段四“客户创建审批流”；S2“客户状态管理”；S3 第 37-43 行。

4.2 成交状态（系统派生）

状态	计算语义
未成交	无满足成交规则的有效交易事实
已成交	恰有一次满足成交规则的有效交易事实
多次成交	有两次及以上满足成交规则的有效交易事实

stateDiagram-v2
    direction LR
    state "未成交" as NotDealt
    state "已成交" as Dealt
    state "多次成交" as MultiDealt
    [*] --> NotDealt
    NotDealt --> Dealt: 首次成交事实生效
    Dealt --> MultiDealt: 再次成交事实生效

该字段只读，由订单金额、赢单或回款等交易事实计算，具体算法见 SM-04。出处：S2“客户状态管理”；S3 第 45-48 行。

4.3 分配状态

stateDiagram-v2
    direction LR
    state "未分配" as Unassigned
    state "已分配" as Assigned
    [*] --> Assigned: 首次分配对象成为客户责任人
    Assigned --> Unassigned: 回收至事业部公海
    Unassigned --> Assigned: 从公海领取或销管分配
    Assigned --> Assigned: 转移客户责任人并保留历史

客户同一时点仅有一个责任人：首次分配对象成为责任人，责任人表示业务归属而非领导层级。责任人可组建客户团队，并为成员配置业务角色、读写/只读权限及线索、商机、订单等关联对象可见范围；成员加入不改变客户分配状态。旧“上位负责人”仅表示历史前责任人。30 天无销售记录自动回收至创建人所属事业部公海；销管可调入全公司公共公海。出处：S1 阶段四/C-25；S2“客户状态管理”第 53-59 行。

现行 V2 权威口径：流程图正文与附录 A 要求先提醒，提醒后仍无有效跟进才进入单独调出流程；“30 天自动回收至事业部公海”是派生材料中的冲突表述，不得作为实现规则，目标池也需另行确认。

非法迁移	原因
审批中 -> 变更中	创建审批未完成，不存在生效后变更
正常 -> 作废	作废必须经过变更/作废审批
作废 -> 正常	作废不可恢复
人工修改成交状态	成交状态是系统派生字段
团队成员加入导致责任人变化	团队成员是授权关系，不是客户责任人；责任转移必须单独执行并留痕

五、商机

5.1 生命状态

stateDiagram-v2
    direction LR
    state "未生效" as Draft
    state "审批中" as Creating
    state "正常" as Active
    state "变更中" as Changing
    state "作废" as Voided
    [*] --> Draft: 新建或审批驳回
    Draft --> Creating: 提交创建审批
    Creating --> Active: 审批通过
    Creating --> Draft: 审批驳回
    Active --> Changing: 已有关联后修改关键交易信息
    Changing --> Active: 变更审批通过或驳回
    Active --> Voided: 管理员作废测试/错误数据
    Voided --> [*]

无后续关联时可直接修改并保持“正常”；已有报价等后续关联时，关键交易信息修改进入“变更中”。正常业务原则上不作废，通常以金额置零保留历史。出处：S1 阶段五“商机变更规则”、C-07；S2“商机状态管理”；S3 第 64-69 行。

5.2 阶段状态（宏观结果）

stateDiagram-v2
    direction LR
    state "进行中" as InProgress
    state "赢单" as Won
    state "输单" as Lost
    state "无效" as Invalid
    [*] --> InProgress: 创建审批通过
    InProgress --> Won: 赢单审批通过
    InProgress --> Lost: 输单审批通过
    InProgress --> Invalid: 无效审批通过
    InProgress --> Lost: 销管管理员直接调整
    InProgress --> Invalid: 销管管理员直接调整
    InProgress --> InProgress: 赢单审批驳回
    InProgress --> InProgress: 输单审批驳回
    InProgress --> InProgress: 无效审批驳回

图中的驳回表示“拟迁移未生效，仍保持进行中”，不是已进入终态后恢复。赢单、输单、无效审批通过后均为业务终态。出处：S1 阶段七；S3 第 71-75 行。

5.3 商机阶段（进行中子阶段）

stateDiagram-v2
    direction LR
    state "需求&方案" as Needs
    state "招投标" as Bidding
    state "商务谈判" as Negotiation
    state "订单输入单" as OrderInput
    [*] --> Needs
    Needs --> Bidding: 进入招投标
    Bidding --> Negotiation: 进入商务谈判
    Negotiation --> OrderInput: 准备订单输入

商机阶段仅描述“进行中”的内部进度；赢单、输单、无效只写入阶段状态，不重复写入商机阶段。是否允许跳级、回退及不同销售模式的起始阶段见 SM-05。出处：S2“商机状态管理”；S3 第 78 行。

5.4 迁移与非法迁移

当前状态	事件	触发条件	目标状态	业务动作
进行中	`OpportunityWon`	报价业务线/金额与商机一致，赢单凭证有效，审批通过	赢单	锁定商机；可生成订单草稿
进行中	`OpportunityLost`	原因和详情完整，审批通过	输单	保存输单原因
进行中	`OpportunityInvalidated`	原因和详情完整，审批通过	无效	保存无效原因
进行中	`OpportunityResultAdjusted`	销管管理员直接调整且原因完整	输单/无效	记录管理员、原因和调整时间；不创建审批实例
正常	`OpportunityChangeRequested`	已有关联报价且修改关键交易信息	变更中	冻结待审版本，保留生效版本
变更中	`OpportunityChangeApproved`	变更审批通过	正常	发布新版本，提示同步报价

非法迁移	原因
进行中 -> 赢单且无一致报价/赢单凭证	HTML 明确为提交前硬阻断
赢单/输单/无效 -> 另一结果状态	终态改判规则未定义
已有关联报价时直接覆盖关键交易信息	必须走变更审批，范围待 C-07
审批中 -> 赢单/输单/无效	创建审批尚未完成

六、报价

6.1 审批状态

状态	含义
草稿	Excel 已上传或 AI 已识别，等待人工确认/提交
审批中	金额一致性校验通过，审批链正在执行
审批通过（当前有效）	全部必要节点通过，且为该商机最新有效报价（last）
已失效	曾审批通过，但已被更新审批通过的报价替代，或商机的报价影响字段发生变更
审批不通过	某节点驳回；当前版本不可作为订单数据源

stateDiagram-v2
    direction LR
    state "草稿" as Draft
    state "审批中" as Pending
    state "审批通过（last）" as Approved
    state "已失效（历史）" as Invalidated
    state "审批不通过" as Rejected
    [*] --> Draft: 上传报价 Excel
    Draft --> Draft: AI 识别并人工确认
    Draft --> Pending: 金额一致性校验通过并提交
    Pending --> Approved: 全部必要节点通过
    Pending --> Rejected: 任一节点驳回
    Rejected --> Draft: 修改后创建新审批实例
    Approved --> Invalidated: 更新报价通过或报价影响字段变更
    Invalidated --> [*]

一个商机可以有多个报价轮次，但任一时点只有最新审批通过版本是当前有效报价（last）；历史轮次保留追溯。商机变更与报价无关时，报价状态不变；金额、产品或其他指定字段变更时，当前 last 立即失效并要求重新提报。具体影响字段清单见 C-07。出处：S1 阶段六；S2“报价与合同管理”。

非法迁移	原因
草稿 -> 审批中且报价/商机金额不一致	HTML 明确阻断提交
审批通过 -> 草稿并覆盖原版本	已审批版本不可原地修改
审批不通过 -> 审批通过	必须修改并新建审批实例
AI 识别完成 -> 审批通过	AI 识别不是审批
订单引用已失效或非 last 报价	订单只能引用同一商机的最新有效报价

七、订单

7.1 生命/审批状态

HTML 使用“草稿、已确认”；调研使用“未生效、正常”。为避免同义枚举并存，当前统一采用 HTML 名称：草稿 = 未生效，已确认 = 正常。

状态	含义	口径级别
草稿	赢单审批通过后系统自动生成；审批驳回后回到此状态	HTML 现行基线
审批中	销管调整订单/执行金额、补录提成并完成审批；等待合同和提成依据时可停留两至三个月	HTML 现行基线
已确认	订单审批通过，审批后的金额、产品、划分和提成事实固定	HTML 现行基线
作废	不可恢复的逻辑删除	调研已明确，HTML 未定义审批路径

stateDiagram-v2
    direction LR
    state "草稿" as Draft
    state "审批中" as Pending
    state "已确认" as Confirmed
    state "作废（待确认）" as Voided
    [*] --> Draft: 赢单审批通过后自动生成
    Draft --> Pending: 销售提交产品明细和业绩划分比例
    Pending --> Pending: 销管调金额/补提成/等待合同依据
    Pending --> Confirmed: 一致性复核通过且最终审批通过
    Pending --> Draft: 审批驳回
    Confirmed --> Voided: 作废审批通过
    Voided --> [*]

销售提报时只负责产品明细和业绩划分比例。订单进入审批后，由销管调整订单/执行金额并补录提成信息。审批按“商机 → 最新有效报价（last）→ 订单”回溯检查关联、内容和版本是否一致且最新；不一致时报错并驳回修改，修改后重新审批。只有最终审批通过才能进入“已确认”，此时所有审批事实固定。出处：S1 阶段七、阶段八及 2026-08-19 确认规则；S2“订单状态管理”；S3 第 81-88 行。

7.2 开票状态（订单派生）

stateDiagram-v2
    direction LR
    state "未开票" as NotInvoiced
    state "部分开票" as PartiallyInvoiced
    state "已开票" as Invoiced
    [*] --> NotInvoiced
    NotInvoiced --> PartiallyInvoiced: 累计有效开票金额大于 0 且小于应开金额
    NotInvoiced --> Invoiced: 一次性足额开票
    PartiallyInvoiced --> Invoiced: 累计有效开票金额达到应开金额

7.3 合同归档状态（订单派生）

stateDiagram-v2
    direction LR
    state "未归档" as NotArchived
    state "部分归档" as PartiallyArchived
    state "已归档" as Archived
    [*] --> NotArchived
    NotArchived --> PartiallyArchived: 部分关联合同已归档
    NotArchived --> Archived: 全部关联合同一次性归档
    PartiallyArchived --> Archived: 全部关联合同已归档

开票状态和合同归档状态均由关联事实聚合计算，不改变订单生命状态，不允许在订单上人工直接跳转。出处：S3 第 90-98 行。

7.4 非法迁移

非法迁移	原因
草稿 -> 已确认	必须经过独立订单审批
审批中 -> 草稿并覆盖审批记录	驳回应回草稿，但审批实例必须留痕
已确认 -> 草稿	已生效订单修改机制未确认，不得直接回退
审批中且商机/报价/订单不一致 -> 已确认	必须先报错、修改并重新审批
`OrderConfirmed` -> 自动生成正式项目或交付准备单	项目由 PMO 手动创建和管理，自动立项不属于当前基线

八、合同

8.1 业务状态

状态	含义	依据
草稿	发起合同、建立关联并确认 AI 识别结果	HTML 阶段九流程
审批中	合同审批正在执行	HTML 阶段九流程
审批通过	合同审批完成；不自动触发 CRM 财务协同	HTML 阶段九

stateDiagram-v2
    direction LR
    state "草稿" as Draft
    state "审批中" as Pending
    state "审批通过" as Approved
    [*] --> Draft: 发起合同并关联订单
    Draft --> Pending: 识别结果人工确认且校验通过
    Pending --> Approved: 审批通过
    Pending --> Draft: 审批驳回后修改
    Approved --> [*]

时序上先有订单、后有合同。关联由合同发起：合同创建时必须选择一个或多个既有订单，订单可仍处于审批中；合同与订单形成 N:M。归档是销管人工维护的独立业务字段，不作为审批通过后的自动生命状态。必要提取字段、审批链、附件和归档字段规则见 C-10/SM-07。合同审批通过不触发 CRM 财务协同；当前唯一确认的 CRM→金蝶动作是提交开票申请时同步申请数据。出处：S1 阶段九、C-09/C-10；S2“报价与合同管理”。

非法迁移	原因
草稿 -> 审批通过	必须先经过合同审批
审批通过 -> 草稿并覆盖原合同	合同变更/补充协议的版本规则未确认
审批通过 -> 自动归档/自动生成应收应付/自动同步金蝶	这些动作均不在当前 CRM 基线；只有提交开票申请时同步申请数据
合同审批通过 -> 自动生成正式项目	项目由 PMO 手动创建，合同不触发自动立项

九、开票与回款边界

9.1 当前可确认的事实流

HTML 和本次确认均未给出可直接落库的正式回款状态枚举。当前只确认：销售提交开票申请时，CRM 将该申请数据直接同步金蝶。是否生成或调整回款计划、实际到账如何回流、核销和异常补偿均不在本版预设。

stateDiagram-v2
    direction LR
    state "开票申请草稿" as Draft
    state "开票申请已提交" as Submitted
    state "申请数据已同步金蝶" as Synced
    [*] --> Draft: 创建开票申请
    Draft --> Submitted: 销售提交
    Submitted --> Synced: 直接同步申请数据

9.2 候选状态机（待财务确认）

以下状态仅用于评审，不是 V2 实现基线。

stateDiagram-v2
    direction LR
    state "计划中（候选）" as Planned
    state "部分回款（候选）" as Partial
    state "已回款（候选）" as Paid
    state "逾期（候选）" as Overdue
    [*] --> Planned: 回款计划生效
    Planned --> Partial: 累计到账大于 0 且小于计划金额
    Planned --> Paid: 一次性足额到账
    Partial --> Paid: 累计足额到账
    Planned --> Overdue: 到期未足额到账
    Partial --> Overdue: 到期仍未足额到账
    Overdue --> Partial: 逾期后部分到账
    Overdue --> Paid: 逾期后足额到账

候选回款状态的金额口径、计划分期、核销、退款/冲销、坏账、币种、到账撤销和逾期计算均未确认，见 SM-08 和 C-18。本候选图仅用于后续财务访谈，不表示已经存在金蝶回流接口。出处：S1 第四节、C-18；S2“开票与回款管理”；S3 第 101-103 行。

非法迁移	原因
仅提交开票申请即标记已回款	当前只确认同步申请数据，不代表到账
未确认接口即增加实际回款或自动更新状态	实际到账回流尚未确认，不得预设
直接实现候选枚举	正式状态和异常路径尚未由财务确认

十、订单、合同与 PMO 手动立项边界

stateDiagram-v2
    direction LR
    state "订单已确认" as OrderConfirmed
    state "合同审批通过" as ContractApproved
    state "PMO 待处理（非业务实体状态）" as PMOQueue
    state "项目已手动创建" as ProjectCreated
    [*] --> OrderConfirmed: 订单审批通过
    [*] --> ContractApproved: 合同审批通过
    OrderConfirmed --> PMOQueue: 仅供 PMO 查询/关联，不自动立项
    ContractApproved --> PMOQueue: 仅供 PMO 查询/关联，不自动立项
    PMOQueue --> ProjectCreated: PMO 手动创建项目

当前 V2 明确采用 PMO 手动创建和管理项目。订单确认、合同审批通过只提供可关联的业务事实，均不自动生成项目或交付准备单。手动立项的条件、关联、编号、取消和重复校验仍作为 C-08/SM-09 待办。出处：S1 第四节、C-08/C-11/C-12/C-13。

十一、集中待确认项

编号	当前调研结论 / 冲突	需确认决策	确认后影响	出处
SM-01	听记摘要称线索无独立“变更中”，手工记录称转客户/联系人期间处于“变更中”；HTML 只明确转客户为独立操作、客户创建需审批	线索转客户/联系人时，线索生命状态是否保持正常；是否仅创建独立审批实例；审批驳回后如何处理	线索枚举、转化审批、事件与审计	S1 阶段二/四；S2“线索状态管理”；S3 第 5-10 行
SM-02	持续跟进保有期可配置，当前为 14 天；部门线索池与销售拓展池参数独立	仅需明确自然日/工作日、起算点、有效记录刷新条件和各池配置权限	定时任务、回收规则、提醒和测试	S1 阶段二；S2“线索状态管理”；S3 第 19 行
SM-03	HTML 仅明确销管创建客户可免创建审批；调研未说明变更/作废是否免审批	销管免审批范围是否覆盖客户变更和作废	客户审批路由、权限与审计	S1 阶段四“免审批特例”；S2“客户状态管理”
SM-04	客户成交状态确定为系统自动计算，但成交事实来源仅描述为订单金额等	明确按赢单、已确认订单、合同、开票还是实际回款计数；撤销/退款后是否回退	客户标签、经营统计、数据修复	S1 阶段四客户标签；S2“客户状态管理”；S3 第 45-48 行
SM-05	商机进行中子阶段确认为需求&方案、招投标、商务谈判、订单输入单；跳级、回退和起始阶段未定义	明确各阶段进入条件、允许回退/跳过的角色，以及订单输入单与赢单/订单创建的先后关系	商机阶段枚举、漏斗报表、自动化	S1 阶段五/七；S2“商机状态管理”
SM-07	合同审批和人工归档字段细则仍未定义；合同必须由合同侧关联一个或多个既有订单	确认附件是否必传、归档字段枚举与维护权限、外部原件和合同编号如何关联	合同字段、附件、审批流、业绩核算	S1 阶段九/C-10；S2“报价与合同管理”
SM-08	当前只确认提交开票申请时同步申请数据到金蝶；正式回款状态及到账回流均未定义	财务确认状态集合、接口边界、金额/分期/核销/逾期/退款/冲销/坏账规则及终态恢复	回款表、潜在金蝶接口、风险升级、财务测试	S1 第四节/C-18；S2“开票与回款管理”
SM-09	已确认项目由 PMO 手动创建和管理，订单/合同均不自动立项	补充 PMO 手动立项的发起条件、关联订单/合同规则、编号、取消、重复校验、通知和历史迁移	PMO 项目状态机、关系和审计	S1 第四节、C-08/C-11/C-12/C-13
SM-10	已确认同一商机允许多个报价轮次、仅最新审批通过版本（last）有效，历史版本保留	补充并行审批冲突、版本号生成和失败重试规则	报价版本、订单外键、审批审计	S1 阶段六；S2“报价与合同管理”

11.1 确认顺序

先确认 SM-09/C-08，补齐 PMO 手动立项条件和关联规则。
再确认 SM-07/C-10，补齐合同必要字段、审批流、附件和人工归档规则。
财务单独确认 SM-08/C-18，形成回款正式状态机。
CRM 依次确认 SM-01 至 SM-05、SM-10 的剩余细节，随后统一冻结枚举、事件名和非法迁移测试用例。

原始 Markdown 按原文件名保存在私有仓库 archive/object-workbench/l2c-v2/；本页仅做格式转换、站内链接适配和显式版本注释。