详解客商主数据的输入及相关管理

客商主数据（客户、供应商、既是客户也是供应商）是企业最常用的主数据类型之一，因在主数据管理层面客户和供应商思路基本一样，所以本文以供应商为例介绍。

先说供应商数据，供应商主数据除了真正在供应商关系管理系统SRM、采购系统、电商等系统或者模块中管理的典型供应商数据外，在财务管理中，只要是我方需要向其支付款项的都是供应商，那么部分业务场景下企业需要向个人支付时，这类个人也是供应商的角色（以下简称“个人供应商”），也需要按主数据管理。此外，在一般情况下，主数据是业务实体数据的子集，比如在SRM系统中对供应商做全方位管理时会包括大量的字段，而属于主数据范畴的字段可能只是其中二十几个。

一般情况下，新增供应商时建议用户先在MDM中查询主数据是否已存在，因为很多时候其他用户此前已输入过，但现实中用户往往还是会习惯性的直接输入。无论用户是否会先查询，在用户输入时MDM系统应首先在数据库中查询该供应商主数据是否已存在，如存在则提示用户主数据已存在是否需要修改等。

此前输入供应商主数据时，供应商名称、统一社会信用代码等内容的准确性检查一直是件头疼的事，严谨的企业会要求上传供应商的工商营业执照等扫描件，在审核时人工比对，在数据量比较大的情况下，主数据管理人员的工作负荷比较大，人工比对也会难免出现较多失误，此前见过的一些案例，大型集团企业在处理全集团的主数据时有些情况下需要第二天才能审核通过。于是后来应用了OCR，影像识别后将扫描件上的企业名称等结构化，之后与用户手工输入的名称进行主动比对，只有比对发现异常时才提示管理人员干预，处理效率和准确性大大提高。

以下的案例来自于我几年前看过的《国家电网公司主数据管理系统功能优化研究》一文。当用户对供应商主数据提出申请后，将通过省（市）公司运维和总部主数据运维两级审批，审批通过后将创建或更新主数据。经统计，仅2014 年通过主数据管理平台申请创建和更新的供应商主数据就有82000 条， 其中公司类数据占到90%以上， 而该类数据需上传的信息包括组织机构代码证、税务登记证、营业执照三类电子扫描图片， 两级审批人员都需对这三项信息进行人工对比审核，效率低且需大量的人力支持。总部运维情况如表1 所示。[1]

在供应商主数据审批功能优化中， 利用两种技术对一副图片的识别审批速度都在1 秒左右， 对应于供应商的公司类数据三份必须资料， 利用两项技术独立串行审批需6 秒左右，并行审批只需3 秒左右。对于这三份必须资料，两次自动审批都通过的比率大概占到60%左右，而转人工审批的资料文件中，存在关键字段字体重叠、印刷位置错误等现象而无法自动审批的文件占50%左右。即机器总的审批数能占到80%左右。机器辅助审批工作量统计见表4，效率提升统计见表5。[1]

因为征信平台提供的商业服务可被信任，于是按上述方式获得的数据是准确的，所以在主数据管理层面或许可以不再上传供应商资料影像件，不再需要基础性的审核。但对个人供应商和境外供应商通常还是需要人工审核的，个人供应商一是数量相对较少，二是没有常规的个人征信服务，那么在输入姓名和身份证号等信息时存在出错的可能性，而大多数的情况下也不能拿到个人供应商的身份证原件，那么对身份证影像件的OCR可以一定程度上实现自动化，但人工审核往往还是需要的；对境外供应商，目前也没有类似国内供应商的18位信用代码，而国际上虽然有邓白氏码，但很多境外供应商因为规模等原因也不一定会注册邓白氏码，那么一般情况下只能通过供应商名称作为唯一性判断条件，这就存在输入错误、外文字符等各种异常状况，一般情况下也需要人工审核。

邓白氏在中国开展业务的官网页面

再补充一点MDM系统查重校验的内容（MDM系统应在软件功能上最大限度的保证主数据的唯一性），对国内常规的组织机构可以通过机构名称（如企业名称）加上18位统一社会信用代码两个条件去复合查重；而对境外的组织机构，现阶段只能以名称进行查重判断；对于个人供应商，因为姓名重名的几率非常大，所以需要按身份证件的类型，以身份证件号码做查重判断，比如居民身份证编号等，综上，需要根据不同的客商主数据类型按不同的查重规则做判断。

当主数据经过一系列校验以及审核，达到规定的数据质量标准后，MDM系统按规则为主数据生成唯一性的主数据编码（这个操作以下简称为“赋码”），随后将主数据推送给所有目标系统，主数据新增完成。

征信服务不仅在主数据输入时有用，因为供应商存在企业名称等内容的信息变更，那么在主数据的日常管理工作中，可以调用征信服务接口定时对MDM库内的主数据做检查，发现库内数据与征信平台不一致时要提示管理人员做后续的处理。

