# Salesforce vs CM Core Object Field Gap Catalog

Date: `2026-07-08`

## Scope

这份文档只看一个问题：

`同一个核心业务对象，如果在 live Salesforce 创建，和在当前 CM + PingCAP pack 路径里创建相比，哪些业务字段更可能出现有值/没值/语义不同的差异。`

边界说明：

- 只看 `主要业务对象` 和 `业务上有意义的字段`
- 不展开大多数纯系统字段
- 优先讨论 `create 后立即可见` 或 `create 后短时间内由自动化补值` 的字段
- 下面的 `当前判断` 分成四类：
  - `已支持`：本地已有明确 formula / rollup / auto-number / Flow 证据
  - `高风险 gap`：已锁定 exact missing Flow / auto-number，或字段很可能在 CM 创建后为空、旧值、未回填
  - `中风险 drift`：字段通常不会完全空，但 create 后的补值时机、来源或语义更可能和 Salesforce 不一致
  - `待补证`：字段已定位到 metadata，但这轮还没有足够强的端到端证据判断

补充说明：

- API 名全部以 pack metadata 为准
- 你截图里的 `order_amount` 这里按 `Order.TotalAmount` 处理
- 你截图里的 `is_onstandard_order`，metadata 里对应的是 `Order.Is_Nonstandard_Order__c`

## 阅读优先级

如果只看
`字段有值 / 没值`
这个角度，当前建议优先读：

1. `Account`
2. `Order`
3. `Revenue__c`
4. `Invoice_Collection__c`
5. `Quote`
6. `CampaignMember`
7. `Lead`
8. `Opportunity`
9. `Org__c`

## `Account`

| 字段 | 业务含义 | Salesforce 侧典型补值方式 | CM 当前状态 | 当前判断 | 证据 / 备注 |
|---|---|---|---|---|---|
| `Account_ID__c` | account 编号 | auto-number | 本地 metadata 已定义为 `autonumber` | `已支持` | 这类字段不是当前 `Salesforce 有值 / CM 没值` 主 gap |
| `Current_Order_Type__c` | account 当前订单类型 | live `Account_Current_Order_Type` 持续维护 | 本地字段在，但 exact Flow 未找到 | `高风险 gap` | 这是当前最清楚的 Account 字段级差异之一 |
| `Partner_Sales_Email__c` | partner sales owner 邻近值 | live `Account_Partner_Sales_Owner_Set` 回填 | 本地字段在，但 exact Flow 未找到 | `高风险 gap` | 下游会外溢到 owner / team 相关维度 |
| `Contract_Valid_Date__c` | 合同有效期截止日 | live `Account_Contract_Valid_Message*` 维护 | 字段在，本地未见 exact peer | `中风险 drift` | 更像 account 治理语义缺口，不一定每次都直接空 |
| `Contract_Valid__c` | 合同是否有效 | live account-side flow 维护 | 字段在，本地未见 exact peer | `中风险 drift` | 常和 `Contract_Valid_Date__c` 一起漂 |
| `Contract_Valid_Days__c` | 距离合同到期天数 | formula | 本地 formula 已定义 | `已支持` | 但它依赖 `Contract_Valid_Date__c` 来源是否正确 |
| `Segmentation__c` | 分群 | 共享维度 / account enrichment | 字段已在 | `已支持` | 当前没有强证据显示它是 create-time 主 gap |
| `ICP__c` | ICP 分类 | 共享维度 / account enrichment | 字段已在 | `已支持` | 当前更像下游维表消费，不是 exact missing mechanism |
| `Industry` | 行业 | account 主数据 | 字段已在 | `已支持` | 目前没有看到 direct parity hole |

## `Order`

