批量导入是B端后台产品中常用的一大功能，看起来简单但是实际上做起来却能够发现里面的坑有很多。作者结合自己的实战经验，与大家分享自己当时从0到1的设计过程，希望对你有所帮助。

批量导入是B端后台产品中非常常见的功能，乍看简单，但实际做起来才发现里面的坑着实不少。笔者根据自己的工作经历，记录整理了当时从0到1的设计过程。内容较长，耐心看完，相信你一定会有所收获！

一、业务分析

在开始任何B端产品的功能设计前，都需要先分析这个功能对应的业务场景以及想解决的业务问题。

批量导入也不例外，一般导入功能都出现在需要单次录入大批量数据的后台产品中。根据不同的场景会有不同的应用，需要结合用户特征来一起分析，它们共同决定了导入功能的软件功能流程和基本逻辑，例如：

1. 导入的数据是“新增”还是“覆盖”？（即系统中已有数据的情况下，本次导入是在其后添加数据，还是完全覆盖系统已有的数据）
2. 存在错误数据时，是忽略错误数据允许正常数据导入，还是全部打回重新导入？
3. 错误数据如何提示和处理，是在线修改，还是导出excel让客户修改后重新导入？
4. ······

这些都是在业务分析阶段就需要思考的事情！

二、导入流程

导入功能大致可以分为3个环节

1. 导入指引：让用户了解怎样使用导入功能，并给出一份模板文件；
2. 导入文件：上传文件，并校验错误数据；
3. 结果反馈：让用户知道本次导入的结果&影响。

其中2是最麻烦最复杂的一环，因为除了常规的文件类型和数据格式校验外，部分B端产品可能还会有一些业务上的限制，需要考虑到导入的数据与现有的业务规则是否冲突，如果存在冲突，要以何种形式告知用户哪些数据异常、要如何处理。

三、功能设计

3.1导入指引

3.1.1导入指引

如果导入过程并不复杂，只需要给出下载模板和上传文件的入口即可；如果流程比较长，需要给出一条明确的步骤指引。

3.1.2模板说明

对于一些重要的系统要求或者是不易察觉的设置，需要在表头上进行说明，引导用户正确的填写数据。

3.2导入文件

3.2.1 导入进度

根据导入数据的规模和校验规则的复杂程度，需要考虑不同的上传进度提示。（这些最好提前与研发人员沟通好）

• 如果一般情况下上传数据少，校验规则也比较简单，耗时短，可以给一个轻量的加载图标；
• 如果单次导入的数据量大，或者校验规则比较复杂，需要较长的时间，可以给一个上传进度条。在这种情况下，导入任务可以设置成异步处理，即允许用户关闭当前导入窗口，使用软件的其他功能模块。

3.2.2 文件解析和数据逐行校验

一般导入文件的校验分为两个过程：

1）文件格式校验

在写入数据前，首先会校验文件的基本格式是否符合规范，如果不符合则需提示用户检查上传的文件并重新上传。一般会有如下规则：

• 文件类型：支持的文件类型，如excel文件；
• 文件大小：是否超出规定的文件大小，如2M；
• 表头：是否与模板一致；
• 行数：是否超过规定的上传上限，比如最多允许导入1000行记录，但上传的文件有2000条记录

2）数据内容校验

文件校验通过后，就开始校验逐行表格中的数据内容，一般包括数据格式和业务规则的检验：

• 数据格式：字段的数据类型、长度，比如某个数量字段，用户填了文字；
• 业务规则：记录重复、不同字段之间的运算关系、主从逻辑判断等；（比较复杂，会在文章末尾中的案例中提供示例参考）

3.3 导入结果反馈

1）导入结果

反馈用户本次导入的结果状态。

• 一般“覆盖”导入（即导入的数据会覆盖系统原有数据），对于错误数据，都是全部拦截并进行报错提示；
• “新增”导入（即导入的数据会在系统原有数据基础上进行新增），一般都只允许正常数据导入，错误数据到出修改，这样可以方便用户快速定位到错误的字段上。

2）错误数据修改

导入失败的数据可以支持单独导出，并在excel中对异常字段进行特别标注，也需附上“错误原因”。（也有文章提过部分情况下可以让用户在线修改，但个人认为这种方式并不好，因为对于由同一个错误引起的大量异常数据，修改效率很低。如果考虑批量编辑功能，开发成本又会变得很高）

3）导入历史（非必须）

部分特殊情况还需要记录导入历史，方便后续查看。

四、分析案例

