导读：随着这些年来的发展，电子发票这个“新鲜事物”也褪去了新鲜感融入了我们的生活中，纵观整个电子发票的路径，顶层为政府的税务部门，中层为“51发票”,“发票通”等发票服务商，应用层则为各消费场景下的开票企业，本文主要讨论应用层的承上启下。

随着这些年来的发展，电子发票这个“新鲜事物”也褪去了新鲜感融入了我们的生活中，纵观整个电子发票的路径，顶层为政府的税务部门，中层为“51发票”,“发票通”等发票服务商，应用层则为各消费场景下的开票企业，本文主要讨论应用层的承上启下。

如果是新企业需要对接电子发票业务的话还需要前往税务部门完成，开票资质申请/电子签章申请/申请发票资质/等业务流程，完成后即可寻找发票服务平台进行合作由他们提供接口支持即可。

一、以订单为核心的系统架构

电子发票以订单为核心，属于独立模块，但是与系统各个模块紧密相连

• 用户端主要支持电子发票的申请与查看，管理端则支持对电子发票的全生命周期进行管理，在后文会进行详细的功能说明
• 订单系统主要为电子发票提供用户开票的具体信息，与订单状态，即开票的内容
• 商品信息用户配置用户开票的商品税率，以计算发票各项明细
• 消息中心则是为了在开具电子发票成功后进行通知用户

二、简单的开票流程

以上是一个简化后的开票流程，对于用户的交互点就三项，申请开票/填写信息/收到发票,但是对于系统的交互点远不止如此，简单的梳理下流程吧

申请发票前通用的前置条件都是需要用户在该交易行为完成后（滴滴到达目的地，电商确认收货，航司航班到达）并且未开具过对应消费的电子发票。

交易完成是指用户已无法对当前消费流程作出更改，即涉及到退改环节的状态应该在交易完成之前，可以定义为退改完成后即为交易完成。

在用户满足申请条件后即向订单系统查询,将用户该次消费的明细列出

• 开票维度：根据各自不同的业务形态，有着不同的开票维度店铺订单/平台订单/客票，建议以最小用户维度来进行开票，多店铺精确到店铺，多人则精确到人。
• 开票内容：发票内容可以规定一张订单开一张发票，或每一件商品可开具一张发票，建议以最大开票内容作为一张发票，可以减少系统交互及人员维护成本。

（总结：开票维度偏向更细，开票内容偏向更广）

在用户提交申请后即调用发票服务商提供的开票接口，提交发票内容及发票抬头信息。

• 订单系统给与具体的商品名称，数量，商品系统/财务系统给出对应商品的税率，该项组成发票内容，将会在票面上展示出明细。
• 发票抬头有，个人/企业/非企业，三种类型，对应不同的填写项目

（一张完成的发票就由发票内容及发票抬头组成）

发票开具成功后向用户推送消息通知与电子发票

• 消息通知可以按渠道分为短信消息通知，邮件消息通知，为了防止一个渠道接收失败的情况建议选择两个渠道同时发送
• 生成的电子发票为pdf文件保存在服务器中，推送时附带下载连接，方便用户下载保存

用户收到发票，发票的流程结束。

三、围绕发票生命周期的功能点

在上面分析了发票的架构与流程，接下来结合实际的业务场景，按照电子发票模块的功能点来逐个分析下，以下的功能点都是在我们的实际运营中面对复杂的业务场景与需求得出来的解决方案，具有一定的借鉴意义，最终你们发票系统的功能点还是需要结合你们自己的业务场景及需求来制定。

围绕着电子发票可以划分为前中后三个生命周期，分别代表着申请前 申请中，申请后，对应着不同的功能点，大部分都是当然还有写辅助性的功能我也会进行补充，接着开始正文吧。

1. 申请（核心功能）

说明：电子发票的申请作为整个发票的开端，涉及系统及应用都比较广泛

系统：申请前需要先检查用户是否满足申请状态（订单内容，订单状态）在上面的流程部分已详细说明

功能设计：在用户填写发票申请时注意各个填写项目的字段规范，长度/类型/不建议做太严格的校验，

功能设计：C端的申请界面可以设计抽屉效果将非必填项目进行收起处理,减少用户填写信息量。

2. 红冲（核心功能）

说明：当开具了错误的电子发票后可以使用红冲功能，再次开具一张相同内容的红字发票，作废原发票。可以理解为作废已开具的发票

功能设计：该功能一般放在B端系统中集成，

3. 换开（辅助功能）

说明：用户可以在C端将已经开具完成的电子发票申请进行作废并根据新填写的信息再次开具。

功能设计：该功能相当于红冲+再次开票的流程，实现效果是用户可以自主完成发票的维护流程，减少客服及运营人员压力

4. 撤销申请（解决异常问题）

说明：由于第三方或者我方服务原因，偶现发票开具失败的情况，用于处理异常使用，

功能设计：将该发票的状态更改为初始状态，主要解决在发票开具过程中的系统错误问题。

5. 业务发票（辅助功能）

说明：独立于正常开票流程之外的功能，能够独立开具电子发票，用于解决某些现有系统不满足的特殊场景，及用户需求，在某些订单不正确的情况下也可用于救火，相当于超级开票功能，但是其中涉及税率，商品等计算，该功能如果各位有需求的话看情况可以单独再讲下。

6. 发票备注模板（辅助功能）

说明：编辑发票右下角区域的信息，可以填写一些简单的备注信息，用户的消费类型，订单号码等，方便追溯

7. 常用发票信息（辅助功能）

说明：在C端用户填写完成发票申请后，将发票抬头信息进行保存，可以保存为三种类型，在用户切换抬头类型时，填入不同的信息。

本文主要讲述对于电子发票这一事物在应用层的，逻辑脉络，框架结构，细节的功能设计由于篇幅所限就不过多赘述了，所写内容也都是本人在负责发票这一项目来的感悟和教训，受限于个人的经验与能力，也还是有不足的地方，各位看官权当个借鉴即可。

保持独立思考，不卑不亢，长成自己想要的模样。

本文由 @沈万三 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议