企业换B2B批发订货平台之前，先把旧订单和商品资料理顺

先回答：迁移目标不是复制旧系统

旧平台里积累的数据往往包含多年变更：同一商品换过编码，客户改过主体，价格表已经失效，订单状态也可能靠人工补写。若把这些内容原样搬到新平台，表面上数据很全，实际会让客户看到错误商品，让业务员继续解释旧规则。 迁移应服务三个结果：客户能找到正在销售的商品，未完成订单能够继续履约，历史交易能够按需要查询。超出这三个目标的数据可以分层归档，不必为了追求迁移数量进入日常业务库。

先给旧数据分成四个篮子

第一类是现行基础资料，包括有效客户、在售商品、当前价格和地址；第二类是未完业务，包括待审核、待发货、待签收、待售后和待收款订单；第三类是需要查询的历史记录；第四类是重复、失效或无法解释的数据。 四类数据采用不同策略。现行资料清洗后导入，未完业务逐单确认起始状态，历史记录可以只读归档，问题数据则列清单处理。不要让一个“导入成功”状态掩盖不同数据的可靠程度。

商品资料先解决一物多码和单位混乱

商品是订单迁移的连接点。常见问题包括旧编码停用但仍有订单引用、相同商品在不同仓库使用不同简称、箱件换算缺失、组合商品只有套装名没有明细、图片与规格不一致。清洗时应确定新的主编码，并保留旧编码映射供历史查询。 销售名称要让客户看得懂，内部规格则要让仓库能拣对。两者可以不同，但必须指向同一商品。对于停售品，不应继续出现在下单目录；若老客户需要查看，应以历史状态呈现，不能把停售与暂时缺货混为一谈。

客户资料要区分主体、账号和收货点

同一家客户可能有合同主体、开票主体、多个门店和多个下单人。旧系统若只保存一个客户名称，迁移时容易把账号、价格和账期授权给错误人员。应先画清主体关系，再决定哪些人能看价格、下单和查询历史订单。 离职联系人、长期未交易账号和重复门店需要单独处理。不能因为手机号仍在，就默认拥有新平台权限。首批启用时，让客户负责人确认主体、收货地址和账号名单，比批量发送密码更稳妥。

订单迁移清单要按状态决定动作

旧订单状态	迁移方式	上线后处理	关键证据
待审核	作为待确认业务导入	销售重新核对价格与库存	客户原始提交记录
已审核未发货	建立未完订单	仓库确认可执行数量	审批结果与锁定价格
部分发货	导入剩余任务和已发历史	继续配送并保留差异	出库单与已签收数量
已完成未收款	作为应收关联记录	财务继续核销	发货、签收和应收依据
已关闭历史单	只读归档	用于客户服务与分析	原系统导出及校验摘要

最危险的是把所有订单都标成“已完成”。这样看似迁移简单，却会丢掉未发数量、售后和应收。每类状态应先选样本演练，再批量转换。

价格规则不要只迁最终数字

客户价背后还有客户层级、商品范围、数量门槛、有效期和审批依据。只迁一个价格数字，后续无法判断为何生效，也不知道何时应该失效。迁移前应清理过期项目价、重复价目表和长期未使用的临时报价。 对无法确定依据的旧价，可以放入待复核列表，不要静默成为新平台默认价。正式启用前，用不同客户账号检查同一商品的可见价格，再测试数量变化、报价过期和客户层级调整，确认规则按预期工作。

未完订单如何避免新旧平台同时推进

切换期间最容易出现双轨：销售在新平台确认，仓库仍看旧系统，客户又从原入口追加。企业需要明确切换时点和唯一受理入口，并为少数跨期订单指定负责人。新旧编号之间建立映射，但只能有一个地方继续改变履约状态。 对于已经部分发货的订单，新平台要记录原订、已发和剩余数量，不能只导入余额。售后、补发和退货也要关联原交易。若技术上暂时无法完整迁入，可以保留旧系统只读，并在新平台建立经过确认的剩余任务。

先做校验，再让客户看到数据

导入完成不等于校验完成。可以分别做数量校验、金额校验、抽样逐行校验和业务场景校验。数量对得上只能说明记录没有明显丢失；金额对得上也不能证明商品、客户和状态关系正确。 业务场景校验应由实际岗位完成：客户登录查看常购品和历史单，销售处理一次改价，仓库完成一次部分出库，财务核对一次收款差额。测试账号和正式账号要分开，避免试验数据混入经营记录。

