多店经营里，ERP 数据录入最容易被误判成“把各店商品表导进去”。实际麻烦常常发生在导入之后：同一款商品在 A 店叫“纯棉短袖白色 M”，在 B 店叫“白T-M-白”，内部表格又用一串旧编码；订单进来后，员工只能靠人工判断是不是同一个 SKU。ERP 里看似有了数据，业务上却仍没有一套可信的资料关系。我的核心判断是：多店基础资料的重点不是录得多快，而是让每条资料能被一致识别、合理关联、有人维护，并经得起实际业务校验。
ERP 基础资料通常包括商品、SKU、类目、计量单位、仓库、供应商、客户、价格及渠道等信息。不同系统模块和字段会有差异，但它们共同承担一个任务：让采购、销售、库存、财务及报表能够对同一业务对象作出相对一致的识别。
因此，建立商品档案时，不能只问“这个字段要不要填”，还要问“这个字段解决什么识别问题”。商品名称方便人阅读，内部编码用于稳定区分，规格描述商品差异，条码便于扫描或核验，店铺商品编号则可能用于对应平台侧的商品记录。这些信息有交集，但不能互相替代。
如果员工只能根据商品名称猜测两条记录是否相同，资料规则就还没有建立好。反过来，当内部编码、规格、单位及店铺关联逻辑清楚，员工即使面对不同平台上的名称差异，也有办法核对和处理。
多店经营通常需要区分两层信息。第一层是企业内部的商品主档，用于定义公司如何管理商品；第二层是各平台或店铺的商品信息，用于保留渠道自己的名称、编号、价格、状态等属性。两层信息的关系需要结合所用 ERP 的能力设置，不能假设所有系统都有相同的映射字段或自动匹配功能。
举例来说，内部主档可以把某款商品定义为“基础款短袖”，并按颜色、尺码拆成具体 SKU；不同店铺则可能使用各自的标题、活动名称和平台商品编号。店铺标题可以因营销需要不同，但不能因此就轻率地把内部商品主档拆成多条，或把规格不同的 SKU 合并。
这个思路的价值不是追求所有店铺字段完全相同，而是明确哪些信息必须统一、哪些信息可以保留渠道差异。统一的是识别基础和管理口径，不是把所有经营差异抹平。
资料导入成功只能说明系统接收了数据，不能证明资料可以支撑业务。更有效的验收方式，是从真实业务动作反向检查：订单中的商品能否对应到正确的内部 SKU；库存是否落入预期仓库；采购或补货人员能否找到正确商品；经营报表是否能按需要汇总到商品、规格或店铺。
建议在开始整理前写下三到五个验收问题，并由实际使用资料的岗位共同确认。例如，运营人员能否找到店铺商品对应关系，仓库人员能否区分相近规格，财务人员能否理解销售口径。验收问题越具体，越不容易陷入“字段填得很齐，业务还是靠人补”的状态。
店铺接入 ERP，通常是为了让平台侧业务数据与企业内部系统产生连接。它并不自动回答企业内部的基础问题：同款商品如何识别、组合装如何管理、销售单位如何定义、旧商品如何停用、店铺商品变更后由谁复核。
这也是为什么只研究账号授权、接口连接或菜单操作，仍可能解决不了多店资料混乱。连接成功后，系统可能已经收到了商品或订单信息，但企业依然需要决定这些记录如何归并、如何使用，哪些差异要保留。
在实施沟通中，我会把“数据能不能进系统”和“数据能不能被正确解释”分开讨论。前者偏技术接入，后者涉及经营规则、组织分工及资料治理。两者都重要，但前者完成并不意味着后者自然完成。
不同店铺可能对应不同人群、价格策略、包装方案、发货仓或促销方式。即使销售的是同一个实物商品，各店标题、商品编号、活动价和销售组合也可能不同。因此，看到两个名称相似的记录，不应立刻合并；看到两个名称不同的记录，也不应立刻拆分。
更稳妥的判断，是先确认它们是否指向同一件实物、是否有相同的规格和库存管理要求、是否能够使用同一条内部 SKU。若商品本身相同但渠道属性不同，可以考虑保留一个内部主档并记录渠道差异；若包装、组合数量或计量方式不同，则应进一步核实是否需要独立 SKU 或独立包装资料。
要特别关注“组合商品”。一个店铺卖单件，另一个店铺卖两件套，商品标题可能很像，但库存扣减和成本核算的处理方式不一定相同。是否建立组合关系、如何扣减组成品，取决于企业流程和 ERP 功能，需要先验证，不能仅靠名称推断。
一些团队会把所有历史表格、全部渠道字段和临时备注一起导入，认为信息越全越保险。实际结果可能是必填字段被大量无效备注淹没，重复资料变多，员工不知道哪个字段可信，旧记录也难以辨别。
我更倾向于先区分“必需识别字段”“业务管理字段”和“历史参考字段”。必需识别字段用于区分对象；业务管理字段服务于采购、库存、销售等动作；历史参考字段用于追溯，不应无条件混进日常操作界面。保留数据与让数据参与当前业务，是两件不同的事。
| 问题表象 | 常见根因 | 优先核查 |
|---|---|---|
| 同款商品出现多条内部记录 | 没有统一的建档判断规则，或旧资料未清理 | 规格、编码、条码、单位、历史使用情况 |
| 不同店铺订单难以对应 | 店铺侧商品信息没有与内部资料建立明确关系 | 店铺编号、规格、商品状态及关联维护方式 |
| 库存数量看似异常 | 单位、组合装、仓库或出入库口径不一致 | 库存单位、销售单位、包装换算及仓库定义 |
| 报表汇总结果不可信 | 重复主档、分类不一致或历史记录未处理 | 汇总维度、商品归属、状态与时间口径 |
商品名称适合让人快速理解商品，不适合单独承担唯一识别任务。名称可能因为平台搜索规则、营销活动或团队习惯而变化，同一商品也可能在不同店铺有多种写法。若把名称相同直接当作同一资料，容易误合并；把名称不同当作不同资料，又容易重复建档。
更合理的做法，是根据商品管理需要建立内部编码或其他稳定识别方式，并用规格、单位、条码等信息进行交叉核验。哪些字段可作为匹配条件，要考虑企业商品类型和 ERP 能力。条码也不应被当作绝对真相：条码缺失、包装变化或历史录入错误都可能出现，必须配合其他信息判断。
如果业务确实没有可靠条码，先建立内部编码规则通常比继续依赖商品名更可控。编码可以是有含义或无明显含义的序列，但要保证不重复、可长期保留，并明确新增、停用及历史追溯的处理方式。
各店独立建档看似尊重渠道差异，实际可能把一个企业拆成多套互不相认的资料体系。后续需要合并销售、核对库存或比较店铺表现时，团队只能用表格做二次匹配。若系统确实要求渠道侧记录分开，也仍应尽可能明确内部主档与渠道记录之间的关系。
反过来，“所有店铺都用一套资料”也不是万能答案。部分差异确实影响实物、计量或库存管理，强行合并会造成更大的解释成本。因此，重点不是追求完全统一，而是把差异分类：哪些是纯展示差异，哪些是经营属性差异，哪些会改变库存和财务处理。
这类做法把短期导入速度放在了长期可控性之前。历史资料往往包含停用品、重复记录、字段缺失和临时名称，未经筛选的大批量导入会把旧问题搬进新系统。等到订单或库存已经引用这些记录，再调整名称、编码和关联关系，影响范围会更大。
建议先把资料按状态分组：在售或仍有业务的资料、近期停用但需要追溯的资料、长期无业务且待确认的资料。不同组采用不同处理策略，不必让全部历史记录都进入当前操作清单。数据保留策略要兼顾审计和业务需要，并按企业制度及系统能力执行。
导入成功不是准确率，成功条数也不是验收结论。文件可能全部上传成功，但单位写错、规格字段错位、重复资料被接受，或者店铺侧记录并未正确对应。至少需要检查字段映射、异常提示、重复记录处理和抽样业务结果。
抽样不应只挑最简单的商品。样本应覆盖普通单品、多规格商品、组合商品、不同单位、长期停用商品，以及确实存在店铺差异的商品。对于高风险类别，可扩大检查范围，必要时逐条核验。抽样比例没有适用于所有团队的固定值，需按数据量、历史错误情况和错误后果调整。
个人经验有价值，但如果资料规则只存在某位同事的记忆里，人员调动、休假或离职后，团队就可能重新出现各自建档的问题。资料维护需要把经验沉淀成简单可执行的规则：谁能新增，哪些情况必须复核，如何处理重复项，停用后保留什么信息。
规则不必一开始就写成厚重制度。对小团队来说，一页字段说明、一份异常处理表和明确的责任人，通常比一套无人更新的复杂流程更实用。随着店铺和 SKU 增长，再逐步增加审批、审计和变更记录要求。
我会先把资料拆成三层：企业内部主档、店铺或渠道侧资料、具体业务单据。主档回答“企业如何定义这个商品”；渠道资料回答“这个店铺怎样展示或管理它”；业务单据回答“某次交易实际发生了什么”。混淆这三层，常见结果是把活动标题写进主档，或把某次订单中的临时说明当成长期商品属性。
例如，店铺标题可能带有活动词、季节词或营销承诺，这些内容不一定适合进入内部主档。内部主档应以稳定识别和管理为目的；渠道侧标题需要保留时，放在系统支持的渠道属性中，或用受控对照表维护。系统字段不同，落地方法也会不同。
判断两个记录是否应共用内部主档时，可以依次核对商品本体、规格、计量单位、包装数量、库存管理方式和售后处理要求。若名称不同但商品本体、规格及库存管理完全一致，可能只是渠道命名差异；若包装数量、容量、颜色或尺码不同，即使标题接近，也可能必须区分 SKU。
这里没有一条适合所有行业的机械规则。服装企业可能特别关注颜色、尺码；食品经营可能关注净含量、保质期和批次；家居商品可能关注尺寸、材质和包装件数。判断字段要从实际履约和库存动作出发，而不是照搬别人的模板。
| 处理方式 | 适用情况 | 主要收益 | 主要代价 |
|---|---|---|---|
| 统一到同一内部主档 | 实物和管理属性一致，差异主要是渠道展示 | 便于跨店汇总与集中维护 | 需要把渠道差异放到其他字段或关联关系中 |
| 保留不同主档并建立关联 | 商品相近但规格、包装或库存处理存在差别 | 保留真实业务差异，降低错误合并风险 | 维护和报表解释更复杂 |
| 暂缓归并，列入待确认 | 信息不足，无法可靠判断是否同款 | 避免贸然合并造成库存或履约错误 | 短期内需要人工核验，汇总可能不完整 |
第三种选择经常被忽略。团队常觉得“总要选一个”，于是根据名称或印象强行合并。实际上，保留待确认状态是成熟的数据治理方式之一。先把不确定性标记出来，再指定负责人和完成时间，通常比制造一个看似完整但不可信的资料结构更安全。
不是每个字段都要投入相同精力。一个资料字段是否需要强校验，可以从两个维度判断：错误后果有多严重，以及它在业务中被使用得有多频繁。比如影响库存扣减、采购下单或财务核算的字段，通常应优先确认；只影响内部阅读的备注字段，可以采用较轻的管理方式。
我建议团队给高风险字段设定清楚的责任和校验规则，给低风险字段保留灵活性。所有字段一律审批，会拖慢日常维护；所有字段都允许自由编辑，则会增加口径漂移。好的规则不是最严，而是把严谨用在可能改变业务结果的地方。
资料可能分散在 ERP、各店铺后台、采购表、仓库表、历史导入文件和员工个人表格中。开始整理前，先记录每类资料的来源、更新时间、负责人和用途。没有这一步，团队很容易拿到多个版本的表格，却不知道哪个是当前有效版本。
盘点不是简单收集文件。建议为每份来源资料标注“当前使用”“历史参考”“待核实”或“确认停用”。若两份资料出现冲突，先回到实际业务验证，不要默认最新文件一定正确，也不要默认系统里的旧值一定可信。
字段名称相同，不代表不同岗位理解一致。“规格”可能有人填颜色尺码，有人填包装数量；“单位”可能有人填销售单位，有人填采购单位。字段说明应写明含义、填写格式、是否允许空值、谁负责维护，以及容易混淆的边界。
| 字段或资料 | 建议定义问题 | 常见核验点 |
|---|---|---|
| 内部商品编码 | 是否长期唯一，停用后是否允许复用 | 重复编码、历史编码引用、编码规则是否稳定 |
| 商品名称 | 面向内部识别还是渠道展示 | 是否包含临时活动词，是否能与规格信息配合识别 |
| SKU 规格 | 哪些属性会影响拣货、库存或售后 | 颜色、尺寸、容量、包装数量是否完整 |
| 计量单位 | 记录采购、库存还是销售单位 | 单位换算是否经验证，跨岗位口径是否一致 |
| 店铺侧编号 | 是否保留各店独立编号及状态 | 商品变更、下架或重建后是否需要复核关联 |
去重不能只靠名称完全相同。可以先用内部编码、条码、规格、单位、品牌或供应商编码等信息筛出候选，再由熟悉商品和业务的人判断是否确实相同。候选匹配只适合缩小范围，不应该自动代替业务确认，尤其是相似规格、组合装和新旧包装并存时。
清洗结果建议至少分成三类：确认重复并可合并、确认不同并保留、信息不足待核实。每类都应记录判定理由，避免过一段时间后又有人把待确认项当成已合并。对已被订单或库存引用的资料，合并或停用前应评估系统支持方式及历史追溯影响。
试录样本要覆盖真实复杂度，而不是只挑最容易的单品。可以选一个普通商品、一个多规格商品、一个组合商品、一个跨店同款商品、一个存在旧编码的商品，以及一个停用但仍需追溯的商品。具体样本数量由数据规模和风险决定，不应把示例数量当成固定标准。
试录后，不只检查字段有没有进系统，还要确认实际业务动作是否按预期使用这些资料。让运营、仓库、采购等岗位分别验证自己负责的场景，避免由整理表格的人单方面宣布验收通过。
上线后发现错码、重复或关联错误很正常，重要的是让问题能被记录、分配和关闭。最简便的方式可以是一份共享问题表，记录问题资料、发现时间、影响业务、临时处理、负责人、最终结论和完成时间。若 ERP 或配套工具已经支持变更记录、审批或异常跟踪，也可以评估是否适合纳入流程。
例如，运营发现某店商品关联到错误 SKU，不能只在群聊里说一声。需要确认错误是否已影响订单、库存或报表，谁有权限修改，修正后由谁复核。资料治理不是要求永远不出错，而是让错误尽早暴露、能判断影响、能完成修复并留下依据。
下面用一个虚构的经营场景演示判断方法：一家商家经营三个线上店铺，内部有商品表，各店铺也有各自的商品名称和编号。团队准备整理一批在售商品，希望后续能够按内部商品、规格和店铺观察经营情况。这里的商品数量、处理结果和流程均为情景模拟，不代表任何企业真实统计，也不表示某个软件能自动完成所有环节。
若需要用报表工具观察不同店铺表现，可以在确认数据来源、字段口径和权限后，评估包括 九数云 在内的分析工具。它在此处仅作为经营分析工具的示例，不应被误解为基础资料治理的替代品。报表能呈现数据关系，不能自动替企业决定哪些 SKU 应合并、谁有权改档或库存单位如何定义。
假设三个店铺里都出现一款白色短袖，店铺 A 使用名称“基础棉T 白色 M”，店铺 B 使用“夏季纯棉T-M”，店铺 C 使用“短袖白M”。团队不能只凭名称就把三条记录合并，而要再看商品实物、尺码定义、面料版本、销售单位和包装情况。
如果核对后确认实物和管理属性相同，可以把三条渠道记录关联到同一内部 SKU，同时保留各店铺自己的商品编号和展示名称。如果其中一个店铺销售的是两件装，则需要判断 ERP 如何表达组合销售与库存扣减；不能为了报表好看就直接当成单件 SKU。
| 记录 | 初步观察 | 建议处理 | 需要继续确认 |
|---|---|---|---|
| 店铺 A：基础棉T 白色 M | 包含款式、颜色及尺码描述 | 作为候选渠道记录保留 | 面料版本、内部编码、销售单位 |
| 店铺 B：夏季纯棉T-M | 标题不同，规格表达不完整 | 与实物及规格资料交叉核对 | “夏季”是否仅为营销词，颜色是否一致 |
| 店铺 C：短袖白M | 简称较多，无法仅凭标题判断 | 列入待核实，不直接自动合并 | 尺码标准、商品批次或包装差异 |
团队可以先挑选一组能代表复杂情况的商品进行整理。情景模拟中，假设先选取 30 条记录，包括普通单品、多规格款、组合装和历史停用资料。30 条只是演示方案，不是推荐的固定抽样比例；如果商品结构更复杂或错误后果更高，应增加样本或重点全检。
试录时同时记录问题类型：资料缺少规格、名称无法区分、单位含义不明、店铺编号变化、重复编码或状态不清。若多数问题集中在同一个字段，说明字段定义或来源治理可能不足；若问题零散但都影响高风险业务，应优先增加相应复核节点，而不是只计算总体错误率。
完成后，让不同岗位分别完成一项实际任务。例如，运营人员确认店铺记录能否找到对应内部商品；仓库人员确认拣货和库存单位是否清楚；管理人员检查按店铺和商品汇总的结果是否符合既有业务认知。这样的验收比单看导入提示更接近上线后的真实使用。
当基础资料和订单数据逐步具备稳定关系后，可以按店铺、内部商品、SKU、时间等维度观察销售数量、退货情况或库存变化。若同一实物商品被拆成多条内部记录，报表可能把销量分散；若不同规格被误合并，汇总又可能掩盖真实差异。
用九数云或其他分析工具建立报表时，建议先写明指标口径和字段来源。例如，“销量”是订单件数、支付件数还是扣除退款后的净销量；“库存”是某一时点的可用库存还是账面库存。若源数据没有说明，图表再精美也只是把不确定性展示得更清楚。
小团队不必一开始就建立复杂的主数据委员会。优先做好三件事：明确一个资料负责人；制定商品编码、规格和单位的基本说明；把待确认项单独标记，不让员工自行猜测。资料量少时，人工审核可能比配置复杂流程更经济。
但“小”不代表可以不留规则。尤其当商品会持续新增、多人共同维护，或库存需要跨店共用时，简单的命名约定和变更记录能减少重复劳动。表格可以作为过渡工具，但要指定唯一有效版本、编辑权限和备份方式，避免每个人各持一份。
当店铺和商品同步增加，依赖员工记忆会越来越脆弱。这类团队应优先建立主档新增、变更、停用和店铺关联的责任链，评估 ERP 是否支持批量导入、字段校验、权限控制、变更日志或商品关联等能力。评估时要看当前版本和实际配置，不要只凭产品宣传页推断功能已经开通。
此阶段可以把资料质量纳入日常检查，但指标要有明确口径。例如，可观察“待核实资料数量”“重复候选处理时长”“关键字段缺失条数”“变更后关联复核完成率”。这些指标不是为了排名团队，而是帮助负责人找到流程卡点。指标必须可从系统或台账中稳定取得，否则会变成额外的手工报表负担。
迁移时最重要的取舍，是不要把旧表格的所有习惯照搬进系统。先确认 ERP 的字段含义、导入规则和业务流程，再决定哪些旧字段保留、合并、映射或仅作历史存档。不同系统的模板和功能不相同，正式迁移前应核对当前产品文档，并在测试环境或小范围数据上验证。
如果团队仍未就商品定义达成一致，不建议把“完整迁移”设成唯一目标。可以先迁入已经确认的在用商品，把争议记录列入待处理范围，同时设计临时识别方式，确保业务不中断。关键是把临时方案标明期限和负责人，防止过渡状态永久化。
管理者有时会先要求做跨店销售、库存或利润分析，随后才发现商品编码、时间口径和店铺关联不一致。此时可先通过一份经过复核的对照表支持阶段性分析，同时标注数据覆盖范围和已知缺口，不要把临时映射包装成长期标准。
若使用九数云等分析工具，建议先确认数据从哪里来、刷新频率如何、字段由谁维护、异常如何追踪，再搭建核心报表。分析工具适合帮助团队观察经营结果和发现异常；基础资料主档、权限和业务规则仍应由企业自己的 ERP 配置、数据管理流程或责任岗位负责。
当同款商品在不同店铺只是标题、活动标签或展示方式不同，而内部采购、库存和履约均按同一对象管理时，通常值得统一到稳定的内部主档，再保留各店铺侧信息。这样更利于跨店观察，但前提是关联依据可靠，且系统或台账能够维护渠道记录。
当颜色、尺码、容量、包装数量、计量单位或库存处理方式不同，或者目前无法确定差异是否重要时，应谨慎统一。可以先保留独立记录、标记待核实，再由商品、仓库或财务相关岗位判断。短期汇总不完整通常比错误合并造成的库存和经营解释混乱更容易控制。
当数据量小、变化少、人员稳定时，人工核对和轻量表格可能更划算；当变化频繁、多人协作、错误会影响采购和履约时，应投入更多权限、复核和留痕机制。选择的依据不是团队规模听起来有多大，而是资料变更频率、协作人数以及错误后果。
在批量导入或正式使用前，负责人可以逐项确认：内部主档和渠道资料是否区分；编码及规格规则是否写明；重复和待核实记录是否有处理状态；单位和包装关系是否经相关岗位确认；谁能新增、修改和停用资料是否明确。
还要确认抽样覆盖了不同商品类型，并从实际业务场景核验结果。至少检查一项订单或商品对应场景、一项库存或仓库场景，以及一项报表汇总场景。系统支持什么测试路径，应以实际版本、配置和产品文档为准。
很多团队只管理新增，却忽略已存在资料的变更。商品改包装、换供应商、调整计量单位、店铺重新发布商品或停止销售时，都可能影响资料关系。要明确哪些变化只更新渠道信息，哪些变化需要新的内部 SKU，哪些变化需要重新核对库存和历史数据。
停用也不等于删除。是否删除、冻结或保留历史记录，应结合系统能力、财务追溯、售后处理和企业制度决定。未经评估直接删除旧资料，可能让历史订单失去可解释性；完全不做停用管理，又可能让员工误选已不再使用的记录。
复查频率不必固定照搬某个行业标准，可以根据新增量、历史差错和业务波动制定。资料变更频繁的团队，可以定期查看待核实项和高风险字段；变化较少的团队，可以在大促、系统切换、仓库调整或商品结构变化前集中复核。
复查内容应围绕实际风险，而不只是确认表格有没有更新。例如，长期没有业务的资料是否仍需要保留；新增商品是否遵守现有编码规则；店铺侧状态变化后内部关联是否还有效；抽查报表中的商品汇总是否出现重复或异常分拆。
可以先选少数能驱动行动的指标：待确认资料数、关键字段缺失数、重复候选关闭时间、变更后复核完成情况。每个指标都要明确统计对象、时间范围和负责人。若不能根据指标结果采取具体行动，就不值得长期维护。
不要因为希望呈现“资料治理成效”，就编造效率提升比例或错误率变化。若要比较前后状态，应先确定相同口径、相同业务范围和采集方式。样本量、统计周期或来源发生变化时，应在报告中说明，避免把数据范围不同造成的波动误读成治理效果。
如果你正在准备多店 ERP 数据录入，不必先追求一次性整理全部历史资料。先挑一批高频、跨店销售或规格复杂的商品，盘点来源，确认字段含义，建立内部识别依据，再逐条核验店铺侧关联。小范围试运行后，把遇到的例外写成规则，再逐步扩大范围。
接下来，明确谁负责建档、谁负责复核、谁处理待确认项，并选取订单、库存或报表中的实际场景验收。若使用分析工具，先把字段口径和来源解释清楚，再讨论图表和经营结论。这样做可能比“全部导入后再整理”慢一点，却更容易控制返工范围。
我认为多店基础资料最重要的验收标准，不是字段数量，也不是导入速度，而是团队能否解释每条关键资料代表什么、为什么这样关联、出现变更时由谁处理。若一个商品的内部身份只能靠某个人的记忆维持，它就还没有成为可靠的主档。
多店经营的数据基础，不是把所有店铺改成同一种写法，而是建立一套能容纳差异、识别同一、记录不确定性并持续修正的规则。从一批商品开始，把“先定规则、再清资料、后试录、用业务验收、持续维护”落实下来，ERP 才不只是数据存放处，而能成为团队共同使用的经营依据。
我刚开始整理多家店铺的 ERP 资料时，最困惑的是商品、仓库、供应商和价格究竟该从哪一类开始。要是先把各店铺的表格全部导进去，之后发现字段规则不一致，是否还得重新清理？
建议先录会影响商品识别和库存流转的资料，再处理店铺差异。通常可按“计量单位与类目规则，商品及 SKU，仓库，供应商，店铺商品关联，价格等渠道信息”的顺序推进。这样安排的原因是：商品是否为同一款、库存记在哪个仓库，往往决定后续订单和库存资料能否正确关联。
例如，先确认一件商品的规格和销售单位，再建立内部商品资料，最后整理它在不同店铺中的名称或编码。价格、促销价等容易变动的内容，适合与相对稳定的商品主档分开管理；具体能否分模块维护，需看所用系统的字段和功能。
我有几家店铺在卖相同商品，但标题、规格写法和商品编码各不相同。以前我以为名称差不多就能合并，现在担心把不同规格误当成同款，或者把同款商品重复建档。
不要只凭商品名称判断是否为同一款。建档前应先核对规格、型号、条码或内部识别码、计量单位等信息；如果这些关键属性不同，即使标题相似，也可能需要分别建档。反过来，如果实物和管理属性相同，而差异只是店铺标题或平台编码，通常可以考虑共用一条内部商品主档，并为各店铺保留对应关系。
可以用一张对照表先整理，再按系统能力导入或建立关联： 内部商品主档店铺 A 资料店铺 B 资料核对重点 收纳盒｜白色｜中号白色收纳盒 M家用整理箱白款中号规格、颜色、单位是否一致 内部编码：SH-001平台编码：A-108平台编码：B-236平台编码分别对应同一主档 表中编码仅为示例，不是通用格式。
正式合并前，应抽查实物、条码和规格；系统若不支持店铺商品关联，可先用受控的对照表记录，避免仅靠名称匹配。
我想把几家店铺已有的商品表一次性导入 ERP，手工逐条录入看起来太慢。但我担心列名对不上、空值被误读，或者导入后重复建档，想知道怎样先小范围验证。
批量导入适合字段规则已经确认、资料来源相对干净的情况；它不能替代资料清洗。建议先统一列名和格式，检查必填字段、重复编码、规格缺失、单位混用及停用商品，再用少量有代表性的商品试导入。样本最好覆盖普通商品、多规格商品和不同仓库或单位等容易出错的情况。试导入后，不要只看系统是否提示成功。
还要核对商品是否对应正确、规格和单位是否保留、店铺关联是否符合预期，并在允许的测试流程中检查订单或库存能否正确调用这些资料。确认结果后再分批扩大导入；具体模板、字段限制和导入方式以当前 ERP 的说明为准。
我担心上线时把资料整理得很规范，过一阵子不同同事又新增了重复商品，或修改了规格、单位却没有同步检查店铺关联。除了定期清理，我还想知道日常应该设置什么维护规则。
与其只安排周期性大扫除，不如先明确资料变更由谁负责。可以规定新增商品由指定角色建档，修改规格或单位时先核对是否影响库存和店铺关联，停用资料时保留历史记录并标记状态；权限与审批方式应按团队规模和系统能力设置，不必为了流程复杂而增加不必要的环节。
一个容易执行的做法是记录变更前后值、变更原因、操作人和日期，并在关键变更后抽查受影响的店铺商品关系。每月或每个经营周期检查一次重复项、缺失项和长期未使用资料即可，具体频率可按上新速度调整。重点不是追求字段越多越好，而是让每条资料有人维护、变更有记录、业务能核对。
读者评论
文中把商品主档和店铺侧信息分开讲得比较清楚，尤其是提醒不能只凭名称判断是否同一 SKU，这确实是多店整理时容易踩的坑。
组合装和计量单位的例子很实用。商品标题相似不代表库存扣减方式相同，导入前先核对包装和单位，能减少后续对账麻烦。
我认同先用少量代表性商品试录，再做业务验收。只看导入成功条数，确实无法确认订单关联和报表汇总是否正确。
资料维护责任人这一点容易被忽略。把新增、复核和停用规则写清楚，比依赖熟悉业务的同事记在脑子里更稳妥。
文中的错误占比明确说明是情景模拟，这点很重要；实际团队还是要根据自己的抽查结果排序，不能直接把示例比例当成行业数据。