ERP 数据录入能力清单，不能只回答“系统里有哪些字段”。真正影响日常管理的，是客户、供应商、物料、仓库、价格、权限等基础资料是否有明确来源、统一规则、责任人和变更记录。资料不完整时，问题往往不会停在录入页面：一个单位填错，可能一路传到采购、库存和成本；一个重复客户档案，则可能让同一笔业务分散在两套记录里。本文按“录什么、谁负责、怎么校验、何时停用”拆解日常需要覆盖的基础资料，并说明哪些是通用项、哪些应按行业启用。
我判断一套 ERP 资料清单是否可执行，通常不先看字段有多少，而是先看每一类资料能否回答四个问题：它是什么、谁提供和维护、录入时如何校验、发生变化后如何处理。只有字段名称、没有责任和规则的清单，往往只能用于项目初期收集，无法支撑日常管理。
例如，客户档案里的名称、统一社会信用代码、结算方式和联系人，可能分别由销售、财务或客服提供。若没有明确哪个岗位负责确认主体信息、哪个岗位负责维护结算条件，资料即使首次录入正确，也可能在后续变更中变得不可靠。
清单要从“资料对象”扩展为“资料对象＋关键字段＋责任岗位＋校验规则＋状态管理”。这五项构成最小管理单元，既能指导初始化，也能用于上线后的日常维护。
ERP 数据经常被笼统地称为“录入资料”，但不同类型的数据维护方式不同。客户、供应商、物料、仓库等相对稳定、会被多个业务重复调用的信息，通常属于基础档案；采购订单、销售订单、入库单和出库单属于业务单据；上线切换时导入的库存、应收应付和账户余额，则属于期初数据或初始化数据。
具体系统可能采用不同的菜单名称或分类口径，因此不必争论某项数据在软件里被放在哪个菜单。管理上更重要的是确认它的业务性质、责任人、更新频率和核对方式。把期初库存当成普通物料档案维护，或把每日订单塞进基础资料清单，都会使职责和审核口径混乱。
| 数据类型 | 常见内容 | 主要维护特点 | 管理重点 |
|---|---|---|---|
| 基础档案 | 客户、供应商、物料、仓库、部门、计量单位 | 相对稳定，会被多个单据重复引用 | 统一编码、去重、责任明确、变更留痕 |
| 业务单据 | 订单、收发货、领料、退货、付款申请 | 随经营活动持续产生 | 业务事实、审批、单据状态、及时性 |
| 期初与切换数据 | 期初库存、未结应收应付、账户余额 | 与特定切换日期和账务口径相关 | 截止时点、来源台账、业务与财务核对 |
基础资料是否完成，不能只按已录入的行数判断。一条资料可能已经存在，却缺少单位、分类、有效状态或关联组织；另一条资料也可能字段齐全，但编码重复、主体信息不一致，无法被业务稳定调用。
我更建议用“可用率”而不是“完成率”来检查。可用率可以定义为：抽查样本中，同时满足必填项完整、编码不重复、关键关联正确、状态有效且责任人明确的记录占比。这个口径需要企业自行约定，不是所有 ERP 都内置的统一指标，但它比“导入了多少行”更接近日常管理目标。
在采购、销售、仓储和财务协同的企业里，资料常常不是由单一岗位天然掌握。销售知道客户常用称呼和交货地址，财务关注主体名称、付款条件和开票资料，仓库关注收货地点及库存管理要求。若各部门各自保存表格，系统里就可能出现一家公司多个简称、多个编码或不同版本的地址。
这不是简单的“员工不认真”，而是信息提供、确认和维护的职责没有被拆开。比如销售提出新增客户档案，财务核验结算和开票信息，系统管理员负责按规则建档；如果所有工作都默认由系统管理员完成，管理员既无法独立验证业务真实性，也容易成为所有资料问题的最终背锅人。
上线前集中整理档案，和上线后持续维护档案，是两种不同的管理任务。初始化期间关注的是范围、格式、历史数据清洗和切换节点；日常期间关注的是新增、修改、冻结、停用以及变更是否影响未完成业务。
如果项目结束后没有把临时整理规则变成日常流程，最常见的结果是：前期统一过的编码，几个月后又出现手工命名；初始资料由项目组核对，后续新增记录却没有审核人；过去使用的供应商虽已停止合作，档案仍保持可选状态。
基础档案的影响不止体现在档案页面。物料单位关系错误，可能影响采购数量、库存结存和领料统计；客户档案重复，可能让销售分析和应收管理按两个客户分别展示；仓库归属或组织关联不一致，则可能造成库存查询口径不同。
因此，发现问题时不应只追问“是谁录错了”，还要追问错误在哪个环节进入系统、哪个检查规则没有拦住、下游有哪些单据已经引用。一个可控的管理流程，要能同时处理资料纠错和已发生业务的影响评估。
下面用一个虚构的综合业务场景说明资料如何串联。某家中小型贸易企业同时经营线上和线下订单，产品有多个规格，客户既有企业客户也有门店。销售使用商品俗称，采购用供应商规格名称，仓库按包装单位收发，财务按交易主体核对往来。
如果这家企业只把“产品名称”作为录入规则，就可能出现销售、采购、仓库各自使用不同名称的情况。更稳妥的做法是建立唯一物料编码，将规格、基本单位、包装换算、业务分类和状态分别维护，再通过规则决定哪些字段由采购确认、哪些由仓库验证、哪些必须经财务或业务负责人审核。
这是用于演示的情景案例，不对应真实客户，也不代表所有企业的实际发生率。它的价值在于揭示一个常被忽略的逻辑：资料标准不是为了让表格整齐，而是为了让不同岗位引用的是同一个业务对象。
为追求“全面”，有些清单把系统能展示的字段都列为必填。实际结果可能是业务人员为了提交单据而随意填入占位文本，或在多个字段里重复录入同一信息。字段数量增加了，数据可信度却未必提高。
我建议把字段分为三类：业务必需、条件必需和可选信息。业务必需字段是完成核心流程不可缺少的内容；条件必需字段只在特定场景使用，例如启用批次管理时才要求维护批次相关属性；可选信息则用于后续分析或服务，不应在没有用途和来源的情况下强制填满。
每个必填字段都应能回答“谁提供、从哪里核实、缺失会影响哪项业务”。如果答不出来，它可能不适合被设为必填，至少需要先明确管理目的。
编码只解决识别问题的一部分。若同一个产品有两条编码，或者编码按部门习惯变化，唯一性就没有保障。反过来，如果编码包含过多容易变化的含义，规格、组织、业务类别一旦调整，编码规则也可能变得难以维护。
我倾向于采用“稳定、唯一、可追溯”的编码原则，尽量不要让编码承担所有描述任务。产品名称、规格、分类和状态应分别维护，编码用于稳定识别对象。编码是流水号还是有含义的组合码，应结合现有系统、条码规则和历史数据决定，没有适用于所有企业的单一答案。
批量导入通过，只能说明文件格式和部分系统校验符合要求，不等于资料在业务意义上正确。系统可能接受一个格式合法、但单位关系错误的物料；也可能接受主体名称完整、但重复于已有客户的记录。
导入后至少需要做三种核验：抽样核对原始来源，检查重复和异常值，使用真实业务路径验证关联。例如，挑选一条物料档案，观察它能否被正确用于采购、入库和库存查询。只看导入日志、不做业务验证，容易把“技术成功”误当作“管理成功”。
客户更名、供应商停止合作、商品规格变化、员工岗位调整，都会改变资料的有效性。基础资料的“稳定”只是相对业务单据而言，并不意味着永远不变。
正确做法通常不是删除旧记录，而是按系统能力和企业规则停用、冻结或标记失效，同时保留历史业务引用。直接删除被业务单据使用过的档案，可能造成追溯困难；一直保留为可选状态，又可能被新业务误用。新增、变更和停用都应有明确的触发条件和审核责任。
系统管理员可以维护账号、字段配置和导入任务，但未必能判断供应商结算条件是否合理、产品规格是否符合业务要求或财务信息是否准确。把业务判断集中交给技术岗位，会造成权责不匹配。
更清晰的方式是由业务岗位提供和确认业务事实，由相关专业岗位复核专业字段，系统管理员负责按规则实施和控制权限。小企业可以让同一人承担多个角色，但应在流程上明确他分别以什么身份完成了什么检查，并避免关键资料完全没有独立复核。
整理清单时，我会先列出企业反复交易、库存、结算或核算的对象，例如客户、供应商、商品、物料、仓库、员工、部门和计量单位。随后再追问这些对象分别在哪些业务流程中被引用。
这种顺序的好处是避免从软件菜单倒推需求。菜单里有字段，不代表企业有必要启用；企业有特定业务对象，也可能需要通过分类、属性或关联资料表达，而不是简单地增加一堆自由文本字段。
通用项通常是多数企业运行基础流程需要的档案，例如组织、用户、客户、供应商、物料或商品、计量单位和仓库。条件项取决于企业是否启用相应管理能力，例如批次、保质期、序列号、辅助单位、价格表。行业项则与制造、工程、电商、医疗或特定监管要求有关。
这个分类比“所有企业必填清单”更可靠。某个企业没有生产管理模块，就不需要为了看起来完整而录入工艺路线；不管理批次的贸易企业，也不应在没有库存追溯需求时人为增加复杂度。但如果产品有保质期或法规追溯要求，批次管理就可能从条件项变成核心项。
| 适用层级 | 常见资料 | 启用判断 | 容易忽略的边界 |
|---|---|---|---|
| 通用项 | 组织、部门、用户、客户、供应商、物料或商品、单位、仓库 | 是否支撑企业正在使用的核心业务流程 | 字段与审批仍应按企业实际规则配置 |
| 条件项 | 批次、保质期、序列号、辅助单位、价格规则 | 是否存在追踪、换算、定价或结算需求 | 不能仅因系统提供功能就默认全部启用 |
| 行业项 | BOM、工艺路线、工作中心、平台商品映射 | 企业是否运行对应行业模块或渠道流程 | 需确认版本、接口和业务规则是否适用 |
| 切换项 | 期初库存、未结往来、余额、未完成单据 | 上线切换方案是否要求导入及其截止时点 | 需与来源台账、盘点结果或财务口径核对 |
字段设计要追求“够用且可核验”，而不是“能想到的都收集”。以供应商为例，至少要确认哪些字段是业务识别必需项，哪些是结算所需项，哪些是按特定流程才需要的属性。字段名称相似时，还要确认定义是否一致，避免“供应商名称”“开票名称”“结算主体”被当成同一概念。
我建议每个字段至少标记四项：是否必填、数据来源、责任岗位、校验方式。对于重要字段，还应增加生效规则和变更审批要求。这样在字段配置、表格导入和岗位培训时，大家使用的是同一套定义。
| 字段属性 | 管理问题 | 示例写法 |
|---|---|---|
| 业务定义 | 这个字段具体代表什么？ | “基本单位”指库存与数量统计使用的单位 |
| 必填条件 | 所有记录都需要，还是特定流程需要？ | 启用批次管理时才要求维护批次相关设置 |
| 信息来源 | 由谁提供，依据什么材料确认？ | 业务部门提供规格，仓储岗位复核收发单位 |
| 校验规则 | 如何发现缺失、重复或不合理值？ | 单位必须来自已维护的计量单位列表 |
| 变更规则 | 谁能修改，何时生效，如何留痕？ | 关键规格变更需审核，并评估未完成单据影响 |
并非所有资料都值得采用同等审核强度。名称拼写错误可能容易发现；单位换算、主体信息、会计维度或生产版本错误，影响范围可能更广。校验资源有限时，应优先投入到错误后果大、被引用频率高、下游传播路径长的资料。
一个实用的排序思路是同时看四个因素：出错概率、业务影响、引用范围和发现难度。高风险资料应设置更严格的权限、双人复核或业务测试；低风险资料可以用格式校验和抽样检查。这里的判断是管理工具，不是要把每项资料都做成复杂审批流程。
资料并非只有“存在”和“不存在”两种状态。至少应区分待审核、有效、暂停使用和已停用等管理状态，具体名称以系统能力为准。每种状态要对应业务规则，例如待审核资料是否允许创建订单、暂停资料能否用于已有合同、停用资料如何保留历史单据。
生命周期规则还应明确何时触发复核。客户信息变更、供应商停止合作、员工离岗、商品规格调整、仓库关闭，都可能成为复核事件。对变化频繁的字段，可以设置周期性核查；对不常变化但影响重大的字段，则在业务事件发生时复核更有效。
组织和权限资料决定谁可以看到、录入、审核和修改业务数据。通常需要梳理公司或业务组织、部门、岗位、用户账号、角色以及审批关系。具体层级依企业结构和系统权限模型而定，不应为了层级完整而建立实际不存在的部门。
这部分最重要的不是把员工信息录得越细越好，而是确保账号与岗位关系及时更新。员工调岗、离职、临时授权和代理审批，都应有明确的创建、调整与收回流程。账号权限属于系统治理资料，和客户、物料等业务基础档案性质不同，但它决定了资料管理规则能否执行。
客户和供应商资料通常包括编码、名称、主体识别信息、联系人、地址、结算条件、交付要求以及业务状态。哪些字段必须录入，要根据企业流程、合同要求、财务核算和系统配置确定。开票、税务和结算相关字段应由负责岗位核实，不能仅凭销售或采购人员口头填写后直接认定为有效。
去重时不能只比较名称。企业可能有简称、品牌名、分支机构、不同结算主体或集团内多个往来单位。建议同时核对主体信息、业务关系和结算对象，并为“同一品牌但不同法人”等特殊场景设置清晰规则。发现重复档案时，也要评估既有单据和余额如何处理，不宜直接删除其中一条。
| 检查点 | 客户档案关注项 | 供应商档案关注项 |
|---|---|---|
| 对象识别 | 客户主体、业务区域、客户类别 | 供应商主体、供货类别、合作状态 |
| 交易条件 | 结算方式、信用或交付约定 | 付款条件、采购和收货约定 |
| 信息维护 | 联系人、地址和有效状态 | 联系人、交付地点和有效状态 |
| 重要核验 | 主体与结算对象是否对应 | 主体、付款信息及实际合作关系是否匹配 |
物料或商品档案往往是跨部门争议最多的一类资料。常见信息包括编码、名称、规格型号、类别、基本单位、辅助单位、条码、批次或序列号管理属性。制造企业还可能需要与 BOM、工艺或生产版本关联；电商企业可能需要商品编码、SKU、平台映射和包装信息。
录入时要把“名称相似”与“对象相同”区分开。规格不同、包装不同、销售单位不同，是否需要拆成独立档案，要看库存管理、成本核算和履约流程。尤其要核对单位换算：一箱等于多少个、采购单位和库存单位如何转换，必须有明确口径。只在备注里写“箱装”，不能替代可计算、可维护的单位关系。
条码和平台映射也不应被误当作唯一编码。条码可能随包装或渠道变化；同一商品在不同渠道可能存在不同映射。若业务依赖这些关系，应单独说明哪个字段是内部稳定标识，哪些字段用于外部系统对照。
仓库档案不仅是一个名称列表，还可能关联组织、仓库类型、责任岗位、库存可用范围以及库区和货位层级。是否需要拆分库区或货位，取决于实际拣货、盘点和追踪需求。仓库数量并非越多越好，过细的层级如果没有维护能力，反而增加收货、调拨和盘点时的操作负担。
还要把“仓库档案”与“现有库存数量”分开。仓库定义的是存储和管理位置，数量是某一时点的库存状态，可能来自期初导入或日常业务单据。批次、保质期、序列号等属性应根据产品特性和追溯要求启用，不宜仅因系统支持就全部打开。
采购和销售流程可能需要维护默认供应商、客户业务属性、价格表、币种、付款条件、交付方式或有效期间等信息。部分资料属于对象档案的属性，部分属于独立价格规则或合同条件，具体分类应以企业的业务口径和系统设计为准。
价格类资料尤其要关注有效期、适用对象、适用数量、币种和审批来源。把一个价格写在客户备注里，无法可靠替代可查询的价格规则；而将所有历史价格覆盖成当前价格，也会削弱追溯能力。需要保留历史时，应明确生效日期、失效日期以及价格变更依据。
税率、开票信息和财务结算字段可能受到地区政策、企业类型和系统配置影响。文章中的通用清单不能代替财务或税务专业审核，实际配置应由企业负责岗位按当前业务和适用规则核实。
启用生产管理的企业，通常还需要梳理 BOM、工艺路线、工作中心、生产版本、损耗或替代料等资料。不同系统的术语、功能范围和配置方式可能不同，因此清单应以实际启用模块和生产流程为准。
生产资料重点在版本和生效管理。产品结构或工艺变化后，旧版本是否继续用于已下达工单、何时启用新版本、替代料如何批准，都需要明确。BOM 录入正确，不等于生产管理已经完整；还要验证版本、工序、物料可用性与实际业务单据之间的关联。
财务相关基础配置可能包括会计科目、结算方式、核算维度、付款条件以及客户或供应商的财务属性。不同 ERP 的财务模块结构和企业会计口径存在差异，不能把某一套字段清单说成所有企业的统一标准。
这类资料应由财务岗位参与定义并审核，系统管理员负责配置实施。若企业计划从旧系统切换，还需区分静态科目或规则配置与期初余额、未结往来等切换数据。余额必须对应明确的截止时点和对账来源，不宜仅凭表格导入成功就视为账务一致。
期初数据通常包括期初库存、应收应付、现金或银行账户余额，以及上线时仍未完成的业务事项。具体导入范围由切换方案决定，未必所有历史单据都需要迁移。关键是确定截止日期、数据来源、确认岗位和核对方法。
期初库存应与盘点结果或可信台账核对；未结应收应付应与财务和业务记录核对；有批次或货位管理要求时，还要确认数量是否按对应维度拆分。若期初数据存在差异，应在切换前记录差异原因和处理结论，而不是先导入、后补解释。
新增资料前，先判断对象是否已存在。不要让业务人员看到名称不同就直接新建，也不要因为系统里有相似名称就默认是同一个主体。对于客户、供应商和商品，应设定必要的查重条件；查重结果有疑问时，交由业务责任岗位确认。
编码规则应在批量整理前确定。规则不需要过度复杂，但要说明编码是否允许修改、是否复用、谁有权分配，以及历史编码如何处理。若不同部门各自给对象编号，后续往往需要额外映射表来解释关系，长期维护成本可能高于一开始统一规则的成本。
录入环节可以按三层检查。第一层是格式校验，例如编码格式、日期格式、必填项；第二层是业务校验，例如单位是否合理、主体是否重复、状态是否符合流程；第三层是关联校验，例如物料是否属于正确分类，仓库是否归属正确组织，价格规则是否关联适用对象。
系统自动校验适合拦截明确、可量化的错误，例如必填字段缺失或编码重复。需要业务理解的判断仍应由责任岗位确认，例如某个商品是否应按多个 SKU 管理。不要把“能做自动校验”与“所有业务问题都能自动识别”混为一谈。
新建资料不一定要立即可供所有业务调用。对于高风险档案，可以将录入和启用分开，审核通过后再生效。对于低风险、变化频繁的资料，也可以采用简化审核或抽样复核。审批层级应与错误影响相匹配，而不是越多越安全。
资料启用后，建议用小范围的真实业务场景做验证：选取一条客户档案试建订单，选取一条物料档案检查采购和库存引用，或检查仓库资料在库存查询中的组织归属。验证发现问题时，应回到规则层定位原因，不要只靠人工临时修补。
修改资料时，先判断它是否已被未完成或历史单据引用。若只是联系人变化，处理方式可能较简单；若是主体、规格、单位或生产版本变化，就要评估关联业务、历史查询和未结订单的影响。是否允许直接修改，应由系统能力和企业规则共同决定。
对于不再使用的客户、供应商、商品或仓库，优先采用停用或冻结方式，并保留历史引用。停用条件可以是合作终止、长期无交易、组织撤销或资料合并。若采用定期清理，必须规定由谁提出、谁审核，以及如何处理余额和未结业务。
上线前不必追求一次性整理企业所有历史资料。先确认首期上线模块、核心流程和必须引用的基础对象，再确定期初数据范围。对暂时不参与首期业务的资料，可以明确延期整理条件，而不是为了看起来完整而批量导入未经核验的旧档案。
这类场景的取舍重点是范围与质量。少量核心档案经过核验，通常比大量历史记录未经清洗地进入新系统更可控；但如果某些历史资料承担追溯、合规或客户服务要求，就不能简单以“暂时不用”为由删除或丢弃。
已上线企业不一定要推倒重做。先抽取一段时间内新增、修改和被频繁引用的资料，检查重复编码、空值、异常状态、单位不一致和长期未使用记录。优先修复高频引用且影响范围大的资料，再逐步处理低频历史档案。
修复前要建立风险清单：哪些单据引用了待合并或待停用档案，是否存在未结订单、库存余额或往来余额。涉及业务事实变更时，不能只在主档里改一个字段就结束，应由相关岗位确认历史和当前交易如何衔接。
小型企业可以让同一位员工承担录入和部分审核工作，但至少要有统一模板、查重规则、关键字段复核和操作留痕。人员少不等于可以依赖口头约定，因为人员变动、业务增长或交接时，口头规则最难复原。
若无法做到双人逐条审核，可以对关键字段做抽样复核，对高风险对象实施启用前确认，对一般变更采用定期汇总检查。需要取舍的是审核成本与潜在返工成本：不是每个字段都值得人工审批，但影响交易主体、数量换算和账务口径的字段通常不应完全放任。
多组织企业应特别检查客户、供应商、物料和仓库是否全局共享，哪些资料只在特定组织使用，哪些属性允许组织级差异。相同编码在不同组织是否代表同一对象，也要有明确规则。否则会出现跨组织重复建档、库存归属不清或价格条件被错误复用。
共享可以减少重复维护，但也会带来权限和适用范围问题。完全共享并不一定更好；若不同组织的商品规格、采购主体或财务口径确实不同，就应通过系统支持的组织属性或分层档案表达差异，而不是把不同对象硬塞进同一条记录。
多平台经营时，内部商品、SKU、平台商品编码、条码和仓库编码可能不是同一套标识。建议把内部稳定编码作为企业内部识别基础，再维护外部平台的映射关系、适用渠道和状态。平台账号授权、接口字段和同步规则属于独立的对接配置，不能用一份基础档案清单替代。
需要权衡的是同步便利与主数据控制。自动同步可以减少重复录入，但如果外部平台名称、规格或状态不规范，未经校验地同步可能把问题扩散到内部系统。首次对接、字段映射调整和批量商品更新时，应先在小范围测试，并保留异常回滚或人工核验办法。
制造企业应根据是否启用计划、生产和质量追溯，决定 BOM、工艺路线、工作中心、批次和序列号资料的范围。不同产品可能有不同的版本控制方式，不能只复制一张历史 BOM 表就认定生产资料准备完成。
在人员和时间有限时，优先核实即将投产产品的结构、工艺和关键物料关系，再扩展到低频或停产产品。旧产品资料要保留历史查询能力，但应避免继续被新工单误选。新旧版本如何切换，应由生产、工程和相关业务负责人共同确认。
治理不是“所有资料都多一层审批”。审批过重会使新增业务等待，审批过轻则可能让错误快速进入多个流程。取舍时可以比较四项因素：错误造成的影响、资料被引用的范围、错误被发现的难度，以及控制措施的实施成本。
| 管理方式 | 适用情况 | 优势 | 代价与限制 |
|---|---|---|---|
| 自动格式校验 | 编码、日期、必填项等规则明确的资料 | 速度快，可拦截重复和格式错误 | 不能判断所有业务含义是否正确 |
| 人工审核后启用 | 主体信息、单位关系、生产版本等高影响资料 | 可在进入业务前发现关键问题 | 需要配置责任岗位，增加等待时间 |
| 抽样复核 | 风险较低、数量较大或更新频繁的资料 | 控制检查成本，适合资源有限的团队 | 不能保证每条记录都被及时发现问题 |
| 定期清理与停用 | 长期未使用、合作关系变化或历史资料堆积 | 减少误选，改善日常维护秩序 | 需检查未结业务和历史追溯需求 |
我正在整理 ERP 上线资料，发现有人把客户、商品、库存数量、采购订单都放进同一张表里。我不确定哪些算基础资料，哪些属于期初数据或日常单据，担心分类不清会让后续维护更乱。
先按“信息是否被反复调用”划分：相对稳定、供多笔业务重复使用的，通常是基础资料；记录某次交易的，是业务单据；反映系统启用时账面状态的，则是期初数据。不同软件的菜单分类可能不同，管理时最好先按用途区分。日常管理可先检查这些通用项：组织、部门与用户权限；客户和供应商；物料、商品、SKU 与计量单位；
仓库及库位；结算方式、价格资料等业务配置。制造企业再按需维护 BOM、工艺路线和工作中心；财务资料及税务字段应由财务人员结合企业制度核对。期初库存、应收应付和账户余额不要混进普通档案清单。它们往往需要确定截止日期、核对来源账簿并由责任人确认，是否导入及采用什么口径应以实施方案为准。
我所在团队里，销售、采购和仓库都能新增客户、供应商或商品档案，结果同一个对象出现了不同写法。我想知道是不是应该让一个人全部录入，还是由业务部门提供、专人维护更合适？
不建议简单地让所有资料都由一个人凭经验填写，也不建议完全开放给各部门自行新增。较稳妥的分工是：业务部门确认资料真实性和业务属性，主数据管理员负责编码、格式和重复项检查，指定审核人批准关键资料生效。
例如，销售提供客户主体、联系人和业务需求，财务核对结算及开票相关信息，主数据管理员检查编码是否重复、必填项是否齐全，再由授权人员审核。供应商资料可采用类似分工，但具体审核岗位应按企业内部控制要求确定。建议每类资料至少明确“提供人、维护人、审核人”三个角色，并规定变更与停用流程。
小团队可以由同一人兼任多个角色，但仍要保留修改记录和复核步骤，避免资料新增、审批和后续更改都无法追溯。
我接手的档案里，同一商品有简称、规格名和旧编码，计量单位也不统一。有些单据能保存，但库存汇总后对不上，我想知道应优先统一哪些规则，才不会只是把错误从表格搬进系统。
优先统一三个方面：唯一编码、名称与规格的表达规则、计量单位及换算关系。编码不应只靠人工记忆来区分对象；名称也不要把颜色、尺寸等关键信息随意塞进备注，导致搜索和报表口径不一致。可以在导入前做一轮去重：先按统一后的名称、规格、主体信息等字段筛查疑似重复项，再由熟悉业务的人确认是否为同一对象。
物料或商品还要核对基本单位、辅助单位和换算关系；客户与供应商则要检查主体名称及状态。具体字段是否必填，取决于系统配置和业务流程。以下是虚构的检查示例，并非行业统计：一张待导入表有 500 行，先标出编码重复、单位为空、名称相近三类记录，再由对应业务岗位逐条确认。
不要仅凭“名称相似”自动合并，规格不同或主体不同的资料可能确实是不同对象。
我准备把旧台账导入新系统，但团队有人想先录库存数量，也有人认为要先建商品和仓库。我担心导入顺序不对会产生重复库存，或出现数量有了却找不到对应档案的情况。
通常先确认组织、仓库、物料或商品、计量单位等基础档案，再核对并导入期初库存。期初数量需要关联到具体物料、仓库以及系统要求的批次或库位信息；关联对象尚未统一时，先导数量容易出现导入失败、错挂档案或后续难以对账。一个实用顺序是：冻结旧账数据的截止时间；清理并确认基础档案；整理期初明细；
按系统模板映射字段；小范围试导入；核对导入结果与原始台账；确认无误后再执行正式切换。若启用了批次、保质期或序列号管理，应提前确认明细粒度，不能只准备总数量。验收时至少核对记录条数、各仓库数量汇总和重点物料明细，并保留来源文件、映射规则、导入时间及确认人。期初库存应与企业认可的截止时点和账务口径一致；
涉及应收应付或财务余额时，还需由财务人员单独核对。
读者评论
把基础资料拆成对象、责任人、校验规则和状态管理，比单纯列字段更便于落地；尤其是明确谁核实主体信息，能减少部门间版本不一致。
文中区分基础档案、业务单据和期初数据很实用，三类数据的维护频率和核对口径确实不同，混在一张清单里容易造成职责混乱。
导入成功不等于数据正确”这一点值得注意。除了检查格式和重复项，还应抽样走采购、入库等实际流程，验证单位和关联关系是否准确。
停用而非直接删除旧档案的建议比较稳妥，既能避免新业务误选，也有助于保留历史单据的追溯关系。