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

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

當我?guī)е碌睦斫膺M行分享時，我的思路和方法論已悄然發(fā)生變化，這篇文章講一下發(fā)票系統(tǒng)0-1的閉環(huán)設計，希望能帶給你幫助~

一、什么是發(fā)票

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

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

此次文檔范圍主要是銷項發(fā)票~

二、發(fā)票系統(tǒng)對接模型

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

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

1. 申請層

申請層主要是指申請開具發(fā)票的數(shù)據(jù)源，如toC：用戶端，用戶可以自主開具發(fā)票。

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

2. 接收層

這里的接收層我把它叫做發(fā)票中臺，發(fā)票中臺負責對接所有所有在申請層的系統(tǒng)， 承接所有申請開票的數(shù)據(jù)，統(tǒng)一由發(fā)票中臺對接發(fā)票服務。

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

這樣設計的好處有兩點：

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

3. 服務層

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

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

三、對接層

1. 申請層

（1）C端

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

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

① 申請節(jié)點

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

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

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

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

② 申請類型

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

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

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

③ 申請信息

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

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

但是由系統(tǒng)自主可以通過訂單獲取到的。

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

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

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

（2）B端后臺

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

2. 接收層

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

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

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

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

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

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

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

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

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

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

3. 外部開票服務

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

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

四、其他

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

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

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

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

題圖來自Unsplash，基于CC0協(xié)議。