快好知 kuaihz

web系统中,导入功能的设计要点

相对于玉树临风的功能界面,导入,显得猥琐又懒散。但对于Web系统而言,导入,有时恰是当时境况下的最优解。

一、一个漫不经心的案例

业务场景:物流供应商制定收费规则(如下图),订单发货之后,自动进行物流费用核算。

从上图可见,规则信息项包括:渠道名称、国家、是否计材积重、材积重系数、重量区间、最低起重、运算公式。

并且:

一个渠道,可以对多个国家 。

一个渠道+国家,可以有多个重量区间。

一个渠道+国家,只能有一个最低起重,只能一个是否计材积重、以及材积重系数。

一个渠道+国家+重量区间,只能有一个计算公式。

一个渠道+国家+重量区间+起止时间,是唯一的。

……

了解了以上,基本可以设置一个创建规则的结构:

这个原型的特点之一是丑,第二个特点是存在一定量的前端交互。

但这时,出现一个客观问题——前端开发人员不够。

为了项目进度,第一版,决定采用导入的方式。

为啥呢?因为导入把页面操作都省了。

二、导入方式

在关系型数据库中(参考文章:《后端产品经理笔记之查询数据库》),数据表结构和Excel表结构相似。

所以这样的场景下,导入功能无异是短直快。

导入一般是从最小粒度开始的。一个渠道+国家+重量区间+起止时间,是最小的数据粒度。

但是看上图的表格导入,要考虑挺多问题。比如,我们知道,渠道+国家+起止时间相同的行,可以拟定为一组规则。

所谓一组,就是只有重量区间不同。那么这组拟定规则中,各行的重量区间不能有交叉:

与已经存在的同组规则的重量区间不能交叉;

起止时间不能交叉。

与已经存在的同组规则的起止时间不能交叉;

各行的最低起重要一致;

各行的是否计材积重一致;

……

整理一下要考察的项,基本和下图差不多。

这样导入,看着没毛病,实现起来事倍功半。

首先,Excel不便于做复杂校验

尽量做轻量校验,把数据带入系统之后,在页面承担更多工作。

其次,尽量提升数据最小粒度的颗粒度。

因为粒度一旦细致,就会倍增式地出现交叉校验

再次,尽量在摘出具有共性的参数,导入之后再统一页面处理。

基于以上现状和方向,再次回归业务进一步掉研。如下:

业务会定期给卖家提供更新的报价方案。比如对1月份发货的订单定下了价格,结果2月出现疫情,需要涨价,于是2月修订价格,应用于2月发货的订单。而我们所说的起止时间,不是规则生效的时间,而是适用于的订单的发货的时间。

以上可以看出来,其实每一次修订,都可看做一次更新迭代。每次迭代,都可以将所有变化和未变化的都导入一遍。于是就可以将起止时间独立出来,放在最外层。也就是导入的这一批适用的订单的发货时间是一致的。

再看‘是否计材积重’。

它表达的是,一些货物是否按体积折算出重量。比如一车棉花,按实际重收费就亏了。因此,这个判断的场景一般是发货的时候,由渠道定的。

所以可以统一在导入之后,与渠道做关联。也就把这项,从导入的规则明细中剔除出来。

三、做了这个导入功能

于是导入的模板就简化为这样:

正常做:

(1)导入框:

(2)校验

第一:校验导入的文件是否正确

表文件A-I是否对的上,对不上视为模板错误。直接报告文件错误,不再进入详情校验

第二,校验内容

必填项不能为空

重量起点(g)<重量止点(g)

单元格内容需被系统识别或格式正确。

先判断不需要查表的项,再判断国家、物流渠道名称这些需要查表的项。

以A+B+C+D列判重,若存在重复的行,则对第二及其后的重复行报错.

A+B列相同的行之间,重量区间不能交叉。

交叉的规则:假设重量区间a-b、e-f,若出现a< e<b、e < a < f、a< f<b、e < b < f任一种情况,则视为这两个区间交叉,则对第二及其后的重复行报错。

这里为啥不校验系统已存在的数据呢?

因为我们用起止时间,将这种本次导入与历史数据的重复规避掉了。具体就是:

全部校验通过,导入这一批,生成一个批次号,这个批次号需要编辑一个起止时间,这个起止时间不能与其他批次号的起止时间交叉。

这时候还余下一个参数 :是否计材积重。在编辑时间的时候进行编辑即可。如下图:

总结这个案例,物流费用规则的页面有两层:

(1)列表页:版本号维度。每成功导入一次,则生成一条对应的版本号数据。

每个版本号对应一批规则,对应同一个适用时间,因此通过版本号标定这一批规则,并将适用时间与版本号进行关联,而不与具体的规则明细关联,简单清晰。贴近业务场景。

(2)明细页:显示某一版本号下的全部规则明细。也就是导入的每一行规则。

四、姗姗来迟的小结

(1)导入的本质:

是将Excel的指定列,赋予数据库的某个字段,比如A列对应字段‘渠道名称’。

(2)导入时候的校验项很多,一条数据不止命中一个错误。

一般而言,按规则的顺序,每一行只报一个错误原因。

(3)因为可能需要反复校验多个校验项,所以依次进行,从简到难。比如:

优先是必填项不能为空,单元格内容格式正确。

然后才是核对数据是否存在于基础数据库中;

最后检测本次导入与已存在数的冲突性校验,比如重复。

(4)每校验一项内容,都将全部数据跑完。

比如四个校验项,100条数据。

先跑校验项1,将各行都检测完;都没错,则跑规则2,出错则报错。

下次修复后再次导入,则还是从验项一跑到验项四。

(5)导入的格式与性能有关

CSV格式的系统开心,秒传,但是用户优势不大喜欢。Excel相反。

(6)与历史数据的更新还是覆盖?这个情况让用户选了。

(7)一旦一条出错,是否全部不予导入呢?

一般而言,若是提交给另外的系统,那通过的基本就写入了,就没法回滚了。所以就部分正确则部分导入

如果是自己系统,一般一旦一个写入错误,则全部回滚,全部检查,直至全部OK才写入。确保完整性。

(8)报错的方式

十几二十条就在弹框说明谁是错的就可以。过多数据的就Excel报错。

(9)Excel 模板可以做什么?

可以加表头标注,加注释说明,加第二分页。但是要开发知道。说明哪些区域是导入区。

(10)导入是猥琐的。但是也有主动使用导入的场景,比如:

从1688导出了订单的采购信息,包括物流单号等。这时候如果要把物流单号加到自己系统中去,一个个加入肯定费劲,直接导入就很快了。

另外其实案例的这个数据量上千,导入也是比较合适的。所以导入的功能是猥琐了点,但是有时候可以大用。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:导入  导入词条  要点  要点词条  功能  功能词条  设计  设计词条  系统  系统词条  
设计

 B端产品的建设过程中的5个阶段

笔者从实际的工作实践出发,对于B端产品整体的建设历程进行了详细地分析与介绍,供大家参考学习。绩效管理系统是公司绩效管理体系落地实施的重要工具,2年前刚从C端产品...(展开)

设计

 TO B 产品在进行logo设计...

本文将to b产品的logo分为四个大类,那么在设计的时候,分别需要考虑哪些因素,且它们在设计的时候的难易程度又是怎样的呢?软件公司的logo大致分四类即:公司...(展开)

设计

 B端产品怎么判断需求优先级?

产品经理的日常工作基本是围绕需求展开的,而面对不同角色给出的各类需求,产品经理该如何判断需求的优先级呢?怎么找到判断标准与关键呢?针对这样的疑惑,笔者给出了一系...(展开)