線上開票系統設計實踐

導讀：爲響應國家號召，提高業務效率，更好的服務企業用戶，雲信於9月末上線了線上開票功能。本文主要介紹了發票相關的基本知識，以及如何實現線上開票功能，遇到的問題和解決方案。

文｜璐西 夜雨

2020年9月29日，稅務總局等十三部門聯合發佈《關於推動納稅繳費便利化改革優化稅收營商環境若干措施的通知》，指出要穩步推動發票電子化改革，促進辦稅提速增效降負，2020年末前基本實現新辦納稅人增值稅專用發票電子化。

爲了提高業務效率，更好的服務於企業客戶，同時響應政策號召，網易雲信2020年9月起支持線上開具電子發票，增值稅普通電子發票將能夠脫離線下人工開票流程，直接在線上完成自動開票。小小的一張發票背後，是一套集用戶後臺、業務後臺、第三方平臺於一體的線上開票系統。線上開票場景適用於各種行業，只要發生線上交易，不管toB 仍是 toC，均會涉及。

本文主要從財稅知識科普、產品設計、技術設計多個維度分享線上增值稅開票系統的實踐，但願能對你們有所幫助。

財務知識科普

在進行線上開票系統的設計以前，須要深刻了解相關背景知識，這樣才能理解整個業務流程。相關說明主要基於內部設計展開，僅供參考。

1.傳統開票方式

一家新企業須要先到稅局申請發票，再向稅控服務公司購買稅控設備。稅控設備安裝好後，再攜帶稅盤（金稅盤或稅控盤）到主管稅務機關初始發行，發行後到櫃檯領用發票。以後企業稅務人員就能夠安裝開票軟件，進行企業內部的線下開票了（紙質或電子）。

金稅盤、稅控盤：俗稱白盤，黑盤，分屬於兩個不一樣的協稅公司，金稅盤屬於航天信息，稅控盤屬於百旺。

2.發票信息

以電子普通發票爲例，一張發票主要涉及如下幾個重點信息，瞭解了這些信息對後續第三方平臺的對接會有很大幫助。

購買方信息:

• 名稱：若購買方爲B端企業/組織，則此處應填寫增值稅納稅人的名稱，納稅人識別號，地址、電話，開戶銀行及帳號，並確保單位名稱和納稅人登記號的相應關係準確無誤。若購買方爲我的，則須要填寫我的身份證姓名。

訂單信息：

• 服務名稱：由商品名稱+商品服務類型組成。通常格式爲商品名稱商品服務類型

  商品服務類型，和稅收分類編碼對應，第三方開票平臺會根據稅收分類編碼自動生成商品服務類型，如信息技術服務技術服務費。

• 單價：這裏指不含稅單價，計算公式爲不含稅單價=round(不含稅金額/數量, 8)，保留8位小數，舍入模式爲四捨五入。
• 金額：這裏指不含稅商品金額，每一個企業都會有對應的發票限額，需提早與稅務確認限額，單張發票的總金額不能超過限額，超事後須要系統自動拆分爲多張。
• 稅率：不一樣的稅收分類編碼對應不一樣的稅率。
• 稅額：國家收取的稅收金額，計算公式爲 稅額=round((數量×含稅單價)×稅率)÷(1+稅率),2)，保留2位小數，舍入模式是四捨五入。

• 價稅合計：即單張發票的含稅總金額。

  若供應兩種不一樣稅率的應稅項目，且合併開具發票的，其商品或勞務的名稱、計量單位、數量、單價、金額，必須按不一樣稅率分別填寫。對供應的貨物既有應稅貨物，又有免稅貨物的，供應的免稅貨物應單獨開具普通發票，不得和應稅貨物合併開具增值稅專用發票。

銷售方信息：

• 名稱等：銷售方企業名稱和後續雙方合同的乙方名稱需保持一致。且名稱、證件號需合法有效。
• 收款人：通常爲銷售方財務人員，可與公司財稅人員確認。
• 複覈：通常爲銷售方財務人員，可與公司財稅人員確認。
• 開票人：通常爲銷售方稅務人員，可與公司財稅人員確認。

銷貨清單：

