【发票进阶】发票系统0-1闭环设计思路
之前也写过发票的设计思路，时隔一段时间重新做了发票的项目，对这部分又有了新的认知和思考，更是发觉之前写的甚浅。
当我带着新的理解进行分享时，我的思路和方法论已悄然发生变化，这篇文章讲一下发票系统0-1的闭环设计，希望能带给你帮助~
一、什么是发票
发票是指一切单位和个人在购销商品、提供或接受服务以及从事其他经营活动中，所开具和收取的业务凭证，是会计核算的原始依据，也是审计机关、税务机关执法检查的重要依据。
发票分为进项发票和销项发票，简单说可以理解为作为一个商家，进项发票就是供应商给我们开的票，销项发票是我们给购买了商品的客户开的票
此次文档范围主要是销项发票~
二、发票系统对接模型
在之前的文章中也提到，B端系统设计之初，需要对系统进行分层，明确系统边界。
这样做的好处是避免后期业务繁杂时各个系统之间功能冗余，逻辑耦合，从而不方便业务拓展。
1. 申请层
申请层主要是指申请开具发票的数据源，如toC：用户端，用户可以自主开具发票。
或者toB 在后台，由客服或者运营为用户申请开票，当发票开具完成后再将发票信息展示出来。
2. 接收层
这里的接收层我把它叫做发票中台，发票中台负责对接所有所有在申请层的系统， 承接所有申请开票的数据，统一由发票中台对接发票服务。
当发票开具完成后再将发票信息传给申请层的系统，有点承上启下的意思。
这样设计的好处有两点：
- 对于上游申请层来说，不需要单独对接一次外部的发票服务，对接发票中台远比对接外部的发票服务成本低；
- 对于发票中台来说，所有申请的数据都天然维护在这里，方便做前期的校验、后续统计等功能。
3. 服务层
这里的服务层是指外部的开票服务，发票中台将所需要的开票信息透传给开票服务。
由开票服务完成开票、红冲等操作，再将结果返回给发票中台。
三、对接层
1. 申请层
（1）C端
申请层主要的功能就是「申请开票」。
那么对于C端来说，它面向的对象就是用户，那么在C端的设计上就要站在用户的角度，这里简单列下主要功能点：
① 申请节点
前文我们说过，发票是指一切单位和个人在购销商品、提供或接受服务以及从事其他经营活动中，所开具和收取的业务凭证。
那么开票的前提是有了交易记录，开票可以根据流水开，也可以根据订单开，下面就按照普遍电商平台的做法，按照订单来说明。
申请开票的节点其实没有明确的要求，目前业内有的是支付后可以申请，有的是还是收货后才可以申请，区别主要是担心产生售后行为后，发票还需要红冲掉，浪费额外的票量。
但像京东现在已经很智能化了，每次支付完会自动开票。
② 申请类型
对于大多数市面的产品来说，一般在C端只允许用户开电子票，原因很简单，电子票和纸质票的法律效应是一致的。
但是电子票比纸质票成本低、效率高，开票所需要的信息也比纸质票简单许多。
当然如果用户有指定开专票或者纸质的普票的话，作为商家还是有义务为用户开票的，对于这种情况可以走线下联系客服等方式在后台申请开票。
③ 申请信息
不同类型的票需要的信息是不一样的，同样纸票和普票所需要的信息也不相同；
这里其实分为几部分，用户的个人申请信息和发票信息，其中个人申请信息是用户自己需要提供的信息，发票信息都是开发票需要。
但是由系统自主可以通过订单获取到的。
下图我简单列了下基本信息，有的字段对于不同的发票类型、发票种类都有不一样的输入要求。
- 查看开票进度：用户申请开票后，发票的状态要讲对应展示文案告知用户开票进度，给用户有一个预期
- 查看发票、下载发票、发送邮箱：开票后用户可以下载发票或者选择将发票发送到指定邮箱
（2）B端后台
- 申请节点：同用户端，前后台保持一致
- 申请类型：在后台申请的话，那么他可申请的范围包括普票、专票、包括电子票和纸质票。
- 查看开票进度：后台也需要展示开票进度，这样用户咨询客服或者运营时，内部人员也可以给出反馈
- 查看发票、下载发票、发送邮箱：根据使用的群体，来设计系统需要支持哪些权限范围的功能，比如用户是可以下载发票的，但是考虑到数据风险，客服是不可以下载的等等
2. 接收层
我们这里可以理解为一个发票中台台系统，用来存储所有申请开票的申请单。
从对接模型上说，这是一个接收层，当然从功能上来说，也可以在这个后台申请发票。
后台系统最基础的增删改查功能这里不多赘述，之前写的一篇已经写过了。
这里其实还想说一个更重要的点，是单据之间的关系以及单据的状态机。
下面用一个ER图可以看一下订单、发票、申请单映射关系
- 订单和申请单是1对N的，因为会存在部分退款后，用户需要对余额重新申请开票的场景，理论上用户申请开票只有金额限制，不应该有次数限制，只要可开票金额大于0且小于等于实付金额，就是可以开票的。
- 订单和发票的关系是1对N的，出现这种情况可能是因为一笔订单中包含不同的税目的商品，内部的额外需求，需要将这类发票拆开，或者是因为开票金额超过限额，会拆分开成几张票。目前限额最大值有1万、10万、100万，一般是由公司和税务局核定后，设置在系统里的。
从创建申请单，到这笔申请单的状态流转为终态，这其中不同状态机下对应的是不同的操作功能映射。
如常见的几个状态机：『待审核』『审核中』『待开票』『开票中』『已开票』『已红冲』。（目前绝大多数电子票都是不需要审核直接开票的，纸质票大多数还是需要审核的）
不同状态下C端的展示逻辑、后台的功能都不同，举个例子用户提交开票信息后，不管申请单数据状态是审核中还是开票中，对用户而言都包装成『开票中』；
例如『待审核』状态下可以『审核驳回』或『审核通过』『已开票』状态下可以下载、查看发票，这都是要基于状态机的变化来的。
3. 外部开票服务
外部开票服务其实就是目前做的很成熟一些税控服务，如某税，发票中台通过对接这样的服务来实现开票、红冲等需求，主要工作量在于两边的接口对接。
蓝票如上所述一般是用户/客服/运营主动申请的，但是红票最好是可以系统自动判断订单的状态，进行红冲。
四、其他
一般比较完善的发票中台，会将票仓管理、主体管理、税目信息管理、票额管理等信息都在线上维护起来。
线上化程度越高，对于业务来说效率就越高，但这个并不影响开票的主流程。
各家公司会根据自己的量级来评估线上化的程度，按自身业务实际情况选择。
本文作者 @闫秀儿 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
