供应商反禁用状态同步实战：金蝶云星空 → MySQL 的状态回写策略

这个策略解决什么问题

某零售企业在用金蝶云星空做供应商主数据管理时，财务或采购在金蝶端把某供应商「禁用」了，但下游订单系统（MySQL）并不知道，下单时仍把这个供应商当可用，导致后续对账、结算、对私支付都出错。这种「上游改了、下游看不见」的撕裂，是供应链集成里最典型的反向状态同步场景。我们的做法是：在轻易云数据集成平台（Qeasy）里配置一条独立的「反禁用状态更新」策略，只回写状态字段，不动主数据其他列，稳、轻、可回滚。

数据流向与字段映射

整体流向是 金蝶云星空（源）→ 轻易云中间层 → MySQL（目标）。金蝶端通过 executeBillQuery 把供应商列表（编码、名称、通讯地址、付款条件、数据状态 FDocumentStatus）拉出来；中间层只保留两列真正用得到的字段，再按对照关系回写 MySQL。

注意：MySQL 端 otherRequest 里是 update … set yn_lock=:yn_lock where supplier_short_code=:supplier_short_code and company_code='TYZN'——账套/公司编码必须做条件，否则会跨公司误改，这是踩坑高发点。

在轻易云上如何配置

在轻易云数据集成平台里，这条策略走的是「源查询 → 字段映射 → 目标执行」三段式：

1. 源端（Kingdee.Cloud）：API 选 executeBillQuery，方法 POST，把 FSupplierId、FNumber、FDocumentStatus、FName、FAddress、FPayCondition_FNumber 等作为请求字段，编码字段直接传值。autoFillResponse=true 让响应按字段名直接展平，省掉一层解析。
2. 中间层：用轻易云的「集成策略」做字段裁剪与映射，把金蝶的 FDocumentStatus 转成 0/1 的 yn_lock。这里建议把编码映射放平台统一管理——轻易云客户里常见做法是建一张「编码映射表」，后续其他供应商策略复用同一张表，避免每个策略各自硬编码。
3. 目标端（MySQL）：API 选 execute（WebAPI），主请求体放 main_params，真正的 SQL 放进 otherRequest.main_sql，使用命名参数（:yn_lock、:supplier_short_code）。idCheck=true 保证只有命中记录才更新，零写入风险。

实施步骤

1. 增量起点：先用「全量」跑一次，把所有供应商的当前状态对齐；首次跑建议放在业务低峰（建议 0:00–5:00）。
2. 日常调度：源端 3 7-22 * * *（每小时第 3 分查），目标端 5 7-22 * * *（第 5 分回写），差 2 分钟给源端留出查询窗口。轻易云客户常见的「增量与全量双轨」做法是：工作日白天走增量（按 FSupplierId 增量），周末凌晨走全量校验。
3. 表头表体分阶段：本策略只动「表头」状态字段，不涉及表体；如果后续要扩展到联系人、付款条款，再单独建一条策略，避免一条策略干太多事。
4. 失败重试与告警：轻易云策略配置里开启失败重试（建议 3 次，间隔 30s），并在监控里对「更新行数为 0」配置告警阈值——长期为 0 通常意味着编码映射断了。

踩坑复盘

1. 典型错误是忘了 company_code 条件。MySQL 那条 UPDATE 没带公司维度，就会把同名供应商在别的公司的记录也改了。稳妥做法是 where 里永远带账套/公司字段。
2. 金蝶 FDocumentStatus 的语义不是简单的启用/禁用。它是数据状态：审核中是「A」，已审核是「B」之类被禁用要看具体业务字段；映射时务必在平台里写转换函数，而不是在 SQL 里写 case when。
3. 回写频率别太密。状态变更属于低频事件，每小时一次足够；如果设到分钟级，金蝶查询接口压力会先扛不住。
4. 编码映射集中管理。别在策略里硬编码「金蝶编码 ↔ MySQL 短码」的对照表，轻易云平台的「编码映射」组件才是归宿——后续物料、客户、银行账户都能复用。
5. 不要顺便回写名称、地址。一旦改了主数据字段，下游若有缓存就会脏；状态字段单独走一条策略，出了问题影响半径最小。

适用场景与不适用场景

适用：上游是金蝶云星空/用友等 ERP、下游是业务数据库，需要把供应商/客户的启用/禁用、审核状态反向回写到业务系统；变更频率低（小时级即可）。不适用：需要把上游审批流、附件、修改历史都同步过来的场景——那应该走全量主数据同步策略，而不是这条状态回写策略。