當發票上的訂單信息超過貨物或應稅勞務、服務名稱一欄展現範圍時，會生成用於記錄完整訂單信息的銷售貨物或者提供應稅勞務、服務清單，發票貨物或應稅勞務、服務名稱一欄內容爲(詳見銷貨清單)。

3.發票類型

發票主要分爲如下幾類，線上開票僅涉及增值稅普通發票（如下簡稱普票）及增值稅專用發票（如下簡稱專票），除電子發票可線上自動開票外，紙質發票的業務邏輯也須要一併兼容。

4.常見術語

藍票、紅票：正常開具發票爲「藍票」，出現退貨或開具的發票有錯誤，須要做廢發票或開具「紅票」（也叫負票）用以衝減當期開票方的銷售收入（也叫紅衝）。

若是是增值稅專用發票，在同一個月開票退貨且發票未認證的，可直接做廢發票；跨月退票的，須要紅衝，開具負（紅字）發票，衝減當期銷售；如已經過同認證的，需購貨方稅務局出具《開具紅字發票通知單》，銷貨方憑此《通知單》才能開具紅字（負數）發票。此流程通常須要線下處理。

產品設計

熟悉了基本知識，在正式進入線上開票系統的產品設計以前，須要進行第三方開票平臺的選型。肯定選型後結合第三方平臺的接口，梳理業務流程及相關功能點。

第三方開票平臺

中國電子發票產業鏈的核心環節包括稅控設備商和第三方電子發票服務平臺。

稅控設備商是國有控股的愛信諾、百旺雙寡頭格局。第三方電子發票服務平臺主要分爲三大陣營，包括百望股份、高燈科技爲表明的新興企業；由稅控設備商、傳統紙質發票印刷商組成的老牌發票服務商；以用友、金蝶爲表明的老牌軟件服務商。能夠根據企業狀況，選擇第三方開票平臺。

企業可經過第三方平臺接口完成於自有系統對接，可選擇自行同步發票，也可選擇掃碼開票。後者在線下門店開票中較爲常見。

業務流程

根據業務特色進行需求分析，設計適合本身業務的開票流程。此過程建議與財稅同窗保持密切溝通，避免設計出來的開票流程不符合財稅要求。

訂單支付完成後，以電子發票線上開票及退票爲例，主要業務流程（含狀態流轉）參考以下：

說明：

• 爲了下降發票的退票率及虛開發票的風險，設計中加入了實名認證的環節，確保發票擡頭和證件號真實有效，且一一對應。
• 部分歷史數據（歷史已經線下開過票的訂單），可考慮經過下單或支付時間進行限制，規避重複開票的風險。
• 財務審覈環節可根據公司財稅要求肯定是否須要保留，但紙質發票流程通常都會涉及到後臺審覈。

  功能

線上開票系統主要涉及用戶和業務後臺，核心功能點參考下圖：

說明：

• 對於後臺操做人員來講，批量處理能夠很大程度上提高工做效率。
• 不一樣的發票狀態對應不一樣的操做類型。
• 銷售後臺需考慮紙質發票的做廢流程。
• 紙質發票的快遞狀態跟蹤也可考慮做爲低優先級功能逐步優化。

  其餘業務場景

實際業務中，還會涉及一些特殊場景，如提早開票、退款退票等。

提早開票，即客戶先開發票再進行支付。不少大企業內部報銷審覈嚴格，須要銷售方先開具發票，而後根據發票報銷打款。

退款退票，即客戶購買後，因爲各類緣由進行了退款操做，包含所有退款或部分退款。若是已經開具發票，則須要同步完成退票流程。針對所有退款的狀況，只須要走正常退票流程便可。但針對部分退款的狀況，原來已經開具發票的須要總體退票以後，再開具剩餘未退款金額的發票。

這些特殊場景也須要完成線上化，經過系統閉環全部開票流程，其優先級可根據自身業務需求制定。

技術設計

對於技術人員來講，在設計任何一個系統時首先都會遇到如下個問題：

1. 系統面向的使用者是誰？
2. 租戶隔離要隔離什麼數據？
3. 系統的外部依賴有哪些，邏輯架構應該怎樣設計？

解決了上述問題後，就輪到咱們的開票系統獨有的內部業務問題了：