| 字段 | 业务含义 | Salesforce 侧典型补值方式 | CM 当前状态 | 当前判断 | 证据 / 备注 |
|---|---|---|---|---|---|
| `AccountId` | 订单挂靠 account | live `Order_Org_Auto_Set_Account_Create/Update` carry-over | 字段在，但 2 条 exact Flow 未找到 | `高风险 gap` | 这是 order 线最关键的 shared-key 风险 |
| `OpportunityId` | 订单关联机会 | live `contractOpportunityInset` 等激活邻近逻辑回填 | 字段在，但 exact Flow 未找到 | `高风险 gap` | 这类关联字段漂了会直接影响 finance / pipeline join |
| `QuoteId` | 订单来源 quote | `Std_CreateOrderFromQuote` 继承 | 本地已有明确 create flow | `已支持` | 不是当前 order 主 gap |
| `Cloud_Registration_Source__c` | cloud registration 来源 | org-to-order carry-over | 本地已有 `Cloud_Registration_Source_from_Org_to_Order` | `已支持` | 但它依赖上游 org/account bridge 正常 |
| `PLG_BD_Pool__c` | finance pool 标记 | live `Order_Set_PLG_BD_Pool` | 字段在，但 exact Flow 未找到 | `高风险 gap` | order / revenue / collection 三侧共用的高价值 gap |
| `Payment_Term__c` | 付款条款 | quote-to-order 继承 | 本地已有 `Order_Quote_Payment_Field_Inheritance` | `已支持` | 你截图这项已在研究结论里 |
| `Payment_Type__c` | 付款方式 | quote-to-order 继承 | 本地已有 `Order_Quote_Payment_Field_Inheritance` | `已支持` | 你截图这项已在研究结论里 |
| `PingCAP_RevRec_Entity__c` | revrec entity | create 后默认值 flow | 本地已有 `Order_Default_RevRec_Entity` | `已支持` | 你截图这项已在研究结论里 |
| `Real_Booking_Date__c` | booking date | formula | 本地 metadata 已定义 formula | `已支持` | 公式直接依赖 `Write_Off_Date__c` / `EffectiveDate` / `Opportunity.CloseDate` |
| `Exchange_Rate_to_Use__c` | 使用汇率 | formula | 本地 metadata 已定义 formula | `已支持` | 公式为 `IF(Exchange_Rate_from_RevRec__c>0, ..., Exchange_Rate__c)` |
| `Is_Nonstandard_Order__c` | 是否非标订单 | formula，跟随 `Quote.Contains_Other_Nonstd_Terms__c` | 本地 metadata 已定义 formula | `中风险 drift` | 自身不是缺口，但会继承 Quote 侧 non-standard gap |
| `Partner_Name__c` | partner 名称 | indirect deal / partner carry-over | `Quote` 和 `Order` 两侧字段都在，但当前 `createOrder` 标准映射里没有显式 `Partner_Name__c` copy，也没看到本地 order-side inheritance flow | `中风险 drift` | 这轮已经能证明 `CM create path` 不能默认指望它自动从 Quote 带到 Order；但 live Salesforce 是否还存在额外自动补值机制，这轮没有直接恢复出来 |
| `Prepayment_or_Not__c` | 预付 / 应收 | formula | 本地 metadata 已定义 formula | `已支持` | 但依赖 recognized/payable 上游值正确 |
| `Termination_Date__c` | 终止日期 | 终止/变更单邻近业务字段 | 字段在，但当前仓内除了对象定义外没有找到 create-side 映射、flow 或下游直接消费证据 | `中风险 drift` | 这更像一个 `create 后不一定自动补值` 的业务字段，而不是当前主创建链里最硬的自动补值 gap |
| `TotalAmount` | order amount | `OrderItem.TotalPrice` 汇总 | `Order.TotalAmount` 已改为 `SUM(OrderItem.TotalPrice)`；`createOrder` 不再从 `Quote.GrandTotal` 平铺写入 | `待运行验收` | pack 与 source-contract 将其作为 OrderItem 权威 rollup；需受控多行 fixture 的 API readback 通过后才可判定已支持 |
| `TCV_Amount__c` | TCV | formula | 本地 metadata 已定义 formula | `已支持` | 公式为 `Net_Fees__c` |
| `ACV_Amount__c` | ACV | formula | 本地 metadata 已定义 formula | `已支持` | 依赖 `TCV_Amount__c` / `Term__c` |
| `Cash_Collected__c` | 已回款金额 | formula | 本地 metadata 已定义 formula | `中风险 drift` | 字段能算，但上游 collection parity 会影响结果 |
| `Deferred_Revenue__c` | 递延收入 | formula | 本地 metadata 已定义 formula | `中风险 drift` | 字段能算，但依赖 revrec 聚合链 |
| `Recognized_Revenue__c` | 已确认收入 | formula | 本地 metadata 已定义 formula | `中风险 drift` | 字段能算，但依赖 `Recognized_Revenue_Amount__c` rollup 正确 |
| `Recognized_Revenue_Amount__c` | 已确认收入汇总 | rollup | 本地 metadata 已定义 rollup | `已支持` | 但仍受 revenue-side parity 影响 |
| `Total_Fees__c` | 含税总费用 | formula | 本地 metadata 已定义 formula | `中风险 drift` | 公式依赖 `Net_Fees__c * (1 + Tax__c)` |
| `Tax__c` | 税率 | 税务/国家规则输入，并继续喂给 order finance 公式 | `Quote` 和 `Order` 两侧字段都在，但当前 `createOrder` 标准映射里没有显式 `Tax__c` copy；同时 `Revenue__c.Tax__c` 和 `Invoice_Collection__c.Tax_Rate__c` 都继续从 `Order.Tax__c` 取值 | `中风险 drift` | 这轮已经能证明它不是“没字段”，而是 `CM create path` 里缺少可见的自动继承证据；你给的 `CN/HK/SG` 缺失、`JP/US` 异常线索仍值得单独深追 |

