客户表能上传，订单表也能上传，为什么进入业务系统后，订单找不到对应客户，产品名称又出现了好几种？常州企业从表格管理转向系统管理时，旧数据导入不能只验收一个上传按钮。先把记录之间的关系说清楚，才能判断搬进去的数据是否可用。
同一个客户，旧表里可能有不同名字
假设一家设备企业准备迁入客户和订单资料，以下是沟通示例，并非客户案例。销售表用客户简称，发货表用公司全称，旧订单还沿用曾经的名称。如果只按文字匹配，有些订单就可能找不到客户；如果看到名字相近就合并，又可能把不同企业放到一起。
这类问题应由熟悉业务的人先确认，再交给开发人员制定导入规则。哪些记录属于同一客户，哪个名称作为当前名称，旧称是否保留为查询线索，都需要有明确依据。不能让程序替企业猜测事实。
导入前，先准备一张字段对应表
拿到旧文件后，逐列确认“这一列在新系统里叫什么、代表什么”。客户名称、产品编号、数量、金额、负责人和订单状态分别核对，不因为两列表头一样，就默认含义相同。
- 记录身份：用双方确认的客户、产品或订单编号对应记录。编号中的字母与前面的零是否有意义，要保留清楚；缺少编号的记录另行整理。
- 数量与单位：件、套、箱不能直接混用。金额是否包含运费、空白表示未知还是未填写，都由企业确认，不能一律补成零。
- 状态与归属：旧表里的“完成”指已经发货还是业务结束，离职人员负责的未结订单交给谁，分别写明。
- 导入范围：正在处理的业务、需要查询的历史记录、仅作归档的资料可以分别安排。不需要上线展示的内部备注，也不随意公开。
原始文件保留一份不改动的副本，整理后的文件另存。每次更正能回到原记录，后面发现异常时也便于查原因。
第一轮试导入，选有代表性的记录
不必一开始就导入全部资料。先在双方确认的测试环境中，选一组有关联的客户、产品和订单，包含普通记录、重名记录、缺项记录，以及还没处理完的订单。测试资料使用虚构信息或按需要脱敏，不把完整客户资料当作演示文件随意转发。
试导入后沿着一张订单检查：客户是否对应，产品与规格是否准确，数量单位有没有变化，负责人能否找到待办。再试一次重复上传同一批文件，确认是拒绝、跳过还是更新，并核对是否意外增加了重复订单。具体处理方式应在开发时约定。
核对结果，不只看“导入成功”
要求结果能说明哪些记录成功、哪些失败、哪些需要人工确认。失败记录应能定位到原文件的具体行和原因；重复记录如何处理、已存在数据是否被覆盖，也要留下可核对的说明。
按业务需要比较记录数量、关联关系与关键汇总值。发现差异，先区分是格式问题、缺失资料还是规则理解不同，再修正重试。不要为凑齐数量，把无法判断的客户或订单直接合并。
正式切换以后，旧表适合作为受控查询依据，不宜再与新系统各记一套。数据关系核对通过后，还应分别检查各岗位的查看与操作范围，避免导入正确、使用时却越权。
返回列表