3. 合规记录基础:供应商合规记录的类型、数据来源与采集方式

供应商合规记录是主数据异常排查的第一道防线。合规记录并非单一维度的“黑名单”查询,而是由资质、授权、负面记录三大类构成的立体数据体系。每一类记录的数据来源、采集频率与更新机制各不相同,联合分析才能形成完整的合规画像。

3.1 合规记录三大类型

类型 核心内容 典型字段 更新频率
资质类 供应商合法经营的基础证照与行业许可 统一社会信用代码、营业执照有效期、安全生产许可证、ISO 体系认证 年度/证照到期前
授权类 品牌方/原厂授予的销售、代理、服务权限 授权书编号、授权范围(区域/产品线)、授权有效期、一级/二级代理标识 按授权周期(通常1年)
负面记录类 行政处罚、司法诉讼、行业黑名单、失信被执行人 处罚机关、处罚日期、案由、黑名单来源、失信等级 实时/每日增量
实务提示:资质类记录是“准入门槛”,授权类记录是“业务范围边界”,负面记录是“风险信号”。三者缺一不可,仅凭营业执照有效不能判定供应商合规。

3.2 数据来源与采集方式

合规记录的数据源可归纳为内部系统与外部接口两大类。内部系统提供基础主数据,外部接口提供动态风险信号。下表对比了主要数据来源及其采集方式:

数据来源 采集方式 数据类型 实时性
ERP/SCM 供应商主数据模块 API 接口 / 数据库直连 资质类、授权类 T+1
国家企业信用信息公示系统 RPA 爬取 / 官方 API 负面记录类(行政处罚、经营异常) 每日
中国裁判文书网 / 执行信息公开网 RPA + OCR 识别 负面记录类(诉讼、失信) 每日
行业黑名单共享平台(如招投标信用平台) WebService / 文件交换 负面记录类(行业禁入) 实时
供应商自荐/电子采购平台 供应商自助上传 + 人工审核 资质类、授权类 按需
采集方式选择原则:对于资质与授权类记录,优先采用API 接口实现系统间自动同步,减少人工录入错误;对于负面记录,建议采用RPA + 结构化数据接口组合方式,兼顾覆盖度与时效性。

3.3 合规记录数据采集架构

下图展示了合规记录从多源采集到统一存储的典型架构。该架构强调“采集层-清洗层-存储层”三层分离,确保数据可追溯、可重跑。

合规记录数据采集架构 合规记录数据采集架构 ERP/SCM 主数据 国家企业信用系统 裁判文书/执行网 行业黑名单平台 采集与清洗层 API 调度 · RPA 执行 · 数据标准化 · 去重校验 合规记录存储层 资质表 · 授权表 · 负面记录表 · 变更日志表 合规预警 · 主数据异常排查 · 供应商评分 采集频率 每日增量 + 全量周

3.4 采集方式对比与选型建议

不同数据源的技术成熟度与维护成本差异较大。以下对比表帮助团队根据自身IT能力选择采集方式:

采集方式 适用场景 优点 缺点 推荐指数
官方 API 国家企业信用信息公示系统、天眼查/企查查等商业数据平台 数据结构化、稳定、合规 需申请权限、有调用次数限制 ★★★★★
RPA 爬取 裁判文书网、地方公共资源交易中心 覆盖无API的网站、灵活 维护成本高、易受网站改版影响 ★★★☆☆
文件交换(SFTP/EDI) 行业黑名单共享平台、集团内部系统 批量传输、适合大数据量 实时性差、需双方约定格式 ★★★★☆
供应商自助上传 资质证照、授权书首次注册 减轻采购团队负担、源头数据 需人工审核真伪、存在PS风险 ★★★☆☆
常见陷阱:仅依赖“供应商自助上传”作为唯一数据源,会导致合规记录严重滞后且真实性存疑。建议将自助上传作为初始录入手段,后续通过外部接口自动核验证照有效期与状态。

3.5 合规记录字段标准化示例

为保障多源数据能够合并分析,必须对关键字段进行标准化映射。以下以“负面记录”为例展示标准化结构:

-- 负面记录标准化表结构(示例)
CREATE TABLE supplier_compliance_negative (
    record_id          VARCHAR(32) PRIMARY KEY,          -- 全局唯一ID
    supplier_code      VARCHAR(20) NOT NULL,             -- 供应商编码(内部主数据)
    source_system      VARCHAR(50),                      -- 数据来源(如:gsxt、wenshu、blacklist)
    record_type        VARCHAR(20),                      -- 记录类型:行政处罚/失信被执行人/行业禁入
    penalty_date       DATE,                             -- 处罚/判决日期
    penalty_reason     TEXT,                             -- 案由/处罚原因
    penalty_level      VARCHAR(10),                      -- 严重程度:高/中/低
    valid_until        DATE,                             -- 有效期(如有)
    etl_timestamp      TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
关键设计要点:source_system 字段用于追溯数据来源,便于排查数据冲突;record_type 字段采用枚举值,避免自由文本导致的统计偏差;etl_timestamp 记录采集时间,支持数据回滚与重跑。

3.6 合规记录与主数据异常排查的关联

合规记录是主数据异常排查的触发信号。当以下场景出现时,合规记录应自动触发主数据复核流程:

  • 资质过期:营业执照或行业许可证到期前30天,标记主数据“待复核”。
  • 授权变更:品牌方授权范围缩小或取消,需同步更新主数据中的“授权产品线”字段。
  • 负面记录新增:供应商被列入失信被执行人或行政处罚,主数据状态自动降级为“观察/冻结”。
  • 多源冲突:内部系统显示资质有效,但外部接口返回“注销”状态,触发人工核查。

下图展示了合规记录变化如何驱动主数据状态变更的闭环流程:

合规记录驱动主数据状态变更流程 合规记录 → 主数据状态变更闭环 合规记录更新 规则引擎判断 主数据状态变更 通知采购/风控 人工复核确认 更新合规记录状态 闭环要点:合规记录变更 → 自动触发主数据状态调整 → 通知人工复核 → 复核结果回写合规记录 确保合规记录与主数据始终保持最终一致
最佳实践:建议在合规记录表中增加“last_sync_status”字段,记录每次与外部接口的同步结果(成功/失败/超时),便于监控采集链路健康度。当连续3次同步失败时,自动告警IT运维团队。