ERP 数据录入最容易被误解的一点，是把它当成“把 Excel 搬进系统”。真正的风险往往不在录入速度，而在于同一客户被建成多个档案、不同仓库使用不同计量单位，或者期初库存导入成功了、数量却和盘点口径对不上。建设路线应从数据范围和业务规则开始，经过盘点、清洗、去重、字段映射、小批量试导、核验与维护；去重只是其中一环，不能靠一条“名称相同就合并”的规则解决全部问题。
我判断一项 ERP 数据准备工作是否完成，不会只看导入记录数，也不会只看系统有没有弹出“导入成功”。数据必须能被业务人员正确查到、被后续单据正确引用，并且能按约定口径用于库存、采购、销售或财务核对，才算真正可用。
例如，系统接受了 3000 条物料记录，不代表物料主数据已经合格。如果同一种规格存在三个名称、采购单位和库存单位的换算关系不清楚，后续订单仍可能选错物料，库存余额也可能无法解释。导入成功是技术状态，业务可用才是验收结果。
适用于多数 ERP 建设或数据迁移项目的基本路线是：先界定对象和范围，再盘点来源、确认规则、清洗去重、字段映射、试导验证，最后正式导入并持续维护。每一步都要有负责人、输出物和通过条件，而不是只留下一份“已处理”标记。
这七步不是所有项目都要用同一套表格或同一顺序。不同 ERP 的模板、导入顺序和校验能力会有差异；但“先定规则，再导数据；先小批验证，再全量执行”是值得坚持的控制原则。
主数据是相对稳定、会被多个业务流程引用的基础对象，例如客户、供应商、物料、仓库和员工。它需要清晰的识别规则、统一编码和变更责任人。
业务数据记录某个时间发生的业务活动，例如销售订单、采购订单、出入库单、应收应付明细。是否迁移全部历史记录，取决于经营查询、审计、法规和系统能力等要求，不能默认“旧数据越多越完整”。
期初数据用于新系统切换时承接某一时点的业务状态，例如库存余额、未结订单、应收应付余额。它要和切换时点、盘点结果及财务口径保持一致，不能把它简单当作普通主数据导入。
销售部门可能按客户简称维护名单，财务按开票抬头管理客户，仓库则按收货点记录送货对象。三份表中的记录看起来都合理，但它们描述的可能不是同一层级的对象：一家企业、一个开票主体、一个收货地点，甚至一个联系人。
如果项目成员只按名称去重，把“华东某公司”“某公司上海分部”和“某公司采购部”合成一条，就可能把不同业务关系压成同一个档案。反过来，如果完全不做去重，同一客户也可能被重复建档，影响账期、信用额度和销售统计。
“规格”究竟填型号还是尺寸，“数量”使用箱、件还是个，“停用”是不能新建单据还是连历史查询也受限，这些问题都不是靠批量粘贴能解决的。字段名相同，不代表含义一致；字段名不同，也不代表内容一定不同。
我会要求数据负责人给关键字段写出业务定义、填写示例、允许值和责任部门。只要这些信息缺失，清洗人员就容易用自己的理解填补空白，等到导入后再让一线人员猜字段含义。
一个重复物料可能只是主数据问题，也可能进一步变成采购重复下单、库存分散、成本归集不一致或报表口径不统一。究竟会造成什么影响，取决于 ERP 的配置和企业流程，不能仅凭某个错误字段就断定业务一定受损。
但在项目计划上应把影响链路画出来：某个字段或编码被哪些单据引用、谁会维护、错了之后会影响哪些报表。优先处理被多个流程引用、变更成本高、当前差异明显的数据，比先清理容易处理但影响有限的字段更有价值。
盘点时，我会要求每个数据对象至少写清来源系统或文件、数据负责人、更新时间、预计记录数、适用范围、是否有重复疑点、是否需要迁入，以及谁有最终确认权。多份表格发生冲突时，必须由业务负责人指定权威来源，不能让清洗人员凭文件名或修改日期自行裁决。
例如，较新的客户表可能只覆盖本季度活跃客户，较旧的表却保留了尚未结清的往来单位。直接用新表覆盖旧表，会让“更近”误变成“更完整”。来源优先级应按业务事实决定，而非单纯按文件新旧排序。
名称匹配是筛选疑似重复的线索，不是自动合并的充分条件。企业名称可能有简称、历史名称、分支机构名称，也可能因为不同主体使用同一品牌而相似；个人姓名更容易重名。物料名称也可能相同，但规格、颜色、版本或计量单位不同。
较稳妥的做法是把记录分成三类：能够按明确业务规则确认的重复；存在冲突、需要业务复核的疑似重复；证据不足、暂时保留的记录。只有第一类才适合按批准规则自动归并。第二类要留待确认，第三类不能为了“去重率好看”而强行合并。
电子表格的“删除重复项”通常依赖所选列完全相同与否，但业务重复记录未必每个字段都一样。两行客户名称相同、税号不同，可能是不同法人；名称略有差异、税号相同，则可能是同一主体的不同写法。只勾选名称或全部字段，都会带来不同误判。
如果需要在表格中做初筛，应先复制原始数据并保留不可覆盖的备份，再统一格式、选择合适的比较字段、生成疑似匹配清单，最后由业务负责人确认处理结果。删除不是去重流程的第一步，复核和留痕才是。
历史单据是否迁移，需看业务查询、未结事项、财务核对、审计留存和系统性能等约束。有些数据适合迁入，有些只需保留在可查询的旧系统或归档文件中。全量迁移并不自动带来更高的数据质量，反而可能把旧系统中的过期编码和错误关系一并带入。
在迁移范围确定前，应先定义新系统上线时必须承接的对象和时点。例如未结订单、尚未核销的往来余额、切换日库存等，通常需要单独评估；已完成且仅供历史查询的单据，则可比较迁入成本、查询需求和留存要求后再决定。
系统校验能检查的通常是已配置的规则，例如必填项、数据格式或编码唯一性；它未必能判断某个物料是否选错、某个客户是否属于正确主体，也未必知道期初数量是否符合盘点口径。系统没有报错，只能说明数据通过了当前可执行的校验。
验收必须同时检查技术结果和业务结果。技术检查关注记录数、错误日志、字段格式和关系引用；业务检查关注能否查到正确对象、能否生成预期单据，以及关键余额是否符合确认口径。
数据清洗需要投入时间，也需要业务判断。为了追求“零空值”“百分之百规范”而不断扩展清洗范围，可能让上线计划被低优先级问题拖慢。反过来，关键字段未确认就急于导入，也会把错误带进核心流程。
我的取舍原则是先识别业务影响和修正成本：会阻断关键单据、造成余额不可核对、影响权限或主体识别的问题优先解决；只影响非关键描述字段、且有后续补录机制的问题，可以登记后分阶段处理。优先级要公开，不要把所有字段都标成“必须上线前完成”。
去重前先明确对象边界。客户档案代表的是法人主体、开票单位、销售关系还是交付地点？供应商档案以签约主体为单位，还是还要区分供货地点？物料档案是按商品本身、规格型号、包装单位，还是按内部可库存的最小单位建立？这些选择没有脱离业务场景的唯一答案。
规则应由实际使用该数据的部门共同确认，而非由数据录入人员单独决定。业务部门知道对象如何使用，财务部门关心结算主体和凭证口径，实施团队了解系统字段和引用关系。三方对关键定义达成一致，才有可能形成可执行的匹配规则。
我建议对每类对象建立一张判断表，至少写明主识别字段、辅助字段、允许差异、冲突处理方式和最终确认人。下面是方法示例，不是可以直接套用到所有公司的固定规则。
| 数据对象 | 可作为候选匹配线索 | 必须关注的冲突 | 建议确认角色 |
|---|---|---|---|
| 客户 | 统一社会信用代码、完整名称、联系方式、地址 | 不同主体共用简称；总公司与分支机构层级不清 | 销售负责人或财务负责人 |
| 供应商 | 主体名称、税务识别信息、银行账户、合同关系 | 同一集团下不同签约主体；收货地点与结算主体混淆 | 采购或财务负责人 |
| 物料 | 内部编码、规格型号、单位、产品属性 | 同名不同规格；同规格但不同管理属性或包装单位 | 仓储、采购或工程负责人 |
| 仓库 | 仓库编码、组织归属、库存管理方式 | 同名异地；普通仓与待检、寄售等管理属性混同 | 仓储负责人 |
表中的字段只用于帮助设计规则。企业是否具备某个字段、字段是否可靠、ERP 是否支持其作为唯一约束，都需在真实模板和业务流程中核实。没有可靠识别字段时，就应该降低自动合并比例、增加人工复核，而不是用更激进的模糊匹配掩盖信息不足。
清洗过程至少保留原始值、标准化值、处理动作、处理理由、处理人和确认状态。这样做不是为了增加文书，而是为了能回答“这条记录为什么被合并”“谁批准停用旧编码”“导入后发现问题应该回到哪一版数据”等问题。
原始文件应设置只读备份或受控版本，清洗结果使用单独副本。对于批量规则处理，可以记录规则版本、执行日期和影响记录数；对于人工处理，记录确认人和依据。涉及个人信息、财务信息或供应商敏感信息时，还要按企业的数据访问和存储规定控制权限。
比较合适的顺序通常是：先去掉无意义空格、统一日期与电话等格式，再识别空值、非法值和明显格式错误；随后按对象规则生成重复候选，最后由业务人员处理冲突和关系。若直接在未标准化的数据上做精确匹配，“上海某公司”和“某公司（上海）”会被当成不同记录；若过度标准化，又可能删掉具有业务意义的规格或主体差异。
因此，标准化不是随意删字符，而是为匹配建立可复核的比较字段。原始字段仍要保留，尤其不能把规格、税号、计量单位等关键内容当成“格式噪声”清除。
试导样本不应只挑最干净、最简单的几行。更有价值的样本应包括正常记录、字段缺失、长名称、特殊字符、重复候选、不同计量单位、跨级分类以及存在关联关系的记录。具体选哪些边界情况，取决于目标 ERP 模板和企业数据特征。
试导后至少检查三件事：第一，模板与系统规则是否兼容；第二，导入后的字段是否按预期呈现；第三，业务人员能否通过这些档案完成真实操作。修正问题后重新试导，直到关键问题被关闭，再安排全量导入。
有些基础对象会被其他数据引用，导入时需要先准备被引用的数据；有些系统支持批次校验、暂存或专用迁移工具，顺序又可能不同。因此，网上列出的“客户、物料、仓库、库存”的固定顺序不能直接当作项目规范。
正确做法是查看系统模板、厂商文档和项目配置，画出对象之间的依赖关系，并确认是否需要先导组织、分类、计量单位或其他基础配置。正式执行前还应明确导入窗口、权限、备份、失败回滚方式和问题联系人。
数量核对可以发现明显漏导或重复导入，但不能证明内容正确。关键字段核对能发现名称、编码、单位等错误，却未必能确认对象关系。关系核对要关注上级组织、分类、仓库和引用关系；业务核对则要看期初余额、未结事项或常用单据是否符合切换口径。
建议为每类数据写一张验收单，记录目标数据范围、源数据口径、导入记录数、失败记录、关键字段抽查结果、关系检查结果、遗留问题、业务确认人和确认时间。抽样比例或容差不应凭空设定为通用标准，应结合风险、系统能力和项目约定确定。
为了说明步骤，我用一个假设性的制造企业场景演示：企业从多个部门表格整理 10000 条物料记录，目标是准备 ERP 的物料主数据和一部分期初库存。下面出现的记录数、比例和工时均为情景模拟，不是行业平均值，也不是任何软件厂商的性能承诺。
设想中的原始数据有四类来源：旧系统导出、采购部门维护表、仓库常用物料表和工程部门规格清单。四份数据的字段名称不同，物料编码也不是完全统一的。项目负责人先建立来源台账，并将仓库、采购和工程分别指定为相关字段的业务确认方。
整理时发现，有些记录虽然名称类似，却对应不同规格；有些名称差异很大，却可能是同一物料；还有一部分是停用编码或旧版本记录。团队没有直接按物料名称删除，而是把物料编码、规格型号、基本单位和使用状态作为候选核对字段，并将规格缺失的记录标记为待复核。
这一步最重要的结果不是“删掉多少行”，而是把数据分成已确认有效、明确重复、疑似重复、信息不足和停用待处理几类。分类之后，负责人才能判断哪些可以合并，哪些必须保留，哪些需要补充技术资料。
团队将前后空格、全半角字符和日期等格式差异进行标准化，同时保留原始值以便追溯。物料规格中的符号、尺寸单位、版本号和特殊字符没有简单删除，因为这些内容可能影响物料区分。对于系统不允许的字符，则先对照 ERP 规则确定转换方式。
对编码冲突的处理也不只是“改成唯一”。项目组先查编码来源、历史单据引用和是否有替代关系，再决定保留主编码、建立旧编码对照，或将记录标记为停用。这样可以减少旧业务记录与新主数据无法对应的风险。
筛查结果可以按“编码相同”“规格高度相似”“名称相似但单位不同”等原因分组，让复核人员快速理解候选记录为什么被放在一起。每组记录都保留判断结果：合并到哪个主档、独立保留、停用，或者继续补充信息。
在这个模拟场景里，假设 10000 行中有 800 行进入人工复核；其中一部分确认是重复写法，一部分是不同规格或不同管理属性，另有一些需要业务补充资料。这里不把任何比例说成通用经验：实际复核量取决于原始数据质量、字段完整度和规则设计。
清洗后的字段按照目标模板映射：物料编码对应内部编码，规格字段按 ERP 的字段要求拆分或保留，基本单位对照计量单位配置，分类字段映射到目标系统的分类层级。若模板把规格拆成多个字段，团队需要确认历史值如何拆分，而不是简单地把整个字符串塞入某一个字段。
试导批次选取常用物料、长描述、特殊规格、单位换算和待确认记录等边界案例。发现错误后，项目组把问题分别归类为模板格式问题、字段映射问题、系统配置问题或源数据问题，再由对应负责人处理。这样的分类可以避免把所有导入错误都推给录入人员。
物料主档通过测试，并不表示期初库存可以直接导入。库存数据还需要明确盘点时点、仓库范围、批次或库位要求、单位口径，以及在途、冻结或待检库存如何表达。若不同表格的库存截点不同，先统一时点，再核对差异来源。
在这个情景中，验收清单分别检查物料档案数量、关键字段、仓库关系和期初库存口径。系统导入条数与源数据条数的差异必须能解释：哪些是经批准的重复合并，哪些是明确不迁入，哪些是失败后补录。无法解释的差异不能只用“清洗过了”带过。
在上述场景里，表格工具可以协助统一格式、生成匹配候选和汇总异常，但是否合并物料仍需要业务判断。把更多记录自动匹配，并不必然意味着质量更好；自动规则越激进，越要证明它不会把不同规格、不同单位或不同管理属性误合并。
因此，我更关注三件事：关键冲突是否被识别、人工复核是否有依据、导入结果是否能追溯。工具可以减少重复劳动，但不能替代数据对象定义、责任划分和最终验收。
如果团队规模不大、数据来源有限，优先选一个业务对象做完整闭环，例如先整理客户档案或常用物料。试点要覆盖“盘点，规则，去重，映射，试导，验收”，而不是只试一次文件上传。确认流程可执行后，再复制方法到其他对象。
小团队不一定需要复杂的数据治理平台，但仍需要版本控制、负责人和复核记录。可以使用受控表格管理问题，但要避免多份文件并行修改，且应规定唯一的工作版本与审批方式。
若销售、采购、仓储、财务和工程部门各自维护数据，优先梳理谁是字段负责人、谁拥有最终确认权、谁能批准合并或停用。每类数据最好有明确的数据所有者，录入人员负责执行规则，而不是替业务部门裁定对象关系。
跨部门项目还需要对齐数据切换时点、范围和冲突升级路径。若两个部门都认为自己的表是权威来源，问题不是再做一次格式清洗，而是业务治理决策尚未完成。
从旧 ERP 或多个业务系统迁移时，应逐项对比源字段与目标字段，确认字段含义是否一致、旧值如何转换、被废弃的字段如何处理、关联记录如何保留。不要只拿新模板要求反向填表，而忽略旧系统字段背后的业务含义。
对历史单据和余额，需明确迁移范围、时点、查询方式、校验责任和失败回滚方案。特别是财务相关数据，应由财务负责人确认口径；库存和未结单据则需与仓储、采购或销售流程共同核对。
当数据量大、来源持续变化、人工处理重复度高时，可以评估批量校验、数据集成或主数据管理能力。选择工具前，先确认它能否支持需要的字段映射、规则复用、错误反馈、版本追踪和权限控制，再评估和现有 ERP 的连接方式。
如果业务规则还在频繁变更，过早自动化可能把错误规则快速复制到更多数据。较稳妥的次序是先用少量样本验证规则，再固化成自动校验；对高风险的主体合并和库存口径判断，仍保留人工审核节点。
我建议用三个维度给对象排优先级：一是错误对业务流程的影响；二是这个数据会被多少流程或部门复用；三是上线后纠错的成本。被多个单据引用、错误后难以修复、上线前就能明确规则的数据，通常应优先处理。
不要只按记录数量排期。数量少但关系复杂、影响财务或核心库存的数据，可能比数量庞大但仅用于低频查询的描述字段更紧急。优先级是项目决策工具，不是数据价值的永久排名。
| 方案 | 更适合的情形 | 主要优势 | 主要限制 |
|---|---|---|---|
| 人工复核为主 | 数据量较小、对象判断复杂、业务规则尚未稳定 | 能结合上下文处理例外情况，便于确认边界 | 耗时较多，需避免不同人员采用不同判断口径 |
| 规则筛查加人工复核 | 数据量中等或较大，重复模式较明确但仍存在例外 | 可减少重复筛查，把人力集中在冲突记录上 | 规则需要测试和维护，筛查结果不能直接等同于最终裁决 |
| 批量自动处理 | 匹配字段稳定、规则经过验证、结果可回滚且风险可控 | 重复性高的格式转换和明确规则处理效率更高 | 规则错误会批量扩散，必须保留日志、抽检和回滚机制 |
多数项目并非只能三选一。实际更常见的组合是：自动处理格式统一和明显错误，规则工具生成疑似重复列表，业务人员处理高风险冲突，最后由责任人确认导入范围。
全量迁移的好处是有机会在新系统中延续较完整的历史查询，但它会扩大字段映射、关系核对、清洗和测试范围。若旧系统数据质量差、历史字段与新系统差异明显，迁移成本和验证复杂度也会增加。
关键数据迁移可以把重点放在当前运营必需的数据、未结事项和切换时点余额，并通过可查询归档保存历史信息。它减少新系统中的历史包袱，但要提前确认旧数据的访问方式、保存周期和查询责任，不能只说“不迁就行”。
最终选择应由业务查询需求、法规和审计要求、系统能力、迁移预算与时间共同决定。无法确认的历史数据，先做范围清单和样本验证，比直接承诺全量迁入更稳妥。
对会影响主体识别、核心交易、库存余额和财务核对的问题，应设为上线前门槛。对低风险、可追踪、可以按规则补录的问题，可以形成明确的遗留清单，安排上线后的责任人和完成时间。
但“上线后再处理”不能成为没有期限的口头承诺。遗留项至少要写明影响范围、临时控制方式、责任人、目标日期和关闭条件。否则，暂缓处理会逐渐变成永久缺陷。
ERP 自带导入模板可能已经满足小规模、低频的数据准备；当数据需要跨多个来源整合、持续校验或反复分析时，再评估辅助工具是否能减少人工步骤。工具应服务于规则执行和质量检查，不应被包装成 ERP 数据治理的替代品。
选择时可以核对：是否支持目标数据格式和字段映射；能否保留原始记录及处理日志；是否有角色权限和审批；出现错误后能否定位和回退；与目标 ERP 的导入方式是否兼容；敏感数据如何存储和访问。对外部服务的功能、合规和安全能力，应以厂商文档、合同和实际测试为准，不要仅依据宣传页面下结论。
如果团队只有一周准备时间，也不要把所有步骤压成“清理表格一天、导入一天”。可以缩小首批数据范围、先处理高风险对象、把低风险问题登记为后续治理项；但范围决定、关键规则、试导和业务验收不能省略。
录入人员通常负责按已确认的规则整理、录入或导入数据，并反馈缺失、冲突和格式异常。若企业没有明确数据责任人，录入人员可能被迫判断客户是不是同一主体、物料是否可以合并；这类判断应升级给业务负责人，不宜由录入岗位自行承担。
数据量不大、规则简单时，受控表格可以完成格式统一、筛查和问题登记。但要保留原始副本、固定工作版本、限制编辑权限，并避免多个人同时维护不同文件。数据量大、更新频繁或跨系统时，可评估自动化能力；工具选择仍要看规则、审计、权限和回滚需求。
先看系统返回的具体错误字段和模板要求，再区分是格式问题、必填字段缺失、编码冲突、引用对象不存在，还是系统配置不符。不要只修改报错行而不记录原因；如果同一错误反复出现，应检查转换规则或数据源，而不是逐行补丁式处理。
不代表。导入成功通常只说明数据通过了当前系统能够执行的检查。还要核对记录范围、关键字段、对象关系和业务口径，尤其是期初库存、余额和未结事项。验收深度应随数据风险和业务影响调整。
可以在同一项目中协调，但不应混成一套规则。主数据关注对象定义、编码、分类和引用关系；期初数据关注切换时点、余额口径、仓库或组织维度及对账结果。两类数据的负责人、验收方式和风险重点通常不同。
不能只追求表面指标。某些空值是确实未知，某些记录需要暂时保留；某些名称相似的记录是不同主体。与其追求“零空值、零重复”的数字，不如先定义什么叫重复、哪些字段必须填、哪些未知值可接受，以及问题如何登记和关闭。
ERP 数据录入路线的关键，不是把步骤写得越多越专业，而是让每一步都能回答四个问题：处理什么对象、依据什么规则、谁来确认、怎样验收。去重只是“依据什么规则”的一部分；没有对象定义和业务确认，去重率再高也不能证明数据更可靠。
如果你正在准备 ERP 数据，下一步不必先买工具或立刻清全量表格。先挑一个业务对象，建立来源清单，写出关键字段定义和疑似重复处理规则，再选一批包含边界情况的数据试导。把确认过的规则、失败原因和验收结果沉淀下来，之后再决定是否扩大范围或自动化。
我的核心建议是：把数据导入当成一次业务规则验证，而不是一次文件上传。能追溯、可解释、有人负责的数据，才适合进入 ERP 并长期被业务流程使用。
我手里有两份客户表，一份写“华东精密制造有限公司”，另一份写“华东精密”，联系人还不一样。我担心按名称自动合并会把不同客户混在一起，也不知道应该先看哪些字段。
不要把“名称相同”直接当作重复，也不要只因名称不同就判断为两条记录。去重应先统一空格、全半角、常见符号等格式，再按业务对象组合字段判断；疑似重复的记录应进入人工复核，而不是自动合并。例如，客户可对照名称、统一社会信用代码、电话和地址；物料可对照编码、规格型号、单位和分类。
税号或物料编码等唯一标识通常比简称更有判断价值，但实际规则要结合企业字段完整度与系统配置确定。建议保留“原记录、匹配依据、处理结论、确认人”四列。比如两条客户名称近似但税号不同，应暂缓合并并交由业务负责人确认；确认合并后，也要记录主记录和被停用记录，方便追溯。
我第一次参与 ERP 上线，手里既有客户、物料和供应商表，也有订单、库存和往来余额。我原本想把所有历史表格一次性导进去，但不确定哪些是基础资料，哪些应该按业务时间或期初口径处理。
建议先把数据分成主数据、业务数据和历史留档数据。客户、供应商、物料、仓库等通常属于主数据；订单、出入库记录、应收应付和期初余额属于业务数据或余额数据；已无需在新系统中操作的旧记录，则可评估是否只留档查询。这一区分会影响导入顺序和核对方法。
业务数据往往引用客户、物料、仓库等基础对象，因此通常要先确认相关主数据可用，再按系统要求处理业务数据；期初库存或余额则必须明确截止日期和统计口径，不能只核对导入行数。实际规划时，可为每类数据登记来源、负责人、是否迁入、截止范围和验收方式。
历史数据并非越多越好：如果迁入范围没有明确用途，反而会增加清洗、映射和核验工作；是否保留应由业务、财务及实施团队共同确认。
我担心试导会拖慢上线进度，想直接按整理好的 Excel 全量导入。如果系统提示导入成功，是不是就说明字段和数据关系都没有问题？
试导不是重复劳动，而是用少量数据提前暴露模板、编码和关联规则的问题。导入成功只说明系统接受了这批数据，不一定代表业务人员能正确检索、字段映射无误，或关联关系符合实际流程。试导样本不宜只挑最整齐的记录。
可以覆盖常见记录和边界情况，例如必填字段齐全与缺失、特殊字符、不同计量单位、相似名称、上下级分类，以及需要关联客户或物料的记录。先用一小批验证错误提示和导入后显示结果，再修正模板。试导时记录“问题字段、系统提示、修正方式、复测结果”，并保留原始文件副本。
若模板调整后重新导入，应确认旧测试数据如何清理，避免测试记录混入正式数据；具体操作要遵循对应系统的导入说明和项目配置。
我以前觉得系统显示导入成功就算完成，但后来发现有些记录数量对不上，个别字段还进错了列。我想知道上线前至少要核对什么，才能尽早发现会影响实际工作的错误。
验收至少分三层：数量核对、字段核对和业务核对。数量核对比较源表记录数与系统有效记录数，并解释被拒绝、重复或停用的记录；字段核对抽查编码、名称、单位、分类等关键字段；业务核对则确认数据能否支持实际查询、下单、收发货或对账。
例如，物料导入不能只看总条数，还要抽查编码是否唯一、规格和单位是否正确、分类关系是否完整。库存期初则应按约定的截止日期与库存口径核对数量及相关维度；差异需要由业务负责人解释，不能简单以系统结果覆盖原账。建议形成一张验收记录：数据对象、源文件版本、源记录数、成功数、异常数、抽查字段、差异说明和确认人。
验收标准应在导入前约定，阈值与核对口径由项目团队按数据类型确定，不存在适用于所有 ERP 项目的统一数字。
读者评论
把导入成功和业务可用区分开很重要，尤其期初库存还要和盘点时点、计量单位一起核对。
客户去重不能只看名称，主体、开票单位和收货地点可能不是同一层级，文中强调业务复核比较务实。
先做小批量试导再全量迁移，能提前发现字段映射和关联问题；建议把试导后的业务核验也纳入验收清单。
历史数据并非越多越好，是否迁入还要看查询、审计和未结事项需求，这种分层处理更符合实际项目取舍。
按业务影响安排清洗优先级有帮助，期初余额和单位冲突应先处理，低影响描述字段可以登记后续完善。