ERP 数据录入出错，常常不是录入员不认真，而是系统没有把业务规则变成字段、校验、权限和反馈流程。选型时如果只看功能演示，忽略这些质量检查，上线后再补规则，往往要同时返工主数据、单据流程和人员习惯。我的判断是：先拿企业自己的数据和业务样例做一轮测试，再讨论系统功能是否“支持”。
“支持批量导入”“支持自定义字段”“支持权限管理”听起来都很完整，但它们只是能力描述，不等于系统在真实业务中能避免错误。选型时真正要验证的是：字段是否符合业务含义，错误输入能否及时提示，异常记录能否定位，修改是否留痕，以及处理结果能否复核。
我会把 ERP 数据质量拆成四个环节：数据进入系统前的准备、录入或导入时的校验、发生异常后的修正、上线后的持续维护。任何一个环节缺位，都可能让错误进入后续流程。界面做得再简洁，如果录入规则含糊，最后仍会把问题转移给人工核对。
选型阶段的重点不是要求系统“保证数据绝不出错”，而是判断它能否降低错误发生的机会、缩短发现时间，并让责任和修改过程可追踪。这比单纯比较菜单数量、报表数量或演示页面，更接近上线后的真实使用情况。
“系统的数据质量好不好”太抽象，无法有效比较。需要把它改写成具体问题，例如：同一供应商是否可能重复建档？数量字段能否限制负数？物料的采购单位和库存单位是否能区分？导入失败时，能否指出具体行和字段？这些问题可以现场操作，也可以记录结果。
我建议每一个选型问题都落到四个动作上：准备样例、执行操作、观察反馈、保存证据。供应商回答“可以配置”后，不要马上记为通过；应要求在测试环境中用企业样例完成配置，并观察业务人员是否能正确使用。
下图是选型检查的逻辑示意，不是行业统计数据。它强调质量检查不是一次性的“输入校验”，而是一条从源头到复核的控制链；链条越完整，越容易在问题扩散前发现异常。
不少企业在整理主数据时，会发现“规格”“型号”“品名”“描述”等字段被不同部门用不同方式填写。采购人员可能把供应商规格写进型号栏，仓库人员则把内部规格写进同一字段。系统里看起来有值，业务上却无法准确匹配。
这类问题很难靠增加必填项解决。字段必填只能保证有人填写，不能保证填写内容正确。选型前要先确定每个关键字段的业务定义、允许值、维护角色和使用场景，并确认系统能否表达这些规则。
例如，“物料编码”可能由企业统一生成，也可能沿用供应商编码；“单位”可能是采购单位、库存单位或销售单位。若这些概念没有区分，界面上只有一个“单位”字段，即使录入准确，也可能在采购、仓储和销售之间发生换算错误。
一条错误主数据可能被采购单、入库单、库存账和销售单重复引用。单据生成时未必会再次核对基础资料，因此错误的影响可能逐步扩散。只检查“录入是否方便”，会漏掉数据如何被下游流程引用、修改后是否影响历史记录等关键问题。
我建议在选型测试中至少追踪一条完整业务链。例如从创建物料、建立供应商关系，到采购下单、收货入库、库存查询和退货处理。检查不同环节是否使用同一套物料定义，单位转换是否可见，异常发生时能否回到源单据定位。
下图为样本推演，用来表示错误在不同业务节点扩散的可能路径。它不代表某家企业的真实错误率，也不意味着每一步都会发生错误；价值在于提醒选型团队，检查范围应覆盖单据之间的数据引用，而不是停在录入页面。
历史数据清洗可以降低迁移时的存量问题，却不能自动解决新数据的录入质量。新品增加、供应商变更、计量单位调整、组织架构变化，都会带来新的维护要求。如果没有新增、变更、停用和复核流程，清洗后的数据也会逐渐失去一致性。
因此，我会把数据质量分成两类来管理：一类是上线前的迁移质量，关注重复、缺失、格式、编码和映射；另一类是上线后的运行质量，关注新增规则、权限、修改留痕、异常处理和定期复核。选型演示应覆盖两者，不能只展示初始导入。
必填项能减少空值，但无法判断值是否符合业务。如果“物料名称”要求必填，录入员仍可能输入“其他”“临时件”或带有个人习惯的简称。某些字段被设成必填，还可能诱发用户填入占位内容，只为完成保存。
更有效的检查方式是把必填、格式、取值范围、关联关系和业务条件分开测试。比如，供应商编码不仅要有值，还要符合编码规则；物料类别不仅要选择，还要与对应的计量单位、仓储属性和审批流程相匹配。
支持 Excel 或 CSV 导入，只能说明系统有某种数据入口，不能说明导入前后的映射关系正确。导入模板字段可能与企业现有字段名称不同，历史数据可能存在一对多映射，编码重复也可能直到入库、对账时才暴露。
测试导入时要检查的不只是“文件是否上传成功”，还包括错误行是否可定位、失败原因是否清楚、部分成功如何处理、重新导入会不会重复创建，以及导入结果怎样与源文件核对。最好使用脱敏后的真实样本做试导入，并保留源数据、映射表、错误清单和结果确认记录。
演示人员熟悉系统菜单，也常使用提前准备好的标准数据。业务人员则要在真实压力下处理例外情况，例如临时替代料、单位不一致、供应商名称变化、历史编码缺失。两种操作体验可能很不一样。
让未来的录入人员和审核人员参加测试，不是为了评判他们“会不会用”，而是观察系统是否能让规则被理解。若某个错误提示只有管理员听得懂，或必须由实施人员解释才能继续操作，那么这个流程对一线人员的实际保护可能有限。
重复录入、字段错填或单位用错，确实可能来自操作疏忽，但频繁重复发生时，通常还要检查流程设计。比如多个岗位都能新建同类资料、审批不区分新增和修改、搜索结果不突出相似记录，都会增加出错机会。
改善顺序应是先判断系统规则和业务流程是否清楚，再看操作培训和个人执行。培训可以解释规则，却无法长期弥补一个容易误操作、缺少校验、权限边界模糊的流程。
演示环境通常数据量小、字段结构简单、流程路径固定。企业实际数据可能有历史编码、异常字符、多单位、多组织和跨部门审批。一次顺利保存，只能证明那个样例成功，不能证明高频业务、异常业务和批量迁移都可用。
选型团队应记录测试条件：样本来自哪里、数据量多大、由谁操作、使用什么权限、覆盖了哪些异常。没有测试条件的“通过”，很难在后续验收时复现，也无法分辨问题来自产品能力、配置选择还是数据准备。
这些误区的共同点，是把一句产品说明或一次顺利演示当成质量证据。下图是选型测试的建议基准示意，不是市场统计；分数表示测试准备的相对成熟度，用来辅助团队检查遗漏，不用于评价具体供应商。
先列出企业要管理的核心数据对象，通常包括物料、客户、供应商、仓库、计量单位、人员、组织和会计相关基础资料。不同企业的业务范围不同，不必照搬完整清单；优先挑选影响采购、库存、销售、生产或财务核算的对象。
每个对象至少写明数据来源、业务负责人、关键字段、允许新增的角色、常见变更场景和下游使用位置。这样能先回答“谁负责这条数据、它为什么存在”，再判断系统需要怎样配置。
如果企业目前连同一字段的含义都没有共识，不应急于要求系统提供更多自定义项。字段越多，维护成本也越高。先解决关键字段的定义和责任归属，通常比先追求字段全面更有价值。
并非每个字段都需要同样严格的校验。物料编码、计量单位、税率、客户信用信息等字段一旦错误，可能影响多个业务环节；内部备注、非关键描述等字段的影响通常较局部。选型测试应优先覆盖错误后果更大的字段。
我建议给风险排序时考虑三个问题：错误发生的可能性、影响范围、发现所需时间。可以采用简单的高、中、低分级，不必假装有精确到小数点的风险模型。分级的目的，是让团队先测高风险数据，不是制造一套复杂评分。
下表给出一个可调整的示例。等级是用于测试排期的判断工具，不是对所有行业的固定规定。企业应根据实际交易频率、合规要求和差错后果调整分类。
| 数据类型 | 常见错误 | 建议检查重点 | 优先级参考 |
|---|---|---|---|
| 物料与商品资料 | 重复编码、规格混用、单位映射错误 | 唯一性、分类规则、采购与库存单位关系 | 高 |
| 客户与供应商资料 | 名称重复、状态失效、关键字段缺失 | 重复识别、状态管理、修改权限与审批 | 高 |
| 业务单据 | 数量、日期、价格或关联对象填错 | 字段范围、逻辑关系、单据间引用 | 高 |
| 人员与组织资料 | 岗位变化未同步、权限残留 | 角色配置、有效状态、权限回收 | 中至高 |
| 备注与补充描述 | 表述不统一、信息遗漏 | 是否需要结构化字段，是否影响查询和报表 | 按业务影响判断 |
“系统要灵活”“录入要方便”不是测试用例。可以把规则写成“输入什么条件，系统应给出什么结果”。例如：已有相同统一编码时，系统提醒并阻止重复创建；采购单位与库存单位不一致时，系统显示换算关系；日期超出允许范围时，系统提示用户检查。
每个用例还要记录执行角色、前置数据、预期结果、实际结果和证据位置。若系统允许通过配置达到目标，应把配置步骤也记下来，并确认普通管理员是否能够维护，还是必须依赖供应商或实施人员。
一个有用的测试集不必很大，但要有代表性。可先选一组常规样例，再加入几条有意设置的异常数据。测试前要脱敏，避免把真实客户、员工、价格或交易信息直接交给供应商。
下图是一个测试漏斗示意：先用少量样本确认字段和规则，再扩大到批量导入和完整流程。数字是建议的测试阶段样本量示例，不是行业要求；企业可以按数据规模、风险和测试资源调整。
好的校验不只是说“数据错误”，还应尽量指出哪个字段、违反什么规则、怎样修正。提示越模糊，用户越可能反复尝试或绕过流程。测试时可以故意输入错误值，记录提示内容、出现时机和是否能定位到对应记录。
同时要区分“提示”和“拦截”。有些错误可以提醒后允许继续，例如非关键备注格式；有些错误必须阻止保存，例如关键编码重复或必需关联对象缺失。规则强度应由业务风险决定，不宜一律拦截，也不宜一律放行。
每个测试项可按“通过、部分通过、未通过、未测试”记录，并附操作证据。部分通过尤其需要写清限制条件，例如需要额外配置、需要人工复核、只支持单条录入而不支持批量校验，或必须由特定角色处理。
给系统打分时，要避免把演示流畅度误当成数据质量能力。可以给字段适配、重复控制、导入校验、异常反馈、权限留痕和维护机制分配权重，但权重应体现企业风险。比如制造企业可能更重视单位换算和物料版本，贸易企业可能更重视客户、供应商及价格资料。
下图使用情景模拟数据演示加权评分方法。分值只说明计算逻辑，不代表任何真实 ERP 产品表现。评分前必须统一测试样例、人员权限和验收口径，否则不同方案之间不具备公平可比性。
以下是一个用于说明方法的情景案例，并非真实客户项目，也不代表特定企业的实际结果。假设一家经营多个仓库的企业准备切换 ERP，待迁移物料约 3,000 条，历史资料由采购、仓库和财务分别维护，部分物料存在简称、规格差异和单位不统一。
如果项目组直接把所有资料导入，再由各部门在使用中纠错，问题可能分散到采购下单、入库计数和盘点环节。即使每条记录都成功导入，也不能据此判断资料正确。这个场景的第一步不是选系统，而是确定物料资料的“正确版本”由谁确认。
项目组可以先按物料编码、名称、规格、分类、采购单位、库存单位、状态等字段整理数据字典。对于关键字段，要记录定义和来源。比如采购单位与库存单位是否可以不同，换算系数由谁提供，旧编码是否保留为别名，停用物料是否允许历史单据继续引用。
在情景中，项目组从 3,000 条记录中挑选一批样本，并按风险分层，而不是简单随机抽几条。高频采购物料、多个仓库共用的物料、存在单位换算的物料和近一年发生过变更的物料，应优先进入测试样本。
下面的示意表假设抽查 120 条记录，用来展示如何记录发现的问题。数字是情景模拟，不是行业平均值，也不能推断其他企业的错误比例。实际项目应根据数据规模、系统能力和业务风险确定样本量与抽样办法。
| 检查项 | 模拟样本数 | 模拟发现数 | 后续动作 |
|---|---|---|---|
| 名称或规格表达不一致 | 120 条 | 18 条 | 明确名称规则，确认规格字段是否需要拆分 |
| 重复或疑似重复编码 | 120 条 | 7 条 | 由业务负责人确认保留编码及历史别名 |
| 采购单位与库存单位关系不清 | 120 条 | 11 条 | 补充换算关系和维护责任，使用业务单据验证 |
| 分类或状态缺失 | 120 条 | 9 条 | 区分待确认、启用和停用状态，明确审批路径 |
这组模拟数据体现一个重要判断：异常类型不同，处理方式也不同。名称不统一需要定义规则；重复编码需要业务确认主记录；单位关系不清需要核实换算逻辑；状态缺失则要补流程和责任。单靠“批量去重”无法解决所有问题。
选型测试中，项目组可以把一条有采购单位与库存单位差异的物料，从主数据创建开始，走到采购订单、收货入库、库存查询和退货。每个环节都记录单位如何显示、数量如何换算、系统是否提示，以及修改物料资料后历史单据是否保持可解释。
重复记录也要实际测试。例如导入一条与系统已有编码相同、名称略有差异的物料，观察系统是直接拒绝、提示疑似重复，还是允许创建。若允许继续，应进一步确认是否有审批或复核机制。不同企业可以选择不同规则，但不能不知道系统实际行为。
导入失败时，检查报告应能帮助项目组回答三个问题：哪一行失败、哪个字段不符合规则、修正后如何安全重试。如果系统只返回“导入失败”，用户需要重新逐行排查，批量导入节省的时间可能被人工核对抵消。
情景案例可以设定一组内部测试指标，例如：完整字段比例、重复记录数量、导入失败定位时间、异常修复耗时、业务人员独立完成率。项目组要先写明口径，再比较配置前后的表现。
例如，“完整字段比例”可定义为关键字段都有有效值的记录数除以抽检记录总数；“异常修复耗时”可从发现问题开始计时，到业务负责人确认并完成修正为止。是否包含等待审批时间，需要在口径中说明。没有统一口径，两个版本的数字就不能直接比较。
下图中的数值同样是情景模拟，只展示可以怎样观察试点过程，不是实际实施成效。重点不是追求某个漂亮百分比，而是确认问题是否更早发现、定位是否更快、业务人员是否知道如何修复。
第一次上 ERP 的企业，常见困难是数据定义分散在个人表格和口头经验里。此时，先选出影响核心交易的基础数据，明确负责人和审批规则，比一次性建立覆盖所有字段的复杂数据治理制度更实际。
资源有限时，可以优先做好三件事：确定关键字段的定义；建立新增、修改、停用的基本流程；用少量真实样本验证导入和错误提示。低频且影响有限的字段可以后续完善，但编码、单位、状态和关键关联关系不宜含糊。
需要接受的取舍是：前期整理时间会增加，项目启动可能变慢一些；但若把基础定义留到上线后，业务人员会在实际单据里边用边改，造成的返工通常更难统一。这里的“更难”是流程判断，不是对所有项目的定量预测。
已有系统的企业通常不缺数据，真正的难点是旧字段、旧编码和新模型之间如何对应。不要只做字段名称的一对一映射，还要检查编码变更、分类合并、单位转换、停用资料和历史单据引用。
迁移前要分清哪些数据需要原样保留，哪些数据可以整理后合并，哪些记录只用于历史查询。若多个旧编码映射到一个新编码，应记录合并依据和对应关系，避免后续无法解释历史交易。
如果系统允许分批迁移，可先选择业务范围明确的样本做试迁移。试点范围应包含典型数据和异常数据，不要只挑“最干净”的部分。若无法分批上线，就应把导入校验、回滚方案和迁移后对账安排写进项目计划。
当同一物料在不同组织、仓库或业务渠道中使用时，核心问题不只是单条资料是否正确，而是不同场景下的权限、单位、分类和状态是否一致。选型时要确认哪些字段是全局统一，哪些允许组织级维护，改变一处资料会不会意外影响其他业务。
这类企业应选择跨部门测试人员共同参与。采购、仓库、销售和财务分别验证与自己有关的字段，再由项目负责人检查定义是否冲突。若不同部门对同一字段各有解释，应该先协调业务规则，而不是把冲突全部交给系统配置。
取舍方面，统一规则有利于汇总和分析，但可能降低局部业务的灵活性；允许组织独立维护，能适应差异，却增加跨组织对账和重复数据风险。选型团队应先识别哪些差异属于真实业务需求，哪些只是历史习惯。
小团队不一定需要复杂审批、多层复核和全面自动化校验。若录入量有限、角色清楚，可以通过集中维护、简单审批和定期抽查实现基本控制。关键是规则能被执行，而不是流程图看起来完整。
可以先规定核心资料由指定角色维护，关键变更留有原因，业务单据由使用者核对关联对象。每月或每季度抽查重复、缺失和异常记录，根据真实问题再决定是否增加自动规则。
此时不宜为了“专业”而建立过度严格的流程。每增加一个审批节点，都要看它能否降低实际风险；如果审批人只是在没有规则依据的情况下点击通过，流程只会增加等待时间，并不一定提升质量。
规则越严格，潜在错误可能越少，但录入阻力、维护成本和例外处理成本也可能上升。选型时需要判断哪些错误必须拦截，哪些可以提醒，哪些适合上线后通过抽查发现。判断依据应是错误后果、发生频率和纠正成本，而不是对自动化的偏好。
例如，重复编码可能严重影响库存和采购，因此值得设置较强的唯一性控制；备注格式差异若不影响检索和业务处理，可以先采用提示或规范文本，不一定阻止保存。规则不应只由 IT 决定，应该由承担业务后果的部门参与确认。
下图为控制方式的情景比较，数值为建议基准示意，不能当作真实成本数据。它表达的是控制强度与操作负担之间的常见权衡：需要根据错误后果选择控制方式，而不是要求所有数据都采取同一强度。
系统上线后，数据质量需要有人负责，但不一定要新设一个专职岗位。企业可以按数据对象分配业务责任：谁有权新增，谁确认关键内容，谁负责停用或变更，系统管理员负责哪些配置，出现异常由谁接收。
责任分配要与实际权限一致。如果某岗位名义上负责物料资料，却没有修改权限或无法查看异常清单，责任就无法落实。选型和实施阶段应确认权限配置是否能反映组织分工，人员调岗或离职后权限如何调整。
异常清单只有进入处理流程才有价值。建议记录异常来源、数据对象、问题类型、责任人、处理状态、修正结果和复核人。对重复出现的问题，还要判断是人员操作、源数据、字段定义、导入映射还是系统校验规则导致。
定期复盘时，不要只追问“这个月有多少错误”，还要看哪些问题反复发生、从发现到关闭花了多久、是否影响下游单据、是否需要修改规则。问题总量减少但处理时间持续增加，也可能意味着异常越来越难定位。
可以从关键字段完整率、重复记录数、异常数据占比、错误定位时间和纠正时长中选几项作为起点。不要一开始就追求大量指标，也不要直接套用未经核实的行业平均数。不同业务的录入量、字段定义和抽检方法不同，简单横向比较容易误导判断。
每个指标要明确分母、统计周期和数据范围。比如“重复记录数”是新增重复、全量重复，还是疑似重复待确认？“纠正时长”是否包含等待审批？口径写清楚之后，趋势变化才有解释价值。
也要保留反例和限制条件。完整率上升不一定代表数据更准确；错误报告数量下降，可能是错误减少，也可能是用户不再上报。指标需要与抽样复核、业务反馈和流程观察结合，不能单靠一个数字判断系统效果。
字段校验规则不是一次配置后永远不变。新增业务类型、计量方式、组织结构或监管要求，都可能影响数据定义。规则变更前应确认影响范围，变更后用典型单据测试，并记录生效时间和责任人。
若企业担心规则修改影响历史数据，可以区分对新数据生效的规则和历史记录处理方式。修改前先评估数据兼容性，保留必要的变更记录。系统是否支持版本管理、审批或日志，应以实际配置和测试结果为准，不要仅凭功能介绍推断。
建议把这份清单变成一张选型测试表，每个问题后面增加“使用的数据样例、操作角色、预期结果、实际结果、证据位置、限制条件”几栏。供应商的口头答复可以记录，但不能替代实际操作结果。
想做好 ERP 数据录入，不必先写一份庞大的数据治理制度。可以从最影响业务的一个数据对象开始：挑选一组脱敏样本，明确字段含义，加入重复、缺失、格式异常和单位差异，再让未来使用者在候选系统中完成录入、导入、修改和查询。
记录的不只是“能不能用”，还要记录系统怎样发现问题、提示是否清楚、错误如何纠正、操作是否留痕、业务人员能否独立处理。测试结束后，把没有验证的项目单独列出来，不要把“暂未发现问题”写成“能力已通过”。
我更看重的不是某套 ERP 宣称拥有多少数据管理功能，而是它能否在企业真实业务中把规则落到操作，把错误变成可处理的异常，并让后续维护有明确责任。相同功能在不同数据结构、组织权限和流程复杂度下，效果可能完全不同。
选型阶段最有价值的质量检查，不是寻找一个“永不出错”的承诺，而是提前验证错误会在哪里出现、谁能看见、怎样纠正、如何确认改对。下一步就从企业最常用、最容易影响下游的一类数据入手，准备样例和测试记录，再带着结果进入供应商演示与方案比较。
我正在比较几套 ERP，演示时每套都说能校验数据，但我不确定该看哪些细节。除了必填项和格式检查，我还应该追问什么，才能判断系统是否适合自己的业务？
别只问“系统有没有校验功能”，要把检查拆成录入前、录入时和录入后三段。录入前看字段定义、编码规则和权限；录入时看重复提醒、格式校验、必填条件能否按业务设置；录入后看错误能否定位、修改是否留痕、异常是否有人负责处理。建议逐项要求供应商用企业自己的场景演示。
例如，采购订单中的计量单位是否与物料主数据一致，客户资料重复时系统如何提示，缺少关键字段时能否阻止提交。记录“能否发现、能否阻止、如何修正、是否留痕”，比单纯勾选“支持数据校验”更有判断价值。
我不想只看供应商预设的演示数据，因为它们看起来都很规整。我该怎样准备一组既能保护企业信息、又能暴露录入问题的测试数据？
从真实业务中抽取少量、经过脱敏的样本，覆盖常用基础资料和典型单据即可，不必一开始就导入全量数据。可以选取一批物料、客户或供应商记录，再配上采购、入库或销售单据，保留真实字段关系，但替换名称、联系方式等敏感信息。
在样本中有意加入可控的边界情况：一条缺少必填字段的记录、一组疑似重复资料、一项格式不一致的日期，以及一条计量单位或分类不匹配的单据。测试时记录系统是提示、拦截还是放行，以及错误能否快速定位。样本数量和问题类型应按企业业务复杂度调整，不要把这组测试当成统计准确率的依据。
我发现团队常把所有问题都归到“数据不规范”，但物料资料、订单和旧系统导出的数据明显不是一回事。我应该怎样分类检查，避免清洗时漏掉关键问题？
不建议用同一套检查规则覆盖所有数据。基础资料重点看唯一性、编码与命名规则、分类和单位；业务单据重点看字段间的逻辑关系，例如数量、单位、日期和关联对象是否一致；历史数据则要额外检查字段映射、旧编码转换和导入后的对账结果。可以先做一张“数据对象，主要风险，验证方式”表。
例如，物料资料检查重复编码与单位，采购单检查供应商、物料和数量关系，历史库存数据检查旧系统与新系统的数量及金额是否按同一口径转换。这样能避免只检查单个字段，却忽略数据进入流程后彼此矛盾。
我担心选型时演示通过了，正式上线后还是要靠人工查错。有没有一套相对客观的验收办法，让业务人员、实施人员和管理者能用同一标准讨论结果？
把演示改成可复核的小型验收：选定一组测试数据，事先写明预期结果，再由实际录入或审核人员操作。每个问题都记录四项：系统是否发现、是否阻止错误进入下一步、修正过程是否清楚、操作记录能否追溯。避免只记录“功能有或没有”，因为同一功能在不同配置和流程下效果可能不同。
验收指标应由企业定义口径，例如必填字段完整度、重复记录数量、测试错误被识别的数量、异常处理耗时。可以把同一批样本分别用人工检查和系统流程处理，比较发现问题的方式与处理步骤，但不要据此推算长期节省比例。上线后还要指定规则维护人，并定期复查异常记录；选型测试只能验证能力，不能替代持续治理。
读者评论
文章把选型重点从功能清单转向可复现的测试，尤其是用真实样本检查导入失败行和重复数据，比较有操作性。
数据质量不只是录入员的问题，字段定义、维护责任和权限流程也很关键。先明确负责人，再配置系统规则，思路比较实际。
建议沿采购、收货、库存等环节追踪同一条数据，能发现只看录入界面时容易漏掉的单位映射和下游影响。