起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識【發票進階】發票系統0-1閉環設計思路
編輯導語：發票是財務中必不可少的物品，那發票系統該如何設計呢？本篇文章中，作者從B端和C端兩個層面，介紹了如何從0到1的設計發票系統。感興趣的小伙伴不妨來看看。
之前也寫過發票的設計思路，時隔一段時間重新做了發票的項目，對這部分又有了新的認知和思考，更是發覺之前寫的甚淺。
當我帶著新的理解進行分享時，我的思路和方法論已悄然發生變化，這篇文章講一下發票系統0-1的閉環設計，希望能帶給你幫助~
一、什么是發票
發票是指一切單位和個人在購銷商品、提供或接受服務以及從事其他經營活動中，所開具和收取的業務憑證，是會計核算的原始依據，也是審計機關、稅務機關執法檢查的重要依據。
發票分為進項發票和銷項發票，簡單說可以理解為作為一個商家，進項發票就是供應商給我們開的票，銷項發票是我們給購買了商品的客戶開的票
此次文檔范圍主要是銷項發票~
二、發票系統對接模型
在之前的文章中也提到，B端系統設計之初，需要對系統進行分層，明確系統邊界。
這樣做的好處是避免后期業務繁雜時各個系統之間功能冗余，邏輯耦合，從而不方便業務拓展。
1. 申請層
申請層主要是指申請開具發票的數據源，如toC：用戶端，用戶可以自主開具發票。
或者toB 在后臺，由客服或者運營為用戶申請開票，當發票開具完成后再將發票信息展示出來。
2. 接收層
這里的接收層我把它叫做發票中臺，發票中臺負責對接所有所有在申請層的系統， 承接所有申請開票的數據，統一由發票中臺對接發票服務。
當發票開具完成后再將發票信息傳給申請層的系統，有點承上啟下的意思。
這樣設計的好處有兩點：
- 對于上游申請層來說，不需要單獨對接一次外部的發票服務，對接發票中臺遠比對接外部的發票服務成本低；
- 對于發票中臺來說，所有申請的數據都天然維護在這里，方便做前期的校驗、后續統計等功能。
3. 服務層
這里的服務層是指外部的開票服務，發票中臺將所需要的開票信息透傳給開票服務。
由開票服務完成開票、紅沖等操作，再將結果返回給發票中臺。
三、對接層
1. 申請層
（1）C端
申請層主要的功能就是「申請開票」。
那么對于C端來說，它面向的對象就是用戶，那么在C端的設計上就要站在用戶的角度，這里簡單列下主要功能點：
① 申請節點
前文我們說過，發票是指一切單位和個人在購銷商品、提供或接受服務以及從事其他經營活動中，所開具和收取的業務憑證。
那么開票的前提是有了交易記錄，開票可以根據流水開，也可以根據訂單開，下面就按照普遍電商平臺的做法，按照訂單來說明。
申請開票的節點其實沒有明確的要求，目前業內有的是支付后可以申請，有的是還是收貨后才可以申請，區別主要是擔心產生售后行為后，發票還需要紅沖掉，浪費額外的票量。
但像京東現在已經很智能化了，每次支付完會自動開票。
② 申請類型
對于大多數市面的產品來說，一般在C端只允許用戶開電子票，原因很簡單，電子票和紙質票的法律效應是一致的。
但是電子票比紙質票成本低、效率高，開票所需要的信息也比紙質票簡單許多。
當然如果用戶有指定開專票或者紙質的普票的話，作為商家還是有義務為用戶開票的，對于這種情況可以走線下聯系客服等方式在后臺申請開票。
③ 申請信息
不同類型的票需要的信息是不一樣的，同樣紙票和普票所需要的信息也不相同；
這里其實分為幾部分，用戶的個人申請信息和發票信息，其中個人申請信息是用戶自己需要提供的信息，發票信息都是開發票需要。
但是由系統自主可以通過訂單獲取到的。
下圖我簡單列了下基本信息，有的字段對于不同的發票類型、發票種類都有不一樣的輸入要求。
- 查看開票進度：用戶申請開票后，發票的狀態要講對應展示文案告知用戶開票進度，給用戶有一個預期
- 查看發票、下載發票、發送郵箱：開票后用戶可以下載發票或者選擇將發票發送到指定郵箱
（2）B端后臺
- 申請節點：同用戶端，前后臺保持一致
- 申請類型：在后臺申請的話，那么他可申請的范圍包括普票、專票、包括電子票和紙質票。
- 查看開票進度：后臺也需要展示開票進度，這樣用戶咨詢客服或者運營時，內部人員也可以給出反饋
- 查看發票、下載發票、發送郵箱：根據使用的群體，來設計系統需要支持哪些權限范圍的功能，比如用戶是可以下載發票的，但是考慮到數據風險，客服是不可以下載的等等
2. 接收層
我們這里可以理解為一個發票中臺臺系統，用來存儲所有申請開票的申請單。
從對接模型上說，這是一個接收層，當然從功能上來說，也可以在這個后臺申請發票。
后臺系統最基礎的增刪改查功能這里不多贅述，之前寫的一篇已經寫過了。
這里其實還想說一個更重要的點，是單據之間的關系以及單據的狀態機。
下面用一個ER圖可以看一下訂單、發票、申請單映射關系
- 訂單和申請單是1對N的，因為會存在部分退款后，用戶需要對余額重新申請開票的場景，理論上用戶申請開票只有金額限制，不應該有次數限制，只要可開票金額大于0且小于等于實付金額，就是可以開票的。
- 訂單和發票的關系是1對N的，出現這種情況可能是因為一筆訂單中包含不同的稅目的商品，內部的額外需求，需要將這類發票拆開，或者是因為開票金額超過限額，會拆分開成幾張票。目前限額最大值有1萬、10萬、100萬，一般是由公司和稅務局核定后，設置在系統里的。
從創建申請單，到這筆申請單的狀態流轉為終態，這其中不同狀態機下對應的是不同的操作功能映射。
如常見的幾個狀態機：『待審核』『審核中』『待開票』『開票中』『已開票』『已紅沖』。（目前絕大多數電子票都是不需要審核直接開票的，紙質票大多數還是需要審核的）
不同狀態下C端的展示邏輯、后臺的功能都不同，舉個例子用戶提交開票信息后，不管申請單數據狀態是審核中還是開票中，對用戶而言都包裝成『開票中』；
例如『待審核』狀態下可以『審核駁回』或『審核通過』『已開票』狀態下可以下載、查看發票，這都是要基于狀態機的變化來的。
3. 外部開票服務
外部開票服務其實就是目前做的很成熟一些稅控服務，如某稅，發票中臺通過對接這樣的服務來實現開票、紅沖等需求，主要工作量在于兩邊的接口對接。
藍票如上所述一般是用戶/客服/運營主動申請的，但是紅票最好是可以系統自動判斷訂單的狀態，進行紅沖。
四、其他
一般比較完善的發票中臺，會將票倉管理、主體管理、稅目信息管理、票額管理等信息都在線上維護起來。
線上化程度越高，對于業務來說效率就越高，但這個并不影響開票的主流程。
各家公司會根據自己的量級來評估線上化的程度，按自身業務實際情況選擇。
本文由 @閆秀兒 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
專欄作家
閆秀兒，微信公眾號：閆秀兒，人人都是產品經理專欄作家。持續沉淀、持續成長的交易產品。
本文原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
大佬如何處理，在b端場景下，用戶應開而未開發票的問題
你這個不合規吧，按國稅局對財務的要求，所有的現金交易都必需開票，不管用戶有無申請。有些電商是用戶未申請但內部是有開出，只是沒有給用戶顯示出票據而已
會有多個訂單對應1張發票的情況嗎？如果開在一張票上，后面全退了一個訂單1，再開票會不會有訂單1和發票詳情對不上吧？
訂單與發票存在1:N的場景，文中所描述的模型有缺失，訂單可能會被拆成不同的商品(即貨物)類型，商品與發票有對應的關系，不同平臺的建設是不一樣的。若不同商品開在不同的發票上，或者不同的商品運營主體不同，例如美團外賣，快遞費是美團平臺運營的、餐費是商家運營的，按照誰收費誰開票(真正的資金流向)的原則，必然是在不同的發票上。
1、開票時需要記錄訂單與商品的關系、還需要記錄商品與發票的關系，否則會出現基于某張發票沖紅找不到對應的訂單，也不知道需要沖減訂單的哪一部分。
2、實際運營中存在另一種訂單部分開票場景，例1中，用戶實付金額5W元，但是用戶只想開具5W元的3W元；
3.合并訂單開票，高頻低額的訂單，需要將所有訂單合并開具。
訂單實際與發票是多對多的關系，但訂單與發票不應該是直接關系上的。
目前互聯網產品淘寶、京東、美團外賣基本是基于單訂單開具；美團零售(自營)、餓了么餐飲和零售、滴滴出行是基于多訂單合并開票的
商品關聯訂單，訂單關聯發票申請單，發票申請單關聯發票，發票自然就記錄的關聯的商品。
大佬，咨詢個問題，我們做的是電商的產品，在商品中心上架的商品，與進貨的商品如何做關聯，進貨商品的發票屬性/規格/數量這些信息維護在哪塊是進銷存系統嗎還是商品系統
我也想知道
其實都可以，采購時其實對商品的屬性已知，該批次比如商品的稅率、貨物品名、規格都是已知的。商品發布時，商品詳情中也有對應的信息。不過開票是基于合同(訂單、合同、賬單)維度開具，而訂單的商品詳情必然有相關屬性，維護在商品側更好。
你好，想請問一下：
“對于上游申請層來說，不需要單獨對接一次外部的發票服務，對接發票中臺遠比對接外部的發票服務成本低；”
有個疑問：我自己的理解，對于上游申請層來說，即使對接了發票中臺，發票中臺最終也是要對接外部底層發票服務商的，那么上游申請層對接發票中臺的優勢為什么是比直接對接外部底層發票服務商更低呢？
哦哦，突然理解了，因為會涉及到多個上游申請層對接，而發票中臺只需要對接一次外部底層發票服務商，應該是這個答案吧哈哈??
是的！