發票系統設計思路,小白也能學會

9 評論 21384 瀏覽 110 收藏 10 分鐘

編輯導讀:好的產品經理要具備的必不可少的能力就是踏實的落地能力,從單純的處理某個功能,到最后站在一個比較高的角度去看系統的整體設計,最后輸出對系統的思考,這都是一種成長。本文作者結合發票的基本知識、發票系統的基本設計思路以及遇到的那些坑,詳細地分析了系統設計,希望會給你帶來幫助。

我認為,所有B端系統的設計都圍繞著一個原則:以滿足業務的需求為準,用系統減輕業務實際操作的負擔,提升工作效率。

所以對于發票管理系統來說,其設計也都是圍繞業務的實際操作來進行的。

發票系統主要是為了服務于稅務同學,因而不可避免的也會涉及到一部分的稅務知識,對剛上手的同學來說可能不是特別友好。

我專業是學計算機的,剛開始接觸發票系統時,完全不清楚紅票、藍票,抬頭、稅額等這些發票里的門門道道,所以前期走了一些彎路,也花了時間去適應。

這次我通過結合發票的基本知識、發票系統的基本設計思路以及我在熟悉系統中遇到的坑來對系統設計進行分析,希望會給你帶來幫助。

一、什么是發票

發票,過去稱之為“發貨票”,是表示錢已經收到,貨已經發出的一個手續。

其實在晚清時期就有發票的雛形,當時買賣雙方很希望有一種能證明交易過程的真實性的證據,商家銷售貨物所開具的一份“發貨單”,也是買賣雙方進行交易的商品清單,當時的這種憑證其實很類似于收據。

后來隨著朝代的更替、結合交易場景發票被逐步優化,就有了現在的發票。

百度上寫道:

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

收據才是收付款憑證,發票只能證明業務發生了,不能證明款項是否收付。

簡而言之,發票就是發生的成本、費用或收入的原始憑證,正因為發票是唯一憑證,所以每張發票都會有一個特定的發票號碼。

其實我們實際生活中涉及到發票的場景非常多:吃飯、住宿需要找店家開張發票,線上購物找商家開發票……

對于商家來說,發票主要是公司做賬的依據,同時也是繳稅的費用憑證。而對于消費者來說,發票主要是用來報銷的。

生活中會出現一種場景,商家反饋本月度票用完了,承諾給消費者下個月開票。這是因為公司會定期從稅務機關購買發票,如當月票已被用完的話,一般都會下月補開。

發票分為普通發票和增值稅專用發票,增值稅專用發票能用于抵扣,增值稅普通發票只能做記賬憑證。

目前專票只支持紙質發票,而普通發票電子、紙質票都支持。

知道了發票類型、形式還不夠,還需要知道一張真正的發票長什么樣子,有哪些字段。

附一張滴滴的發票:

我們可以看到,一張發票中會包含發票抬頭、發票稅率、發票號碼、開票公司等信息。

二、設計發票系統需要考慮的三個維度

1. 發票數據的基本操作

1)開具發票

需要輸入哪些發票信息,提交信息后如何開票。

對于抬頭信息、電子郵箱或者郵寄地址是需要用戶來錄入的,像稅率、納稅人識別號、開票人信息等都是公司自己配置好的,自動帶入即可。

當信息填寫完成后,大部分中小型公司都是會通過調用第三方系統進行開票。當開票成功后,就如上文所說,生成一個特定的發票號碼。

2)查詢發票

查詢條件有哪些,支持哪些數據的展示。

要明確的是,查詢項的主要目的是用于定位數據。

除了最基礎的一些查詢項,如發票申請時間、開票成功的時間,還要根據業務日常的操作訴求進行設計,比如是否需要根據提交人進行查詢、是否需要通過交易訂單號查詢等。

3)查看發票

除了發票本身信息以外,還支持查看哪些信息。

