经销商主数据治理:编码、分级、信用档案

为什么经销商主数据总是最先烂掉

经销商档案散落在 CRM、ERP、DMS、返利系统里,各录各的:同一个经销商三个名字、两个编码,地址一个是注册地一个是收货地;经销商换了主体(注销重开),系统里还挂着旧档案继续下单。订单、库存、返利数据接回来对不上,十有八九是主数据先出了问题。

主数据治理的目标很朴素:一个经销商,全公司一个编码、一份档案、一套状态。

第一层:编码规则

经销商编码要满足三个要求:无业务含义(防改)、全局唯一、可机读。推荐结构:

D + 4位区域码 + 4位顺序号    示例:D31010023

几条纪律:

1. 编码不含等级、品类等会变动的属性——经销商从二级升一级,编码不能跟着变。
2. 换主体(新公司承接老业务)必须新发编码,用“承继关系”字段关联旧编码,保证历史数据可追溯。
3. 编码发放收敛到一个入口(主数据平台或 ERP),禁止各系统自造编码。

第二层:属性模型与分级

经销商档案建议分四组属性:

分级模型

按年度协议量、覆盖终端数、资金能力把经销商分为核心 / 重点 / 一般三级(或 A/B/C),等级驱动差异化政策:账期、返利阶梯、数据上报要求(如核心经销商必须 API 直连)。等级每年评审一次,评审过程留痕。

第三层:信用档案

信用档案 = 静态授信 + 动态行为:

1. 授信要素:初始信用额度、账期,由财务与渠道共同核定,写入 ERP 作为订单校验依据。
2. 行为数据:回款及时率、订单履约率、退货率、窜货违规记录——这些数据全部来自已经打通的业务链路,每日增量归集。
3. 动态调整:触发规则自动调整,如“连续两季度回款及时率 < 90% → 账期缩半并预警渠道经理”。

信用档案的价值在于把“感觉这家经销商不太对”变成可量化、可追溯的风险视图。

变更流程:主数据的生命周期

• 新增:业务员发起 → 资质校验(证照 O 位、黑名单比对)→ 编码发放 → 同步下游系统。
• 变更:分级、区域、额度等关键字段走审批流;变更事件以消息方式通知 DMS、返利系统等订阅方,保证各系统同日生效。
• 停用 / 退出:先做业务校验(无在途订单、无未结返利、无欠款),再置停用状态;停用不删除,历史单据永久可追溯。

集成要点

1. 主数据的权威源唯一(建议主数据平台或 ERP),其他系统只订阅不修改。
2. 同步用“变更事件 + 定期全量校准”双保险:事件保证时效,每日全量比对兜住丢失的变更。
3. 下游系统的本地冗余字段(如经销商名称快照)不随主数据回改——历史单据上的名称必须是交易发生时的名称。

小结

经销商主数据治理没有高深技术,难在纪律:编码入口唯一、权威源唯一、变更走流程、停用不删除。这四条守住,上面的订单、库存、返利、窜货监控才有可靠的地基。