1. 發票上的各項金額分別表明什麼含義，如何計算？
2. 多訂單合併開票或大額訂單開票時，發票應該如何拆分？

理順了內部業務邏輯，最後就該思考如何對外提供服務，並儘可能提高服務體驗，也就是要解決如下問題：

• 接口時序是怎樣的，哪些步驟應該異步化？

  系統使用者

一般對於一個集團公司來講，業務結構是呈現金字塔形狀的，即集團公司下有不一樣的子公司，子公司下有不一樣的產品線，但也偶爾有一些產品線是由不一樣的子公司甚至外部公司組成。

所以咱們應該把終端產品線做爲租戶。

終端隔離

明確了系統使用者，接下來就須要考慮租戶應該隔離哪些數據。

目前市面上的開票供應商提供的都是銷方帳戶隔離，有兩點限制：

1. 同一銷方帳戶內訂單號必須惟一；
2. 銷方帳戶每張發票的不含稅金額有上限；

而在實際的線下開票中，咱們還會碰到如下場景：

1. 相同的稅收分類編碼在不一樣產品線中有不一樣的商品名稱；
2. 相同的商品在不一樣產品線或者同一產品線中有不一樣的商品規格、商品單價；

所以，咱們的租戶對應的數據映射關係以下：

1. 租戶和銷方帳戶是1對1的關係；
2. 租戶和單張發票不含稅金額上限是1對1的關係；
3. 租戶和訂單編號是1對N的關係；
4. 租戶和容許開票的商品SKU（即容許的名稱/稅收分類編碼/規格/單價組合）是1對N的關係；

   邏輯架構

發票的生成須要如下必要元素：

1. 發票主體；
2. 訂單信息；
3. 商品信息；
4. 實際開票能力；

按微服務來講，就是咱們要依賴4個外部服務：

1. 用戶中心負責提供通過實名認證的發票主體信息；
2. 訂單中心負責提供訂單編號以及包含的商品SKU購買數量數據；
3. 商品中心負責提供商品SKU的名稱、稅收分類編碼、商品規格、含稅單價數據；
4. 開票供應商負責提供實際的電子開票能力；

因而，咱們的邏輯架構圖應該以下圖：

金額計算

發票裏的各項屬性的含義能夠參考上文，經過各項金額的定義，咱們能夠獲得如下計算公式：

• 稅額=round((數量×含稅單價)×稅率)÷(1+稅率),2)，保留2位小數，舍入模式是四捨五入。
• 稅額=round((數量×不含稅單價×稅率), 2) ，保留2位小數，舍入模式是四捨五入。
• 不含稅單價=round(含稅單價/(1+稅率), 8)，保留8位小數，舍入模式是四捨五入。

  發票拆分

各個產品線在申請開票時都是但願訂單和發票會一一對應，但實際狀況是，受限於企業資質，銷方開出的每張發票是有不含稅金額上限的，超出上限就不能開具發票。

底層的開票供應商一般都具備自動拆票功能，即一筆訂單的不含稅金額超過上限，就會自動拆分紅多張發票。但開票供應商一般會建議咱們本身封裝一套拆票邏輯，這是由於供應商的拆票是面向單筆訂單的，若是業務上是多筆訂單合併開票，供應商拆票後就會出現某幾張發票的金額遠小於上限，形成發票份數的浪費。

稅務每個月能從稅務局領取的發票份數是有限的。

1. 藍票拆分

首先，咱們把藍票開票流程中涉及的對象實體進行抽象：

（1）把產品線提交的一次藍票開票請求抽象爲一個主流程，一個藍票主流程包含一筆或多筆訂單；

（2）把拆分後的單張藍票抽象爲一個子流程，因此一個藍票主流程有一個到多個藍票子流程；

（3）每張藍票有一行或多行發票明細項目，因此一個藍票子流程有一條到多條發票明細項目；

（4）單張發票的不含稅金額上限做爲拆分時的不含稅金額閾值；

而後咱們來進行拆分規則的制定；

（1）商品的不含稅單價不得大於不含稅金額閾值，若是有超過閾值的會被拆分紅一組到2組商品：一組商品的單價等於不含稅金額閾值，數量爲原商品不含稅金額/拆分不含稅金額閾值；若是還有剩餘不含稅金額，則拆分紅一個單價爲剩餘不含稅金額，數量爲1的商品，訂單編號、商品名稱、稅收分類編碼不變；

