币种管理汇率逻辑调整 PRD

版本：v1.0 | 创建日期：2026-05-12

需求来源：产品现状问题 + 本地代码验证 + 竞品录屏调研 + 官方文档

优先级：P1 | 文档状态：草稿

适用范围：多币种管理、金额字段个人币种展示、汇率函数、原币到转换币查询接口

一、需求概述

1.1 需求背景

核心问题： 当前纷享销客多币种管理中，既可以在本位币视角维护“1原币 -> n本位币”的汇率，也可以在某个原币视角维护“1其他原币 -> n当前原币”的汇率。两套人工维护入口会导致同一组币种存在两套换算结果。

核心结论：汇率人工维护只能有一个事实源，即“原币 -> 本位币”。原币到原币、原币到个人币种仍保留为系统换算能力，但不再作为独立人工维护主数据。新企业从启用多币种起直接使用该模型；历史企业以“停止新增编辑、保留历史配置兼容、完成治理后切换”的方式迁移。

本需求不是反馈驱动，而是系统汇率模型的逻辑优化。背景部分只记录当前系统现状、截图情况和由此产生的产品问题。

系统现状与截图情况：

系统现状	截图/依据	当前表现	问题与优化方向
本位币入口可维护原币到本位币汇率		管理员可以从本位币视角维护其他币种到本位币的汇率	该入口符合中心汇率模型，应保留为唯一人工维护入口
非本位币入口也可维护原币到原币汇率		从某个原币进入“调整汇率”后，可以维护其他原币到当前原币的汇率	会形成第二套汇率事实源，需改为只读派生展示，不再允许人工维护
前台展示个人币种换算值		金额字段展示原币金额，同时在括号中展示个人币种金额；这个汇率的参考就是取的 原币到原币的汇率转换	展示能力需要保留，但汇率应由本位币汇率派生，不应要求管理员单独维护原币间汇率
系统已开放原币到转换币查询能力	EXCHANGERATE(currency1,currency2,defaultValue)、find_exchange_rate_by_currency	公式和接口可按原币、转换币查询汇率	不能直接删除原币到原币能力，需要在原有查询链路中增加本位币派生兜底

竞品情况：

产品	截图	关键机制	产品判断
Salesforce		管理有效币种、公司币种标识、兑换率、小数位数	汇率围绕 Corporate Currency 维护，不提供任意原币对原币的人工维护入口
Salesforce		新增币种时填写兑换率和小数位数	新增币种的汇率心智是相对公司币种
HubSpot		账户币种列表展示汇率、格式、更新时间，支持自动汇率更新和汇率日志	围绕 Company Currency 管理汇率，强调中心化维护和更新记录
Zoho CRM		手册截图中货币列表直接标识“基础货币：人民币-CNY”，其它货币围绕基础货币展示汇率	Zoho 将基础货币作为组织级汇率锚点，而不是维护任意原币对
Zoho CRM		编辑货币弹窗中维护单个货币的“汇率”字段	汇率维护入口围绕单个货币到基础货币的关系展开

官方资料：

