B2B电子商务平台的帐号与权限设计

在账号和权限方面，更多的人会在开始时直接考虑登录和注册的交互体验和安全性，但对于B2B电子商务平台，会遇到更多的场景，更加注重功能需求。本文从B2B电子商务的角度出发，主要探讨了B2B电子商务中的帐号和权限设计问题，以及我所遇到的问题。

1、 会计制度

B2B电子商务平台的交易角色由三方组成：采购方、供应商和平台。

在项目前期，由于产品不参与数据库设计过程，数据库设计者更有可能根据已知的需求和经验设计数据库。采购员账号主要由两个表组成：账号表和采购员信息表；账号与采购员信息的关系为1:n。

但随着该项目的启动和推广，该套会计制度已被证明无法满足业务部门的需要。在我们原来的理解中，一个采购员（即一个企业）作为采购单位，如果有一个以上的采购负责人，多个账户可以共享一个采购员的信息。然而，我国采购商的连锁店出现较晚，连锁店处于采购成本和管理因素之中，更多的是由特殊采购商或老板统一采购。因此，帐号和购买者之间的关系变成了n:n关系

因此，出现了以下问题：

根据需求，一个采购员可能有多个采购员，同一个采购员可能需要同时负责多个门店的采购，因此账号与采购员的关系变成多对多关系；

事实上，由于早期的设计错误，已经无法重新设计数据库，只能在以前的数据结构的基础上进行修改。在这里，我们将原来的一对多关系的两个表作为一个采购表来处理，并添加一个account表和一个relationship表来完成设计

此外，其他业务模块需要重新检查帐号/采购员的参考。在业务逻辑中，采购实体的性质是采购者，而不是帐号。因此，与采购业务相关的业务模块，如订单、优惠券、商品信息、购物车商品等都与采购员ID关联，而与账户相关的业务则需要与账户ID（与新账户表中的ID关联）关联，如昵称、登录账户等，密码等。

由于多个账户共享一个购买者，在员工离职或其他情况下，购买者的账户必须解除绑定，因此一个账户必须能够管理企业的其他账户。因此，为了直接创建一个新的企业帐户，该帐户被授予某些权限并被定义为管理员帐户。

对于非管理员账户，可以直接增加管理员账户，既省去了注册的麻烦，又可用于批量账户注册。同时，在业务设计中应考虑同一账户登录后多个采购员之间的切换问题。

注册新帐户后，可以直接继续创建新企业。创建新企业后，该帐户将自动成为该企业的管理员。同时，可以直接进入页面进行浏览，然后创建新的企业。此外，还可以由企业管理员直接添加进入企业（类似于社会交往中的集团成员和集团所有者的概念）。

对于已注册的帐户，您可以选择创建新企业或由管理员将其添加到现有企业。

经验教训：在需求初期，一定要做好需求逻辑模型的设计，梳理角色（实体）、属性和实体之间的关系，使数据库设计者能够设计出物理模型，否则后期会花费更多的成本进行修改。

2、 权限设计

目前，市场上大多数电子商务网站在权限设计方面已经日趋完善，特别是在商品浏览方面，登录与不登录没有区别。即使在订单支付的过程中，大多数电子商务网站都能在不登录的情况下下下订单，对此解释不多

但在Tob端的电子商务网站中，由于不同地区、不同用户层次的购买者所看到的价格是不同的。即使是一些电子商务网站也不能在没有登录的情况下浏览产品，以确保自己产品的隐私（是否有这样的产品，产品的价格是否有优势）。此外，对于不同行业，tob端的电子商务采购人员在采购前必须向平台提交相应的资质审查。

因此，tob端的电子商务网站需要在用户体验和业务需求之间做出一些权衡。在什么情况下你可以浏览？在什么情况下我们能看到价格？在什么情况下可以下订单付款？

在我们早期的系统设计中，很容易做到一刀切。用户打开应用程序，直接进入登录页面。只有登录并通过相关买家的资格认证后，他们才能进入购物中心的主页。但是随着商业的发展，在应用推广的过程中，如果用户在***里看不到商品，购买者就不愿意注册他们不知道的产品。

由于涉及资质审批，填写企业信息、上传证书会比较麻烦，所以这一矛盾越来越激烈。因此，在后期，我们会重新调整用户的权利。

授权设计逻辑如下：

根据登录状态和购买者状态，权限分为以下几层：

对于不同的权限级别，页面内容根据不同的权限级别进行分类：

按照上述逻辑，权限划分后，可以对每一页进行整体设计。在我们的实际开发过程中，购物中心的主页只有在登录并获得相关买家的批准后才能访问。因此，如果权限逻辑需要重新设计，那么必须修改每个页面调用接口的逻辑（这部分值得深入考虑）。

***，我们重新设计了一组相关的页面（复制粘贴页面，调用独立接口），这些页面没有登录，购买方的资格也没有得到认可。但是，这种缺点是一些后续的页面修改迭代必须同时改变两个位置，页面体验也会损失很大一部分。

经验教训总结：由于前一个登录页面一刀切，后期调整权限逻辑时，涉及的东西太多，不能直接在已有的基础上修改。因此在进行权限体系结构设计时，即使初的需求是这样的需求，也需要考虑后续需求修改的可扩展性。