很多場景下，都需要開發票。日常的我們所接觸都是作為需求方，那作為發票平臺方，我們如何實現對用戶的開票和發票提供呢？本文將會帶您了解“發票系統”，一起看看吧！

很多場景下，我們會要求對方開發票，住酒店時，購買某種服務或者商品時，用于后續的報稅或者報銷。

這是我們作為發票需求方，而如果我們作為平臺方，如何實現對用戶的開票和發票提供呢？比如你是一家外賣公司，要給平臺商家提供某項費用的增值稅發票。

一、先認清要開的“票”

廣義上去看，“票”的種類很多，不止是增值稅專票或者普票，我們可以將一種“憑證”都可以認為是一種“票”，比如電子回單、消費小票等等。

他們實現的底層邏輯和方法是類似，可以共用一個抽象模型。

在要實現自主開票之前，我們要先確定這是一個什么“票”。

這張票的樣子，也就是板式，票上需要展示的數據，這些數據來自哪里，是業務系統里還是從用戶那采集得到。

如下圖這張增值稅普通發票，其中的納稅人識別號就需要從用戶那里采集得到，在開通獲得發票以后，又可以得到發票代碼等數據。

因此，先分析你要實現的發票版式和數據參數，以及數據獲取方式。

二、把握發票系統的框架

要實現一個開票系統，怎么做，要先“心中有框架”。

先把大的邏輯和結構搞清楚，再去分塊去實現，從宏觀到微觀的過程，如下圖框架。

首先就是“數據準備”。

要明確開的各個票種的源數據是什么，從哪里獲取，是賬務數據、賬單數據、還是稅單數據。

并且，該票種所需要的開票數據也不一定從一個地方就能完全獲得，可能是一個字段來自一個地方，比如稅號來自用戶中心，從客戶端采集的，而開票金額字段從賬務中心獲得。

因此，源數據是要“拼出來”。

然后就是開票的模式、發票的模版等基礎配置，不同的開票模式流程不同，例如你要開“消費小票”那么就不需要發票服務商，完全可以自主閉環開出來，而要開正規的增值稅發票，就需要依賴外部服務商。

所以，發票模式跟支付模式類似，對私和對公有區別，快捷支付和網關支付也有區別。

接下來就是開票主流程，所有票種的開具都可以通過這個流程實現，三大步：開票規則解析、開票數據封裝、提交開票申請。

其中提交開票申請，類似提交支付申請，可能不同國家、不同票種要提交給不同的發票服務商。

三、數據、狀態、能力、歷史

發票系統要重點想明白和管理好4個核心。

發票的數據，就是最原始的發票單據，可能每個商家每個結算周期一條數據，這條數據記錄了開什么票、開票金額是多少、商家的稅號等信息。

開票的狀態，每條數據的開票狀態是什么，是待開、開票中、沖銷了、還是已開票。

開票的能力，不同的票種或者接的不同服務商所需要的開票能力不同，首次開票、沖銷能力、重開能力、下載發票能力、開票調整能力，這些能力的接入和實現依賴實際的需求。

最后就是開票歷史，每一章開好的票以某種形式存儲在數據庫中，方便用戶或者后臺管理人員查看，pdf形式、xml形式或者是圖片形式。

四、選服務商、接所需能力

如果某票種需要接入發票服務商，那么就需選擇一個適合自己的服務商，不同國家、不同票種可能適合的服務商不同。

但是，無論什么服務商，其服務接入邏輯是類似的，提供的能力也是類似的。

這一點跟接入支付渠道商差不多。

無論是接入哪家開票服務商，其實現的邏輯都如下圖類似，下圖以Gosocket為例，而且這家服務商是全球性質的，比如你接入了墨西哥這個國家，那么在另一個國家也有可能不需要重復接入，只需要修改幾個傳參、語種即可。

整個邏輯流程圖里要搞清楚這幾個主要問題。

開票的能力，圖中包含了“申請開票”“下載發票”“沖銷發票”三個主要能力。

然后就是通過開票結果對發票源數據的“開票狀態”的更新，開票成功則更新為已開票、開票失敗則保持“待開票”的狀態，沖銷成功以后將“已開票”狀態更新為“待開票”。

針對不同的開票狀態，可以進行不同的操作，例如自動開票、沖銷發票、手動開票等。

然后就是下載獲得了發票以后，將發票進行存儲，提供給后臺和用戶查看和下載，或者郵件自動發送給用戶。

比如我們在滴滴App內選擇“開票”，勾選對應訂單以后申請開票，就需要填寫一個收票“郵箱”。

該郵箱，就會存儲到發票系統的“用戶郵箱”中，用于向用戶主動發送電子發票。

五、想好怎么給用戶

好了，通過上面的努力，我們終于可以實現自動開票了。

最后一步就是想明白你要如何將發票提供給需要的用戶。

比較常見的就是發送用戶指定的郵箱。

同樣，對于商家來說也可以在其后臺提供發票自主下載的能力。

以上就是如何實現一個發票管理系統的方法論。