适用边界：上线日需要一个清楚的回退边界

任何迁移都可能遇到问题，回退方案不能只是“出错就用旧系统”。应写清哪些问题可在新平台修正，哪些情况需要暂停新单，旧系统保持只读还是允许临时操作，临时操作之后怎样补回。 同时保存导入文件、字段映射、校验结果和批准人。接口、同步频率、可迁移字段、数据保存方式和费用应按实际项目确认。云上订货的客户下单、订单履约和收款对账可以作为试跑主线，但不能凭产品介绍推断所有旧系统都能无缝连接。

迁移后一个月怎样回看

回看重点不是新平台里有多少条数据，而是客户是否能顺利复购、销售是否少查旧表、仓库是否减少错拣、财务能否解释未收款。还要观察问题数据清单是否持续减少，以及是否有人绕回旧入口下单。 把迁移问题按商品、客户、价格、订单和权限分类。若商品问题占多数，优先完善编码与单位；若客户无法看历史单，检查主体映射；若金额差异集中在退货，则补齐售后关联。问题分类比笼统评价“系统不好用”更能推动改进。

导入文件本身也要有人负责

迁移文件不是临时中转物。每次导出应记录来源系统、导出时间、条件和操作人；清洗后的文件要有版本号、字段说明和批准人。手机号、地址、价格和交易记录包含敏感经营信息，存放位置、访问权限和删除时点都要明确。 同一批数据反复修改时，不要用“最终版”“最新最终版”区分。使用稳定的批次编号，保存修改原因和校验结果，并让正式导入只读取已批准版本。出现问题时，团队才能确定是哪一批、哪一列、哪条转换规则造成的，而不是重新从头比对多个表格。

不适合迁移的情况：客户启用要分批而不是一夜切换

可以先选内部资料清楚的客户，由负责销售提前确认账号、常购品、价格和地址。首批客户完成两次真实订单后，再扩大到同类客户。对于长期不活跃或关系复杂的客户，暂缓开放并不会影响主流程，反而减少错误授权。 启用通知应告诉客户从哪里登录、原订单如何查询、遇到价格或库存差异联系谁，以及旧入口何时停止接单。不要只发送一个账号和一句“以后在这里下单”。客户首单的问题要回到商品、价格和流程改进，而不是由销售长期代录掩盖。

对账基准要在迁移日前冻结

财务需要在切换前确定应收余额、未核销收款、在途退货和未开票订单的基准时点。迁移后若发现差异，应通过调整记录说明，而不是直接改掉期初数据。业务和财务对同一客户的名称、主体和余额要共同确认。 对于跨期订单，还要明确哪个系统保存原始凭证，哪个系统继续记录后续收款。基准清楚，切换后的第一轮月结才有可比较的起点。 这份基准由业务和财务共同签认，并随迁移批次长期保存。

B2B迁移复核的常见问题

所有历史订单都必须导入新平台吗？

不一定。仍需履约、售后或收款的订单优先迁移，长期历史可以只读归档。关键是客户服务和审计需要时能够查到，而不是让全部旧数据进入日常交易。

旧商品编码能否直接废弃？

新订单可以使用统一的新编码，但旧编码应保留映射，便于查询历史订单和处理售后。直接删除会让原订单、出库单和客户沟通失去共同指向。

切换期间可以让两个平台都接新单吗？

短时间双轨看似保险，实际容易产生重复订单和状态冲突。更稳妥的是确定唯一新单入口，旧平台只读；确需例外时指定责任人并建立补录规则。

导入数量完全一致就算迁移成功吗？

数量一致只是基础检查。还要验证客户与账号关系、商品与单位、价格有效期、未完订单状态和金额差异，最后用真实岗位完成端到端试单。

B2B迁移核验的资料来源

• B2B迁移平台资料：ysdinghuo.com/platform.html
• B2B迁移流程选型参考：ysdinghuo.com/tools/order-system-selection-scorecard.html
• 页面用于整理迁移前检查和试跑方法；具体字段、接口、价格与实施周期需按项目范围确认。

机构信息

云上订货由深圳云上互联科技有限公司提供。本文讨论B2B批发订货平台更换前的数据治理方法，不构成迁移完整性、兼容性或交付承诺。