4.1 产品介绍

一款面向小微企业&个体工商户的ERP进销存管理软件，帮助他们实现业务的数字化管理。（说人话就是，倒买倒卖的中间商每天向哪个供应商买了哪些商品？又向哪个客户卖了哪些商品？仓库里现在又还有哪些货、数量多少？······

成千上万个商品在不同时间、不同客户、不同供应商中积累的价格、数量、金额等信息是海量的，光靠脑子不可能记得住，更不用说去分析一个周期内的销售额、利润！因此软件就是帮助这些中间商记录商品流通过程中的信息数据，更好地掌握生意状况）

4.2 需求背景

我是一名批发商，上次向某个供应商订了一批货，这次供应商把货送了过来，还附了一张单据（可能是电子单据，也可能是纸质单据，不同供应商给的单据格式也不一样，如下图所示），你确认没问题后，把这批货搬进仓库，然后把这个单据录到系统中，一个个选择商品肯定太麻烦了，于是你希望有一个导入功能，帮你把这些数据批量处理掉。

4.3 业务背景

这里提两个比较重要的概念，方便读者更好的理解下面的分析过程。

1）商品唯一性标识

商品条码一般是商品的唯一标识，由商品国际物品编码协会赋予，包含该物品的生产国、制造厂家、商品名称、生产日期、类别、日期等许多信息，在商品流通有广泛的应用。（简单来说就是你去便利店买东西结账，店员用扫码枪“嘀”的那块地方，如下图）

但是对于部分行业，流通的商品大多是非标品，例如茶叶、部分食品、五金件等，也没有条码的概念，只能通过一定的规则（通常是商品名称）去标识一个唯一的商品。

而我们软件定位是泛行业的软件，所以商品条码是商品最高级的唯一标识，却又不是一个必要信息。除此之外，商品名称&规格组合也是一个商品的唯一标识，不可重复。

2）单位

商品单位容易理解，计量商品的标准量，如个、件、箱、米等。值得注意的是，部分商品在实际业务中可能同时存在多个单位，例如300ml罐装的可乐，1“瓶”3元，论“箱”（1箱=24瓶）销售时，1“箱”70元，即同一商品不同单位之间存在换算关系，所以这些商品在商品管理上略微复杂，导入功能设计上也需要考虑到这种情况。

4.4 分析过程

1）用户分析

在过往的用户调研中，我们发现用户大多是四十左右的中年人，文化水平普遍偏低，对于大篇幅的文字说明都不太敏感，可能导入出错的概率会比较高。因此除了功能框架层设计上要简单清晰，还要强化对异常情况的处理提示，让用户一眼就知道导入失败原因在哪以及如何处理。

2）业务场景分析

进货场景下，可能同时会进一些新商品和旧商品（即软件中没有/已有的商品资料），进新商品会新建商品资料，进旧商品会更新库存数量，综合考虑决定“商品名称”和“数量”为必填字段，其他为非必填字段；另外导入数据规模上，产品介绍有提到软件面向的是小微企业主，他们的进货规模根据调研结果，单次大多不超过100个sku，所以导入限制在200~1000行数据就足够了。

3）可能出错情况

由于新旧商品同时存在，因此要考虑的难点除了旧商品与已有商品资料的冲突，还有建立新商品资料的业务规则冲突。需要分别穷尽所有的出错情况，并根据出错场景，来决定哪些需要软件自动处理这些错误，哪些需要导出让用户确认修改这些错误。

分析到这里，差不多一个完整的导入功能流程就呼之欲出了。

4.6 功能流程图

4.7 原型设计&说明

这里就不贴原型了，网上资源多的是。主要讲讲其中的核心部分：数据内容的逐行校验与提示。

由于公司保密制度规定非常严格，无法把PRD全部贴上来，这里简单提几个可能的业务规则校验供大家参考：

• 不同供应商品名：系统商品资料存在这个条码，但对应的商品名称不同（比如一罐可口可乐，供应商A叫“可口可乐”，你录到系统里也命名为“可口可乐”，但你这次又从供应商B那里进了这个商品，他给你的单据上显示名称为“可口可乐300ml”）
• 旧商品新单位：商品条码、名称与系统一致，但该商品没有此单位
• 运算关系冲突：多个字段之间存在运算关系，但用户上传的数据不符合计算逻辑，比如单价*数量≠金额
• ······

值得注意的是，上面提到的业务规则校验，并不是所有都要当错误处理，有些可以让程序自动处理，提高用户的产品体验。