- 输入数据
- 供应商主数据、员工信息、付款明细
- 核心方法
- 交叉比对 + 字符串相似度
- 输出物
- 异常供应商清单
虚构供应商、员工把自己的账户挂成供应商、同一家公司在系统里建了两个编码，这些问题不在付款单上，而在供应商主数据里。这个模型把供应商主数据和员工信息放在一起比对，用五条规则找出需要核实的供应商。结果是疑点清单，不是舞弊结论。
适用场景
- 主数据定期体检：每季度对全部启用和停用的供应商跑一遍。
- 新增供应商审核：新建或修改银行账号、联系电话后立即比对。
- 舞弊风险排查：内部审计在付款检查之前，先排除「供应商本身有问题」的情况。
输入数据要求
两张表：供应商主数据和员工信息。
| 表 | 字段 | 是否必需 | 说明 |
|---|---|---|---|
| 供应商 | 供应商编码、供应商名称 | 必需 | 名称用于判断疑似重复 |
| 供应商 | 银行账号、联系电话 | 必需 | 必须按文本读取，否则长数字会被改写 |
| 供应商 | 状态、最近付款日期 | 必需 | 状态取值启用、停用 |
| 供应商 | 开户行、注册地址、创建日期 | 可选 | 只带到结果里方便核实 |
| 员工 | 员工编号、姓名、银行账号、手机号 | 必需 | 员工银行账号一般取自工资发放账户 |
| 员工 | 部门、住址 | 可选 |
员工信息属于个人敏感信息。使用前确认数据授权范围，结果只在审计或内控人员之间流转。
判定规则
| 规则 | 条件 | 风险 |
|---|---|---|
| V1 员工与供应商账号相同 | 供应商银行账号等于某员工银行账号 | 高 |
| V2 员工与供应商电话相同 | 供应商联系电话等于某员工手机号 | 高 |
| V3 多个供应商共用账号 | 同一银行账号对应两家及以上供应商 | 高 |
| V4 疑似重复供应商 | 名称规范化后相同：去掉「（示例）」、括号、空格，以及结尾的「股份有限公司」「有限责任公司」「有限公司」「公司」 | 中 |
| V5 停用后仍有付款 | 状态为停用，但最近付款日期在检查期起点（2026-01-01）之后 | 中 |
五条规则相互独立，同一家供应商可以命中多条。V3、V4 这类分组规则，组内每家供应商都输出一行。
工作流步骤
节点按 KNIME 英文名给出，iModel 中文界面的节点名以你所用的版本为准。示例数据已放在工作流内，导入后直接执行即可。五条规则各走一个分支，最后合并。
- 读取供应商与员工CSV Reader
- V1 账号比对Joiner
- V2 电话比对Joiner
- V3 共用账号GroupBy
- V4 名称规范化后重复String Manipulation
- V5 停用后付款Row Filter
- 合并五个分支Concatenate
- 输出疑点清单CSV Writer
- 读取两张表CSV Reader
读取
vendors.csv与employees.csv；账号、电话、编码类字段全部设为文本。 - V1 账号比对Joiner
供应商「银行账号」与员工「银行账号」内连接。
- V2 电话比对Joiner
供应商「联系电话」与员工「手机号」内连接。
- V3 共用账号GroupByRow FilterJoiner
供应商按「银行账号」分组计数，保留大于等于 2 的账号，再与供应商表内连接取回每一家。
- V4 疑似重复String ManipulationGroupByRow FilterJoiner
新增「规范化名称」：
regexReplace($供应商名称$, "\\s|（示例）|[（）()]|股份有限公司|有限责任公司|有限公司|公司", "")
按规范化名称分组计数，保留大于等于 2 的组，再取回每一家。正则里较长的后缀要写在较短的前面。 - V5 停用后付款String to Date&TimeRow Filter
保留「状态」为停用且「最近付款日期」不早于检查期起点的供应商。
- 合并输出Constant Value ColumnConcatenateSorterCSV Writer
每个分支整理为「命中规则、风险等级、供应商编码、供应商名称、关联对象、匹配字段、匹配值」七列后合并，按风险等级、规则、供应商编码排序，写出结果文件。
参数
| 参数 | 默认值 | 作用 | 怎么调 |
|---|---|---|---|
| 检查期起点 | 2026-01-01 | V5 判断停用后付款的起点 | 有停用日期字段时，改为比较「最近付款日期 > 停用日期」更准确 |
| 名称规范化规则 | 去掉示例标记、括号、空格与公司后缀 | V4 的判断依据 | 按本单位供应商命名习惯补充，如「集团」「分公司」 |
用示例数据验证
运行后结果应与示例数据包里的 expected_result.csv 完全一致。
| 命中规则 | 风险 | 供应商 | 名称 | 关联对象 | 匹配字段 | 匹配值 |
|---|---|---|---|---|---|---|
| V1 员工与供应商账号相同 | 高 | V008 | （示例）西南盛远建筑材料有限公司 | E003 韩冰 | 银行账号 | 6222761570946213 |
| V1 员工与供应商账号相同 | 高 | V034 | （示例）西北盛华信息技术股份有限公司 | E012 彭博 | 银行账号 | 6222438293723743 |
| V2 员工与供应商电话相同 | 高 | V020 | （示例）西南德丰机械配件有限公司 | E001 林悦 | 联系电话 | 13253420596 |
| V3 多个供应商共用账号 | 高 | V013 | （示例）西北恒远印刷服务有限公司 | 共 2 家 | 银行账号 | 6222189185294698 |
| V3 多个供应商共用账号 | 高 | V046 | （示例）华东达通信息技术有限责任公司 | 共 2 家 | 银行账号 | 6222189185294698 |
| V4 疑似重复供应商 | 中 | V004 | （示例）华南盛远信息技术有限公司 | 共 2 家 | 规范化名称 | 华南盛远信息技术 |
| V4 疑似重复供应商 | 中 | V010 | （示例）西北信通化工原料有限责任公司 | 共 2 家 | 规范化名称 | 西北信通化工原料 |
| V4 疑似重复供应商 | 中 | V029 | （示例）华南盛远信息技术公司 | 共 2 家 | 规范化名称 | 华南盛远信息技术 |
| V4 疑似重复供应商 | 中 | V056 | （示例）西北 信通化工原料有限公司 | 共 2 家 | 规范化名称 | 西北信通化工原料 |
| V5 停用后仍有付款 | 中 | V016 | （示例）西北泰和电子元件股份有限公司 | 最近付款日期 | 2026-03-18 | |
| V5 停用后仍有付款 | 中 | V038 | （示例）华北泰远物流服务有限公司 | 最近付款日期 | 2026-05-09 |
另有四类不应被标出的数据：与员工账号只差最后一位的供应商、注册地址相同但账号不同的两家供应商、名称只差地区字的两家供应商、2025 年停用且此后没有付款的供应商。
适用边界
- 只能发现字段完全一致的关联。员工用亲属账户、供应商换号码，这个模型发现不了，需要结合工商股权等外部数据。
- 地址没有比对。地址写法差异太大，直接比较误报多；需要先做地址标准化再加入。
- 名称规范化覆盖不了简称与全称。「华东包装」和「华东包装材料」不会被判为重复。
- V2 会误报共用座机或代理人电话。小型供应商常用经办人手机登记，命中后先核实联系人身份。
常见问题
员工信息拿不到怎么办？
可以只跑 V3、V4、V5 三条，它们只需要供应商主数据。
能不能做名称的模糊匹配？
可以增加字符串相似度计算，但相似度阈值需要反复调，误报较多，建议先把规范化规则做细。
主数据在 ERP 里，怎么接？
把第 1 步换成数据库读取节点，读出上表字段即可。
命中 V1 就说明员工有舞弊吗？
不一定。也可能是员工代垫后被错误建成供应商，或报销账户录错位置，需要调取建档资料核实。
