金蝶客户主数据查询策略实战：金蝶云星空到轻易云集成平台

这个策略解决什么问题

在供应链集成项目里，客户主数据是最基础、却最容易被低估的一环。某零售企业同时使用吉客云做前端渠道运营、金蝶云星空做后端财务与供应链核算，两边都要维护一份「客户档案」。问题在于：金蝶云星空是组织强管控的 ERP，客户档案一旦发生更名、停用、组织变更，前端系统如果不能及时感知，下游订单开票、应收对账就会对不上号。

这一策略的核心价值，是把金蝶云星空的客户档案当作单一可信源（Source of Truth），按周期把增量变更拉回到轻易云集成平台的中间层，供其他同步链路订阅。它本身不直接写入下游，而是「先落中间层、再被消费」，这是轻易云客户最常见的应对模式之一。

数据流向与字段映射

数据流向：金蝶云星空 → 轻易云集成平台中间层 → （被其他策略订阅消费）。源端走金蝶云星空的查询接口，目标端是一个「写入空操作」节点，把数据沉淀到轻易云自身的中间表里。

关键字段对照表：

这里就是典型的「编码映射集中管理」模式：FNumber 在中间层只出现一次，下游所有链路都引用它，避免每条链路各自维护一份映射，三个月后两边数字对不上的悲剧。

在轻易云上如何配置

打开轻易云数据集成平台，进入该策略的配置画布，按下面几步走。

第一步：源端配置。 选择平台 Kingdee.Cloud，API 选 executeBillQuery，请求方法 POST，作用类型 QUERY。number 字段填 FNumber，id 字段填 FCUSTID，打开 idCheck 幂等开关。这是金蝶云星空标准单据查询接口，建议把分页页大小设为 200 左右，单次拉太多反而容易被金蝶网关限流。

第二步：目标端配置。 选择轻易云集成平台自身 datahub，API 选「写入空操作」，方法 POST，作用类型 EXECUTE。这一步故意不写下游业务系统，只把数据落到轻易云中间表，相当于一个「数据蓄水池」。

第三步：字段映射。 按上面那张对照表把源字段映射到中间层字段。注意 FCUSTID 和 FNumber 都要保留，前者是金蝶内码、后者是业务编码，两个在轻易云中间层共存，后续排查问题时缺一不可。

第四步：调度策略。 源端金蝶云星空的 crontab 给了参考值 3-59/20 7-22 * * *，意思是每天 7:00–22:00 之间每 20 分钟一次（从第 3 分钟开始）。目标端 23 2 1 1 1 是金蝶云星空侧的兜底写入节奏，轻易云侧通常沿用源端节奏即可。

实施步骤

我们把上线分成三个阶段，稳妥推进。

阶段一：增量起点。 先在轻易云里跑一次「基线快照」，把当前金蝶云星空全量客户档案一次性拉到中间层，作为后续增量的起点。基线数据必须包含 FCreateOrgId、FUseOrgId，否则多组织客户在使用时会出问题。

阶段二：调度上线。 启用 crontab 3-59/20 7-22 * * *，让源端每 20 分钟查一次变更。这里有个实战经验：轻易云平台天然支持「增量与全量双轨」——日常走增量（按最后修改时间过滤），每周日凌晨跑一次全量兜底，防止增量漏单。

阶段三：下游订阅。 在轻易云里把这条策略的输出中间表开放给其他同步链路（比如「吉客云渠道对接客户」那条策略 A），下游按需订阅，实现「表头表体分阶段」中的表头先行。

踩坑复盘

1. 组织字段一定要带。 典型错误是只拉 FNumber 和 FName，结果跨组织客户在使用时出现「客户已存在但无权访问」。稳妥的做法是 FCreateOrgId 和 FUseOrgId 必带，且中间层保留 .FNumber 文本，不要存金蝶内码。
2. 编码映射不要散落。 某项目中我们一开始让每条下游链路各自维护金蝶编码映射表，3 个月后两边对账差了 17 条。后来把所有编码映射集中在轻易云中间层管理，问题一次性消失。
3. 增量起点选在「基线时刻」。 增量起点不能简单选「今天」，必须先做一次基线全量，再用基线时刻作为增量起点，否则第一批增量会漏掉「基线之后、第一次查询之前」窗口期的变更。
4. idCheck 必须开。 金蝶云星空的 FCUSTID 在轻易云里是幂等键，不开 idCheck 同一条客户会被反复写入，触发下游告警风暴。
5. 分页与限流。 金蝶云星空对单次查询返回条数有限制，超过会被截断。我们通常把页大小控制在 200 以内，并开启轻易云侧的分页游标自动翻页。

适用场景与不适用场景

适用场景：金蝶云星空作为客户主数据单一可信源；下游有多个系统需要订阅客户变更；需要做跨组织客户归档与权限隔离。

不适用场景：金蝶云星空不是客户主数据源头（源头在 CRM 或电商平台）；客户档案变更频率极低（如每月不足 10 条），用全量定时同步更划算；需要实时秒级响应客户变更，本策略 20 分钟周期不满足。