一张图，搞懂“发票系统”

很多场景下，我们会要求对方开发票，住酒店时，购买某种服务或者商品时，用于后续的报税或者报销。

这是我们作为发票需求方，而如果我们作为平台方，如何实现对用户的开票和发票提供呢？比如你是一家外卖公司，要给平台商家提供某项费用的增值税发票。

一、先认清要开的“票”

广义上去看，“票”的种类很多，不止是增值税专票或者普票，我们可以将一种“凭证”都可以认为是一种“票”，比如电子回单、消费小票等等。

他们实现的底层逻辑和方法是类似，可以共用一个抽象模型。

在要实现自主开票之前，我们要先确定这是一个什么“票”。

这张票的样子，也就是板式，票上需要展示的数据，这些数据来自哪里，是业务系统里还是从用户那采集得到。

如下图这张增值税普通发票，其中的纳税人识别号就需要从用户那里采集得到，在开通获得发票以后，又可以得到发票代码等数据。

因此，先分析你要实现的发票版式和数据参数，以及数据获取方式。

二、把握发票系统的框架

要实现一个开票系统，怎么做，要先“心中有框架”。

先把大的逻辑和结构搞清楚，再去分块去实现，从宏观到微观的过程，如下图框架。

首先就是“数据准备”。

要明确开的各个票种的源数据是什么，从哪里获取，是账务数据、账单数据、还是税单数据。

并且，该票种所需要的开票数据也不一定从一个地方就能完全获得，可能是一个字段来自一个地方，比如税号来自用户中心，从客户端采集的，而开票金额字段从账务中心获得。

因此，源数据是要“拼出来”。

然后就是开票的模式、发票的模版等基础配置，不同的开票模式流程不同，例如你要开“消费小票”那么就不需要发票服务商，完全可以自主闭环开出来，而要开正规的增值税发票，就需要依赖外部服务商。

所以，发票模式跟支付模式类似，对私和对公有区别，快捷支付和网关支付也有区别。

接下来就是开票主流程，所有票种的开具都可以通过这个流程实现，三大步：开票规则解析、开票数据封装、提交开票申请。

其中提交开票申请，类似提交支付申请，可能不同国家、不同票种要提交给不同的发票服务商。

三、数据、状态、能力、历史

发票系统要重点想明白和管理好4个核心。

发票的数据，就是最原始的发票单据，可能每个商家每个结算周期一条数据，这条数据记录了开什么票、开票金额是多少、商家的税号等信息。

开票的状态，每条数据的开票状态是什么，是待开、开票中、冲销了、还是已开票。

开票的能力，不同的票种或者接的不同服务商所需要的开票能力不同，首次开票、冲销能力、重开能力、下载发票能力、开票调整能力，这些能力的接入和实现依赖实际的需求。

最后就是开票历史，每一章开好的票以某种形式存储在数据库中，方便用户或者后台管理人员查看，pdf形式、xml形式或者是图片形式。

四、选服务商、接所需能力

如果某票种需要接入发票服务商，那么就需选择一个适合自己的服务商，不同国家、不同票种可能适合的服务商不同。

但是，无论什么服务商，其服务接入逻辑是类似的，提供的能力也是类似的。

这一点跟接入支付渠道商差不多。

无论是接入哪家开票服务商，其实现的逻辑都如下图类似，下图以Gosocket为例，而且这家服务商是全球性质的，比如你接入了墨西哥这个国家，那么在另一个国家也有可能不需要重复接入，只需要修改几个传参、语种即可。

整个逻辑流程图里要搞清楚这几个主要问题。

开票的能力，图中包含了“申请开票”“下载发票”“冲销发票”三个主要能力。

然后就是通过开票结果对发票源数据的“开票状态”的更新，开票成功则更新为已开票、开票失败则保持“待开票”的状态，冲销成功以后将“已开票”状态更新为“待开票”。

针对不同的开票状态，可以进行不同的操作，例如自动开票、冲销发票、手动开票等。

然后就是下载获得了发票以后，将发票进行存储，提供给后台和用户查看和下载，或者邮件自动发送给用户。

比如我们在滴滴App内选择“开票”，勾选对应订单以后申请开票，就需要填写一个收票“邮箱”。

该邮箱，就会存储到发票系统的“用户邮箱”中，用于向用户主动发送电子发票。

五、想好怎么给用户

好了，通过上面的努力，我们终于可以实现自动开票了。

最后一步就是想明白你要如何将发票提供给需要的用户。

比较常见的就是发送用户指定的邮箱。

同样，对于商家来说也可以在其后台提供发票自主下载的能力。

以上就是如何实现一个发票管理系统的方法论。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！