销售退货-币别策略实战：吉客云到金蝶云星空的多币种字段映射
这个策略解决什么问题
某零售企业在多币种销售退货场景中，遇到一个很现实的财务痛点：吉客云的销售退货入库单已经传到金蝶云星空，但财务子表里的结算币别和汇率始终是空的，月末对账时金额对不上。问题就出在「基础销售退货同步」之外，缺一个专门补齐币别、汇率等财务字段的子策略。
我们用轻易云数据集成平台承接的「销售退货-币别」策略，正是为解决这个空白而设计的：它在已有的销售退货同步基础上，重点补充 SubHeadEntity 中的结算币别、汇率等字段，保证多币种退货业务在金蝶侧能准确核算。
数据流向与字段映射
数据流向是单向的：吉客云（销售退货入库单，inouttype=105）→ 轻易云 → 金蝶云星空（销售退货单 SAL_RETURNSTOCK）。
下面这张表只列与币别相关的关键字段，方便快速看清映射。
| 源字段（吉客云） | 目标字段（金蝶 SubHeadEntity） | 映射类型 | 取值规则 |
|---|---|---|---|
| chargeCurrencyCode | FSettleCurrId | 直接/转换 | 优先取此字段 |
| currencyCode | FSettleCurrId | 回退 | chargeCurrencyCode 为空时取此 |
| currencyCode | FCURRENCYID | 直接 | 交易币别 |
| localExchangeRate | ExchangeRate | 直接 | 本币折算汇率，优先使用 |
| currencyRate | ExchangeRate | 回退 | localExchangeRate 为空时取此 |
主表其他字段如 goodsdocNo → FBillNo、companyCode → FSaleOrgId / FStockOrgId、inOutDate → FDate 沿用基础策略。退货客户 FRetcustId、关联单号 F_LSJC_Text、收货单号 F_LSJC_Text2 通过 _mongoQuery 从退换补货单数据源按 returnChangeNo = billNo 或 sourceBillNo 联查得到。
在轻易云上如何配置
在轻易云集成平台里，这个策略按「源 → 中间层 → 目标」三段搭建。
源端（吉客云）
- API：
erp.storage.goodsdocin.v2，POST 查询 - 关键过滤：
inouttype=105 - 拉取字段除基础字段外，额外带出
currencyCode、currencyRate、localExchangeRate、chargeCurrencyCode四个币别相关字段 - 单据编号字段：
goodsdocNo，幂等字段：recId，idCheck=true
中间层（轻易云）
- 主表币别映射配置在
SubHeadEntity节点，使用「优先取值 + 回退」的 CASE 表达式 - 联查配置使用
_mongoQuery，语法上用$or兼容billNo与sourceBillNo - 不写脚本，纯映射 + 联查即可
目标端（金蝶云星空）
- API：
batchSave，POST 执行 - FormId：
SAL_RETURNSTOCK，Operation：Save IsVerifyBaseDataField=true（会校验币别编码是否存在于金蝶基础资料）IsAutoSubmitAndAudit=false（保存后不自动提交审核）InterationFlags=STK_InvCheckResult（允许负库存）SubHeadEntity当前配置为 null，需按本方案补全币别、汇率映射
实施步骤
我们建议客户分三个阶段上线，避免一次性铺开后对账困难。
阶段一：基础资料与币别档案先行
币别档案必须先于单据同步，否则 IsVerifyBaseDataField=true 会直接报错。物料档案（P3-057）、客户档案、组织档案同理。建议在轻易云里把这些基础资料同步策略作为依赖项检查清单。
阶段二：增量起点校准
源端按创建时间增量拉取，公式为 from_unixtime((LAST_SYNC_TIME - 18000), '%Y-%m-%d %H:%i:%s') 到 from_unixtime((CURRENT_TIME - 7200), '%Y-%m-%d %H:%i:%s')。前后各留 5 小时和 2 小时的窗口，是为了防止源端时间漂移导致漏单。第一次上线时，建议把 LAST_SYNC_TIME 手工回拨到一个明确的业务起点，再观察几轮。
阶段三：调度频率与全量补传
源端 crontab 40 */2 * * *（每 2 小时第 40 分），目标端 */20 * * * *（每 20 分钟）。频率错峰是稳妥做法——源端拉得慢一点，目标端执行得快一点，可以保证数据及时落库又不至于堆积。
如果客户上线初期数据缺失，可以用「全量触发」模式跑一次历史补传，再切回增量双轨。
踩坑复盘
-
币别档案没同步就先传单据。这是最典型的翻车点，
IsVerifyBaseDataField=true时金蝶直接拒收。稳妥的做法是把币别档案同步作为本策略的前置依赖。 -
汇率方向反了。金蝶汇率字段是「本币/原币」还是「原币/本币」，不同版本不一致。这里容易翻车，必须先在测试环境用一笔美元单据验证汇率换算结果，再上正式。
-
billNo为空导致联查失败。源端billNo可能为空，只查billNo会漏单。必须用$or同时匹配sourceBillNo，我们在客户现场就遇到过一次。 -
chargeCurrencyCode与currencyCode都为空。极端情况下两个币别字段都空，此时不要硬抛错，可以配置默认币别（如人民币）兜底，再让财务补录。 -
SubHeadEntity忘记补全。基础销售退货策略里这个字段是 null，本策略必须补全，否则币别字段都进不了金蝶。这个问题隐蔽，第一次配置时容易忽略。
适用场景与不适用场景
适用：多币种销售退货业务、需要在金蝶侧按币别和汇率核算财务的场景、已有基础销售退货同步需补齐财务子表的集成。
不适用：单一币种（如纯人民币）业务、不需要金蝶核算币别汇率的场景、未先完成基础资料同步的前置环境。