## `Revenue__c`

| 字段 | 业务含义 | Salesforce 侧典型补值方式 | CM 当前状态 | 当前判断 | 证据 / 备注 |
|---|---|---|---|---|---|
| `Name` | revrec 编号 | live auto-number | 本地字段类型仍是普通 `string`，未见 auto-number | `高风险 gap` | 这是 revenue 最清楚的字段级 gap |
| `PLG_BD_Pool__c` | finance pool 标记 | live `RevRec_Set_PLG_BD_Pool` | 字段在，但 exact Flow 未找到 | `高风险 gap` | revenue 线最值得优先补的 exact gap |
| `Amount_Before_Adjust__c` | 调整前金额 | formula | 本地 metadata 已定义 formula | `已支持` | 你后面如果要抽样，别把它误判成“没承接” |
| `Amount__c` | revenue 金额 | revenue 主字段 | 字段已在 | `已支持` | 当前没有强证据表明 create 后会系统性空白 |
| `Credit_Amount__c` | credit 金额 | revenue 主字段 | 字段已在 | `已支持` | 更多受整体 revenue runtime residue 影响 |
| `Exchange_Rate_to_Use__c` | revenue 汇率 | live revenue helper / runtime | 字段在，但未恢复出这轮 exact local peer | `中风险 drift` | 不是最清楚的 blank-field gap，但值得抽样 |
| `Partner_Name__c` | partner 名称 | revenue partner helper | 本地已有 `RevRec_Partner_Name` 证据 | `已支持` | 当前不是 revenue 主缺口 |

## `Invoice_Collection__c`

