起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識拆解電子發票，關于應用層的承上啟下
導讀：隨著這些年來的發展，電子發票這個“新鮮事物”也褪去了新鮮感融入了我們的生活中，縱觀整個電子發票的路徑，頂層為政府的稅務部門，中層為“51發票”,“發票通”等發票服務商，應用層則為各消費場景下的開票企業，本文主要討論應用層的承上啟下。
隨著這些年來的發展，電子發票這個“新鮮事物”也褪去了新鮮感融入了我們的生活中，縱觀整個電子發票的路徑，頂層為政府的稅務部門，中層為“51發票”,“發票通”等發票服務商，應用層則為各消費場景下的開票企業，本文主要討論應用層的承上啟下。
如果是新企業需要對接電子發票業務的話還需要前往稅務部門完成，開票資質申請/電子簽章申請/申請發票資質/等業務流程，完成后即可尋找發票服務平臺進行合作由他們提供接口支持即可。
一、以訂單為核心的系統架構
電子發票以訂單為核心，屬于獨立模塊，但是與系統各個模塊緊密相連
- 用戶端主要支持電子發票的申請與查看，管理端則支持對電子發票的全生命周期進行管理，在后文會進行詳細的功能說明
- 訂單系統主要為電子發票提供用戶開票的具體信息，與訂單狀態，即開票的內容
- 商品信息用戶配置用戶開票的商品稅率，以計算發票各項明細
- 消息中心則是為了在開具電子發票成功后進行通知用戶
二、簡單的開票流程
以上是一個簡化后的開票流程，對于用戶的交互點就三項，申請開票/填寫信息/收到發票,但是對于系統的交互點遠不止如此，簡單的梳理下流程吧
申請發票前通用的前置條件都是需要用戶在該交易行為完成后（滴滴到達目的地，電商確認收貨，航司航班到達）并且未開具過對應消費的電子發票。
交易完成是指用戶已無法對當前消費流程作出更改，即涉及到退改環節的狀態應該在交易完成之前，可以定義為退改完成后即為交易完成。
在用戶滿足申請條件后即向訂單系統查詢,將用戶該次消費的明細列出
- 開票維度：根據各自不同的業務形態，有著不同的開票維度店鋪訂單/平臺訂單/客票，建議以最小用戶維度來進行開票，多店鋪精確到店鋪，多人則精確到人。
- 開票內容：發票內容可以規定一張訂單開一張發票，或每一件商品可開具一張發票，建議以最大開票內容作為一張發票，可以減少系統交互及人員維護成本。
（總結：開票維度偏向更細，開票內容偏向更廣）
在用戶提交申請后即調用發票服務商提供的開票接口，提交發票內容及發票抬頭信息。
- 訂單系統給與具體的商品名稱，數量，商品系統/財務系統給出對應商品的稅率，該項組成發票內容，將會在票面上展示出明細。
- 發票抬頭有，個人/企業/非企業，三種類型，對應不同的填寫項目
（一張完成的發票就由發票內容及發票抬頭組成）
發票開具成功后向用戶推送消息通知與電子發票
- 消息通知可以按渠道分為短信消息通知，郵件消息通知，為了防止一個渠道接收失敗的情況建議選擇兩個渠道同時發送
- 生成的電子發票為pdf文件保存在服務器中，推送時附帶下載連接，方便用戶下載保存
用戶收到發票，發票的流程結束。
三、圍繞發票生命周期的功能點
在上面分析了發票的架構與流程，接下來結合實際的業務場景，按照電子發票模塊的功能點來逐個分析下，以下的功能點都是在我們的實際運營中面對復雜的業務場景與需求得出來的解決方案，具有一定的借鑒意義，最終你們發票系統的功能點還是需要結合你們自己的業務場景及需求來制定。
圍繞著電子發票可以劃分為前中后三個生命周期，分別代表著申請前 申請中，申請后，對應著不同的功能點，大部分都是當然還有寫輔助性的功能我也會進行補充，接著開始正文吧。
1. 申請（核心功能）
說明：電子發票的申請作為整個發票的開端，涉及系統及應用都比較廣泛
系統：申請前需要先檢查用戶是否滿足申請狀態（訂單內容，訂單狀態）在上面的流程部分已詳細說明
功能設計：在用戶填寫發票申請時注意各個填寫項目的字段規范，長度/類型/不建議做太嚴格的校驗，
功能設計：C端的申請界面可以設計抽屜效果將非必填項目進行收起處理,減少用戶填寫信息量。
2. 紅沖（核心功能）
說明：當開具了錯誤的電子發票后可以使用紅沖功能，再次開具一張相同內容的紅字發票，作廢原發票?？梢岳斫鉃樽鲝U已開具的發票
功能設計：該功能一般放在B端系統中集成，
3. 換開（輔助功能）
說明：用戶可以在C端將已經開具完成的電子發票申請進行作廢并根據新填寫的信息再次開具。
功能設計：該功能相當于紅沖+再次開票的流程，實現效果是用戶可以自主完成發票的維護流程，減少客服及運營人員壓力
4. 撤銷申請（解決異常問題）
說明：由于第三方或者我方服務原因，偶現發票開具失敗的情況，用于處理異常使用，
功能設計：將該發票的狀態更改為初始狀態，主要解決在發票開具過程中的系統錯誤問題。
5. 業務發票（輔助功能）
說明：獨立于正常開票流程之外的功能，能夠獨立開具電子發票，用于解決某些現有系統不滿足的特殊場景，及用戶需求，在某些訂單不正確的情況下也可用于救火，相當于超級開票功能，但是其中涉及稅率，商品等計算，該功能如果各位有需求的話看情況可以單獨再講下。
6. 發票備注模板（輔助功能）
說明：編輯發票右下角區域的信息，可以填寫一些簡單的備注信息，用戶的消費類型，訂單號碼等，方便追溯
7. 常用發票信息（輔助功能）
說明：在C端用戶填寫完成發票申請后，將發票抬頭信息進行保存，可以保存為三種類型，在用戶切換抬頭類型時，填入不同的信息。
本文主要講述對于電子發票這一事物在應用層的，邏輯脈絡，框架結構，細節的功能設計由于篇幅所限就不過多贅述了，所寫內容也都是本人在負責發票這一項目來的感悟和教訓，受限于個人的經驗與能力，也還是有不足的地方，各位看官權當個借鑒即可。
保持獨立思考，不卑不亢，長成自己想要的模樣。
本文由 @沈萬三 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
優秀