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

一、业务分析

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

批量导入也不例外，一般导入功能都出现在需要单次录入大批量数据的后台产品中。根据不同的业务场景，所对应的业务需求也会有所不同，从而在产品设计方案上也会造成巨大的差异，例如：

1. 导入的数据是“新增”还是“覆盖”？（即系统中已有数据的情况下，本次导入是在其后添加数据，还是完全覆盖系统已有的数据）
2. 存在错误数据时，是忽略错误数据允许正常数据导入，还是全部打回重新导入？

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

二、导入流程设计

导入功能大致可以分为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 产品介绍

一款面向小微批发商的进销存管理软件，主要提供库存管理、销售管理、客户管理等功能，帮助商家提升店铺的运营效率和管理水平

说人话版本：批发商基本就干两件事，从工厂或者上级代理商拿货，然后卖给下级的零售店，利用倒买倒卖的差价赚取利润。在这个过程中，商家就需要去管货（不然客户来订货，都不知道货够不够）、管钱（为了更好卖，允许客户先拿货，月底再结账，那就需要管理欠款和已收款），管客户（不同客户拿货量不一样，给每个客户/客户群不同的销售价），管利润（忙活了一个月，到底赚了多少钱）

4.2 业务背景

批发商为了以更低的成本拿到货，通常会一次性向供应商订购大批量货品，收到货物后，需要将这批货物的采购信息录入系统中，以便后期追溯。但是一次采购可能有几十上百种货品，一个个录入太麻烦了，因此希望有导入功能，能将数据批量导入到系统中，提高效率

4.3 需求分析

新商品和旧商品同时导入非常普遍

采购场景下，商家出于提升吸引力的考虑，可能同时会进一些新商品（新商品在这里指软件中还没有录入资料的商品）。因此，为了提升用户的使用体验，产品设计上需要考虑支持新旧商品一起导入，后台逻辑上需要对商品存量数据更新库存，同时对新商品新增基础数据。另外导入数据规模上，产品介绍有提到软件面向的是小微企业主，他们的进货规模根据调研结果，单次大多不超过100个sku，所以导入行数限制在200~1000行就足够了。

需要导入图片

上游供应商提供的单据就是用户想要导入的数据来源，不同供应商给的单据格式也不一样，可能是电子化的（pdf、excel等），也可能是纸质的，如下图所示：

excel导入就是比较常见的导入功能，但是图片导入也是一个值得挖掘的场景，可以考虑结合OCR和AI的能力来处理，数据处理逻辑和excel导入类似，不过交互上会有很大差异，这里只展示一个案例效果，就不做过多深入了。

预期导入可能出现的异常情况

由于允许新旧商品同时存在，因此要考虑的异常情况很多，除了旧商品与系统商品资料的冲突，还有新商品资料与系统的基础资料创建规则冲突，需要分别穷尽所有的异常情况，并根据每一个异常对应的业务场景，来决定软件要如何处理异常和提示报错。

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

4.5 功能流程图

4.6 原型设计&说明

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

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

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

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