金蝶云·星空旗舰版物料主数据同步到小满OKKICRM:实战教程
这个策略解决什么问题
某零售企业的物料主数据长期沉淀在金蝶云·星空旗舰版,但销售团队日常用的是小满OKKICRM,报价单、产品选择都要从CRM里挑。物料一旦在ERP里改了名称、改了规格、下了架,CRM这边如果还显示老信息,前端销售拿着错误资料跟客户谈单,回来对不上账。
这条策略要解决的就是:让CRM里的产品数据跟ERP里的物料主数据保持一致,做到「ERP改一处,CRM跟着变」。我们用轻易云数据集成平台(Qeasy)来做承接,核心思路是金蝶作为唯一可信源,小满作为消费方,单向同步。
数据流向与字段映射
数据流向分三段:金蝶云·星空旗舰版 → 轻易云集成平台中间层 → 小满OKKICRM。中间层不长期落库,主要做字段清洗、编码映射、字段类型转换。
| 业务含义 | 金蝶云·星空旗舰版(源) | 轻易云中间层 | 小满OKKICRM(目标) |
|---|---|---|---|
| 物料编码 | FNumber | material_code | product_code |
| 物料名称 | FName | material_name | product_name |
| 规格型号 | FSpecification | spec | spec |
| 基本单位 | FBaseUnit | unit | unit |
| 默认仓库 | FDefaultStock | default_warehouse_id | warehouse_code |
| 启用状态 | FUseOrgId / FForbidStatus | is_active(0/1) | status(active/inactive) |
| 分类编码 | FCategoryId | category_code | category_code |
有几点要在中间层显式处理:
- 编码映射集中管理:金蝶的仓库编码、分类编码、小满那边的编码往往不是一一对应,务必在轻易云里建一张映射表,不要在每条同步里硬编码。
- 启用状态要做归一化,金蝶用组织+禁用标记组合判断,小满只要一个布尔值。
- 名称里的全角符号、特殊字符在中间层清洗掉,避免CRM端入库失败。
在轻易云上如何配置
在轻易云数据集成平台里,这条策略拆成两个动作:一个查询动作(Query)从金蝶拉数,一个写入动作(Write)推到小满。
配置要点:
- 数据源连接:金蝶侧用轻易云自带的金蝶云·星空旗舰版连接器,填好接口地址和认证信息;小满侧用OKKI CRM连接器。
- 查询策略:拉金蝶的物料列表,推荐用
FModifiedDate作为增量游标,首次跑全量,之后按修改时间增量。 - 字段映射:在轻易云的映射画布里,把源字段拖到目标字段,中间层字段命名遵循 snake_case,方便后续维护。
- 编码映射组件:仓库、分类、单位的映射都走轻易云的「查表」组件,映射表单独维护,字段改动不用改主流程。
- 写入策略:推小满时,先按编码做匹配,匹配上就更新,匹配不上就新增。这是典型的「增量与全量双轨」模式,客户现场用下来比较稳。
- 异常处理:轻易云的任务里要勾上「失败重试」「错误数据写入异常队列」,跑批后看一眼异常队列是基本动作。
实施步骤
我们通常分三个阶段推进:
阶段一:全量初始化 手工触发一次全量同步,把金蝶现有的物料一次性灌到小满。这一步建议放在业务低峰期,先在测试环境跑一遍,核对两边数据条数和关键字段。
阶段二:增量起点标定 全量跑完之后,记录金蝶那边最大修改时间作为增量起点。轻易云的调度配置里把这个时间戳写入「上次同步时间」变量,后续按这个变量做增量。
阶段三:调度频率上线 物料主数据不像订单那样实时,一般每15分钟或每小时跑一次足够。轻易云的调度策略里配置cron表达式,工作时间内跑,非工作时间可以暂停,避免无效日志堆积。
上线第一周,建议每天人工抽查一次两边物料数量和几个抽样字段,确认无误后转入自动化运行。
踩坑复盘
- 坑1:编码映射没集中管理。早期有客户把仓库映射直接写在每条同步的脚本里,后来业务调整,要改10条策略的脚本,改到崩溃。后来全部迁移到轻易云的「查表」组件集中维护,一处改全处生效。
- 坑2:启用状态判断漏了组织维度。金蝶的禁用状态是按组织隔离的,某零售企业全国有多组织,一个物料在A组织禁用、在B组织启用,不能简单看一个标志位。稳妥的做法是按目标组织逐一判断。
- 坑3:全量和增量混跑导致重复。全量跑完没及时更新增量起点,导致同一批数据被增量又跑了一遍。一定要在全量结束事件里强制刷新增量起点。
- 坑4:单位、规格里的特殊字符。金蝶那边物料名称里偶尔有全角括号、特殊符号,小满CRM端校验严格,容易写入失败。中间层必须做一次字符清洗。
- 坑5:小满侧的限流。小满API有调用频率限制,大批量写入时容易触发限流返回429。轻易云的写入端要做批量拆分和退避重试。
适用场景与不适用场景
适用:ERP作为主数据源、CRM作为消费方的企业;物料主数据变更频率不高(天级或小时级);对数据一致性要求高、不允许两端长期漂移。
不适用:CRM侧需要做业务加工后再回写ERP的场景;对实时性要求秒级响应的场景;物料结构差异巨大、需要双主数据管理的场景。