• Salesforce Manage Multiple Currencies：[https://help.salesforce.com/s/articleView?id=sf.admin_currency.htm&type=5](https://help.salesforce.com/s/articleView?id=sf.admin_currency.htm&type=5)
• Salesforce Set Your Corporate Currency：[https://help.salesforce.com/s/articleView?id=xcloud.admin_currency_set_corporate.htm&type=5](https://help.salesforce.com/s/articleView?id=xcloud.admin_currency_set_corporate.htm&type=5)
• Salesforce Advanced Currency Management：[https://help.salesforce.com/s/articleView?id=sales.administration_about_advanced_currency_management.htm&type=5](https://help.salesforce.com/s/articleView?id=sales.administration_about_advanced_currency_management.htm&type=5)
• HubSpot Add and edit your account currencies：[https://knowledge.hubspot.com/account-management/add-and-edit-your-account-currencies](https://knowledge.hubspot.com/account-management/add-and-edit-your-account-currencies)
• Zoho CRM 管理多货币：[https://help.zoho.com.cn/portal/zh/kb/crm/organization-settings/company-settings/articles/multiple-currencies?crmprod=1](https://help.zoho.com.cn/portal/zh/kb/crm/organization-settings/company-settings/articles/multiple-currencies?crmprod=1)

为什么围绕本位币维护汇率是更规范的方案：

下图说明两种模式的本质差异。左侧任意两个币种之间均可双向人工维护；以 AED、USD、CNY 三个币种为例，共有 3 × 2 = 6 条有向汇率关系。右侧只维护“非本位币 -> 本位币”两条中心汇率，其余四条有向关系均由系统派生。

图示结论：现状下不仅 AED -> USD 与 USD -> AED 可以分别人工维护，AED/CNY、USD/CNY 两组关系也都能双向维护，六条值可能彼此无法互相推导。目标态的实线箭头仅允许单向指向本位币：只维护 AED -> CNY、USD -> CNY 两条中心汇率；CNY -> AED、CNY -> USD、AED -> USD、USD -> AED 均为唯一的派生结果，任何反向关系不得人工维护。

因此，本期不是下掉“原币到原币换算能力”，而是把它从“人工维护主数据”调整为“系统派生结果”。这样既能保留个人币种展示、函数和接口查询，又能避免管理端继续产生冲突汇率。

现状依据：

产品价值：

1. 统一多币种汇率事实源，避免同一币种对出现两套结果。
2. 降低管理员维护成本，从维护 N×N 原币汇率收敛为维护 N 个原币到本位币汇率。
3. 保留个人币种展示、汇率函数、汇率查询接口等现有能力，降低存量企业受影响风险。

1.2 需求目标

1. 管理端只允许人工维护“原币 -> 本位币”的中心汇率
2. 新企业从启用多币种起不再创建或维护原币到原币汇率；原币间及个人币种换算均按中心汇率实时派生。
3. 历史企业不再允许新增或修改原币到原币汇率；已有显式汇率在兼容期内可继续作为原有调用的有效值，避免公式和前台金额突然变化。
4. 前台金额字段在未命中历史显式汇率或新企业场景下，仍能按本位币汇率派生并展示个人币种换算值。
5. EXCHANGERATE(currency1,currency2,defaultValue) 和 find_exchange_rate_by_currency 保持兼容，并能返回有效的历史配置值或本位币派生值。

二、产品方案

2.1 整体方案

本次采用“中心汇率 + 派生换算”方案：管理端只维护“原币 -> 本位币”；新企业和完成迁移的历史企业，其“原币 -> 原币 的汇率”均由系统按本位币汇率派生。 已有显式原币间汇率的历史企业在兼容期内按“历史配置值优先、未命中再派生”返回，直至完成企业级切换。

派生规则：

rate(A -> B) = rate(A -> 本位币) / rate(B -> 本位币)

示例：

AED -> USD = 0.888 / 7.200 = 0.123333

1 AED = 0.123333 USD

2.2 管理端界面改造方案

本期 UI 改造基于现有币种管理页面调整，不新增独立配置页。

界面/入口	当前界面现状	优化后界面规则
本位币行“调整汇率”		（保持现状）保持可编辑，作为唯一人工维护入口；
非本位币行“调整汇率”		新老企业均调整为“查看汇率”；去掉输入态和保存动作，不再新增或修改独立原币间汇率
非本位币汇率弹窗内容	当前展示其他原币到当前原币的可编辑汇率	展示有效汇率、来源、计算公式和更新时间；值不可编辑。派生值示例：AED -> USD = AED -> CNY / USD -> CNY
历史汇率查看	展示历史汇率	继续展示；原币到原币结果按来源标识“系统派生”或“历史配置值（兼容期）”。每次中心汇率版本变更后，实际变化的派生币对也按该版本记录

非本位币入口不建议直接隐藏，新老企业均保留并统一命名为“查看汇率”。该入口承担“查看某币种换算到其他币种的有效结果”的职责，避免用户误解为原币换算能力被删除；它不再是配置入口。

2.3 企业类型与历史兼容

本期以“企业是否已在上线前开通多币种”为分界。入口形态保持一致，但有效汇率的来源不同，必须在查看页明确标识，避免管理员把历史配置值误认为实时派生值。

查看汇率的实时规则： 只有来源为“系统派生”的结果实时变化。其值由当前两侧“到本位币汇率”计算得出，任一中心汇率保存成功后，下一次查看、公式计算、接口查询和前台展示均应使用新结果。来源为“历史配置值（兼容期）”的结果固定为该条历史配置，不随中心汇率变化；页面需同时给出“当前中心汇率派生值”和“差异提示”，推动企业完成治理。

历史企业的兼容期不应无限期保留两套有效事实源。推荐以“历史汇率差异已确认 + 企业切换完成”为退出条件：对每个企业一次性切换到中心汇率派生模型；切换后原币间显式记录仅保留审计，不再参与查询和展示。

2.4 运行逻辑调整

派生汇率版本与查看历史汇率

本期的“实时派生”指当前查询始终基于最新中心汇率返回结果，但不意味着历史不可追溯。每次管理员保存“到本位币汇率”后，系统创建一个中心汇率版本，并按该版本重新计算当前启用币种间的全部有向汇率关系；与上一生效版本按汇率精度比较后，只有实际发生变化的派生结果写入“查看历史汇率”。

例如 CNY 为本位币、AED 的“到 CNY 汇率”发生变化时，系统需要计算 AED、USD、CNY 三个币种的六个有向换算结果。其中 AED -> CNY、CNY -> AED、AED -> USD、USD -> AED 会随之变化，USD -> CNY、CNY -> USD 不变。历史记录只新增前四条变化结果，并关联本次中心汇率版本；这四条均为“系统派生”历史快照，不能在历史页编辑，也不会重新成为交叉汇率主数据。

派生汇率精度与舍入

原币到原币的派生可能产生无限循环小数，例如 1 / 3 = 0.333333...。本期将“汇率精度”和“金额精度”分开处理：汇率用于计算和追溯，金额才是用户最终看到或写入业务记录的值。不得在中间派生步骤按金额小数位截断。

计算约束： 每次派生都直接引用同一中心汇率版本的两条“到本位币汇率”，按 6 位 HALF_UP 得到唯一业务汇率。不得用已有派生汇率继续派生，也不得用 A -> B 的已输出值再取倒数生成 B -> A；反向币对必须按中心汇率公式重新计算，避免多轮换算产生累计误差。

异常边界： 中心汇率必须大于 0；任一所需中心汇率为空、为 0 或无效时，不生成派生率或派生历史快照。前台按现有无汇率兜底处理，EXCHANGERATE 返回其 defaultValue。

2.5 兼容策略

历史企业中显式汇率与派生汇率同时存在时，兼容期采用“历史显式值优先 + 差异识别”。新企业不存在该优先级分支。历史企业完成差异确认并切换后，统一改为“本位币派生优先”，不再回退到显式原币间汇率。

历史汇率差异处理（是否需要处理，待定）

这里的“差异”不是泛指历史数据有问题，而是指同一企业、同一币对同时满足以下条件：已有原币到原币的人工配置值，且按当前两条“到本位币汇率”计算出的结果与该人工值超出既定精度容差。例如历史配置 AED -> USD = 0.120000，当前中心汇率推导为 0.888 / 7.200 = 0.123333，该币对进入差异列表。

系统在灰度前和企业切换前生成“历史汇率差异列表”。列表只用于让管理员确认迁移口径，不要求管理员再编辑原币间汇率；每条至少展示企业、币对、历史配置值、当前派生值、差异比例、当前生效来源，以及受影响的公式/接口/个人币种展示范围。

业务记录上的汇率快照不参与上述处理，也不因企业切换而回刷。历史配置值在切换后保留审计信息，供追溯“切换前为何显示该结果”，但不再作为新的计算来源。

三、其他说明

3.1 多语能力支持

无。

3.2 需求埋点/日志

无新增产品埋点。

系统侧建议保留后台日志，用于定位派生汇率计算、显式汇率冲突、函数兜底命中情况。

3.3 沙盒/更改集能力

待确认现有币种管理配置是否支持沙盒/更改集。本期如果只调整系统换算逻辑，不应新增更改集对象。

3.4 对象与字段影响

无新增业务对象。若研发需要新增 manual/derived 等汇率来源标识，仅作为技术字段评估。

3.5 风险点

3.6 上线策略

3.6.1 收费标准

• [X] 不收费
• [ ] 收费

3.6.2 上线节奏

• [ ] 全网
• [X] 灰度

3.6.3 适应版本

待确认。建议与当前多币种能力支持版本保持一致。

四、验收标准

五、待确认事项

附1：需求变更记录

附2：需求 Story 列表