服務熱線
400 180 8892
前 言
本標準按照GB/T 1.1—2020《標準化工作導則 第1部分：標準化文件的結構和起草規則》 的規則起草。
本標準由浙江省財政廳提出并歸口。
本標準主要起草單位： 浙江省財政票據管理中心、浙江省數字財政管理中心、螞蟻科技集團股份有限公司。
本標準主要起草人：
區塊鏈財政電子票據規范
1 范圍
本標準規定了基于區塊鏈技術實現的財政電子票據的技術框架、業務流程、數據規范和技術要求等。
本標準適用于財政電子票據的開具、傳輸、存儲歸集、查詢、報銷入賬和歸檔，適用于基于區塊鏈的財政電子票據系統的設計、建設、開發、部署和應用。
2 規范性引用文件
下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅所注日期的版本適用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。
ISO/AWI 22739 區塊鏈和分布式記賬技術—術語和概念
ISO/AWI 23257 區塊鏈和分布式記賬技術—參考架構
ISO/AWI TS 23259 區塊鏈和分布式記賬技術—合規性智能合約
GB/T 36609-2018 電子發票基礎信息規范
3 術語、定義和縮略語
3.1 術語和定義
3.1.1
財政票據 finance invoice
由財政部門監（?。┲啤l放、管理，國家機關、事業單位、具有公共管理或者公共服務職能的社會團體及其他組織依法收取政府非稅收入或者從事非營利性活動收取財物時，向公民、法人和其他組織開具的憑證。
財政票據包括非稅收類票據、結算類票據、其他財政票據。其中，其他財政票據包括公益事業捐贈票據、醫療收費票據、社會團體會費票據、其他應當由財政部門管理的票據。
3.1.2
財政電子票據 finance e-invoice
以數字信息代替紙質文件、以電子簽名代替手工簽章，依托計算機和信息網絡技術開具、存儲、傳輸和接收財政電子票據，實現電子開票、自動核銷、全程跟蹤、源頭控制的電子形式票據。
注：財政電子票據基本特征是以數字信息代替紙質文件、以電子簽名代替手工簽章，通過網絡手段進行傳輸流轉，通過計算機等電子載體進行存儲保管。
3.1.3
區塊鏈 blockchain
一種在對等網絡環境下，通過透明和可信規則，構建不可偽造、不可篡改和可追溯的塊鏈式數據結構，實現和管理事務處理的模式。
3.1.4
區塊鏈電子票據系統 blockchain-based e-invoice system
基于區塊鏈技術實現的財政電子票據系統，借助于區塊鏈技術在財政票據應用中以電子數據形式實現財政票據的開具、傳輸、存儲、歸集、應用、入賬和歸檔。
3.1.5
智能合約 smart contract
存儲在分布式賬本中的計算機程序，其共識執行結果都記錄在分布式賬本中。
3.2 縮略語
4 概述
基于區塊鏈的財政電子票據，簡稱為“區塊鏈電子票據”，在財政電子票據無紙化基礎上，基于區塊鏈技術，打通電子票據的所有流程，支持快速可靠的票據應用。
區塊鏈電子票據具有以下特點：
a) 票據源可信：由財政部門監制并上鏈，確保票據源的可信性；
b) 全鏈路可信：基于區塊鏈不可篡改、不可抵賴的特點，確保傳輸、存儲、應用全鏈路的可信性；
c) 用票可信：基于實名認證、用票授權等確保用票的可信性；票據通過狀態機維護可信狀態。
5 參考模型
5.1 技術框架
區塊鏈電子票據系統的技術框架如圖1所示。
圖1 區塊鏈電子票據系統架構圖
區塊鏈電子票據系統由支撐系統、服務系統和業務系統構成。
支撐系統實現電子票據的存儲、歸集、狀態機維護等；服務系統分為密鑰子系統、業務受理子系統和業務處理子系統，其中密鑰子系統負責密鑰管理和密鑰生成，業務受理子系統實現票據上鏈（簡稱為“上票”）、換開等，業務處理子系統實現電子票據的查詢、理賠、報銷等應用；業務系統由各票據業務使用方搭建，其中服務接入系統面向C端用戶提供票據的驗證和查詢，應用單位接入系統負責用戶的實名認證，并發起業務。
5.2 系統角色
5.2.1 概述
區塊鏈電子票據涉及的角色分為服務提供方和服務使用方，相關部署方式參見附錄A。服務提供方包括共識節點、監管節點、業務節點；服務使用方包括財政部門、開票單位、收票方、用票方和監管部門。
5.2.2 服務提供方
5.2.2.1 共識節點
共識節點參與共識過程，維護全量數據。
注：典型的共識節點如財政管理部門部署的區塊鏈節點。
5.2.2.2 監管節點
監管節點不參與共識過程，不維護全量數據，維護與監管職能相關的所有數據。
注：典型的監管節點如衛生保健部門部署的區塊鏈節點、醫療保障部門部署的區塊鏈節點、檔案管理部門部署的區塊鏈節點。
5.2.2.3 業務節點
業務節點不參與共識過程，不維護全量數據，維護與業務主體相關的所有數據。
注：典型的業務節點如醫院或學校部署的區塊鏈節點。
5.2.3 服務使用方
5.2.3.1 財政部門
財政部門監制財政電子票據，通過財政部門接入系統（通常為財政電子票據管理系統），實現財政電子票據的上鏈。
財政電子票據管理系統應進行升級改造以接入區塊鏈電子票據服務系統的受理子系統。接入方式包括但不限于：客戶端、用戶圖形接口、命令行、腳本、API等。
5.2.3.2 開票單位
開票單位宜支持通過區塊鏈電子票據系統實現鏈上開票，并對鏈上開具的票據進行簽名。
開票單位在入賬、歸檔后，應及時將相關信息反饋至區塊鏈電子票據系統。
5.2.3.3 收票方
收票方分為個人和單位。
收票方通過服務應用，實現財政電子票據的查詢。典型的服務應用，如支付寶、浙里辦等。
5.2.3.4 用票方
用票方實現電子票據的應用、報銷入賬，并在入賬、歸檔后將相關信息反饋至區塊鏈電子票據系統，更新電子票據的狀態。用票方接入系統應對收票方進行實名認證。
注：典型的用票方如醫療保障部門、保險機構等。
5.2.3.5 監管部門
監管部門可接收區塊鏈電子票據系統推送的與監管職能相關的信息。
注：典型的監管部門包括財政管理部門、稅務管理部門等。
5.3 區塊鏈節點
5.3.1 概述
按照節點的主要功能，區塊鏈組網中節點可分為共識節點和非共識節點。共識節點保證區塊鏈分布式系統數據的一致性；非共識節點（如監管節點和業務節點等）可以提供鏈上數據的查詢服務，分散區塊鏈系統數據查詢壓力。
5.3.2 節點變更
應支持區塊鏈兩種節點的動態增加和刪除，實現根據具體業務對資源的動態擴容或降配，相關要求包括：
a) 區塊鏈平臺運營方調用區塊鏈系統合約，在節點增加應等待新節點完成數據同步；
b) 區塊鏈平臺運營方調用區塊鏈系統合約，應在釋放節點資源后完成節點刪除；
c) 為增強區塊鏈電子票據系統的整體健壯性，鏈上共識節點數量宜為3f+1。
注：f為系統能夠容錯的節點個數。
5.3.3 節點管理
應根據實際業務需求，在不影響現有節點運行的情況下，由區塊鏈平臺運營方管理員動態增加或刪除節點，且增加或刪除節點不影響現有業務的運行。
6 業務流程
6.1 概述
區塊鏈電子票據系統支持的業務包括：鏈上開票、票據上鏈（簡稱為“上票”）、票據查詢、票據應用（簡稱為“用票”）、票據入賬、票據沖紅和票據換開。
6.2 鏈上開票
鏈上開票基于區塊鏈系統實現電子票據的鏈上開具。利用區塊鏈的可信身份認證、可信計算特性，真正實現區塊鏈電子票據開票業務，保證電子票據真實有效，同時可節省人力資源成本。
鏈上開票由執收機構發起開票請求，經由區塊鏈開票業務系統接入鏈上開票系統，生成票據xml數據文件，再經由制票服務完成開票單位和財政的電子簽名，生成電子票據xml文件、pdf或png板式文件。
6.3 票據上鏈
票據上鏈業務，由財政部門發起，經由財政部門接入系統，最終存入電子票據區塊鏈平臺。業務流程如圖2所示。
圖2 票據上鏈業務流程示意圖
票據上鏈業務涉及的角色包括財政部門、收票方；涉及的系統包括受理子系統、密鑰系統、服務應用、電子票據區塊鏈。時序圖如圖3所示。
圖3 票據上鏈業務時序圖
票據上鏈業務流程為：
1.財政部門對票據進行驗簽；
2.財政部門向受理子系統發起票據上鏈請求，生成業務流水號，并上傳電子票據的原始文件。原始文件包括描述票據信息的XML文件，以及票據版式文件URL地址；
3.受理子系統從XML文件中抽取字段，并驗證數據的合法性；
4.受理子系統將需要加密的數據進行加密，將需要哈希的數據進行哈希運算；
5.受理子系統根據數據規范（見7.2）構造上鏈數據；
6.受理子系統將上鏈數據傳送給電子票據區塊鏈平臺；
7.電子票據區塊鏈平臺建立收票方賬戶，并將票據歸集到該收票方賬戶下；
8.歸集成功后，電子票據區塊鏈平臺向財政部門返回交易哈希，并向收票方推送票據消息。
6.4 票據查詢
6.4.1 用戶票據查詢
用戶查詢名下的票據信息，由收票方發起，經由服務應用系統，查詢票據信息列表并對用戶選取的票據進行展示。用戶票據查詢業務涉及的角色為收票方、業務處理子系統、服務應用、電子票據區塊鏈。交互時序圖如圖4所示。
圖4 用戶票據查詢業務時序圖
6.4.2 票據查驗
票據查驗服務，由收票方發起，經由服務應用系統，查驗票據真偽信息。交互時序圖如圖5所示。
圖5 票據查驗業務時序圖
6.5 票據應用
票據應用業務，由收票方發起，由用票方受理，進行報銷、理賠等應用。業務流程如圖6所示。
圖6 票據應用業務流程示意圖
票據應用業務涉及的角色為收票方、用票方；涉及的系統包括業務處理子系統、服務應用、電子票據區塊鏈。時序圖如圖7所示。
圖7 票據應用業務時序圖
6.6 票據入賬
票據入賬指的是企業單位收入或支出票據, 計入賬簿里進行會計賬務處理。
區塊鏈電子票據系統提供按交款方、收款方歸集服務，企事業單位可以在自己的賬戶下，查詢歸集到的票據，并計入賬簿里進行會計賬務處理。
6.7 票據沖紅
沖紅是執收單位原先開具的票據有誤或需更正、調整賬目，而重新開具的紅字票據，通常金額是負數。執收機構可以經由區塊鏈業務中臺，調用鏈上沖紅接口，開票紅票，或將已有紅票上鏈。
6.8 票據換開
票據換開業務，由財政部門發起，經由財政部門接入系統，由區塊鏈電子票據平臺進行處理。業務流程如圖8所示。
圖8 票據換開業務流程示意圖
票據換開業務涉及的角色為財政部門；涉及的系統包括受理子系統、電子票據區塊鏈。時序圖如圖9所示。
圖9 票據換開業務時序圖
6.9 電子票據狀態
電子票據狀態應包括初始狀態、狀態查詢、用票中、已用票、已開紅票、已換開和已入賬，相關狀態及轉換關系如圖10所示。
電子票據的狀態機由開票單位和用票方共同維護，通過財政部門統一管理，保持唯一性。通過可信的電子票據狀態機，防止財政電子票據重復報銷套取資金等。
圖10 電子票據狀態機
其中，初始狀態、用票中、已用票、已入賬是電子票據的有效狀態。已換開和已開紅票是電子票據的失效狀態。電子票據進入失效狀態后不應再進行操作。狀態機流轉規則為：
——票據上鏈后，進入“初始狀態”；
——收票方提出換開紙質票據后，相應票據進入“已換開”狀態；
——開票單位退款或沖紅后，相應票據進入“已沖紅”狀態；
——用票方從業務子系統獲取票據文件后，相應票據進入“用票中”；
——用票方返回用票結果，相應票據進入“已用票”；
——用票方提交入賬反饋，相應票據進入“已入賬”；
——用票方提交開具紅票請求并完成處理后，相應票據進入“已開紅票”。
7 數據規范
7.1 數據格式
電子票據區塊鏈存儲的上鏈票據信息應包括三部分：描述票據信息的XML文件，票據版式文件URL地址，票據關鍵信息，具體信息格式應符合GB/T 36609—2018要求。
其中票據關鍵信息由受理子系統從XML文件中抽取，應包括以下字段信息：
——票據代碼；
——票據號碼；
——票據校驗碼；
——票據總金額；
——開票時間；
——開票單位代碼；
——開票單位名稱；
——收票方代碼；
——收票方名稱。
當票據沖紅時，還應包括以下字段信息：
——相關票據代碼；
——相關票據號碼。
7.2 數據存儲
上鏈票據信息中加密存儲的信息包括：
——XML文件；
——版式文件URL地址；
——收票方名稱。
上鏈票據信息中哈希存儲的信息包括：
——票據校驗碼；
——開票單位代碼；
——收票方代碼。
上鏈票據信息中明文存儲的信息包括：
——票據代碼；
——票據號碼；
——票據總金額；
——開票時間；
——開票單位名稱。
具體數據存儲如表1所示
表1 數據存儲方式
序號 數據項 存儲方式
1 電子票據代碼 明文存儲
2 電子票據號碼 明文存儲
3 校驗碼 哈希存儲
4 總金額 加密存儲
5 開票時間 加密存儲
6 開票單位代碼 哈希存儲
7 開票單位名稱 加密存儲
8 收票方代碼 哈希存儲
9 收票方名稱 加密存儲
10 電子票據 加密存儲
11 存儲地址 加密存儲
7.3 數據加解密
7.3.1 密鑰生成
密鑰的生成應滿足以下要求：
——一票一密?；谄睋拇a、號碼、校驗碼，生成該票據的唯一加密密鑰，從而確保一張票據的密鑰泄露不會影響其他票據的安全。
——密鑰不落盤。密鑰應通過計算的方式得到，禁止在硬盤存儲密鑰，從而避免拷貝等問題帶來的密鑰泄露風險。
——加密的根密鑰應由財政部門或財政部門授權的相關部門進行管理。
密鑰生成方法如圖11所示。
圖11 密鑰生成方法示意圖
7.3.2 加密與解密流程
票據上鏈時，應在受理子系統完成加密。票據應用時，應在業務處理子系統完成解密。加解密流程如圖12所示。
圖12 加解密流程圖
8 基本要求
8.1 實名歸集
電子票據區塊鏈平臺應支持實名歸集功能，通過區塊鏈歸集業務模塊（包含業務中臺、數據庫和鏈上智能合約）實現。實名歸集功能包括：
——基于收票方代碼建立賬戶；
——將對應收票方的票據歸集到對應賬戶；
——基于開票單位代碼建立賬戶；
——將對應開票單位的票據歸集到對應賬戶；
——歸集到賬戶名下的票據信息，應包含票據代碼、票據號碼、票據檢驗碼、票據總金額。
8.2 一致性
一致性相關要求包括：
a) 在存儲層級，通過鏈式架構、區塊存儲、時間戳等關鍵技術以及檢驗機制，實現票據數據存儲的可靠性、不可篡改、不可偽造特性；
b) 網絡層需要對不同節點的功能進行統一控制，對新生數據進行全網傳播后共同認證，驗證完成的新數據才能進行區塊鏈存儲；
c) 在共識層級，應采用共識算法保障交易數據的同步性；
在密碼技術層面，要求采用國產密碼 SM2/SM9、SM3、SM4 密碼算法，進行摘要計算、認證簽名、所有權確認與使用權保障，并通過加密技術確保信息安全防護等級，從而保障區塊數據的一致性、可靠性。
8.3 共識機制
共識機制相關要求包括：
a) 交易有效：能夠根據票據驗證及背書策略確保區塊中所有票據應用有效；
b) 交易有序：能夠確保所有節點提交和應用票據順序的一致性；
交易驗證：能夠利用智能合約的接口，驗證票據的有效性和提交順序。
8.4 不可篡改
不可篡改相關要求包括：
a) 票據鏈賬本不可篡改，即通過時間戳證明、首尾相連記賬規則、哈希算法、數字簽名、共識機制等技術應用和機制設計，保證票據應用記錄的不可篡改；
b) 鏈下票據數據庫不可篡改，即通過智能合約技術，實現票據數據庫鏈上鏈下的實時映射與比對，保證鏈下數據庫的票據記錄的正確性與完整性。
9 性能要求
9.1 業務應用
應符合如下要求：
a) 支持的電子票據容量應不小于20億；
b) 并發性能不小于3000吞吐量；
c) 票據上鏈服務響應時間不大于3秒；
9.2 業務連續性
應符合如下要求：
a) 應確保區塊鏈財政電子票據系統可用率不低于99.999%；
b) 應實現對區塊鏈財政電子票據系統及應用的全面監控，即監控覆蓋率達到100%。
9.3 平臺高可用
平臺高可用相關要求如下：
a) 宜支持異地多活技術，不同城市建立獨立的數據中心，接入高可用架構;
b) 宜實現相距大于150公里的異地多數據中心架構；
c) 宜確保任何單機、單機房或單個城市故障，都不會停止服務，即系統恢復時間（RTO）為0；
d) 宜確保數據恢復時間（RPO）不高于60秒；
e) 宜確保業務功能恢復時間不高于30分鐘。
附 錄 A
（資料性附錄）
區塊鏈電子票據系統部署方式
區塊鏈電子票據系統部署可分為三種模式：
A.1 專網部署方式
區塊鏈電子票據核心系統部署在財政專網內，通過白名單、數字證書、簽名密鑰的方式向外部需求方提供服務。
A.2 互聯網部署方式
區塊鏈電子票據核心系統部署在互聯網并提供RESTful服務，外部機構單位可以訪問區塊鏈電子票據系統，提交開票、換開、沖紅、用票流轉等業務。
A.3 專網-互聯網互通方式
區塊鏈電子票據系統通常包括前端執收機構管理、RESTful服務、業務中臺、區塊鏈組網節點、業務數據庫等部分組成。前端執收機構管理、RESTful服務、業務中臺 實現了互聯網、財政專網的互通。
參 考 文 獻
[1] 財綜[2017]32號 財政部關于印發《關于穩步推進財政電子票據管理改革的試點方案》的通知
[2] 中華人民共和國財政部令第104號--財政部關于修改《財政票據管理辦法》的決定
[3] 網信辦[2019]3號 《區塊鏈信息服務管理規定》
