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

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

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

1. 发票数据的基本操作

1）开具发票

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

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

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

2）查询发票

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

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

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

3）查看发票

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

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

4）修改发票

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

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

2. 发票数据状态的管理流转

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

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

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

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

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

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

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

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

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

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

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

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

三、思考

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

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

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

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

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

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