电子票|发票系统0-1闭环设计思路( 二 )

当然如果用户有指定开专票或者纸质的普票的话，作为商家还是有义务为用户开票的，对于这种情况可以走线下联系客服等方式在后台申请开票。
③ 申请信息
不同类型的票需要的信息是不一样的，同样纸票和普票所需要的信息也不相同；
这里其实分为几部分，用户的个人申请信息和发票信息，其中个人申请信息是用户自己需要提供的信息，发票信息都是开发票需要。
但是由系统自主可以通过订单获取到的。
下图我简单列了下基本信息，有的字段对于不同的发票类型、发票种类都有不一样的输入要求。

文章插图

查看开票进度：用户申请开票后，发票的状态要讲对应展示文案告知用户开票进度，给用户有一个预期

查看发票、下载发票、发送邮箱：开票后用户可以下载发票或者选择将发票发送到指定邮箱

（2）B端后台

申请节点：同用户端，前后台保持一致
申请类型：在后台申请的话，那么他可申请的范围包括普票、专票、包括电子票和纸质票。
查看开票进度：后台也需要展示开票进度，这样用户咨询客服或者运营时，内部人员也可以给出反馈
查看发票、下载发票、发送邮箱：根据使用的群体，来设计系统需要支持哪些权限范围的功能，比如用户是可以下载发票的，但是考虑到数据风险，客服是不可以下载的等等

2. 接收层我们这里可以理解为一个发票中台台系统，用来存储所有申请开票的申请单。
从对接模型上说，这是一个接收层，当然从功能上来说，也可以在这个后台申请发票。
后台系统最基础的增删改查功能这里不多赘述，之前写的一篇已经写过了。
这里其实还想说一个更重要的点，是单据之间的关系以及单据的状态机。
下面用一个ER图可以看一下订单、发票、申请单映射关系

订单和申请单是1对N的，因为会存在部分退款后，用户需要对余额重新申请开票的场景，理论上用户申请开票只有金额限制，不应该有次数限制，只要可开票金额大于0且小于等于实付金额，就是可以开票的。
订单和发票的关系是1对N的，出现这种情况可能是因为一笔订单中包含不同的税目的商品，内部的额外需求，需要将这类发票拆开，或者是因为开票金额超过限额，会拆分开成几张票。目前限额最大值有1万、10万、100万，一般是由公司和税务局核定后，设置在系统里的。

文章插图
从创建申请单，到这笔申请单的状态流转为终态，这其中不同状态机下对应的是不同的操作功能映射。
如常见的几个状态机：『待审核』『审核中』『待开票』『开票中』『已开票』『已红冲』。（目前绝大多数电子票都是不需要审核直接开票的，纸质票大多数还是需要审核的）
不同状态下C端的展示逻辑、后台的功能都不同，举个例子用户提交开票信息后，不管申请单数据状态是审核中还是开票中，对用户而言都包装成『开票中』；
例如『待审核』状态下可以『审核驳回』或『审核通过』『已开票』状态下可以下载、查看发票，这都是要基于状态机的变化来的。

文章插图
3. 外部开票服务外部开票服务其实就是目前做的很成熟一些税控服务，如某税，发票中台通过对接这样的服务来实现开票、红冲等需求，主要工作量在于两边的接口对接。