編輯導語：發票是財務中必不可少的物品，那發票系統該如何設計呢？本篇文章中，作者從B端和C端兩個層面，介紹了如何從0到1的設計發票系統。感興趣的小伙伴不妨來看看。

之前也寫過發票的設計思路，時隔一段時間重新做了發票的項目，對這部分又有了新的認知和思考，更是發覺之前寫的甚淺。

當我帶著新的理解進行分享時，我的思路和方法論已悄然發生變化，這篇文章講一下發票系統0-1的閉環設計，希望能帶給你幫助~

一、什么是發票

發票是指一切單位和個人在購銷商品、提供或接受服務以及從事其他經營活動中，所開具和收取的業務憑證，是會計核算的原始依據，也是審計機關、稅務機關執法檢查的重要依據。

發票分為進項發票和銷項發票，簡單說可以理解為作為一個商家，進項發票就是供應商給我們開的票，銷項發票是我們給購買了商品的客戶開的票

此次文檔范圍主要是銷項發票~

二、發票系統對接模型

在之前的文章中也提到，B端系統設計之初，需要對系統進行分層，明確系統邊界。

這樣做的好處是避免后期業務繁雜時各個系統之間功能冗余，邏輯耦合，從而不方便業務拓展。

1. 申請層

申請層主要是指申請開具發票的數據源，如toC：用戶端，用戶可以自主開具發票。

或者toB 在后臺，由客服或者運營為用戶申請開票，當發票開具完成后再將發票信息展示出來。

2. 接收層

這里的接收層我把它叫做發票中臺，發票中臺負責對接所有所有在申請層的系統， 承接所有申請開票的數據，統一由發票中臺對接發票服務。

當發票開具完成后再將發票信息傳給申請層的系統，有點承上啟下的意思。

這樣設計的好處有兩點：

1. 對于上游申請層來說，不需要單獨對接一次外部的發票服務，對接發票中臺遠比對接外部的發票服務成本低；
2. 對于發票中臺來說，所有申請的數據都天然維護在這里，方便做前期的校驗、后續統計等功能。

3. 服務層

這里的服務層是指外部的開票服務，發票中臺將所需要的開票信息透傳給開票服務。

由開票服務完成開票、紅沖等操作，再將結果返回給發票中臺。

三、對接層

1. 申請層

（1）C端

申請層主要的功能就是「申請開票」。

那么對于C端來說，它面向的對象就是用戶，那么在C端的設計上就要站在用戶的角度，這里簡單列下主要功能點：

① 申請節點

前文我們說過，發票是指一切單位和個人在購銷商品、提供或接受服務以及從事其他經營活動中，所開具和收取的業務憑證。

那么開票的前提是有了交易記錄，開票可以根據流水開，也可以根據訂單開，下面就按照普遍電商平臺的做法，按照訂單來說明。

申請開票的節點其實沒有明確的要求，目前業內有的是支付后可以申請，有的是還是收貨后才可以申請，區別主要是擔心產生售后行為后，發票還需要紅沖掉，浪費額外的票量。

但像京東現在已經很智能化了，每次支付完會自動開票。

② 申請類型

對于大多數市面的產品來說，一般在C端只允許用戶開電子票，原因很簡單，電子票和紙質票的法律效應是一致的。

但是電子票比紙質票成本低、效率高，開票所需要的信息也比紙質票簡單許多。

當然如果用戶有指定開專票或者紙質的普票的話，作為商家還是有義務為用戶開票的，對于這種情況可以走線下聯系客服等方式在后臺申請開票。

③ 申請信息

不同類型的票需要的信息是不一樣的，同樣紙票和普票所需要的信息也不相同；

這里其實分為幾部分，用戶的個人申請信息和發票信息，其中個人申請信息是用戶自己需要提供的信息，發票信息都是開發票需要。

但是由系統自主可以通過訂單獲取到的。

下圖我簡單列了下基本信息，有的字段對于不同的發票類型、發票種類都有不一樣的輸入要求。

• 查看開票進度：用戶申請開票后，發票的狀態要講對應展示文案告知用戶開票進度，給用戶有一個預期

• 查看發票、下載發票、發送郵箱：開票后用戶可以下載發票或者選擇將發票發送到指定郵箱

（2）B端后臺

• 申請節點：同用戶端，前后臺保持一致
• 申請類型：在后臺申請的話，那么他可申請的范圍包括普票、專票、包括電子票和紙質票。
• 查看開票進度：后臺也需要展示開票進度，這樣用戶咨詢客服或者運營時，內部人員也可以給出反饋
• 查看發票、下載發票、發送郵箱：根據使用的群體，來設計系統需要支持哪些權限范圍的功能，比如用戶是可以下載發票的，但是考慮到數據風險，客服是不可以下載的等等

2. 接收層

我們這里可以理解為一個發票中臺臺系統，用來存儲所有申請開票的申請單。

從對接模型上說，這是一個接收層，當然從功能上來說，也可以在這個后臺申請發票。

后臺系統最基礎的增刪改查功能這里不多贅述，之前寫的一篇已經寫過了。

這里其實還想說一個更重要的點，是單據之間的關系以及單據的狀態機。

下面用一個ER圖可以看一下訂單、發票、申請單映射關系

1. 訂單和申請單是1對N的，因為會存在部分退款后，用戶需要對余額重新申請開票的場景，理論上用戶申請開票只有金額限制，不應該有次數限制，只要可開票金額大于0且小于等于實付金額，就是可以開票的。
2. 訂單和發票的關系是1對N的，出現這種情況可能是因為一筆訂單中包含不同的稅目的商品，內部的額外需求，需要將這類發票拆開，或者是因為開票金額超過限額，會拆分開成幾張票。目前限額最大值有1萬、10萬、100萬，一般是由公司和稅務局核定后，設置在系統里的。

從創建申請單，到這筆申請單的狀態流轉為終態，這其中不同狀態機下對應的是不同的操作功能映射。

如常見的幾個狀態機：『待審核』『審核中』『待開票』『開票中』『已開票』『已紅沖』。（目前絕大多數電子票都是不需要審核直接開票的，紙質票大多數還是需要審核的）

不同狀態下C端的展示邏輯、后臺的功能都不同，舉個例子用戶提交開票信息后，不管申請單數據狀態是審核中還是開票中，對用戶而言都包裝成『開票中』；

例如『待審核』狀態下可以『審核駁回』或『審核通過』『已開票』狀態下可以下載、查看發票，這都是要基于狀態機的變化來的。

3. 外部開票服務

外部開票服務其實就是目前做的很成熟一些稅控服務，如某稅，發票中臺通過對接這樣的服務來實現開票、紅沖等需求，主要工作量在于兩邊的接口對接。

藍票如上所述一般是用戶/客服/運營主動申請的，但是紅票最好是可以系統自動判斷訂單的狀態，進行紅沖。

四、其他

一般比較完善的發票中臺，會將票倉管理、主體管理、稅目信息管理、票額管理等信息都在線上維護起來。

線上化程度越高，對于業務來說效率就越高，但這個并不影響開票的主流程。

各家公司會根據自己的量級來評估線上化的程度，按自身業務實際情況選擇。

本文由 @閆秀兒 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。