导读:设计原型应该是很多同学最关心的，但原型设计其实是系统设计中最简单的部分。理清了产品的逻辑和结构之后，设计原型就是一个“物理”的活动。对了，第三篇更新了。看的比较早的同学可以关注一下。

本文中的原型只涉及核心功能，只起到抛砖引玉的作用。请原谅我。

后台系统原型设计分为两步。首先，设计系统结构。然后设计各个模块的详细功能。

系统的第一部分功能结构图已经设计完成，如下图所示:

系统功能结构

菜单设计，根据组织结构图设计菜单，如下图所示:

系统菜单设计

通用凭证系统和营销系统一起设计，不仅可以复用系统管理功能(用户管理、权限管理、登录等。)，而且还减少了系统之间的对接。如无特殊情况，不建议将凭证制度做成独立的制度。关于“系统管理”的部分也是系统设计的基础，这里不再赘述。

系统设计中可复用的组件主要是菜单和页眉，所以让这部分成为主人可以提高设计效率。

如第三章所述，就原型设计而言，后端系统是四个基本模块:添加、删除、修改和检查。根据这个原理，初学原型设计的学生可以防止模块缺失。

系统设计的时候会生成历史数据，既不做“删除”，也不做“更改”，所以在凭证系统的设计中不会做这两块。

1.凭证管理

1)优惠券规则(优惠券模板)管理

第二章分析并确定了优惠券的种类:折扣券、全额折扣券和礼品券。

第三章还总结了每个凭证规则所需的字段:

凭证规则和必填字段

我把三种凭证规则的管理设计到一个菜单里，减少了系统菜单的数量，从操作人员的角度让系统变得“简单”。工程师在开发时可以复用功能，但缺点也很明显:增加了系统的耦合度，只要有一种凭证规则需要调整，就会影响其他凭证规则的使用。在系统设计的时候，要考虑是酌情拆分还是合并。

全额优惠券减免的详细设计

全额优惠券折扣规则的详细信息

不要一个一个的解释领域，说说关键领域。

面值:优惠券减少的金额；

条件:优惠券的使用条件，需要满足该条件才能减免相应的优惠券面值；

最大减少金额:如果优惠券减少逻辑是循环的，则此字段是必需的。比如每1000减50，那么2000就减100；

有效期类型:“固定”有效期，无论用户何时获得优惠券。代金券固定时间有效，固定时间无效。比如2019年8月8日00: 00: 00到2019年9月9日00: 00有效。无论用户是7月31日领券，还是8月31日领券，都是在这个固定的时间范围内可用。

“动态”有效期，从用户收到优惠券开始，在规定时间内有效。为了防止优惠券有效期不可控，增加了“有效期”。比如优惠券有效期30天，9月5日前使用。用户将在7月31日收到优惠券，并可在8月29日前使用。8月3日领券的话，9月3日之前就有了。

动态有效期

代金券渠道:目前前端产品并不单一，比如小程序、M站、app、PC站。用于控制可以使用优惠券的渠道。

优惠券商店:或“经纪行”。平台产品中有很多商家需要设置优惠券可以在哪些商家试用，如果是新零售项目，优惠券可以在哪些店铺使用。

参与商品:可以使用副券的商品，买哪些商品可以使用此券。

b折扣券

折扣券规则的详细信息

折扣券的字段与全折扣券的字段类似，此处不再赘述。

C礼券

折扣券规则的详细信息

礼券的规则更简单。全折扣券和折扣券最大的区别在于，礼券设置的是“兑换商品”，而不是参与活动的商品。我能用这张优惠券换什么商品和多少？

2)优惠券代码管理

首先，根据优惠券规则生成优惠券代码。

凭证编码是根据凭证规则生成的，所以可以在凭证规则列表中增加生成凭证的功能。根据实际需要，也可以使用单独的菜单选择优惠券规则，填写生成的优惠券代码数量。提交后，系统会根据优惠券代码生成规则自动生成优惠券代码。

生成凭证代码

在优惠券规则到期之前，优惠券代码可以无限制次数和数量地导出。

b系统需要有优惠券代码列表，方便查看和管理。

凭证编码有两个基本的管理功能:作废和核销。

该凭证编码作废后不能使用，核销功能等同于用户使用，后面的“凭证使用”会详细说明。

证券代码管理

凭证取消和凭证核销要考虑使用场景，需要批量处理功能，可以自己弥补。

2.凭证活动管理

我们只能为优惠券发放活动设计手动和系统自动优惠券发放的原型，需要其他营销活动通过系统接口调用来发放优惠券。如果我们有机会向您介绍其他营销活动，我们会详细阐述。

凭证发放和凭证接收活动是将会员ID与凭证代码相关联并记录这种关系的过程。(已经在第三章详细解释过了，这里不再赘述)

优惠券活动列表如下:

优惠券活动管理列表

1)发放凭证

手动发放优惠券只需要优惠券规则和会员ID。提交后，系统自动生成优惠券代码，并将优惠券代码与会员ID绑定。

人工发放活动

优惠券发放方式上图为根据会员级别发放优惠券，导入会员ID的方式如下:

凭证发放活动-导入成员

系统自动签发活动是在手动签发凭证的基础上增加自动触发签发凭证的逻辑。基于手工发券的逻辑，大家可以自己补或者自己练。

2)凭证收集活动

如第三章所述，这里的“集券活动”特指“集券专区”的活动，其他场景的集券活动=其他营销活动+集券。

优惠券活动详细信息示例

关键字段

优惠券总量:整个优惠券领取活动中可以领取的优惠券数量；

每日限额:优惠券领取活动每天可领取的优惠券数量；

会员每日限额:在优惠券领取活动中，每个会员ID可以领取的优惠券数量；

会员总限额:每个会员ID每天可以领取的优惠券数量；

3.优惠券的使用

优惠券的使用在第三章也有详细介绍，不再赘述。

1)订单的注销

线上电商，线下实体店，客服，下单都是用优惠券。这个流程优惠券平台没有用户界面，所以不需要设计原型。

2)无订单核销(直接核销)

用户直接在门店用代金券兑换礼品属于非订单核销的场景。

“1”中的凭证代码列表的图表中已经有凭证核销的原型。凭证管理-2。凭单代码管理-系统B需要凭单代码列表……”。

没注意的同学，回去看。

4.优惠券统计

报表从原型设计来说是最简单的，也就是一个“表”。因此，报表原型设计并不重要。把报告背后的逻辑“说”清楚，才是工程师最需要的。

1)优惠券使用统计

凭证使用的统计原型

如果有运营生的需求，设计代金券使用报表是最理想的情况。如果没有具体需求，有以下几个要点:

哪个会员拿到了A券？

B券用过吗？

如果用C券，用哪个顺序，什么时候用。

这几点很关键，因为运营生关注的方向是“成本率”，这些数据是基础。

2)优惠券活动统计

原型设计可以说是整个系统设计中最“物理”的部分，也是我最不喜欢的部分。所以还是把优惠券活动的统计留给大家去思考吧。

结论:凭单系统的设计远不是仅仅四篇文章就能完成的。我刚才说的是核心部分，涉及到优惠券的销售，金融部分，以及更多类型的优惠券。我们以后会续借。