供应商主数据清洗与维护

名称相似不一定是同一家，同一主体也可能因采购组织或结算用途拥有多个编码。WorkBuddy 可发现异常、整理映射与变更草稿，不能直接合并档案或更改账户。

本篇同时覆盖联系人信息维护，使用脱敏导出表，尚未在真实 WorkBuddy 账号验证。

准备可恢复的导出资料

保留原始导出及记录号，提供字段规范、采购组织说明、已知错误样例。字段包括供应商编码、法定名称、主体识别码、别名、地址、联系人角色、资料日期及业务状态；计划参数按需要加入交期、最小起订等定义。

银行账号、证件号和无关个人信息不上传。敏感账户只用“是否需要人工核验”状态，本流程不验证付款账户。

第一步：确认字段规范

根据样表与公司规范建立字段字典。
列字段含义、类型、必填条件、格式、来源、负责人及更新条件。
区分主体识别、组织用途、联系人、商务和计划参数。
未批准规范标待确认，不修改原始值。编号保留为文本，不能丢前导零。

人确认哪些为主体唯一标识、哪些只是系统用途。不能用联系人电话或简称作为合并依据；名称变更需证明，不能直接写成新公司。

第二步：生成异常及疑似重复清单

按确认规范检查导出表，保留原记录号。
输出字段缺失/格式异常表和疑似重复组。
每组列原编号、识别码、名称、组织用途、相同点、差异、建议核验。
相似名称只标疑似；识别码相同也先核组织用途和历史关联。
不合并、不删除、不推测缺失信用代码和联系方式。

人工核对不同主体、总部与分支、曾用名、采购组织和未结业务。重复判定与是否可以合并是两个问题；即使同主体，也可能需要保留多个用途记录。

第三步：确认清洗和映射草稿

逐组写明“保留、建议归并、分开管理、待核实”，附确认人及依据，交回 AI：

只依据人工确认结果生成清洗建议表。
列原编号、原值、建议值、原因、证据、确认状态、生效日期待填。
如允许归并，另列原码到建议主码映射，以及历史订单、付款、合同关联需系统负责人核查的待办。
未确认项保持原值，不把建议称为已执行。

教学假设：两记录信用代码相同，但分别用于两采购组织。先标同主体多用途，人员判断是否可共用，不因为“同号”就删其中一条。

第四步：补上日常维护规则

依据已批准规范起草供应商信息维护单。
涵盖创建、名称变更、联系人/授权变更、计划参数修订、停用。
列申请事项、变更前后、依据、所需核验、负责人、审批与生效日。
银行账户等敏感变更仅列人工双核待办，不生成账户值。
保留历史版本，停用不等于删除，不修改系统。

联系人离职时确认新对接人与权限，不能只收到一封邮件就认可新授权。交期、起订量等参数以合同和业务确认更新，避免旧订单突然套用新规则。

检查与系统执行边界

交付异常表、确认后的建议表、编号映射及维护单。原记录都能追溯，未确认项未被改写，重要字段有依据与生效日。数据负责人先检查影响，再按系统流程实施；执行后只验证批准范围，历史关联不能丢。

信用代码缺失先补核，数据版本冲突保留双方，联系人更新与账户更新分开处理。账户变更由财务按公司双核流程完成，AI 输出不能作为付款依据。