ERP 数据录入里最容易被低估的，不是“有没有重复记录”，而是企业能不能分清哪些记录确实重复、哪些只是相似，以及系统在判断错误时能不能阻止不可逆的后果。选型时如果只问厂商“有没有查重功能”，很可能买到一个会弹提示、却无法进入导入、审核、合并和追溯流程的功能点。我的判断是：数据去重不是 ERP 的附属按钮，而是检验主数据规则、录入流程、权限控制和项目责任边界的一次压力测试。
厂商介绍中出现“重复校验”“智能匹配”“自动合并”等词，并不代表这些能力覆盖同一件事。查重可能只在新增档案时弹窗提醒；可能只对某个名称字段做完全一致比较；也可能支持多字段匹配、人工复核、合并留痕和批量导入校验。它们解决的问题不同，实施成本和误判风险也不同。
因此，我不会把“有无查重”设为一个简单的勾选题，而会把它拆成几个能被现场验证的问题：在什么环节判重、按哪些字段判断、怎样处理疑似项、谁有权限确认、合并后如何追溯、导入和接口数据是否走同一套规则。回答不了这些问题，功能名称再完整，也无法说明它适不适合企业的业务。
去重结果不是软件单独决定的。系统可以执行匹配规则，却不能替企业决定“同一客户”的业务定义，也不能自动判断某个名称相似的主体是否属于同一法律实体。规则由谁制定、异常由谁复核、旧编码如何保留，都会改变最终效果。
我建议把去重能力拆成四层评估：数据标准层回答“什么字段足以识别对象”；流程层回答“在哪个节点检查、由谁处理”；系统层回答“如何匹配、提示、拦截、合并和留痕”；治理层回答“规则谁维护、误判谁纠正、结果谁负责”。四层中有一层缺位，去重就容易变成上线前集中清洗、上线后继续重复录入。
去重不是识别越积极越好。漏掉一条重复客户档案，可能让交易记录分散、报表需要人工合并；把两个不同客户误合并，则可能把合同、应收、联系人、信用额度或组织权限归到错误主体下。前者常常能被发现并补处理，后者可能带来更复杂的恢复和审计工作。
所以，选型不能只看系统能发现多少疑似重复，还要观察它如何处理不确定性。对关键主数据，系统最好允许把“明确重复”和“疑似重复”分开：前者按规则拦截或提示，后者进入人工复核；对存在明显风险的合并操作，应能预览影响范围、记录操作者，并提供可追溯的纠错路径。
主数据是业务反复引用的对象档案，例如客户、供应商、物料、员工、仓库或科目。主数据重复通常表现为同一对象有多个档案，或者不同部门用不同编码代表同一对象。它会影响后续订单、采购、库存、结算和报表的关联口径。
业务单据重复则是订单、收货、发票、付款申请等事务记录发生重复创建或重复传输。它的判定通常要结合业务编号、来源系统、发生时间、金额、状态和审批关系。一个客户档案重复，不等于客户订单重复；反过来，同一客户下出现两张订单，也不必然是重复单据。
这两类问题不能由同一个“查重开关”一概而论。主数据治理更关注识别对象、确定主记录和维护关系；单据重复控制更关注幂等处理、业务状态和重复提交拦截。选型阶段如果没有先区分数据对象，演示很容易只展示一种场景，却让人误以为系统覆盖了全部风险。
客户名称是很常见的搜索字段，但单独按名称判重有明显局限。企业名称可能出现简称、曾用名、分支机构名称、地区前缀和符号差异；也可能有不同主体恰好使用相似名称。供应商档案还可能因集团关系、开票主体和实际供货主体不同而需要分别管理。
物料也一样。两条记录可能名称相同，却在规格、材质、等级、包装单位或适用工艺上不同；也可能描述不同，但实际上是同一物料的历史编码。判重规则必须围绕业务对象建立，而不是把“名称相同”当作普遍真理。
我会要求业务团队先定义关键识别字段。例如，客户可参考统一社会信用代码、税务信息、主体名称、地址和联系方式；物料可参考物料编码、规格、型号、基本单位、品牌及分类。哪些字段是必填、哪些字段只作辅助匹配，应结合数据质量和业务风险确定。字段越多并不天然越准确，关键在于字段是否稳定、可得、可追溯。
重复记录不一定是员工重复点了两次“保存”。常见路径包括：多个部门各自建档；旧系统迁移时编码规则不一致；外部系统同步时缺少唯一标识；模板导入前没有统一校验；人员在等待审批期间重新提交；接口重试时没有识别同一请求。
这些路径对应的控制点不同。新增档案需要录入前提示或审核；批量导入需要预检、错误清单和重复项处理策略；系统集成需要明确外部主键、幂等标识和冲突处理；历史迁移则需要先做映射、清洗和数据归属确认。只在界面新增时弹窗，未必能阻止接口和导入产生重复数据。
对于中小企业，问题往往不是“数据量巨大”，而是数据来源逐步增多、旧规则沉淀下来，却没有一个明确的主数据责任人。数据量不大时，人工似乎可以兜底；等到需要跨部门汇总、对接多个系统或做历史迁移，原有差异就会集中暴露。
模糊匹配适合发现“可能有关联”的记录，却不等于可以直接合并。系统按名称相似度、地址相近或电话相同给出提示，是一项筛查能力；最终是否属于同一业务对象，还要看法律主体、交易关系、组织管理方式和企业数据政策。
例如，两条客户记录名称接近，可能是同一公司的简称与全称，也可能是母公司与子公司，或者同一品牌下的不同经销商。若匹配机制只有一个“相似度高”结果，却没有解释命中字段、处理建议和人工确认入口，用户很难判断系统依据，最后要么忽略提示，要么过度相信提示。
演示时应让厂商展示匹配依据，而不只是展示匹配结论。要看系统是否能说明哪些字段相同、哪些字段冲突、哪些字段缺失，是否能让审核人标注“确认重复”“不是重复”或“需要补充信息”。被排除的疑似项是否会重复出现，也值得一起验证。
界面新增是最容易展示的场景，却未必是企业数据进入 ERP 的主要通道。如果企业每月通过表格导入大量物料或客户，或者依赖外部系统同步，只有手工录入页面具备查重提示，就会形成“前门严、侧门宽”的控制缺口。
我会把数据入口画成一张简图，再逐一问：新增、复制、导入、接口、迁移、审批回退和历史修正是否都经过相同的校验？如果不同入口使用不同规则，谁负责维护这些规则的同步？遇到接口离线后重复重试，系统如何识别同一请求？这些问题比演示页面上有没有红色提醒更能检验适配程度。
自动合并看起来节省操作，但合并并非简单地把两行记录变成一行。系统需要确定保留哪个编码、保留哪些字段、如何处置关联单据、怎样更新接口映射，以及合并后用户是否仍能从旧编码追溯历史。不同对象的合并策略可能不同，不能只看“合并成功”的提示。
如果合并后历史订单、采购记录、库存流水或财务凭证无法按旧编码查询，或者原档案关系消失，就可能让核查变得更困难。对于存在审批、审计、外部接口和历史追踪要求的数据，人工确认、影响预览和可回滚能力通常比自动化速度更重要。
上线前清洗可以降低初始风险，却无法保证新数据以后不再重复。若录入标准没有统一、必填字段缺失、部门权限未设置、导入模板没有校验，旧数据清理得再干净，新的重复记录仍会进入系统。
更可持续的做法是将清洗和预防连起来：先识别已有问题，形成明确规则；再把规则放进新增、导入和集成流程；最后监控疑似项和误判，定期调整规则。数据治理不是一次性项目动作，而是需要明确负责人、处理时限和升级路径的日常工作。
识别率看起来直观，但如果没有样本定义、判定口径和误判成本，它就很难用于选型比较。厂商展示的测试数据可能来自经过整理的样本，而企业真正面对的数据往往有简称、空值、历史编码、跨组织关系和特殊业务例外。
评估时至少要分开看漏报、误报、人工复核量、处理时间和可追溯性。更重要的是，不要只比较“识别多少”，还要比较系统对不同风险类型的处理方式。对客户主体和供应商结算对象，误合并成本较高；对某些低风险、可逆的内部标签，企业可能接受更高程度的自动化。
不要从“系统有哪些去重功能”开始，而要从“企业有哪些关键数据对象”开始。把客户、供应商、物料、员工、仓库、账户和业务单据分别列出，再标记它们的创建渠道、更新频率、主责部门、关键识别字段和错误影响。
同一企业里，不同对象的判重规则可以完全不同。客户的法律主体识别可能依赖统一代码和税务信息；物料可能依赖编码、规格和单位；业务单据则可能依赖来源系统编号、业务状态和请求标识。若试图用统一的模糊匹配规则处理所有对象，往往会增加误报。
| 数据对象 | 常见疑似重复信号 | 重点验证的问题 | 建议处理方式 |
|---|---|---|---|
| 客户 | 名称近似、税号相同、电话或地址相同 | 能否区分同一主体、分支机构和关联公司 | 强匹配提示或拦截，疑似项由业务人员复核 |
| 供应商 | 名称相似、收款账户相同、开票信息相同 | 能否保留开票主体、供货主体和付款关系差异 | 分字段校验，涉及付款关系时提高审批等级 |
| 物料 | 规格相近、旧编码相同、名称不同但参数一致 | 能否组合型号、规格、单位和分类判断 | 建立编码映射，未经确认不自动合并库存档案 |
| 业务单据 | 来源编号相同、重复提交、金额与日期相近 | 是否支持幂等控制、状态检查和重复提交拦截 | 优先基于业务唯一标识和状态规则处理 |
强匹配通常意味着关键识别字段完全一致，且业务规则允许将其作为高置信度信号。弱匹配则是名称相似、地址相近或部分字段一致，需要额外核查。信息不足指关键字段缺失，系统无法可靠判断，应该提示补录或转人工，而不是悄悄放行或自动合并。
这里的重点不是规定所有企业都用同一套阈值，而是要求厂商说明规则如何配置、如何解释、如何调整。企业可以先以保守规则运行，收集一段时间的命中和误判，再逐步优化。若产品只允许单一阈值或固定算法，需评估它是否适合字段质量波动较大的历史数据。
查重提示之后必须有明确去向。处理人可以确认重复、排除重复、退回补充字段，或者提交更高权限人员审批。系统应记录处理意见和操作者，避免同一疑似项由不同部门重复判断，或者被忽略后持续积压。
我会特别检查几种情况：重复项被排除后，后续录入是否再次提示；规则变更后，历史排除记录是否重新进入待核查队列；合并后是否保留旧编码和来源信息；被拒绝的合并能否撤销；数据量增长后待处理队列是否可筛选和分派。功能是否存在，不如流程能不能真正闭环重要。
每个数据入口都应单独测试，而不能以一个新增页面代替所有场景。把同一组测试样本分别走手工录入、批量导入、接口同步和历史迁移流程，比较判重结果是否一致。若系统设计上入口规则不同，至少要能说明原因、风险和补救机制。
接口场景要额外测试重复发送。比如外部系统因超时重试同一请求，ERP 是否会再次建立一条记录；若外部主键变化但业务对象相同，是否能进入冲突处理；接口返回失败后再次提交，系统怎样判断前一次是否已经成功。此类问题往往不会在标准演示中主动出现，应由选型方提出测试。
“支持智能去重”无法直接验收；“对指定样本按约定字段提示疑似记录、支持人工确认、保留合并前后映射并可查询操作记录”则更接近可验证要求。验收口径应包括数据对象、样本类型、预期结果、例外处理、责任人和留痕要求。
如果厂商承诺某个准确率或效率提升，应要求同时明确测试样本来源、样本量、重复定义、人工复核方式和统计公式。没有这些条件，数字很难复现，也不适合写进项目目标。与其追求未经解释的百分比，不如把关键场景逐条验收。
下面是一个用于说明测试方法的模拟场景，不代表真实客户项目。某企业准备把销售、财务和采购系统中的客户及物料档案导入新 ERP。销售侧使用客户简称，财务侧使用开票全称，采购侧维护供应商供货名称；物料档案则同时存在旧编码、新编码和不同单位写法。
如果只按名称完全一致查重，简称和全称可能被漏掉；如果只按名称相似度合并，集团内不同法人主体又可能被误判为同一客户。物料记录中，“不锈钢螺栓 M8”与“螺栓 M8×30，304材质”可能存在关联，也可能因为长度和材质不同而必须分别保留。测试的关键不在于系统能不能显示相似记录，而在于能不能把证据解释给业务人员。
我建议每类关键对象至少准备四种测试记录：完全相同的重复记录、字段格式不同但业务上相同的记录、看起来相似但业务上不同的记录，以及关键字段缺失的记录。必要时再增加历史编码、组织关系、曾用名和接口重复提交等场景。
每条样本都记录四项结果：系统是否命中、命中理由是否可解释、处理人能否作出正确决定、处理结果能否追溯。若系统把疑似项提示得很全面，却没有分派和处置机制，实际工作仍会堆积；若系统自动合并得很快，却不能还原合并前的关系，业务风险可能更高。
验收表还要记录未命中和误命中。未命中说明规则或字段质量可能不足；误命中说明规则过宽，或者业务定义没有澄清。问题不应简单归为“系统不智能”，而要判断是数据字段缺失、规则配置不当、业务口径冲突，还是产品能力边界不适合。
| 测试样本 | 预期系统行为 | 观察记录 | 验收关注点 |
|---|---|---|---|
| 客户税号相同、名称有简称差异 | 提示高关联记录并显示命中字段 | 记录提示依据与复核动作 | 能否避免只按名称判断 |
| 集团内两个不同法人名称相近 | 允许保留独立档案，必要时显示关联关系 | 记录是否出现误拦截或误合并 | 能否区分关联企业与同一主体 |
| 物料名称相同、规格或单位不同 | 提示差异，不直接合并 | 记录关键规格字段是否参与判断 | 是否支持对象专属规则 |
| 同一接口请求重复发送 | 识别重复请求或通过幂等标识避免重复建档 | 记录第一次和重试后的结果 | 是否覆盖接口重试路径 |
测试不要只靠口头说明或临场操作。每个场景都保存脱敏样本、操作步骤、预期结果、实际结果、截图或日志编号，并记录未通过项由谁跟进。对于涉及合并和删除的场景，应先在测试环境操作，确认影响范围和恢复方式之后再评估上线方案。
若选型团队同时比较多个系统，应使用同一套样本、同一套规则目标和同一套评分口径。演示数据由厂商准备时，往往过于规整，难以暴露字段缺失和业务例外。企业自己的样本才更接近上线后将面对的真实输入，但在提供给厂商前应脱敏并控制访问。
如果企业数据量不大，主要由少数人员维护，短期内不需要复杂算法。优先统一必填字段、命名规则、编码方式和档案责任人，再确认新增时是否提示相似记录、关键字段是否有唯一约束、重复项由谁审批。
此时更重要的是把规则写清楚，并建立简短的待处理清单。对少量疑似项，人工核实可能比高成本定制更可靠。不要为了追求“智能去重”增加难以维护的配置，也不要因为数据量少就完全忽略后续导入和人员交接。
当销售、采购、财务等部门都能创建档案时，首要问题通常是“谁有权建”和“谁负责审核”。建议先确定主数据负责人、创建权限、部门可编辑范围和跨部门复核路径，再选择系统配置方式。
若多个部门必须维护各自视角的信息，可以将共享主体档案与部门属性分开管理，而不是通过创建多条主体记录来容纳不同需求。选型时要验证系统是否支持组织维度、角色权限和统一编码，也要确认部门信息能否在不复制主体档案的情况下表达。
迁移项目里，最稳妥的顺序不是把旧系统记录一股脑导入，再让新系统自动处理，而是先抽样检查字段质量、编码冲突、空值比例、历史映射和数据归属。数据剖析之后，才能确定哪些记录可以自动归并、哪些需要业务确认、哪些应保留为不同对象。
历史数据如果关联了订单、凭证、库存或合同，合并规则就必须同时考虑关联关系的保留。对无法确认的记录，宁可进入待核查队列，也不要为了赶进度把不确定判断变成不可逆的合并结果。迁移计划中要预留业务复核时间，而非只估算技术导入时间。
如果数据经常在 ERP、订单平台、仓储系统、财务系统或外部服务之间流转，单靠名称匹配不足以控制重复。应先明确每个系统的主键、外部编码、映射关系和主数据权属，再验证接口重复提交、超时重试、消息乱序和字段更新冲突的处理方式。
接口发生重试时，系统需要知道这是同一请求再次发送，还是一笔新的业务。选型演示可以模拟第一次请求成功但响应超时、随后再次提交的情况，观察是否会创建第二条记录。若产品需要额外开发才能实现，应把开发边界、测试责任和后续维护成本写进方案。
对客户结算主体、供应商付款账户、物料库存档案、财务科目等高影响对象，应采取更保守的自动化策略。系统可以主动提示和聚合证据，但涉及主体合并、账户变更或历史关联迁移时，最好有权限复核、操作留痕和影响预览。
如果业务追求快速处理，可以让系统自动处理低风险、规则明确的重复项，将不确定项集中给人工；但需要定期检查自动处理结果，并保留纠错机制。自动化比例不应成为唯一目标，降低高成本错误才是更重要的决策标准。
数据量小、对象单一、业务变化少时，轻量配置加人工复核通常够用。它的优势是实施快、规则容易理解、维护成本低；短板是对多字段匹配、跨系统映射和复杂历史数据的处理能力有限。
当数据来源多、历史迁移复杂、接口持续增加或错误可能影响结算与库存时，专项治理更有价值。它需要花时间梳理对象定义、清洗规则和责任流程，也可能涉及实施配置、数据修复和后续监控。不能只比较软件报价，还要将规则设计、数据准备、测试和长期维护成本一并估算。
自动合并适合边界清楚、关键字段稳定、错误可逆且影响有限的对象。它能减少重复操作，但需要清晰的主记录选择逻辑、关联数据处理和操作日志。若规则依赖模糊字段，自动合并带来的速度收益可能被纠错成本抵消。
人工确认适合主体身份不明确、业务影响较大或历史关联复杂的场景。它的代价是需要人员和处理时限，疑似项积压时会拖慢建档。解决办法不是取消人工，而是分级：强匹配采用拦截或快速确认，弱匹配进入队列，信息不足则要求补录。
统一规则能减少部门各自解释字段的空间，有利于汇总、接口和后续分析；但完全不允许例外，可能无法覆盖分支机构、跨境主体、特殊物料或临时业务场景。反过来，如果每个部门都能随意绕过规则，标准化也会失去意义。
较稳妥的做法是将例外变成受控流程：说明适用对象、申请理由、审批人、有效期限和后续处理方式。例外记录应能被查询和复盘，不能只靠口头授权。选型时要确认系统是否能支持例外审批、字段扩展或受控状态，而不是在标准规则和完全自由之间二选一。
提前治理会增加项目初期的梳理和测试工作，但能减少上线后跨部门核对、批量修复和历史追溯的不确定性。延后处理看起来节省预算，却可能把数据问题带入订单、库存、付款或报表流程，让修复需要更多角色共同确认。
不需要所有企业在上线前做全面主数据重构。可以先按风险分层，优先治理频繁使用、跨部门共享、影响结算或库存的对象；低频、低影响的数据可以记录问题、限定创建权限，并安排分阶段清理。关键是把“暂缓治理”也变成明确决定，写清风险接受人和复查时间。
在联系厂商前，企业可以先用一页纸写清楚关键对象、数据入口、重复风险、必须字段、疑似项处理人和不可接受的错误。这样可以减少演示过程中被功能名词带着走，也能让不同厂商面对同一组业务问题作答。
标准演示适合了解界面和基础流程，但不适合验证企业特有的数据问题。测试样本要脱敏，并由业务、实施和技术人员共同准备。样本中应包含容易判断的记录，也应包含会引发争议的边界案例。
演示时不要只看系统弹出多少条疑似记录，还要问：为什么命中？如果判断错误能否撤销？合并会影响哪些关联对象？导入失败如何定位具体行？接口重复提交会怎样？这些追问能够把抽象能力变成可以观察的操作。
有些能力是产品原生提供的，有些需要参数配置，有些要由实施团队做数据映射，还有些只能由企业制定业务规则。选型方案应把这几类工作分开列明，避免把“产品支持”误解成“项目已经包含并完成”。
同时需要明确谁负责清理旧数据、谁批准主体合并、谁维护规则、谁处理接口异常、谁定期检查积压项。如果这些责任没有落实，再完善的功能也可能无人使用。对于新增的开发或接口改造，要说明交付范围、测试方式、维护周期和升级影响。
验收时应使用事先约定的数据样本和操作步骤，记录每个场景的预期结果与实际结果。对于规则命中率等量化目标，要明确统计口径；对于误合并风险，要检查控制措施是否实际存在；对于追溯要求，要从旧记录反向查询合并关系和操作人。
如果业务规则在测试后发生变化，应更新需求和样本，不要只在会议纪要里留下“后续优化”。上线前至少要确认哪些风险已关闭、哪些由人工流程兜底、哪些暂时接受，以及出现问题时谁有权暂停导入或回退。
ERP 数据去重影响选型，原因不在于它看起来技术复杂，而在于它把企业对数据的定义、录入权限、业务责任、历史关联和异常处理全部暴露出来。只问系统有没有查重，回答的是功能名称；用企业样本测试新增、导入、接口、复核和合并，才能回答它是否适合实际业务。
我更看重三个结果：系统能否在合适的入口发现问题，能否把不确定判断交给正确的人，能否在处理完成后保留足够证据。识别数量只是其中一部分。对高风险对象，防止错误合并通常比多自动处理几条记录更重要；对低风险、规则清楚的对象，适度自动化则能减少重复劳动。
企业可以先选一个最常出问题的数据对象，例如客户或物料，整理一小批脱敏样本，覆盖完全重复、格式差异、合法相似和字段缺失四类情况。随后让候选系统分别走手工新增、批量导入和接口测试，并记录命中依据、人工处理量、错误恢复方式和操作留痕。
测试后再决定需要轻量配置、专项清洗还是更完整的治理机制。把结果写进需求、方案和验收清单，并明确企业内部的数据负责人。真正可靠的选型，不是选到一个宣称“能自动去重”的系统，而是建立一套即使遇到模糊数据、业务例外和错误判断，也能被解释、被复核、被纠正的工作机制。
我在梳理 ERP 需求时，发现不少厂商都会说系统支持查重，但演示时往往只展示相同名称的提示。我想知道，除了有没有查重按钮，我还应该检查哪些能力，才能判断它是否适合自己的业务？
别把“支持查重”当成完整答案。选型时至少要拆成四件事：系统依据什么字段判断重复、怎样处理疑似重复、谁有权确认或合并，以及合并后能否追溯和修正。只展示相同名称弹窗，无法证明系统能应对简称、字段缺失、历史编码差异等真实数据情况。
可以在演示中要求厂商用同一组样本走完新增、批量导入、疑似匹配、人工确认、合并和查询历史记录的流程。
以下是建议准备的测试场景，数量是测试设计示例，不代表行业统计： 测试场景样本设置重点观察 完全相同名称、税号、电话均相同能否提示并阻止重复新增 名称近似简称与全称，其他字段部分相同是否提示复核，而非直接合并 合法同名名称相同，税号或地址不同能否避免误判为同一主体 字段缺失名称相似，但税号、电话为空是否说明判断依据与不确定性 我的判断是，选型重点不在“识别得多积极”，而在于识别结果可解释、误判能拦截、处理过程可追溯。
若厂商只用标准演示数据，建议把自己的脱敏样本带进演示或试点。
我担心系统查重规则设得太松，会漏掉重复客户或物料；但规则设得太严，又可能把名称相似的不同公司合并。我想知道这两类错误的代价有什么不同，选型时应该怎样验证？
规则不是越严格越好，因为“漏掉重复”和“把不同对象误合并”并非同一种风险。漏判通常会留下多条档案，后续可能需要人工核对；误合并则可能把不同主体的交易、权限或历史记录混在一起，修复难度取决于系统的数据关联和撤销机制。
建议把匹配结果分成三档，而不是只设一个“重复/不重复”开关：关键标识一致时强提示或拦截；多个辅助字段相似时标记为疑似并交由人员复核；证据不足时允许新增，但留下检查线索。具体字段要按数据对象决定，客户、供应商和物料不应共用一套规则。
可以用一组明确标注为测试样本的数据做对比：例如准备 12 条客户记录，其中 4 组为完全重复、4 组为近似但不同主体、2 组为合法同名、2 组缺少关键字段。记录系统的提示、漏判、误报和人工处理步骤。这个样本用于比较系统行为，不应被包装成真实业务准确率。演示时还要追问：系统为什么判定重复？
用户能否查看命中字段？合并前是否预览关联记录？误合并后能否撤销或恢复？如果这些问题没有清晰答案，单看识别率或“智能匹配”宣传词不足以判断风险。
我正在考虑把旧系统数据导入 ERP，担心重复记录在迁移后才被发现，到时订单、客户档案和报表都要逐条核对。我想知道，测试时应该覆盖哪些导入场景，才能避免只验证了手工录入？
迁移测试不能只在系统里手动新建一条记录，再看有没有弹窗。重复数据常在批量导入、接口同步或多来源数据合并时暴露，因此应分别验证文件导入、接口写入和人工新增；还要确认系统对“已存在记录”和“同一批文件内互相重复”的处理是否一致。测试前先把样本分组，并记录每组预期结果。
比如从旧系统抽取脱敏记录，保留原编码、名称、税号或规格等必要字段，再人为加入简称、空字段、前后空格、不同单位写法等变体。不要只挑明显完全相同的数据，否则测试结果会高估规则的实际适用性。
验收时逐项记录导入结果：新增了多少条、被拦截或标记了多少条、是否出现错误合并、失败记录能否导出和重试、原系统编码能否追溯。重点不是追求一个看起来漂亮的百分比，而是确认每种异常都有可理解的处理路径，且不会静默覆盖已有数据。如果迁移规模较大，可以先做一轮小批量试导入，再由业务负责人抽查疑似匹配项。
将判重字段、异常处置人、回滚方式和数据修正责任写进迁移方案，能比上线后临时排查更容易控制风险。
我发现需求文档里写“系统应支持数据查重”，看起来有要求，实际却很难判断厂商交付是否达标。我想知道，怎样把这句话改成能演示、能验收的标准，同时区分软件功能和企业自己的数据治理责任？
“支持数据查重”太宽泛，既没有定义数据对象，也没有说明匹配规则、处理方式和验收证据。建议把要求拆成可验证的场景：对哪些档案或单据查重、匹配字段如何配置、什么情况提示或拦截、谁能确认合并、操作记录保留什么信息，以及导入和接口场景是否适用。验收口径可以采用“场景＋预期行为＋证据”的写法。
例如：对税号相同且名称不同的两条客户记录，系统应提示疑似重复并展示命中字段；未经授权用户不能合并；确认合并后应能查询操作人、时间和关联记录。对于相似名称但税号不同的样本，则要求系统进入人工复核，而非自动合并。还要把责任边界说清楚。软件方负责约定范围内的规则配置、权限和日志能力；
实施团队负责将已确认的业务规则配置到系统并组织测试；企业则需要确定主数据标准、审核责任人和日常维护流程。若企业尚未定义“什么算重复”，单靠购买软件无法自动补齐这项业务决策。建议把脱敏测试样本、预期结果、误判处理、回滚方式和验收记录作为项目附件或验收材料。
对“准确率提升”“自动清理”等笼统承诺，先要求对方说明统计口径、样本范围和异常处理方式，再决定是否写入交付指标。
读者评论
把主数据和业务单据分开评估很有必要，两者的判重逻辑和处理方式确实不同。
文中强调误合并可能比漏报更难补救，这一点对客户、供应商等关键档案尤其重要。
选型时除了看新增页面，也应测试批量导入和接口重试，否则容易留下数据入口的控制缺口。
情景数据明确标注为模拟值，避免被误当成行业统计；实际测试还是要用企业自己的样本。
人工复核、合并留痕和旧编码追溯都值得纳入演示，单看查重提示无法判断能否形成业务闭环。