電子發票核心元數據構成與捕獲研究

張雅君 李澤鋒

摘要：本文依據新修訂的《會計檔案管理辦法》，《文書類電子文件元數據方案》等檔案行業標準，引入全生命周期管理思想，以電子發票的電子屬性與電子簽名等構成其核心元數據，提出捕獲前應實施嚴格的前端控制，捕獲中采取系統自動捕獲與嵌入兩種方式。

關鍵詞：電子發票核心元數據捕獲

電子發票作為電子會計資料中一個重要的支付憑證，必將歸檔作為電子會計檔案進行保存，但存在著歸檔后的真實性保障問題。本文依據新修訂的《會計檔案管理辦法》、財政部《財政電子票據管理基本流程》、《文書類電子文件元數據方案》（DA/T 46-2009）等，引入全生命周期的管理思想，將財政部門、開票單位、繳款單位三方對電子發票的管理通過元數據建立有機聯系，研究電子發票核心元數據的構成，提出核心元數據的捕獲策略。

一、電子發票生成流程

電子發票從制樣開始，經歷賦碼、開具、傳輸查驗、入賬和歸檔等流程環節，有財政部門、開票單位、繳款單位三方參與其中，都需要對電子發票進行歸檔與管理。其中，財政部門歸檔作為備查依據，開票單位歸檔作為記賬依據，繳款單位歸檔作為報銷憑據。也就是說，同一份電子發票應在三個機構進行歸檔，需要“分別按照《會計檔案管理辦法》的有關規定進行歸檔，形成符合長期保管要求的電子會計檔案”。[1]

二、電子發票核心元數據構成

元數據管理有助于保證電子文件的真實性、完整性、可靠性、可用性，保障電子文件的證據特性，這一觀點已是學界的共識。新《會計檔案管理辦法》第十二條規定，“電子會計檔案移交時應當將電子會計檔案及其元數據一并移交，且文件格式應當符合國家檔案管理的有關規定”。[2]

（一）電子發票核心元數據構成

目前，電子會計檔案元數據方案尚未制定，按照《電子文件歸檔與電子檔案管理規范》（GB/T 18894-2016）規定，專業類電子文件元數據的歸檔范圍可以參照《文書類電子文件元數據方案》（DA/T 46-2009，以下簡稱《方案》）執行。

《方案》中許多元數據在紙質檔案管理中有了成熟的獲取與管理經驗，如《方案》中M21-M39關于題名、主題詞等的元數據，M76-M79關于機構/人員的元數據，M80-M83關于業務行為的元數據等，和紙質檔案的著錄有相通之處。還有一些元數據是電子文件所特有，對電子文件的真實性、長期可讀性有著至關重要的作用，如電子屬性（M46-M51）、數字化屬性（M52-M56）、電子簽名（M57-M64）等。從長期保存視角，本文定義這些電子文件所特有的元數據為核心元數據。

由于數字化屬性元數據是當電子文件由掃描或縮微影像轉換形成時才是必選元數據，而電子發票是原生性電子文件，因此將電子屬性、電子簽名兩方面的元數據作為電子發票的核心元數據。

（二）確定核心元數據中的各子元素

《方案》中，電子屬性與電子簽名是容器型元數據，包含若干個元數據。[3]

1.電子屬性

《方案》中電子屬性包括格式信息、計算機文件名、計算機文件大小、文檔創建程序與信息系統描述五個子元素。電子發票所選用的文件格式應該滿足行業標準《版式電子文件長期保存格式需求》（DA/T 47-2009）的要求，目前主要使用有國家標準支撐的PDF/ A-1格式，《方案》中的“文檔創建程序”“信息系統描述”這兩個元數據就沒有必要作為電子發票的元數據再加以著錄。

因此，電子發票元數據的電子屬性元數據可以保留格式信息、計算機文件名、計算機文件大小三個元數據。

2.電子簽名

《方案》中編號M57的“電子簽名”含7個子元素：簽名規則、簽名時間、簽名人、簽名結果、證書、證書引證、簽名算法標識。

電子簽名一般由CA認證中心頒發，其對每一個頒發出的電子簽名有其相應的記錄，并歸檔保存。對于電子簽名元數據來說，把電子簽名涉及技術相關的內容交由認證中心來保障，電子文件元數據只記錄電子簽名使用的過程，在檔案實際工作中更容易操作，更有利于檔案人員對元數據的著錄與捕獲。按照該思路，《方案》中“簽名規則”“簽名算法標識”可由CA認證中心進行保障，將“證書”分為“證書頒發者”、“證書編號（在認證中心的唯一編號）”，電子文件通過這兩個元數據建立與CA認證中心的聯系，進一步提供“簽名規則”、“簽名算法標識”元數據。《方案》中“證書引證”用于指向驗證簽名證書的鏈接，由于建立了與CA認證中心的聯系，該元數據也可不用。因此，電子簽名元數據所包含的子元素應有簽名證書頒發者、簽名證書編號、簽名人、簽名時間。