在第三方系统中输入供应商主数据

如果把第三方系统作为主数据的输入端，那么第三方系统应具备上述MDM系统输入主数据时所需的全部功能，并在此基础上开发与MDM系统集成的一系列接口和功能。首先，因为第三方系统与MDM系统是独立的两套系统，数据库也是各自的，那么就可能存在两个数据库中数据不一致的情况，特别是如果有多个供应商主数据入口（含个别直接在MDM系统输入主数据的情况），很可能出现两个数据库中数据数量不一样的情况，比如第三方系统中没有的主数据但在MDM系统中有，那么第三方系统判断主数据是否存在的功能就不能只检查自己的数据库，还需要开发一个接口去MDM系统中做查询（查重逻辑与MDM系统中的一致），如果在MDM系统中没有才认为是真的没有，如果有，则需要一个机制做数据同步。

当供应商主数据在第三方系统中经过一系列校验成功录入后，需要由第三方系统进行如上的审核使主数据进一步符合质量要求，这个审核可能需要管理或者业务方的参与，比如财务部门。当主数据审核通过后，第三方系统需要开发一个接口把主数据推送给MDM系统，无论采用同步接口还是异步接口，都需要保障数据推送的可靠性，只有第三方系统成功的从MDM系统收到正确的反馈时才认为主数据被成功送达。为此，需要第三方系统开发有接口监控的功能，以监控向MDM系统推送和接收数据的状态，在包括网络、系统、企业服务总线等出现异常时可以掌握情况并做处置。

这个接口还需要支持实时或者定时的推送控制，常规情况下，达到标准的供应商主数据应实时推送给MDM系统，之后再由MDM系统推送给各个用户系统，有些业务场景对主数据的时效性是有要求的。并且，当推送遇到异常时，第三方系统可以批量的重新发起推送。此外，第三方系统应记录所有与MDM系统的交互日志，一旦交互异常，可以加以分析和处理。

在第三方系统作为主数据输入的情况下，主数据编码的产生也需要予以重点关注。如果第三方系统是明确唯一的主数据入口，那么原则上主数据编码可以由第三方系统赋码，如果不能确保主数据入口的唯一性，即当前第三方系统不是唯一的供应商主数据入口，那么通常就只能由MDM系统赋码了。对于后一种情况，相当于在第三方系统中产生的主数据是半成品，因为缺少最关键的主数据编码，主数据编码必须由MDM系统赋码并返回给第三方系统，于是就需要再开发一个接口用于返回主数据编码。

此时又分为两种情况，第一种是第三方系统有自己的编码体系，并且这个编码体系作用于第三方系统的业务功能，只能使用第三方系统自己的编码，只是为了需要与其他系统集成应用，与其他系统数据交换时需要采用主数据编码，于是主数据编码可被认为是第三方系统中供应商数据的一个功能性字段，当第三方系统按供应商主数据的标准把数据推送给MDM系统后产生了主数据编码后，通过接口把主数据编码反填至第三方系统的对应字段中，这个对主数据编码字段的反填接口通常是需要按非主数据编码的一个字段进行判断的（因为此时第三方系统还没有主数据编码），比如国内供应商可以按18位信用代码，此时需要第三方系统和主数据系统务必做好数据唯一性的管理。

另外一种情况是，第三方系统可以不使用自己的编码体系，完全依赖于MDM系统的赋码，此时，第三方系统刚录入的供应商主数据可以采用一个临时编码，临时编码与数据一并发给MDM系统，MDM系统成功返回主数据编码后，第三方系统根据这个临时编码去查找到对应的供应商数据并把临时编码替换为正式的主数据编码。这两种情况适用于不同的应用场景，具体按系统情况决定，但无论哪种情况，主数据编码返回到第三方系统后的更新接口需要特别的严谨和可靠，需要纳入到接口监控的范围中，以保障主数据和主数据编码的唯一性。

上述是供应商主数据新增时的一些管理内容，那么因为第三方系统是供应商主数据的入口，那不仅是新增时的管理，对主数据修改的管理也是第三方系统需要承担的工作内容，也需要第三方系统开发一系列接口用于数据的修改，主数据修改的接口可以直接使用主数据编码在第三方系统和MDM系统中定位到数据，同时仍然需要对接口做重点的监控，保障MDM系统中的主数据成功得到了修改才行。

综上所述，本文以供应商主数据为例，介绍了在MDM系统和第三方系统中输入主数据时常规的一些管理内容，在具体实践中，在不同企业、不同系统情况、不同应用场景下，会有更多的技术细节需要具体关注。

金蝶软件官网 http://www.3rensoft.com

金蝶软件产品网 http://www.winerp.cn

西安金蝶精斗云 http://www.ijdy.cLoud

西安金蝶云  http://www.ikingdee.cloud

西安（陕西）地区金蝶软件销售及服务咨询

西安三人行云计算有限公司

销售咨询电话：029-88455355

技术咨询电话：029-88455366