| 字段 | 业务含义 | Salesforce 侧典型补值方式 | CM 当前状态 | 当前判断 | 证据 / 备注 |
|---|---|---|---|---|---|
| `Name` | collection 编号 | live auto-number | 本地字段类型仍是普通 `string`，未见 auto-number | `高风险 gap` | 这是 collection 对象最直接的值差异之一 |
| `PLG_BD_Pool__c` | finance pool 标记 | live `Collection_Set_PLG_BD_Pool` | 字段在，但 exact Flow 未找到 | `高风险 gap` | 和 `Order` / `Revenue__c` 共用同类 gap |
| `Collections_Amount_exc_tax__c` | 不含税 collection 金额 | live `Collection_Amount_and_Payable_Amount_exc_tax*` | 字段在，但 2 条 exact Flow 未找到 | `高风险 gap` | 这是 finance 报表最该先抽样的字段之一 |
| `Payable_Amount_USD2_exc_tax__c` | 不含税 payable USD 金额 | live `Collection_Amount_and_Payable_Amount_exc_tax*` | 字段在，但 2 条 exact Flow 未找到 | `高风险 gap` | 同上 |
| `Marketplace__c` | marketplace 来源 | live `Cloud_Registration_Source_from_Org_to_Collections` carry-over | 字段在，但 exact Flow 未找到 | `高风险 gap` | org-to-collection bridge 当前是高价值缺口 |
| `CollectionsStatus__c` | 回款状态 | collection 主状态 + helper 维护 | 字段在 | `中风险 drift` | 字段本身不缺，但 live helper 对状态语义仍更完整 |
| `Payment_Status__c` | payable/collected 衍生状态 | formula | 本地 metadata 已定义 formula | `已支持` | 但它依赖 `CollectionsStatus__c` 与 `Payable_Date__c` 正确 |
| `Cash_Collected__c` | 已回款金额 | collection 金额链 | 字段在，受 helper parity 影响 | `中风险 drift` | 往往不是字段不存在，而是 helper 没补齐 |
| `Actual_Billing_Date__c` | 实际 billing 日期 | validation / billing 语义 | 本地已看到 validation parity | `已支持` | 当前不是最重 gap |

## `Quote`

| 字段 | 业务含义 | Salesforce 侧典型补值方式 | CM 当前状态 | 当前判断 | 证据 / 备注 |
|---|---|---|---|---|---|
| `QuoteNumber` | quote 编号 | auto-number | 本地 metadata 已定义为 `autonumber` | `已支持` | 不是当前 quote 主 gap |
| `Contains_Other_Nonstd_Terms__c` | 是否含非标条款 | live `Quote_update_nonstandard_conditions_checkbox*` 维护 | 字段在，但 2 条 exact Flow 未找到 | `高风险 gap` | quote 线当前最硬的字段 gap |
| `Other_Nonstandard_Terms_and_Conditions__c` | 非标条款内容 | commercial helper 邻近字段 | 字段在，但上游 checkbox flow 缺失 | `中风险 drift` | 文本本身可填，但自动勾选/联动语义可能不一致 |
| `Service_Start_Date__c` | 服务开始日期 | quote service-window 维护 | 字段在 | `中风险 drift` | 当前更像 commercial helper 语义不完全一致 |
| `Service_End_Date__c` | 服务结束日期 | quote service-window 维护 | 字段在 | `中风险 drift` | 同上 |
| `Governing_Service_Start_Date__c` | governing service start | quote/order 邻近治理语义 | 字段在 | `中风险 drift` | 受 quote helper / order contract policy 一起影响 |
| `Governing_Service_End_Date__c` | governing service end | quote/order 邻近治理语义 | 字段在 | `中风险 drift` | 同上 |
| `Payment_Term__c` | 付款条款 | quote 主字段，并继续继承到 order | 字段在 | `已支持` | 当前不是 quote 主缺口 |
| `ApproveStatus__c` | 审批状态 | commercial approval helper | 字段在 | `中风险 drift` | 当前更多是 quote 商业语义对齐问题 |
| `Technical_Support_Level__c` | 支持等级 | quote 商业语义 | 字段在 | `已支持` | 未见强 blank-field 证据 |

## `CampaignMember`