按照財政電子票據基本流程，電子發票開票單位開具生成含有單位簽名的票據信息后，通過系統自動上傳到財政端，以追加財政監制簽名，制作生成完整的財政電子票據，即電子發票有兩個電子簽名。

因此完整的電子發票電子簽名元數據包括證書頒發者、簽名證書編號、簽名人、簽名時間、簽名原文引用、簽名值。其中，簽名原文有兩類：開票單位電子簽名原文與財政部門監制電子簽名原文。前者包括財政電子票據頭部、財政電子票據票面信息，后者包括開票單位電子簽名原文的Hash值、開票單位電子簽名。

三、核心元數據的捕獲

（一）捕獲前核心元數據的前端控制

在電子發票全生命周期過程中，要特別關注核心元數據捕獲的及時性。一旦前一階段忽略了相應元數據的著錄，后面階段將很難再彌補。

電子簽名元數據所包含的子元素是電子發票真實性的重要保障，《方案》專門對其信息來源進行了描述，“由形成、處理、管理電子文件的系統捕獲或手工著錄”，實際上，在發票生成階段如果沒有著錄該元數據值，歸檔后基本不可能再進行補錄。對于電子屬性元數據，一般來說在文件歸檔后很難再進行捕獲或手工著錄，即使著錄也會出現著錄不全的問題?？紤]到電子發票的特殊性，其格式較為固定，歸檔后可以補錄，但歸檔時涉及電子票證較多，最好還是由前端進行記錄，歸檔時進行捕獲。

從以上分析可以看出，電子發票長期保存所需的核心元數據大多在其形成階段生成，電子發票管理系統應當在電子發票生成過程中，實施嚴格的前端控制，將核心元數據如實記錄并保存在管理系統中。考慮到核心元數據的技術特性，人工著錄困難，其記錄與保存應該由系統自動完成，可以保證元數據的完整齊全、真實可信。這就要求發票管理系統（含財政端和單位端）應具有電子文件管理的特定功能，真正實現前端控制。

（二）核心元數據的捕獲方式

1.系統自動捕獲

該方式主要是針對財政部門與具有接口的開票單位，實現財政部門歸檔作為備查依據、開票單位歸檔作為記賬依據。這些單位可較好實現電子發票管理系統與檔案管理系統的對接，核心元數據由系統自動生成、捕獲，并通過捕獲接口將電子發票及其相關元數據連同其他相關電子會計檔案一起歸檔到檔案管理系統中，該捕獲接口應包含捕獲的時機、動作、范圍、封裝等內容[4]。

該方式可以實現電子發票及其元數據的實時捕獲，電子發票一旦在管理系統中生成，其相應元數據同時生成，這時不論其是否辦理完畢，均按照既定要求進行捕獲。更進一步的是，在設計電子發票管理系統功能時，將電子發票的歸檔范圍和歸檔要求設計在發票管理系統之中，屬于該范圍的電子發票一經生成就被加上歸檔標識，自動生成并捕獲相應核心元數據，使之具有防止非法修改和刪除的屬性，確保其安全留存和內容真實。通過指針、鏈接等方式在核心元數據和發票文件之間建立聯系，并始終維護其關聯，從而真正滿足《電子文件管理系統通用功能要求》（GB/T 29194-2012）的要求。

2.嵌入到電子發票中

該方式主要針對于使用生成系統單位端或第三方服務公司開具電子發票的開票單位與繳款單位。其特征是單位難以與發票管理系統建立接口，不能實現元數據的實時捕獲，由于電子發票已脫離了管理系統，就需要采用嵌入方式將核心元數據嵌入到電子發票中，以滿足前端控制。

按照《電子檔案管理基本術語》（DA/T 58-2014），嵌入是指“將元數據內嵌于電子檔案的過程”。電子發票是一個標準的版式電子文件，完全可以通過設置規范的元數據，以XML方式內嵌入電子發票中，用于描述其屬性特征。實際上，電子簽名的頒發者、使用者、序列號、哈希算法等均已嵌入到了電子發票中，成為電子發票計算機文件的有機組成部分。嵌入的信息并不是都成為核心元數據，應按照前述分析挑選相應信息作為元數據。這種方式下，檔案管理系統應具有從電子發票中提取核心元數據的功能。

*本文系河南省教育廳人文社科研究一般項目“新《會計檔案管理辦法》下的電子發票歸檔保存研究”（2017-ZZJH-559）的成果之一。

參考文獻：

[1]中華人民共和國財政部.財政電子票據管理基本流程[Z].2017.6.

[2]中華人民共和國財政部，國家檔案局.會計檔案管理辦法[Z].2015.12.

[3]國家檔案局.DA/T 46-2009文書類電子文件元數據方案[S].

[4]李澤鋒，于紅焱.全生命周期管理中電子文件捕獲工作實現研究[J].北京檔案，2017.5.