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

最新动静，从2018年11月1日起，遵循结构调剂原则，参照国际通行做法，将现行货物出口退税率为15%的和部门13%的提至16%;9%的提至10%，其中部门提至13%;5%的提至6%，部门提至10%。对高耗能、高污染、资赋性产物和面临去产能使命等产物出口退税率连结不变。进一步简化税制，退税率由原本的七档减为五档。

对B2B电商平台来讲，账户登录注册体验来讲会碰着更多的场景，对功能的要求也斗劲正视。本文首要从B2B电商的角度，讲述账号及权限设计的问题。

1、账号系统

B2B电商平台的生意脚色由采购商，供给商和平台三方组成。

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

可是跟着项方针上线及奉行，该套账号系统被证实不能知足营业部门的需求。在我们原本的认知中，一个采购商(即一个企业)作为一个采办单元，假若有多小我负责采购的气象下，多个账号共享一个采购商的信息便可。可是后来我们的采购商闪现的连锁店，而且连锁店处于采购成本和治理的成分，更多的是由专门的采购人员或老板进行统一的采购，是以账号与采购商的关系酿成了n：n的关系

是以衍生出以下几个问题：

1. 数据库的设计

遵循需求一个采购商可能会存在多个采购人员，统一个采购可能需要同时负责多家店的采购，是以账号和采购商的关系酿成多对多的关系;

现实上因为前期设计短处，导致从头进行数据库的设计不再可能，只能基于之前的数据结构进行改削，这里我们将原本的一对多关系的两个表整体看作一个采购商表，新增一个账号表和一个关系表便可完成设计

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

2. 营业流程设计

因为多个账号共用一个采购商，在有员工去职或其他气象下，必需对采购商的某个账号进行关系的解绑，所以必需有一个账号能够治理该企业的其他账号。所以对直接建树新企业的账号，将这个账号赋予必定的权限，将其界说为治理员账号。

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

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

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

(2)老账号绑定企业

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

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

2、权限设计

此刻市道上除夜除夜都电商网站对权限的设计已日趋完美，出格是在商品浏览方面，登录与不登录没有甚么分辩，甚至不才单支出环节除夜除夜都电商网站已可以做到不用登录便可下单，这方面不做过量声名

可是在to B端的电商网站中，因为对不合地域，不合用户等第的采购商来讲，看到的价钱是纷歧样的。甚至有些电商网站为了保证自家商品的隐私性(是不是有该商品，商品的价钱是不是有优势)，在不登录的气象下都不成以浏览商品。此外对不合的行业，to B端的电商上的采购商必需提交响应的天资给平台进行审核才能进行采购。

是以，to B端的电商网站需要在用户的体验和营业需求长进行一些权衡，甚么气象下能浏览?甚么气象下能看到价钱?甚么气象下能进行下单支出?

在我们前期的系统设计中，索性直接一刀切，用户打开APP直接进入登录页面，在未登录且联系关系采购商天资审核经由过程前不能进行进入商城主页面。但跟着营业的成长，在APP的奉行过程中，假定用户看不到商城的商品，采购商不太愿意注册一个不体味的产物。

因为这中心涉汲嗍质的审核，需要填写企业资料、上传证件，会斗劲麻烦，所以这类矛盾变得愈来愈乖戾。是以，在后期我们对用户的权限进行的从头的调剂。

权限设计逻辑以下：

遵循登录状况和采购商状况，将权限分为以下几层：

未登录账号的权限;

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

已登录账号且已绑定采购商，可是采购商未审核经由过程;

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

对不合的权限等第，将页面内容遵循不合权限等第进行归类：

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

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

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

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

遵循以上逻辑对权限进行划分往后，便可对各个页面进行整体的设计了。在我们的现实斥地过程中，因为之前是只有已登录且联系关系采购商审核经由过程才可进入商城主页面。所以若需要对权限逻辑进行从头设计，那么各个页面调取接口的逻辑必需改削(这部门处所值得深切思虑)。

所以最后我们对未登录，采购商天资未审核经由过程权限触及的相关页面从头设计了一套(页面的复制粘贴，调取自力的接口)，但这样的短处是后续有一部门页面的改削迭代都必需同时改两处处所，而且页面的体验也会损失踪踪很除夜一部门。

经验教训总结：因为前面直接在登录页面进行一刀切，在后期对权限逻辑进行调剂的时辰，导致触及的工具太多而不敢直接在已有的根底长进行改削。所以我们在做权限架构设计的时辰，就算当初的需求是这样要求的，也需要考虑后续需求改削的拓展性。

3、前端揭示页面相关设计

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

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

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

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