| 字段 | 业务含义 | Salesforce 侧典型补值方式 | CM 当前状态 | 当前判断 | 证据 / 备注 |
|---|---|---|---|---|---|
| `FirstRespondedDate` | 首次响应日期 | response / attribution helper | 本地 first/last-touch 主链已在 | `已支持` | 当前不是 campaign member 最硬缺口 |
| `Status` | campaign member 状态 | campaign response 语义 | 字段在 | `已支持` | live warehouse 也已真实消费 |
| `HasResponded` | 是否响应 | attribution helper | 字段在 | `已支持` | 当前不是 exact missing gap |
| `Key_Message__c` | key message | live `Campaign_Member_Key_Message_Update` | 字段在，但 exact Flow 未找到 | `高风险 gap` | 这是 campaign member 线最明确的字段缺口 |
| `LeadSource` | 来源 | lead/contact/campaign source helper | 字段在 | `中风险 drift` | 更像 source 语义与时机差异 |
| `Lead_Source_Detail__c` | 来源详情 | lead/contact/campaign source helper | 字段在 | `中风险 drift` | 同上 |
| `Recent_Source__c` | 最近来源 | source helper | 字段在 | `中风险 drift` | 同上 |

## `Lead`

| 字段 | 业务含义 | Salesforce 侧典型补值方式 | CM 当前状态 | 当前判断 | 证据 / 备注 |
|---|---|---|---|---|---|
| `MQL_Date__c` | MQL 日期 | lifecycle flow / trigger 维护 | 字段在，本地已有 lead substrate | `中风险 drift` | 当前更像时机差异，不是直接空白 |
| `MQL_Stage_DateV2__c` | MQL 时间戳 | lifecycle helper | 字段在，本地已有 lead substrate | `中风险 drift` | 这类 timestamp 最容易出现语义收窄 |
| `IQM_Date__c` | IQM 日期 | lifecycle flow / trigger 维护 | 字段在，本地已有 `IQM_Completion_Flow` | `中风险 drift` | 不宜直接定义成“CM 没值” |
| `IQM_Completed_Date__c` | IQM 完成日期 | lifecycle flow / trigger 维护 | 字段在，本地已有 `IQM_Completion_Flow` | `中风险 drift` | 同上 |
| `Nurture_Marketing_Date__c` | marketing nurture 时间 | live active，local activation mismatch | 定义在本地，但激活态未对齐 | `中风险 drift` | 这是 lead 线上较明确的 activation-state mismatch |
| `Nurture_Sales_Date__c` | sales nurture 时间 | live active，local activation mismatch | 定义在本地，但激活态未对齐 | `中风险 drift` | 同上 |
| `Recent_Source__c` | 最近来源 | source helper | 字段在 | `中风险 drift` | 更像 source/helper 时机问题 |
| `Recent_Source_Detail__c` | 最近来源详情 | source helper | 字段在 | `中风险 drift` | 同上 |
| `BN_Account__c` | lead 对应业务账号 | lead-account stitching | 字段在，但这轮没拿到完整 create-side peer | `中风险 drift` | 更像 stitching 语义，不是最清晰 blank-field gap |

## `Opportunity`

| 字段 | 业务含义 | Salesforce 侧典型补值方式 | CM 当前状态 | 当前判断 | 证据 / 备注 |
|---|---|---|---|---|---|
| `StageName` | 机会阶段 | stage flow / helper | 本地已有 `Std_OpportunityStageDerivedFields` | `已支持` | 当前不是机会主缺口 |
| `CloseDate` | close date | stage / close-date helper | 本地已有 `Opportunity_Close_Date_Auto_Set` | `已支持` | 当前不是 blank-field gap |
| `ForecastCategory` | forecast 分类 | stage-derived helper | 本地已有 `Std_OpportunityStageDerivedFields` | `已支持` | 下游直接消费，但本地主链已在 |
| `Forecast_Type__c` | forecast type | 邻近 forecast 语义 | 字段在 | `中风险 drift` | 当前剩余差异更多是长尾 defaulting / trigger residue |
| `Cloud_Order_Type__c` | cloud order type | opportunity helper | 本地已有 `Opportunity_Cloud_Order_Type_Set` | `已支持` | 但依然受长尾机会语义影响 |
| `Launch_Date__c` | launch date | stage-to-launch helper | 本地已有 `Opportunity_Auto_To_Launch_Stage` | `已支持` | 当前不是字段空白问题 |
| `Opt_Owner_Role__c` | owner role | owner helper | 本地已有 `Add_or_update_Opt_Owner_s_Role` | `已支持` | current peer 已明确存在 |
| `ARR_Amount_USD__c` | ARR 金额 | opportunity finance helper | 字段在 | `已支持` | 当前未见 exact missing field mechanism |
| `Accurate_ACV_Amount__c` | ACV 金额 | formula | 本地 metadata 已定义 formula | `已支持` | 当前不是主要 create-time gap |

