主数据同步策略:商品/客户/供应商的唯一真相源

主数据为什么必须先治

交易数据(订单、出入库单)的集成出问题时,排查到最后,一大半是主数据问题:商品编码对不上、客户档案重复、供应商名称一个系统一个写法。交易数据是"流",主数据是"河床";河床不平,水流必然乱。

第一原则:每类主数据只有一个主系统

唯一真相源(Single Source of Truth)的前提是分工明确:

其余系统全部是"订阅方":只读、不创建、不修改主数据,本地只做映射缓存。

编码体系:主数据的地基

主数据同步失败的头号原因是编码不统一。建议的规则:

1. 主系统内码不外泄:ERP 的物料内码是数据库主键,同步给外部系统时映射为业务编码(SKU 编码);
2. 业务编码全局唯一、不可复用:停用的 SKU 编码永久退役,不回收给新品;
3. 建立交叉映射表:每个订阅系统存"本系统编码 ↔ 主系统编码"的映射,新 SKU 先建映射再开卖。

同步策略选择

• 全量定期同步:适合供应商、仓库等低频变化的主数据,每天凌晨跑一次对账式同步;
• 增量同步:商品、客户按修改时间戳增量,10-30 分钟一次,注意时钟漂移;
• 事件驱动:新品建档、客户授信变更等关键事件实时推送(Webhook),其余仍走定时增量兜底。

实践中最稳的组合是:事件驱动做实时,定时增量做兜底,每日全量做对账。

冲突仲裁规则

多系统都可能"看起来能改"主数据时,必须提前定仲裁规则:主系统为准,订阅系统的本地修改在下次同步时被覆盖,并产生一条差异告警;订阅系统侧对主数据字段做只读控制(界面置灰),从交互上杜绝本地修改。仲裁规则没有技术含量,难的是让各业务方签字认账——这是治理问题,不是技术问题。

落地检查清单

1. 每类主数据是否明确了唯一主系统?
2. 交叉映射表是否有 owner、有新增流程?
3. 停用/归档主数据在订阅系统如何表现?
4. 主数据同步失败有没有告警,还是等业务报错才发现?
5. 每日全量对账的差异有没有闭环处理人?