a. 例如訂單1/商品A/稅收分類編碼TC1/數量2件/單價18萬會被拆分紅訂單1/商品A/稅收分類編碼TC1/數量3件/單價10萬和訂單1/商品A/稅收分類編碼TC1/數量1件/單價6萬；

b. 例如訂單1/商品A/稅收分類編碼TC1/數量2件/單價15萬會被拆分紅訂單1/商品A/稅收分類編碼TC1/數量3件/單價10萬；

(2) 將(訂單+商品名稱+稅收分類編碼+不含稅單價)做爲拆分維度的最小單位，商品數量最小爲1，若是當前發票含稅金額的剩餘額度小於商品單價則自動開具下一張發票，若是當前發票含稅金額的剩餘額度大於商品單價，則當前發票最多可放置當前商品的數量=min((剩餘額度/商品單價), 商品數量)，若是所有商品數量均可以放下則切換到下一個商品，不然將剩餘商品數量放到下一張發票裏；

上述的規則說明中是以技術服務類這種沒有規格的商品做爲說明的，若是是實體類商品則需把商品規格也加入到拆分維度中。

詳細拆分步驟見流程圖：

拆分示例：

假設銷方單張發票的不含稅金額上限爲10萬，產品線提交的原始開票訂單以及商品列表以下：

咱們指望不含稅單價溢出商品拆分後，單價溢出的商品8被拆分紅兩組商品：

咱們指望最終的拆分結果爲7張發票：

2. 紅票拆分

紅票是根據對應藍票來開具的，紅票和藍票有如下映射關係：

1. 紅票發票明細和藍票發票明細一一對應，除了商品數量、不含稅金額、稅額、含稅金額是對應藍票發票明細的負數外，其餘各項屬性都是相同的；
2. 紅票的發票備註中須要以"對應正數發票代碼:xxxxxxxxxxxx號碼:xxxxxxxx"的形式填充上對應藍票的發票代碼和發票號碼；

因此只須要根據藍票的拆分結果就能完成紅票拆分。

參照藍票拆分中的實體定義，對紅票開票流程中涉及的對象實體進行抽象：

1. 把產品線提交的一次紅票開票請求抽象爲一個主流程，一個紅票主流程必須關聯且只關聯一個藍票主流程；
2. 把拆分後的單張紅票抽象爲一個子流程，一個紅票主流程有一個到多個紅票子流程，每一個紅票子流程和藍票主流程關聯的藍票子流程一一對應，紅票子流程的發票備註以"對應正數發票代碼:xxxxxxxxxxxx號碼:xxxxxxxx"的形式填充上對應藍票子流程的發票代碼和發票號碼；
3. 每張紅票有一行或多行發票明細項目，每一個紅票發票明細和藍票子流程關聯的藍票發票明細一一對應，紅票發票明細的商品數量、不含稅金額、稅額、含稅金額是對應藍票發票明細的負數，其餘各項屬性相同；

   接口時序和異步化

邏輯架構中的訂單中心、用戶中心、商品中心都是提供只讀服務，所以能夠採用同步調用快速失敗的方式進行熔斷。可是對於大額訂單開票來講，藍票拆分邏輯較爲複雜耗時，且和開票供應商交互生成發票的過程不可控，所以咱們能夠將這兩個步驟異步化，而且在異步化流程中加入錯誤重試機制。

開具藍票的接口時序：

開具紅票的接口時序：

異步流程：

在異步流程中，咱們須要實現如下兩個功能：

1. 藍票/紅票拆分紅藍票/紅票子流程，拆分出的子流程有4種狀態：

a. 供應商待申請 -還沒有提交給開票供應商；

b. 供應商開票成功；

c. 供應商開票失敗；

d. 供應商開票中 - 既不是開票成功，也不是開票失敗的其餘狀態都屬於開票中；

1. 藍票/紅票子流程提交給開票供應商生成電子發票，包括開票結果的查詢以及開票異常的重試；

詳細步驟見流程圖：

以上就是網易雲信線上開票系統設計的實踐，目前該功能已經上線，歡迎你們體驗！