查询金蝶银行账户：单一策略下的供应商主数据拉取实战

这个策略解决什么问题

在供应链集成里，「银行账户」是一类典型的轻量但高敏感主数据——它本身不参与交易流转，却是付款单、报销单、银行承兑汇票的前置依赖。某零售企业把金蝶云星空作为财务与供应链的底座，小满 OKKI CRM 作为销售前端；销售侧需要拿到一份「干净的银行账户清单」来辅助客户对账与回款认领，但又不希望直接读写金蝶的实体表。这条策略的目的就一句话：用一次轻查询，把金蝶云星空的银行账户只读地拉到轻易云集成平台，供下游消费方按需取用。

数据流向与字段映射

数据流向是单向只读：金蝶云星空 → 轻易云数据集成平台。源端调用金蝶的 executeBillQuery（POST）查询银行账户资料，结果落地到轻易云中间库；下游再从中间库取数，不会回写金蝶，也不会直接打到 CRM。

关键字段对照表如下：

这里有个容易踩雷的点：源 JSON 里 FBANKID 的 value 写的是 FCURRENCYID，属于金蝶查询接口的字段别名习惯，配置时务必按金蝶真实返回拆分，别照搬字符串。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略配置成「源策略 + 目标空写」的两段式，目标是平台自身，所以 target.metadata.api 设为 写入空操作，type=WebAPI、effect=EXECUTE、idCheck=true，相当于把金蝶的查询结果沉淀到平台中间表。

源策略的核心配置如下：

• API：executeBillQuery，type=QUERY、effect=QUERY、method=POST，主键和 ID 都用 FNumber。
• 请求字段：勾选 FName、FNumber、FBANKID 三列返回，is_required 全部置 false，避免单条缺字段阻塞整批。
• 分页参数：在 otherRequest 里用占位符 {{PAGINATION_PAGE_SIZE}} 与 {{PAGINATION_START_ROW}}，由轻易云的分页器自动注入，这是金蝶查询接口的标准做法。
• 勾选开关：idCheck=false、buildModel=false、autoFillResponse=false，保留原始返回，便于事后比对。

目标端不需要构造请求体，保持空数组即可。

实施步骤

分三阶段推进，是某零售企业客户现场跑通的节奏：

1. 初始化全量：源端 crontab 配 3 2 * * *，凌晨低峰触发第一次全量拉取，把金蝶现存银行账户一次性灌到轻易云中间库。
2. 目标侧落地：目标端 crontab 配 23 2 * * *，比源端晚约 20 分钟，确保全量结果已经落库后再做平台侧写入，避免空跑。
3. 稳态增量：全量完成后切到增量模式——源端按 FNumber 去重，只拉新增或变更的账户；目标端继续按调度跑，把增量结果覆盖到中间表。

这里用到的是轻易云客户常见的「增量与全量双轨」：全量负责初始化，增量负责稳态，两者用同一张表，靠时间戳字段区分。

踩坑复盘

1. 字段别名混用：源 JSON 里 FBANKID.value 实际是 FCURRENCYID，直接照搬会把开户银行和币别搞串。稳妥的做法是在轻易云的字段映射里手动指定源字段名，而不是相信 value 串。
2. 分页参数漏配：金蝶的 Limit 和 StartRow 是必填，缺一就会整页报错。第一次上线时容易漏掉 otherRequest，要在轻易云的请求体模板里显式补上两个占位符。
3. 源端 is_required 全 true：有些工程师习惯把所有字段勾成必填，结果一条记录缺币别就把整批卡住。银行账户这种基础资料，建议非主键字段一律 false，交给目标端容错。
4. 调度时间撞车：源端 02:03、目标端 02:23，看似错开，但全量首次跑时金蝶自身可能还有别的批处理。建议错峰至少 30 分钟，并在轻易云监控里给两个策略分别打告警。
5. 下游误以为源：中间库的「银行账户表」只有数据，没有写入接口，CRM 侧若按写入去调用会失败。需要在轻易云的策略描述里明确标注「只读中转」，并在 CRM 端文档同步。

适用场景与不适用场景

适用：金蝶云星空作为主数据源、下游多个系统需要共享银行账户但又不能直接访问金蝶的私有化场景；以及作为后续「付款单同步」「银行承兑汇票同步」的前置依赖。

不适用：需要实时联查（秒级）的业务——这条策略走的是批调度，最细粒度是天级；如果销售前端要「打开客户档案立刻看到账户」，应在 CRM 侧做缓存，而不是依赖本策略。