查询金蝶部门：基础资料从ERP同步到OA的实战配置指南
这个策略解决什么问题
在一次实际项目中，我们遇到过这样的场景：某制造企业的审批流程挂在泛微OA-E9上，但组织架构、人员归属、成本中心的「权威数据」却一直在金蝶云星空里。OA里的部门字典是几年前手工导入的，早就和ERP对不上了——HR在OA改了部门名称，金蝶没同步；财务在金蝶新建了一个成本中心，OA里压根没有这条记录。
「查询金蝶部门」这个策略解决的就是这个最基础、也最容易翻车的问题：让ERP的部门主数据成为单一事实源，按节奏推到中台，下游OA、HR、费控等系统按需消费。我们用轻易云数据集成平台承接这条数据通道，整个过程不需要在ERP里做定制开发。
数据流向与字段映射
这条策略的流向很清晰：金蝶云星空 → 轻易云中间层 → 泛微OA-E9Http。源端调用的是金蝶的 executeBillQuery 单据查询接口，目标是写入空操作（占位节点），真实消费方是后续依赖此策略的下游链路。
关键字段对照：
| 业务含义 | 源端字段（金蝶） | 目标字段 | 备注 |
|---|---|---|---|
| 主键 | FDEPTID | — | 部门FID，整型 |
| 编码 | FNumber | — | 业务编码，建议作为外部键 |
| 名称 | FName | — | 必填 |
| 使用组织 | FUseOrgId.FNumber | — | 关联组织编码 |
| 创建组织 | FCreateOrgId.FNumber | — | 创建组织编码 |
需要注意，源端 buildModel: true 表示轻易云会根据返回值自动构建响应模型；autoFillResponse: true 则让平台把响应字段自动回填到元数据里——这两项开关是金蝶查询类策略的标配。
在轻易云上如何配置
在轻易云数据集成平台里，这条策略的配置核心有三块：
第一，源端元数据。 在「金蝶云星空」连接器下新建一个 QUERY 类型策略，API 选 executeBillQuery，方法 POST。然后把 FDEPTID、FNumber、FName、FUseOrgId.FNumber、FCreateOrgId.FNumber 这五个字段按素材里的描述配置好。其中 number 字段填 FNumber，id 字段填 FDEPTID，idCheck 设为 false——因为部门数据我们是按编码去识别唯一性的，不是按内部FID。
第二，目标端占位。 因为部门数据本身不直接写入目标系统，而是在中台被下游策略消费，所以目标端配成一个 WebAPI「写入空操作」节点，请求体和响应体都留空，buildModel: false。这是轻易云客户常见的「表头先归位、表体再分阶段」做法——主数据先稳态落库，业务单据后续按需引用。
第三，调度策略。 源端 cron 配 */5 7-23 * * *，也就是工作时段每5分钟跑一次；目标端 cron 写 1 1 1 1 1（占位值，不实际触发）。
实施步骤
我们建议分三阶段推进：
阶段一：全量打底。 先用轻易云的「手动触发」跑一次全量，把金蝶里所有有效部门拉到中台。这一步重点观察返回的记录数和ERP里 select count(1) from t_org_department where FDeleted=0 是否一致。如果对不上，多半是过滤条件没写——金蝶的 executeBillQuery 默认会把已删除记录也带回来，必须加 FilterString 过滤。
阶段二：增量起点设定。 全量完成后，把金蝶的「最后修改时间」字段（通常是 FModifyDate）作为增量游标。在轻易云里配置「上次成功执行时间 + 1秒」作为下次查询起点，这样后续每次跑就只拿增量。注意金蝶的时间字段是带时区的，跨时区部署时这里容易翻车，稳妥的做法是统一以ERP所在时区的零点为基准。
阶段三：调度上线与监控。 把 cron 从「每5分钟」放开到全天，观察 24 小时的执行成功率。金蝶这类查询接口对并发有限制，建议在轻易云的「连接器」配置里把单连接 QPS 调到 2 以下，避免触发金蝶的限流。监控层面主要看两条线：单次执行的返回行数（突增可能是有人批量改组织架构），以及失败重试次数（持续失败多半是 Token 过期或者账套切换了）。
踩坑复盘
1. 编码映射没集中管理，3个月后两边对不上。 典型错误是直接在字段映射里写死「FNumber → OA编码」。建议在轻易云里建一张独立的「编码映射表」，把 ERP编码、OA编码、中台编码三者关系维护起来，后续组织调整只改这张表，不用动策略本身。
2. 忽略了「使用组织」和「创建组织」的多组织语义。 金蝶的部门是支持多组织的，同一个部门编码在不同组织下是不同的实体。我们见过客户没注意这一点，把不同组织的同名部门当成同一条数据合并，结果下游审批流走了错误的责任人。
3. 已删除部门被同步。 上面提到过，金蝶的查询接口默认包含已删除记录。必须在请求参数里加 FilterString: FDeleted=0，否则下游会看到一堆「幽灵部门」。
4. 增量游标漂移。 用 FModifyDate 做增量游标时，如果ERP服务器时钟和轻易云服务器时钟有时差，会出现「漏数据」或「重复数据」。稳妥的做法是用轻易云的「水位线」机制，让平台自动管理游标，而不是手工写SQL。
5. 全量和增量切换时漏数据。 全量跑完到第一次增量跑之间如果有新增数据，要么用「全量覆盖 + 增量补充」双轨，要么把切换窗口放在业务低峰期。这是轻易云客户常见的「增量与全量双轨」应对模式。
适用场景与不适用场景
适用：以ERP为主数据源、需要把组织/部门/人员这类基础资料稳态推到OA、HR、费控等下游系统的私有化集成项目；多组织、多账套的集团型企业；对数据一致性要求高、不允许OA端手工维护部门的场景。
不适用：实时性要求在秒级的场景（金蝶查询接口本身有延迟，加上调度节拍，最快也是分钟级）；组织架构频繁变动（每天超过50次增删改）的企业——这种更适合走事件驱动而不是轮询。