金蝶云星空与钉钉基础资料集成方案：风险供应商转正管理

场景与价值

在供应商主数据治理中,部分企业会先将供应商以「风险供应商」分类引入,经过一段时间观察后再决定是否转正为正式供应商。这一流程通常涉及两类系统:ERP 负责供应商主数据与状态字段的维护,OA 协同平台负责审批流与消息触达。当两边系统割裂时,容易出现「审批已通过但 ERP 未生效」「到期未提醒导致超期未处理」等问题。

本方案以风险供应商转正管理为切入点,设计金蝶云星空与钉钉之间围绕「基础资料」的双向集成:金蝶侧按创建日期识别风险供应商并发出提醒,钉钉侧接收审批结果后回写金蝶完成转正与解禁。整个过程以增量同步为主、全量为辅,既能满足日常运行,也便于初始化与数据修复。

集成架构与数据流

整体架构由三部分组成:金蝶云星空作为供应商主数据源、钉钉作为审批与消息通道、集成平台作为中间编排层。中间层负责三件事:供应商编码到内码 FSupplierId 的联查、组织编码到钉钉用户 ID 的映射、上下游策略的依赖编排。

数据流分为两条主线:

• 金蝶 → 钉钉(提醒):集成平台按 FCreateDate 过滤风险供应商,符合条件的记录以 Markdown 消息形式通过机器人批量推送至钉钉,提醒责任人发起转正审批。
• 钉钉 → 金蝶(回写):钉钉审批通过后,集成平台依据审批实例 ID 拉取审批详情,先调用金蝶 batchSave 接口执行转正,再调用 Enable 接口解禁供应商。两条策略存在严格顺序依赖,不能并行执行。

策略层面共 4 个,均为 SYNC 类型:2 个用于金蝶向钉钉推送转正提醒,2 个用于钉钉审批通过后回写金蝶。提醒类策略相互独立,可并行调度;审批回写类策略依赖上游审批实例 ID 拉取动作,且自身存在先转正后解禁的顺序约束。

接口清单

实施要点

阶段划分:整体执行拆为两阶段。第一阶段为提醒类策略,可并行触发;第二阶段为审批驱动类,需严格按「审批实例 ID 拉取 → 转正 → 解禁」顺序执行。第二阶段中两条策略不可交换,否则会出现「已解禁但未转正」的状态不一致。

编码映射:供应商在钉钉表单和金蝶主数据中存在两套标识。集成平台需通过集线器将供应商编码联查为金蝶 FSupplierId 内码;组织到钉钉用户 ID 的映射建议在配置层以 case-when 方式集中维护,避免硬编码散落在多个同步任务中。

增量与全量:日常运行使用增量模式,钉钉侧按 start_time 增量拉取,金蝶侧按 FCreateDate 过滤;初始化或数据修复场景需移除时间限制拉取全量。两种模式建议在同一策略内通过参数切换,而不是维护两套任务。

异常重试:API 超时或 5xx 采用指数退避(30s/60s/120s,最多 3 次);钉钉侧 429 限流采用固定 60s 重试(最多 5 次);业务校验失败的 4xx 不重试,直接进入告警队列;编码映射失败仅重试 1 次后告警,提示人工排查映射配置。

告警阈值:单策略失败率超过 10% 触发警告,连续失败 3 次升级为严重;编码映射失败率超过 5% 触发警告。告警应指向具体策略编号与最近一次失败批次,便于运维人员快速定位。

最佳实践

1. 顺序依赖显式化:审批回写类策略之间存在强依赖,建议在调度编排中显式声明先后关系,而不是依赖固定时间窗口。

2. 集线器优先:所有编码到内码的转换走统一集线器,避免在多个策略中重复实现联查逻辑,既能减少代码重复,也便于后续追溯。

3. 配置层与代码分离:组织到用户的映射、机器人编码、消息模板等高频变动信息放在配置层,业务逻辑保持稳定,降低变更风险。

4. 重试与告警分级匹配:可重试错误(超时、限流)与不可重试错误(业务校验、映射缺失)应走不同分支,避免无效重试消耗配额或掩盖真因。

5. 隐私设计前置:方案在设计阶段即明确不落地企业名称、API Key、租户 ID 等敏感信息,所有环境相关参数通过配置注入,有利于在多环境交付与版本复用。

结语

风险供应商转正管理是基础资料集成中一个典型场景:数据量不大、但对状态一致性与时效性要求较高。通过清晰的阶段划分、显式的依赖声明与分级的异常处理策略,可以将跨系统的状态联动收敛到可观测、可重试、可告警的运行轨道上。本文给出的四策略、两阶段结构,亦可作为其它「状态变更 + 审批回写」类基础资料集成的参考模板。