b2b电子商城系统功能之账号与权限设计

最新消息，从2018年11月1日起，按照结构调整原则，参照国际通行做法，将现行货物出口退税率为15%的和部分13%的提至16%;9%的提至10%，其中部分提至13%;5%的提至6%，部分提至10%。对高耗能、高污染、资源性产品和面临去产能任务等产品出口退税率维持不变。进一步简化税制，退税率由原来的七档减为五档。

对于B2B电商平台来说，账户登录注册体验来讲会遇到更多的场景，对于功能的要求也比较重视。本文主要从B2B电商的角度，讲述账号及权限设计的问题。

一、账号体系

B2B电商平台的交易角色由采购商，供应商和平台三方构成。

在项目初期，由于产品未参与数据库设计的过程，所以数据库设计者更多的是凭借已知的需求及经验进行数据库的设计，采购商的账号方面主要是由两个表组成：账号表和采购商信息表;账号与采购商信息之间的关系为1：n的关系。

但是随着项目的上线及推广，该套账号体系被证明不能满足业务部门的需求。在我们原来的认知中，一个采购商(即一个企业)作为一个购买单位，如果有多个人负责采购的情况下，多个账号共享一个采购商的信息即可。但是后来我们的采购商出现的连锁店，而且连锁店处于采购成本和管理的因素，更多的是由专门的采购人员或老板进行统一的采购，因此账号与采购商的关系变成了n：n的关系

因此衍生出如下几个问题：

1. 数据库的设计

根据需求一个采购商可能会存在多个采购人员，同一个采购可能需要同时负责多家店的采购，因而账号和采购商的关系变为多对多的关系;

实际上由于前期设计错误，导致重新进行数据库的设计不再可能，只能基于之前的数据结构进行修改，这里我们将原来的一对多关系的两个表整体看做一个采购商表，新增一个账号表和一个关系表即可完成设计

另外，其他业务模块对于账号/采购商的引用需要进行重新的检查，在业务逻辑上，一个采购实体的性质是采购商而不是账号。所以和采购业务相关的业务模块如：订单、优惠券、文章消息、购物车商品等均与采购商id关联，而与账号相关的业务需要与账号Id关联(与新的账号表中的id关联)，如：昵称、登录账号、密码等。

2. 业务流程设计

由于多个账号共用一个采购商，在有员工离职或其他情况下，必须对于采购商的某个账号进行关系的解绑，所以必须有一个账号能够管理该企业的其他账号。所以对于直接创建新企业的账号，将这个账号赋予一定的权限，将其定义为管理员账号。

对于非管理员账号，可以由管理员账号直接添加，这样可以省去注册的麻烦也可用于批量注册账号。同时业务设计中也需要考虑登录同一个账号后，在多个采购商之间进行切换使用的问题。

(1)新增账号并绑定企业

注册新账号之后，可以直接继续创建新的企业，创建新企业后，该账号将自动成为企业的管理员。同时也可直接进入页面浏览之后，再创建新的企业。另外，也可直接由企业管理员添加进入该企业(有点类似于社交中群成员和群主的概念)。

(2)老账号绑定企业

已注册的账号，可以选择创建新企业或由管理员添加进入已存在的企业。

经验教训总结：在需求的初期，一定得做好需求的逻辑模型的设计，梳理其中的角色(实体)，属性及实体之间的关系，以供数据库设计人员进行物理模型的设计，否则在后期会花费更多的成本进行修改。

二、权限设计

现在市面上大多数电商网站对于权限的设计已日趋完善，尤其是在商品浏览方面，登录与不登录没有什么区别，甚至在下单支付环节大多数电商网站已经可以做到不用登录即可下单，这方面不做过多说明

但是在to B端的电商网站中，由于对于不同地区，不同用户等级的采购商来说，看到的价格是不一样的。甚至有些电商网站为了保证自家商品的隐私性(是否有该商品，商品的价格是否有优势)，在不登录的情况下都不可以浏览商品。另外对于不同的行业，to B端的电商上的采购商必须提交相应的资质给平台进行审核才能进行采购。

因此，to B端的电商网站需要在用户的体验和业务需求上进行一些权衡，什么情况下能浏览?什么情况下能看到价格?什么情况下能进行下单支付?

在我们前期的系统设计中，索性直接一刀切，用户打开APP直接进入登录页面，在未登录且关联采购商资质审核通过前不能进行进入商城主页面。但随着业务的发展，在APP的推广过程中，如果用户看不到商城的商品，采购商不太愿意注册一个不了解的产品。

因为这中间涉及资质的审核，需要填写企业资料、上传证件，会比较麻烦，所以这种矛盾变得越来越激烈。因此，在后期我们对于用户的权限进行的重新的调整。

权限设计逻辑如下：

根据登录状态和采购商状态，将权限分为以下几层：

未登录账号的权限;

已登录账号，但未绑定采购商的权限;

已登录账号且已绑定采购商，但是采购商未审核通过;

已登录账号且已绑定采购商，采购商资质审核已通过。

对于不同的权限等级，将页面内容按照不同权限等级进行归类：

不需登录即可看到的内容，主要是商品列表中的商品，注册相关页面等;

需登录但是不需要采购商信息的内容，如：账号名，昵称等;

需要登录且需要采购商信息，但采购商为未审核通过的状态所看到的内容;

需要登录且需要账号信息才能看到的内容，如：商品价格，购物车等。

按照以上逻辑对于权限进行划分之后，就可对各个页面进行整体的设计了。在我们的实际开发过程中，由于之前是只有已登录且关联采购商审核通过才可进入商城主页面。所以若需要对权限逻辑进行从新设计，那么各个页面调取接口的逻辑必须修改(这部分地方值得深入思考)。

所以最后我们对于未登录，采购商资质未审核通过权限涉及的相关页面重新设计了一套(页面的复制粘贴，调取独立的接口)，但这样的弊端是后续有一部分页面的修改迭代都必须同时改两处地方，而且页面的体验也会损失很大一部分。

经验教训总结：由于前面直接在登录页面进行一刀切，在后期对权限逻辑进行调整的时候，导致涉及的东西太多而不敢直接在已有的基础上进行修改。所以我们在做权限架构设计的时候，就算当初的需求是这样要求的，也需要考虑后续需求修改的拓展性。

三、前端展示页面相关设计

登录注册流程：与C端的电商的登录注册模块不同，除了账号的申请之外还要考虑采购商企业资料的提交(也提供跳出路程的出口)。

账号的管理：上文说到的每个采购商的管理员需要管理子账号，所以提供添加子账号的页面(不存在的子账号则直接先生成一条账号信息)，并可将该账号从采购商中删除。

创建新采购商：提供两条路径：一个是在注册时，一并完成新采购商的创建，一个是登录后，专门提供一个入口创建新采购商。

切换所属的企业：采购商可以切换当前所属的企业，以方面单独为每个企业进行采购。