查看發票詳情里的字段一般是包含了查詢項以及提交項的內容,除此之外集合實際業務場景考慮是否增設其他信息,還如自動帶入的配置信息、訂單信息、商品信息等。

4)修改發票

發票中哪些信息支持修改,修改的功能主要會涉及到安全問題。所以這里要考慮功能的權限配置,同時還要給出修改規則,即哪些字段可以修改,哪些不能。

如用戶自己提交的信息基本都是可以修改的,而像系統自動帶出的字段都是不允許修改的。

2. 發票數據狀態的流轉

“用戶提交一條數據—發票系統生成一條數據—提交三方系統開票–返回開票結果”,這是一張發票在系統的正向流轉過程。

簡單來說就是未開始—進行中—已完成/失敗,我們可以發現,這里其實有涉及到數據的狀態變更,同時還用考慮在對應不同的狀態下,會有不同相關聯的操作。

比如說對于已成功開具的發票,我們可以對此進行紅沖。

紅沖后,我們就會得到一張“紅票”,未紅沖的開成功的票即“藍票”(雖然“紅票”是基于對“藍票”進行紅沖后生成的,但實際上這屬于兩張發票,有各自不同的發票號碼。)

再比如,開票失敗以后我們可以再次開票等等。

3. 與不同系統之間的關聯

我們上文說過,發票是發生的成本、費用或收入的原始憑證,是有一個前置動作的。

所以對于發票系統來說,他不會是一個完全獨立的系統,要從訂單系統、退費系統、商品系統中獲取信息,從而對發票信息進行判斷。

如在開發票時,發票系統需要去訂單系統抓取訂單狀態進行判斷,當訂單狀態為“已付款”或“已收貨”(具體狀態因業務場景而定)時才能發起。

像京東這樣的電商平臺,會自動抓取訂單“已簽收”狀態進行自動開電子票。

同時發票系統也要去判斷當前訂單是否重復開票,同理,當訂單狀態為“已退費”時,發票系統也需要對之前開過的票進行紅沖。

所以熟悉發票系統的前提下,也要求對其他系統有一定熟悉。

三、思考

不管從功能支持來說,還是從界面設計來說,不同業務下不同公司的發票系統設計的肯定不一樣。

但是本質還是圍繞發票本身的性質結合業務訴求進行設計,這篇文章主要提供一種設計思路。

上文的這些內容其實都是一些很基礎、但是一不注意就會被忽視的思考點。

其實在我看來,一個好的產品經理需具備的必不可少的能力就是踏實的落地能力。

從知道這個事怎么做,到最后把這件事做好,這其中如果不細細思考,得出的結論也大多是些泛泛之空談。

從單純的處理某個功能,到最后站在一個比較高的角度去看系統的整體設計,最后輸出你對系統的思考,試著輸出你認為還需要優化的點,這都是你的一種成長。

 

作者:閆秀兒;公眾號:閆秀兒

本文由 @閆秀兒 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Pixabay,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 專票現在也能開電子發票了

    來自廣東 回復
  2. 不夠全面

    來自廣東 回復
  3. 感謝普及

    回復
  4. 老師,訂單支付成功就開具發票,還是要確認收貨后才開具發票???是根據訂單狀態為依據嗎?

    回復
  5. 有沒有進項發票的管理?

    回復
  6. 如果像電商行業,在售后的流程,自然要改變發票的狀態,如果買家未收到貨,申請退款,發票就及時沖藍。吶如果是退貨訂單,是商家同意退貨就沖藍?還是等商家收到貨,確定退款時才沖藍?

    來自廣東 回復
    1. 一般商家都要等貨和票都到了才會退款。如果是增專票的話需要退貨到了退貨款,退票到了退稅金。有時候對方已經認證了發票就需要對方開紅字通知單過來。

      回復
  7. 加油,持續關注~

    來自遼寧 回復
    1. 謝謝您的鼓勵!

      來自北京 回復