编辑导读：好的产品经理要具备的必不可少的能力就是踏实的落地能力，从单纯的处理某个功能，到最后站在一个比较高的角度去看系统的整体设计，最后输出对系统的思考，这都是一种成长。本文作者结合发票的基本知识、发票系统的基本设计思路以及遇到的那些坑，详细地分析了系统设计，希望会给你带来帮助。

我认为，所有B端系统的设计都围绕着一个原则：以满足业务的需求为准，用系统减轻业务实际操作的负担，提升工作效率。

所以对于发票管理系统来说，其设计也都是围绕业务的实际操作来进行的。

发票系统主要是为了服务于税务同学，因而不可避免的也会涉及到一部分的税务知识，对刚上手的同学来说可能不是特别友好。

我专业是学计算机的，刚开始接触发票系统时，完全不清楚红票、蓝票，抬头、税额等这些发票里的门门道道，所以前期走了一些弯路，也花了时间去适应。

这次我通过结合发票的基本知识、发票系统的基本设计思路以及我在熟悉系统中遇到的坑来对系统设计进行分析，希望会给你带来帮助。

一、什么是发票

发票，过去称之为“发货票”，是表示钱已经收到，货已经发出的一个手续。

其实在晚清时期就有发票的雏形，当时买卖双方很希望有一种能证明交易过程的真实性的证据，商家销售货物所开具的一份“发货单”，也是买卖双方进行交易的商品清单，当时的这种凭证其实很类似于收据。

后来随着朝代的更替、结合交易场景发票被逐步优化，就有了现在的发票。

百度上写道：

发票是指一切单位和个人在购销商品、提供或接受服务以及从事其他经营活动中，所开具和收取的业务凭证，是会计核算的原始依据，也是审计机关、税务机关执法检查的重要依据。

收据才是收付款凭证，发票只能证明业务发生了，不能证明款项是否收付。

简而言之，发票就是发生的成本、费用或收入的原始凭证，正因为发票是唯一凭证，所以每张发票都会有一个特定的发票号码。

其实我们实际生活中涉及到发票的场景非常多：吃饭、住宿需要找店家开张发票，线上购物找商家开发票……

对于商家来说，发票主要是公司做账的依据，同时也是缴税的费用凭证。而对于消费者来说，发票主要是用来报销的。

生活中会出现一种场景，商家反馈本月度票用完了，承诺给消费者下个月开票。这是因为公司会定期从税务机关购买发票，如当月票已被用完的话，一般都会下月补开。

发票分为普通发票和增值税专用发票，增值税专用发票能用于抵扣，增值税普通发票只能做记账凭证。

目前专票只支持纸质发票，而普通发票电子、纸质票都支持。

知道了发票类型、形式还不够，还需要知道一张真正的发票长什么样子，有哪些字段。

附一张滴滴的发票：

我们可以看到，一张发票中会包含发票抬头、发票税率、发票号码、开票公司等信息。

二、设计发票系统需要考虑的三个维度

1. 发票数据的基本操作

1）开具发票

需要输入哪些发票信息，提交信息后如何开票。

对于抬头信息、电子邮箱或者邮寄地址是需要用户来录入的，像税率、纳税人识别号、开票人信息等都是公司自己配置好的，自动带入即可。

当信息填写完成后，大部分中小型公司都是会通过调用第三方系统进行开票。当开票成功后，就如上文所说，生成一个特定的发票号码。

2）查询发票

查询条件有哪些，支持哪些数据的展示。

要明确的是，查询项的主要目的是用于定位数据。

除了最基础的一些查询项，如发票申请时间、开票成功的时间，还要根据业务日常的操作诉求进行设计，比如是否需要根据提交人进行查询、是否需要通过交易订单号查询等。

3）查看发票

除了发票本身信息以外，还支持查看哪些信息。

查看发票详情里的字段一般是包含了查询项以及提交项的内容，除此之外集合实际业务场景考虑是否增设其他信息，还如自动带入的配置信息、订单信息、商品信息等。

4）修改发票

发票中哪些信息支持修改，修改的功能主要会涉及到安全问题。所以这里要考虑功能的权限配置，同时还要给出修改规则，即哪些字段可以修改，哪些不能。

如用户自己提交的信息基本都是可以修改的，而像系统自动带出的字段都是不允许修改的。

2. 发票数据状态的流转

“用户提交一条数据—发票系统生成一条数据—提交三方系统开票–返回开票结果”，这是一张发票在系统的正向流转过程。

简单来说就是未开始—进行中—已完成/失败，我们可以发现，这里其实有涉及到数据的状态变更，同时还用考虑在对应不同的状态下，会有不同相关联的操作。

比如说对于已成功开具的发票，我们可以对此进行红冲。

红冲后，我们就会得到一张“红票”，未红冲的开成功的票即“蓝票”（虽然“红票”是基于对“蓝票”进行红冲后生成的，但实际上这属于两张发票，有各自不同的发票号码。）

再比如，开票失败以后我们可以再次开票等等。

3. 与不同系统之间的关联

我们上文说过，发票是发生的成本、费用或收入的原始凭证，是有一个前置动作的。

所以对于发票系统来说，他不会是一个完全独立的系统，要从订单系统、退费系统、商品系统中获取信息，从而对发票信息进行判断。

如在开发票时，发票系统需要去订单系统抓取订单状态进行判断，当订单状态为“已付款”或“已收货”（具体状态因业务场景而定）时才能发起。

像京东这样的电商平台，会自动抓取订单“已签收”状态进行自动开电子票。

同时发票系统也要去判断当前订单是否重复开票，同理，当订单状态为“已退费”时，发票系统也需要对之前开过的票进行红冲。

所以熟悉发票系统的前提下，也要求对其他系统有一定熟悉。

三、思考

不管从功能支持来说，还是从界面设计来说，不同业务下不同公司的发票系统设计的肯定不一样。

但是本质还是围绕发票本身的性质结合业务诉求进行设计，这篇文章主要提供一种设计思路。

上文的这些内容其实都是一些很基础、但是一不注意就会被忽视的思考点。

其实在我看来，一个好的产品经理需具备的必不可少的能力就是踏实的落地能力。

从知道这个事怎么做，到最后把这件事做好，这其中如果不细细思考，得出的结论也大多是些泛泛之空谈。

从单纯的处理某个功能，到最后站在一个比较高的角度去看系统的整体设计，最后输出你对系统的思考，试着输出你认为还需要优化的点，这都是你的一种成长。

作者：闫秀儿；公众号：闫秀儿

本文由 @闫秀儿 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pixabay，基于 CC0 协议