## `Org__c`

| 字段 | 业务含义 | Salesforce 侧典型补值方式 | CM 当前状态 | 当前判断 | 证据 / 备注 |
|---|---|---|---|---|---|
| `Account__c` | tenant 对应 account | live `Org_Set_Account` | 本地已有 active `Org_Set_Account` | `已支持` | `Org__c` 自身不是这轮主 gap |
| `Name` | org 名称 | org 主数据 | 字段在 | `已支持` | 当前没看到 object-specific parity hole |
| `Registration_Status__c` | 注册状态 | org 主数据 / helper | 字段在 | `已支持` | 当前不是重点问题 |
| `Status__c` | org 状态 | org 主数据 / helper | 字段在 | `已支持` | 当前不是重点问题 |

## 这份目录最重要的收敛

### 1. 当前最硬的逐字段 gap

- `Account.Current_Order_Type__c`
- `Account.Partner_Sales_Email__c`
- `Order.AccountId`
- `Order.OpportunityId`
- `Order.PLG_BD_Pool__c`
- `Revenue__c.Name`
- `Revenue__c.PLG_BD_Pool__c`
- `Invoice_Collection__c.Name`
- `Invoice_Collection__c.Collections_Amount_exc_tax__c`
- `Invoice_Collection__c.Payable_Amount_USD2_exc_tax__c`
- `Invoice_Collection__c.Marketplace__c`
- `Invoice_Collection__c.PLG_BD_Pool__c`
- `Quote.Contains_Other_Nonstd_Terms__c`
- `CampaignMember.Key_Message__c`

### 2. 当前更像“字段有值，但语义/时机不同”的对象

- `Lead`
- `Opportunity`
- `CampaignMember` 的 source / touch 邻近字段
- `Order` / `Revenue__c` / `Invoice_Collection__c` 里的部分 formula 字段

### 3. 现在还需要进一步加固证据的字段

- `Order.Partner_Name__c`
- `Order.Tax__c`

这两项已经不是“目录没覆盖”或“字段没定位到”的问题，而是：

- 当前仓内证据已足够说明 `CM create path` 没有看到显式继承
- 但 live Salesforce 侧是否还有额外自动补值机制，这轮没有直接恢复到 exact mechanism

如果下一步还要深追，优先级仍然是 `Order.Tax__c`，因为你已经给出了国家维度的异常线索，而且它会继续喂给 `Order` 自身费用公式、`Revenue__c` 和 `Invoice_Collection__c`。

## Coverage Audit

这轮目录的“补全”现在可以更精确地说成两件事：

1. `主要业务对象覆盖已补全`

- `Account`
- `Order`
- `Revenue__c`
- `Invoice_Collection__c`
- `Quote`
- `CampaignMember`
- `Lead`
- `Opportunity`
- `Org__c`

2. `主要字段目录已补全，但字段结论强度不完全一样`

- 大部分高优先字段已经能落到 `已支持`、`高风险 gap` 或 `中风险 drift`
- 当前没有再保留“对象级空白”或“这批字段根本没进目录”的情况
- 剩下仍值得继续深追的，不是“有没有列到”，而是 `Order.Partner_Name__c` / `Order.Tax__c` 这类字段在 live Salesforce 侧的额外自动补值机制是否还能恢复到 exact name / exact timing