編輯導語：發票是财務中必不可少的物品，那發票系統該如何設計呢？本篇文章中，作者從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協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部