金蝶收款单对接收款记录接收：单策略同步方案实战

这个策略解决什么问题

某零售/分销类企业的财务系统使用金蝶云星空，业务前台使用一套自研或第三方业务系统做订单与收款对账。金蝶里审核通过的收款单需要把明细按行写入业务系统的银行回款记录，供前台对账、核销、生成凭证使用。这条策略解决的是「已审核收款单 → 业务系统回款明细」的单向增量同步，看似简单，但收款单是主从结构、目标接口是扁平单条写入，编码拼接、增量起点、明细循环是常见翻车点。

数据流向与字段映射

数据从金蝶云星空流向业务系统，中间经过轻易云数据集成平台（Qeasy）的可视化编排与转换层。源端按 FApproveDate 增量拉取已审核单据，目标端按明细行逐条调用写入接口。

核心字段对照如下：

源端收款单是主从结构，目标接口每次只接收一条扁平记录，因此必须按明细行循环展开，主表字段（FBillNo、FID、FDATE、FSETTLENO、FCONTACTUNIT_Fname）在每条明细中重复带入。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略被拆成「源查询 → 转换 → 目标写入」三段式。

• 源端（QUERY）：选金蝶云星空的 executeBillQuery，表单填 AR_RECEIVEBILL，FieldKeys 显式列出 FID、FBillNo、FDOCUMENTSTATUS、FApproveDate、FApproveDate 等主表与明细字段（带 _D 后缀的明细字段也要带出来）。FilterString 固定为：FApproveDate>='{{LAST_SYNC_TIME|dateTime}}' and FDocumentStatus='C'，只拉已审核。
• 目标端（EXECUTE）：选业务系统的 /Kingdee/UpdateBankPayBackInfo，number 留空或填入 fBussinessOrderNo 用于幂等去重。
• 映射层：在轻易云的字段映射画布里，fBussinessOrderNo 用「字符串拼接」转换器写入 {{FBillNo}}-{{FID}}，常量字段（fbookedType、fCreateOrgName、customerFbankId）直接填固定值。客户常见的应对模式是编码映射集中管理：所有 FBillNo+FID 这种唯一键拼接都在一张映射表里维护，方便后期切换规则。

实施步骤

分阶段调度是这条策略能否稳定运行的关键。

1. 增量起点：首次上线时不要用 FApproveDate>=某个历史时间 跑大批量，稳妥做法是先手动指定 LAST_SYNC_TIME 为上线当天 0 点，让它只拉当天数据；历史数据走全量触发单独补。
2. 全量触发：用轻易云的「全量重跑」功能补历史已审核单据，按审核日期分批（如按月分批），避免一次拉几万条把源端 executeBillQuery 打爆。
3. 调度频率：源端建议 */10 7-22 * * *（白天每 10 分钟，夜里不打扰），目标端 */10 * * * *（全天每 10 分钟）。源端夜间不调度，是因为财务月末结账经常在夜间操作，避免触发接口异常。
4. 上线节奏：先灰度一批单据类型或客户，确认对账无误后再放开全天调度。

踩坑复盘

• FBillNo 拼接冲突：直接用 FBillNo 当唯一键会和业务系统已有的订单号撞车，必须拼上 FID。FID 为空时拼接结果会重复，源端返回里要确认 FID 非空。
• 明细行漏行：executeBillQuery 默认返回主表字段，明细字段（如 FREALRECAMOUNTFOR_D）如果不显式写进 FieldKeys，response 里就是空的，结果整个金额都是空值。典型错误是只勾了主表字段。
• 审核时间没维护：LAST_SYNC_TIME 必须每次同步成功后写回，否则下次要么漏拉要么重复拉。轻易云的增量变量会自动维护，但源端如果改了字段名要同步更新。
• 主表与明细日期不一致：明细行的实际入账日期可能和主表 FDATE 不同，本策略统一用主表日期，业务上需要接受这个简化。
• 常量字段后续要改：fbookedType 写死成「银行转账」，如果以后要支持承兑汇票或第三方支付，得改成可变字段。在轻易云里把这种常量集中到一个「常量映射表」，后期切换一行就行，不用动每个策略。

适用场景与不适用场景

适用：财务系统是金蝶云星空、业务系统需要按回款明细逐笔入账、对账时效要求高（10 分钟级）的企业集成场景。不适用：需要把收款单回写到业务系统后再回传金蝶（双向同步）、需要按未审核单据同步、需要把收款单按分摊规则拆到多个订单行（这需要脚本扩展，不在本策略范围）。