這裡將詳細地對示例性實施例進行說明，其示例表示在圖式中。下面的描述涉及圖式時，除非另有表示，不同圖式中的相同數字表示相同或相似的要素。以下示例性實施例中所描述的實施方式並不代表與本說明書一個或多個實施例相一致的所有實施方式。相反，它們僅是與如所附申請專利範圍中所詳述的、本說明書一個或多個實施例的一些方面相一致的裝置和方法的例子。
需要說明的是：在其他實施例中並不一定按照本說明書示出和描述的順序來執行相應方法的步驟。在一些其他實施例中，其方法所包括的步驟可以比本說明書所描述的更多或更少。此外，本說明書中所描述的單個步驟，在其他實施例中可能被分解為多個步驟進行描述；而本說明書中所描述的多個步驟，在其他實施例中也可能被合併為單個步驟進行描述。
圖1是一示例性實施例提供的一種基於區塊鏈的發票報銷方法的流程圖。如圖1所示，該方法應用於區塊鏈節點，可以包括以下步驟：
步驟102，接收用戶透過用戶端發起的針對在所述區塊鏈中存證的目標發票的發票報銷請求。
在一實施例中，用戶端可以為用戶(用戶為報銷請求方)使用的手機、平板電腦、PC等任意類型的電子設備，本說明書並不對此進行限制。用戶透過在電子設備上登錄已註冊帳號，可與接入該電子設備的區塊鏈節點進行互動。
在一實施例中，用戶可透過用戶端向區塊鏈節點提交發票記錄請求(包含發票內容)以使得該區塊鏈節點將該發票內容存證至區塊鏈上，進而在用戶存在針對目標發票的報銷需求時，透過用戶端發起發票報銷請求以使得區塊鏈節點對目標發票進行報銷處理。
在一實施例中，用戶在完成一筆交易後，可透過用戶端向區塊鏈節點發送記錄請求以使得該區塊鏈節點將該交易的交易資訊發佈至區塊鏈。例如，交易資訊可以包括交易標識、交易平台、交易金額、交易內容、交易參與方、交易時間等。當然，本說明書並不對交易資訊的具體內容進行限制。進一步的，用戶可透過用戶端向區塊鏈節點提交發票創建請求，以使得區塊鏈節點調用智慧合約中聲明的發票創建邏輯，根據儲存的交易內容創建相應的發票，並將創建的發票存證在區塊鏈上。那麼，當用戶存在針對目標發票的報銷需求時，可透過用戶端發起發票報銷請求以使得區塊鏈節點對目標發票進行報銷處理。
透過將發票發佈至區塊鏈，使得各個區塊鏈節點均記錄有一份完整的發票，那麼即使某個節點出現資料損壞的問題，也不會影響整體的資料完整性；同時，可充分利用區塊鏈儲存資料的不可篡改性，從而防止不法分子惡意修改發票的內容，保證了發票的安全和透明。而基於發票在鏈上的存證，當區塊鏈節點接收到針對目標發票的發票報銷請求時，可調用智慧合約中聲明的發票報銷邏輯，為目標發票進行報銷處理，從而實現基於區塊鏈的發票報銷方案。
步驟104，回應於所述發票報銷請求，判定所述目標發票的發票狀態。
在一實施例中，區塊鏈節點在將發票存證至區塊鏈時，可關聯存證發票的發票狀態(可以包括未報銷狀態、已報銷狀態和已鎖定狀態)。其中，在關聯存證發票的發票狀態時，可預設將發票設置為未報銷狀態；而在判定出需要對發票進行報銷處理時，可先將發票由未報銷狀態更新為已鎖定狀態以防止對發票的重複報銷(例如，在接收到針對某一發票的發票報銷請求時，若該發票已經是已鎖定狀態，則說明在之前已接收到針對該發票的發票報銷請求；為了防止重複報銷，可直接返回報銷失敗的提示消息)；在對發票進行報銷處理且報銷成功後，可將發票更新為已報銷狀態。
在一實施例中，可透過存證發票標識與發票狀態的映射關係來關聯存證發票的發票狀態。換言之，區塊鏈中存證了發票標識與發票狀態的映射關係，而基於發票報銷請求中包括目標發票的標識資訊，可透過以下方式判定目標發票的發票狀態：回應於所述發票報銷請求，調用發佈在區塊鏈上的智慧合約中聲明的發票查詢邏輯，查詢所述區塊鏈上是否存證了與所述發票報銷請求中的所述目標發票的標識資訊對應的目標發票；如果是，進一步基於所述發票報銷請求中的所述目標發票的標識資訊查詢所述映射關係，判定所述目標發票的發票狀態。其中，發票標識為針對發票內容，或者發票內容中的唯一性資訊進行hash計算得到的hash值。例如，唯一性資訊可以包括：發票號碼、發票代碼、發票日期、不含稅金額等資訊。當然，本說明書並不對發票內容以及發票內容中唯一性資訊的具體形式進行限制。
需要說明的是，上述查詢區塊鏈上是否存證有目標發票的操作以及基於映射關係判定發票狀態的操作，還可由區塊鏈節點自身執行，本說明書並不對此進行限制。
步驟106，如果所述目標發票的發票狀態為未報銷狀態，調用發佈在區塊鏈上的智慧合約中聲明的發票報銷邏輯，針對所述目標發票進行報銷處理，並在報銷成功後將所述目標發票更新為已報銷狀態。
在一實施例中，用戶可透過用戶端填入報銷單據標識(發票報銷請求中包括報銷單據標識)，進而使得區塊鏈節點基於與該報銷單據標識對應的報銷單據對目標發票進行報銷處理。而為了防止重複報銷，在對目標發票進行報銷處理之前，可調用發佈在區塊鏈上的智慧合約中聲明的發票鎖定邏輯，保存報銷單據標識與目標發票的綁定關係，並在保存綁定關係後將目標發票的發票狀態由未報銷狀態更新為已鎖定狀態。其中，在目標發票與任一報銷單據標識綁定且被更新為已鎖定狀態後，區塊鏈節點僅能夠基於對應於該任一報銷單據標識的報銷單據對目標發票進行報銷處理。進一步的，在將目標發票的發票狀態由未報銷狀態更新為已鎖定狀態後，可調用發佈在區塊鏈上的智慧合約中聲明的發票報銷邏輯，針對目標發票進行報銷處理。
在一實施例中，如果判定出目標發票的發票狀態為已報銷狀態或者已鎖定狀態，向用戶端返回報銷失敗的提示資訊。其中，當發票狀態為已報銷狀態時，返回的報銷失敗的提示資訊可以是用於提示用戶目標發票已被報銷；當發票狀態為已鎖定狀態時，返回的報銷失敗的提示資訊可以是用於提示用戶目標發票已被鎖定(即無法進行報銷處理)。
在一實施例中，當用戶透過用戶端提交發票報銷請求使得目標發票被鎖定後，只有該用戶具有解除目標發票處於已鎖定狀態的權限。那麼，當用戶透過用戶端提交發票報銷請求以請求對目標發票進行報銷處理但報銷失敗後(例如，不在設定的報銷期限內、報銷金額超出額度等)，由於目標發票處於已鎖定狀態(與報銷單據標識綁定)，若該用戶需重新請求對目標發票進行報銷處理(例如，調整在設定的報銷期限內、調整報銷金額等)，則需要先對目標發票進行解鎖處理。因此，區塊鏈節點可接收用戶在目標發票報銷失敗後透過用戶端發起的針對目標發票的解鎖請求，以及回應於該解鎖請求，調用發佈在區塊鏈上的智慧合約中聲明的發票解鎖邏輯，判定解鎖請求的發送方是否為發票報銷請求的發送方(即判定解鎖請求的發送方是否具有解鎖的權限)；如果是，刪除報銷單據標識與目標發票的綁定關係，將目標發票的發票狀態由已鎖定狀態更新為未報銷狀態，並向用戶端返回解鎖成功的提示資訊。進一步的，在對目標發票成功進行解鎖後，該用戶可透過用戶端再次提交發票報銷請求(包括其他報銷單據標識)以對目標發票進行報銷處理。
在一實施例中，上述區塊鏈可以為聯盟鏈，聯盟鏈的節點成員可以包括支付平台、稅務機關等。
需要說明的是，區塊鏈中的交易，存在狹義的交易以及廣義的交易之分。狹義的交易是指用戶向區塊鏈發佈的一筆價值轉移；例如，在傳統的比特幣區塊鏈網路中，交易可以是用戶在區塊鏈中發起的一筆轉帳。而廣義的交易是指用戶向區塊鏈發佈的一筆具有業務意圖的業務資料；例如，運營方可以基於實際的業務需求搭建一個聯盟鏈，依託於聯盟鏈部署一些與價值轉移無關的其它類型的線上業務(比如，租房業務、車輛調度業務、保險理賠業務、信用服務、醫療服務等)，而在這類聯盟鏈中，交易可以是用戶在聯盟鏈中發佈的一筆具有業務意圖的業務消息或者業務請求。
圖2是一示例性實施例提供的一種發票報銷方案的整體架構示意圖。如圖2所示，報銷請求方可在用戶端21中輸入目標發票的發票內容，用戶端21基於用戶輸入的發票內容向伺服器22發送發票報銷請求；而伺服器22(作為區塊鏈節點)在接收到發票報銷請求後判定區塊鏈中存證的目標發票的發票狀態，進而在目標發票的發票狀態為未報銷狀態時對目標發票進行報銷處理，並在報銷成功後將目標發票更新為已報銷狀態。
為了便於理解，下面針對用戶端21、伺服器22分別在發票報銷過程中實現的操作和功能，結合圖3-6對本說明書的發票報銷方案進行詳細說明。圖3是一示例性實施例提供的一種發票上鏈的互動示意圖。如圖3所示，該互動過程可以包括以下步驟：
步驟302，用戶端21與伺服器22之間實現對綁定關係的建立。
在一實施例中，所需建立的綁定關係為用戶的身份資訊與用戶端21的設備資訊之間的綁定關係。基於該綁定關係，使得伺服器22在接收到用戶端21後續發送的發票記錄請求、發票創建請求和發票報銷請求時，可以確認這些請求對應於該用戶。
舉例而言，用戶可以預先在伺服器22處進行帳號註冊，得到與自身唯一對應的已註冊帳號。然後，用戶可以透過在用戶端21上登錄該已註冊帳號，而伺服器22基於該已註冊帳號在用戶端21上的登錄資訊，判定該已註冊帳號(對應於該用戶)與用戶端21之間建立了綁定關係。
步驟304，用戶端21獲取待記錄的發票。
在一實施例中，用戶在完成一筆交易並開具發票後，可透過用戶端21輸入發票內容，用戶端21進而向伺服器22提交發票記錄請求(包含發票內容)，以使得伺服器22將待記錄的發票發佈至區塊鏈中。其中，用戶可以預先註冊得到唯一對應的數位身份，該數位身份由一組公私鑰對進行表徵。相應地，用戶端21在獲取到用戶輸入的發票內容後，可產生發票記錄請求並透過對應於該用戶的數位身份的私鑰對發票記錄請求進行簽名。
步驟306，用戶端21向伺服器22提交發票記錄請求。
步驟308，伺服器22驗證簽名。
在一實施例中，伺服器22上運行有區塊鏈的用戶端，使得該伺服器22被配置為一區塊鏈節點。伺服器22在接收到發票記錄請求後，可基於上述步驟302建立的綁定關係判定出用戶的身份，從而透過對應於該用戶的公鑰進行驗簽，以判定該發票記錄請求已由該用戶進行授權，而並非由不法分子冒充該用戶的身份進行發送。
步驟310，伺服器22將發票發佈至區塊鏈。
步驟312，伺服器22將發票標記為未報銷狀態。
在一實施例中，伺服器22可透過調用智慧合約中聲明的映射建立邏輯，根據發票內容中的唯一性資訊(發票號碼、發票代碼、發票日期、不含稅金額等資訊)進行hash計算得到相應的hash值(作為發票標識)，並建立各發票的hash值與發票狀態的映射關係。其中，可將發佈至區塊鏈的發票默認設定為未報銷狀態。
請參見圖4，圖4是一示例性實施例提供的另一種發票上鏈的互動示意圖。如圖4所示，該互動過程可以包括以下步驟：
步驟402，用戶端21與伺服器22之間實現對綁定關係的建立。
步驟404，用戶端21獲取待記錄的交易資訊。
在一實施例中，用戶在完成一筆交易後，可透過用戶端21輸入交易資訊，用戶端21進而向伺服器22提交交易記錄請求(包含交易資訊)，以使得伺服器22將待記錄的交易發佈至區塊鏈中。
步驟406，用戶端21向伺服器22提交交易記錄請求。
步驟408，伺服器22驗證簽名。
在一實施例中，用戶端21對交易記錄請求進行簽名，以及伺服器22驗證簽名的原理與上述類似，在此不再贅述。
步驟410，伺服器22將交易資訊發佈至區塊鏈。
步驟412，用戶端21向伺服器22提交發票創建請求。
在一實施例中，當用戶需要針對某一交易開具發票時，可透過用戶端21向伺服器22提交針對該交易的發票創建請求，以使得伺服器22調用智慧合約中聲明的發票創建邏輯為該交易創建發票。其中，發票創建請求中可以包括交易標識和用戶透過用戶端輸入的發票創建資訊。
步驟414，伺服器22驗證簽名。
步驟416，伺服器22調用智慧合約中聲明的發票創建邏輯，根據發票創建資訊創建發票並將創建的發票發佈至區塊鏈。
在一實施例中，該智慧合約可由支付機構和稅務機關預先部署於區塊鏈。
在一實施例中，用戶輸入的發票創建資訊可以包括發票的抬頭資訊和交易資訊，伺服器22在接收到發票創建請求後將發票創建資訊中包含的交易資訊與區塊鏈上存證的交易資訊(與交易標識相對應)進行對比，當對比結果為兩者一致時，直接根據發票創建資訊中包含的交易資訊和抬頭資訊創建發票。例如，伺服器22在接收到針對目標交易的發票創建請求後，讀取發票創建資訊中包含的交易資訊並計算得到第一雜湊值，將該第一雜湊值與區塊鏈上存證的交易資訊(與交易標識相對應)的第二雜湊值進行對比，當第一雜湊值與第二雜湊值相等時，可判定用戶輸入的交易資訊即為目標交易的交易資訊，那麼可直接根據用戶輸入的交易資訊和抬頭資訊為目標交易創建發票，而無需讀取區塊鏈上存證的目標交易的交易資訊，從而提高創建發票的效率。
步驟418，伺服器22將發票標記為未報銷狀態。
在一實施例中，伺服器22可透過調用智慧合約中聲明的映射建立邏輯，根據發票內容中的唯一性資訊(發票號碼、發票代碼、發票日期、不含稅金額等資訊)進行hash計算得到相應的hash值(作為發票標識)，並建立各發票的hash值與發票狀態的映射關係。其中，可將發佈至區塊鏈的發票默認設定為未報銷狀態。
基於將發票發佈至區塊鏈，用戶可進一步針對目標發票請求進行報銷處理。請參見圖5，圖5是一示例性實施例提供的基於區塊鏈的另一種發票報銷方法的流程圖。如圖5所示，該方法應用於區塊鏈節點(以伺服器22為例)，可以包括以下步驟：
步驟502，接收用戶透過用戶端21發起的針對在區塊鏈中存證的目標發票的發票報銷請求。
在一實施例中，發票報銷請求中包括目標發票的發票內容，或者為用戶端根據用戶輸入的發票內容中的唯一性資訊(發票號碼、發票代碼、發票日期、不含稅金額等資訊)進行hash計算得到的hash值，以及報銷單據標識。
步驟504，獲取目標發票的發票標識。
在一實施例中，當發票報銷請求中記錄的是目標發票的發票內容時，讀取發票內容中的唯一性資訊進行hash計算以得到目標發票的發票標識；當發票報銷請求中記錄有目標發票的發票標識(用戶端根據用戶輸入的發票內容中的唯一性資訊進行hash計算得到的hash值)時，直接讀取該發票標識即可。
步驟506，若區塊鏈上存證了與獲取到發票標識對應的目標發票，則轉入步驟510；否則轉入步驟508。
在一實施例中，可調用發佈在區塊鏈上的智慧合約中聲明的發票查詢邏輯，查詢區塊鏈上是否存證了與獲取到發票標識對應的目標發票。當然，也可以由伺服器22自身來執行上述查詢目標發票的操作，本說明書並不對此進行限制。
步驟508，向用戶端21返回發票不存在的提示消息。
步驟510，根據區塊鏈上存證的發票標識與發票狀態的映射關係，判定對應於獲取到的發票標識的發票狀態。
舉例而言，假定區塊鏈上存證的映射關係如表1所示： 發票標識(hash值) 發票狀態
發票a 未報銷狀態
發票b 已鎖定狀態(發票b與報銷單據標識b綁定)
發票c 已報銷狀態
…… ……
表1
步驟512，若發票狀態為未報銷狀態，則轉入步驟514；否則，轉入步驟526。
步驟514，調用發佈在區塊鏈上的智慧合約中聲明的發票鎖定邏輯，保存報銷單據標識與目標發票的綁定關係，並在保存該綁定關係後，將目標發票的發票狀態由未報銷狀態更新為已鎖定狀態。
以發票a為例，承接於上述舉例，區塊鏈上存證的映射關係如表2所示： 發票標識(hash值) 發票狀態
發票a 已鎖定狀態(發票a與報銷單據標識a綁定)
發票b 已鎖定狀態(發票b與報銷單據標識b綁定)
發票c 已報銷狀態
…… ……
表2
步驟516，若目標發票為已鎖定狀態，則轉入步驟520；否則，轉入步驟518。
步驟518，向用戶端返回鎖定失敗的提示資訊。
在一實施例中，當透過步驟514執行鎖定目標發票的操作後，可能出現鎖定失敗的情況(需要說明的是，該情況區別於發票在之前已經被鎖定的情況；例如，伺服器22因被佔用過多處理資源導致已無法再繼續調用智慧合約)，因此，在應當執行鎖定操作(此時目標發票為未報銷狀態)而執行的結果為鎖定失敗時，可向用戶端21返回鎖定失敗的提示資訊。那麼用戶在用戶端21側接收到該提示消息後，可後續再重新提交針對目標發票的發票報銷請求。
步驟520，在將目標發票的發票狀態由未報銷狀態更新為已鎖定狀態後，調用區塊鏈上的智慧合約中聲明的發票報銷邏輯，針對目標發票進行報銷處理。
步驟522，若報銷成功，則轉入步驟524；否則，轉入步驟526。
步驟524，在報銷成功後將目標發票由已鎖定狀態更新為已報銷狀態。
步驟526，向用戶端21返回報銷失敗的提示資訊。
在一實施例中，承接於步驟512，當目標發票為已鎖定狀態時，說明在(步驟502)之前已接收到針對目標發票的發票報銷請求；因此，為了防止重複報銷，可直接返回用於提示用戶目標發票已被鎖定的提示消息。當發票狀態為已報銷狀態時，可返回用於提示用戶目標發票已被報銷的提示消息。
在一實施例中，承接於步驟522，在對目標發票進行報銷處理時，可能出現報銷失敗的情況。例如，不在設定的報銷期限內、報銷金額超出額度等。因此，當報銷失敗後，可返回用於提示用戶目標發票報銷失敗的提示消息(可具體標明報銷失敗的原因)。
在一實施例中，當用戶透過用戶端提交發票報銷請求使得目標發票被鎖定後，只有該用戶具有解除目標發票處於已鎖定狀態的權限。那麼，當用戶透過用戶端提交發票報銷請求以請求對目標發票進行報銷處理但報銷失敗後(例如，不在設定的報銷期限內、報銷金額超出額度等)，由於目標發票處於已鎖定狀態(與報銷單據標識綁定)，若該用戶需重新請求對目標發票進行報銷處理(例如，調整在設定的報銷期限內、調整報銷金額不超過額度等)，則需要先對目標發票進行解鎖處理。下面結合圖6進行詳細說明。
請參見圖6，圖6是一示例性實施例提供的解鎖發票的流程圖。如圖6所示，該方法應用於區塊鏈節點(以伺服器22為例)，可以包括以下步驟：
步驟602，接收用戶在目標發票報銷失敗後透過用戶端發起的針對目標發票的解鎖請求。
步驟604，若該用戶具有解鎖的權限，轉入步驟606；否則，轉入步驟610。
在一實施例中，可調用發佈在區塊鏈上的智慧合約中聲明的發票解鎖邏輯，判定解鎖請求的發送方是否為發票報銷請求的發送方；如果是，刪除報銷單據標識與目標發票的綁定關係，將目標發票的發票狀態由已鎖定狀態更新為未報銷狀態，並向用戶端21返回解鎖成功的提示資訊。那麼，在對目標發票成功進行解鎖後，該用戶可透過用戶端再次提交發票報銷請求(包括其他報銷單據標識)以對目標發票進行報銷處理。其中，可採用上述步驟302中用戶註冊得到的帳號來判定解鎖請求的發送方是否為發票報銷請求的發送方，還可以採用步驟306-308中驗簽的方式。當然，本說明書並不對此進行限制。
步驟606，刪除報銷單據標識與目標發票的綁定關係，將目標發票的發票狀態由已鎖定狀態更新為未報銷狀態。
以解鎖發票a為例，承接於上述舉例，映射關係更新為如表3所示： 發票標識(hash值) 發票狀態
發票a 未報銷狀態
發票b 已鎖定狀態(發票b與報銷單據標識b綁定)
發票c 已報銷狀態
…… ……
表3
步驟608，向用戶端21返回解鎖成功的提示資訊。
步驟610，當用戶不具有解鎖的權限時，向用戶端21返回解鎖失敗的提示資訊。
圖7是一示例性實施例提供的一種設備的示意結構圖。請參考圖7，在硬體層面，該設備包括處理器702、內部匯流排704、網路介面707、記憶體708以及非揮發性記憶體710，當然還可能包括其他業務所需要的硬體。處理器702從非揮發性記憶體710中讀取對應的電腦程式到記憶體708中然後運行，在邏輯層面上形成基於區塊鏈的發票報銷裝置。當然，除了軟體實現方式之外，本說明書一個或多個實施例並不排除其他實現方式，比如邏輯裝置抑或軟硬體結合的方式等等，也就是說以下處理流程的執行主體並不限定於各個邏輯單元，也可以是硬體或邏輯裝置。
請參考圖8，在軟體實施方式中，該基於區塊鏈的發票報銷裝置可以包括：
報銷接收單元81，接收用戶透過用戶端發起的針對在所述區塊鏈中存證的目標發票的發票報銷請求；
狀態判定單元82，回應於所述發票報銷請求，判定所述目標發票的發票狀態；
報銷單元83，如果所述目標發票的發票狀態為未報銷狀態，調用發佈在區塊鏈上的智慧合約中聲明的發票報銷邏輯，針對所述目標發票進行報銷處理，並在報銷成功後將所述目標發票更新為已報銷狀態。
可選的，所述區塊鏈中存證了發票標識與發票狀態的映射關係；所述發票報銷請求中包括所述目標發票的標識資訊；
所述狀態判定單元82具體用於：
回應於所述發票報銷請求，調用發佈在區塊鏈上的智慧合約中聲明的發票查詢邏輯，查詢所述區塊鏈上是否存證了與所述發票報銷請求中的所述目標發票的標識資訊對應的目標發票；
如果是，進一步基於所述發票報銷請求中的所述目標發票的標識資訊查詢所述映射關係，判定所述目標發票的發票狀態。
可選的，所述發票標識為針對發票內容，或者發票內容中的唯一性資訊進行hash計算得到的hash值。
可選的，所述發票報銷請求包括報銷單據標識；
在調用發佈在區塊鏈上的智慧合約中聲明的發票報銷邏輯，針對所述目標發票進行報銷處理之前，還包括：
鎖定單元84，調用發佈在區塊鏈上的智慧合約中聲明的發票鎖定邏輯，保存所述報銷單據標識與所述目標發票的綁定關係，並在保存所述綁定關係後，將所述目標發票的發票狀態由未報銷狀態更新為已鎖定狀態；
所述報銷單元83具體用於：在將所述目標發票的發票狀態由未報銷狀態更新為已鎖定狀態後，調用所述發票報銷邏輯，針對所述目標發票進行報銷處理。
可選的，還包括：
提示單元85，如果所述目標發票的發票狀態為已報銷狀態或者已鎖定狀態，向所述用戶端返回報銷失敗的提示資訊。
可選的，還包括：
解鎖接收單元86，接收用戶在所述目標發票報銷失敗後透過用戶端發起的針對所述目標發票的解鎖請求；
鑒權單元87，回應於所述解鎖請求，調用發佈在區塊鏈上的智慧合約中聲明的發票解鎖邏輯，判定所述解鎖請求的發送方是否為所述發票報銷請求的發送方；
解鎖單元88，如果是，刪除所述報銷單據標識與所述目標發票的綁定關係，將所述目標發票的發票狀態由已鎖定狀態更新為未報銷狀態，並向所述用戶端返回解鎖成功的提示資訊。
上述實施例闡明的系統、裝置、模組或單元，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦，電腦的具體形式可以是個人電腦、膝上型電腦、蜂巢式電話、相機電話、智慧型電話、個人數位助理、媒體播放機、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任意幾種設備的組合。
在一個典型的配置中，電腦包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。
記憶體可能包括電腦可讀介質中的非永久性記憶體，隨機存取記憶體(RAM)和/或非揮發性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀介質的示例。
電腦可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存介質的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可程式設計唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶、磁片儲存、量子記憶體、基於石墨烯的儲存介質或其他磁性儲存設備或任何其他非傳輸介質，可用於儲存可以被計算設備訪問的資訊。按照本文中的界定，電腦可讀介質不包括暫存電腦可讀媒體(transitory media)，如調製的資料信號和載波。
還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。
上述對本說明書特定實施例進行了描述。其它實施例在所附申請專利範圍的範圍內。在一些情況下，在申請專利範圍中記載的動作或步驟可以按照不同於實施例中的順序來執行並且仍然可以實現期望的結果。另外，在圖式中描繪的過程不一定要求示出的特定順序或者連續順序才能實現期望的結果。在某些實施方式中，多工處理和並行處理也是可以的或者可能是有利的。
在本說明書一個或多個實施例使用的術語是僅僅出於描述特定實施例的目的，而非旨在限制本說明書一個或多個實施例。在本說明書一個或多個實施例和所附申請專利範圍中所使用的單數形式的“一種”、“所述”和“該”也旨在包括多數形式，除非上下文清楚地表示其他含義。還應當理解，本文中使用的術語“和/或”是指並包含一個或多個相關聯的列出專案的任何或所有可能組合。
應當理解，儘管在本說明書一個或多個實施例可能採用術語第一、第二、第三等來描述各種資訊，但這些資訊不應限於這些術語。這些術語僅用來將同一類型的資訊彼此區分開。例如，在不脫離本說明書一個或多個實施例範圍的情況下，第一資訊也可以被稱為第二資訊，類似地，第二資訊也可以被稱為第一資訊。取決於語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當……時”或“回應於判定”。
以上所述僅為本說明書一個或多個實施例的較佳實施例而已，並不用以限制本說明書一個或多個實施例，凡在本說明書一個或多個實施例的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本說明書一個或多個實施例保護的範圍之內。The exemplary embodiments will be described in detail here, and examples thereof are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings indicate the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with one or more embodiments of this specification. On the contrary, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of the present specification as detailed in the scope of the appended application. It should be noted that in other embodiments, the steps of the corresponding method may not be executed in the order shown and described in this specification. In some other embodiments, the method includes more or fewer steps than described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description. Fig. 1 is a flowchart of a blockchain-based invoice reimbursement method provided by an exemplary embodiment. As shown in Fig. 1, the method is applied to a blockchain node and may include the following steps: Step 102: Receive an invoice reimbursement request for a target invoice deposited in the blockchain and initiated by a user through a user terminal. In an embodiment, the user terminal may be any type of electronic device such as a mobile phone, a tablet computer, and a PC used by the user (the user is the reimbursement requester), which is not limited in this specification. The user can interact with the blockchain node connected to the electronic device by logging in the registered account on the electronic device. In one embodiment, the user can submit an invoice record request (including the invoice content) to the blockchain node through the user terminal so that the blockchain node can store the invoice content on the blockchain, and then the user can target the target When the invoice is required for reimbursement, an invoice reimbursement request is initiated through the client so that the blockchain node can reimburse the target invoice. In one embodiment, after completing a transaction, the user can send a record request to the blockchain node through the user terminal so that the blockchain node publishes the transaction information of the transaction to the blockchain. For example, transaction information may include transaction identification, transaction platform, transaction amount, transaction content, transaction participants, transaction time, etc. Of course, this manual does not limit the specific content of transaction information. Further, the user can submit an invoice creation request to the blockchain node through the client, so that the blockchain node can call the invoice creation logic declared in the smart contract, create a corresponding invoice based on the stored transaction content, and save the created invoice Proof on the blockchain. Then, when the user has a reimbursement requirement for the target invoice, the invoice reimbursement request can be initiated through the user terminal to make the blockchain node perform reimbursement processing on the target invoice. By publishing the invoice to the blockchain, each blockchain node records a complete invoice, so even if a node has data corruption, it will not affect the overall data integrity; at the same time, the area can be fully utilized. The non-tamperable modification of the data stored in the blockchain prevents criminals from maliciously modifying the content of the invoice and ensures the security and transparency of the invoice. Based on the deposit certificate of the invoice on the chain, when the blockchain node receives an invoice reimbursement request for the target invoice, it can call the invoice reimbursement logic declared in the smart contract to perform reimbursement processing for the target invoice, thereby achieving a blockchain-based Invoice reimbursement plan. Step 104: In response to the invoice reimbursement request, determine the invoice status of the target invoice. In one embodiment, when the blockchain node deposits the invoice to the blockchain, it can associate the invoice status of the deposited invoice (which may include the unreimbursed status, the reimbursed status, and the locked status). Among them, when associating the invoice status of a certificated invoice, you can preset the invoice to the unreimbursed status; and when it is determined that the invoice needs to be reimbursed, you can first update the invoice from the unreimbursed status to the locked status to prevent Repeated reimbursement of invoices (for example, when receiving an invoice reimbursement request for an invoice, if the invoice is already locked, it means that the invoice reimbursement request for the invoice has been received before; in order to prevent repeated reimbursement, Can directly return to the prompt message of reimbursement failure); after reimbursing the invoice and the reimbursement is successful, the invoice can be updated to the reimbursed status. In an embodiment, the invoice status of the certificated invoice can be associated with the mapping relationship between the certificated invoice identifier and the invoice status. In other words, the mapping relationship between invoice identification and invoice status is stored in the blockchain, and based on the identification information of the target invoice included in the invoice reimbursement request, the invoice status of the target invoice can be determined in the following way: in response to the invoice reimbursement request, Call the invoice query logic declared in the smart contract published on the blockchain to query whether the target invoice corresponding to the identification information of the target invoice in the invoice reimbursement request is stored on the blockchain; if it is Query the mapping relationship further based on the identification information of the target invoice in the invoice reimbursement request, and determine the invoice status of the target invoice. Among them, the invoice identifier is a hash value obtained by hashing the content of the invoice or the unique information in the content of the invoice. For example, the unique information can include: invoice number, invoice code, invoice date, and tax-exclusive information. Of course, this manual does not limit the content of the invoice and the specific form of the unique information in the invoice content. It should be noted that the operation of querying whether there is a target invoice on the blockchain and the operation of determining the status of the invoice based on the mapping relationship can also be performed by the blockchain node itself, and this specification does not limit this. Step 106: If the invoice status of the target invoice is not reimbursed, call the invoice reimbursement logic declared in the smart contract published on the blockchain to perform reimbursement processing for the target invoice, and after the reimbursement is successful The target invoice is updated to the reimbursed status. In one embodiment, the user can fill in the reimbursement document identifier through the user terminal (the invoice reimbursement request includes the reimbursement document identifier), so that the blockchain node performs reimbursement processing on the target invoice based on the reimbursement document corresponding to the reimbursement document identifier. In order to prevent repeated reimbursement, before reimbursing the target invoice, you can call the invoice locking logic declared in the smart contract published on the blockchain, save the binding relationship between the reimbursement document identifier and the target invoice, and save the binding After the relationship, the invoice status of the target invoice is updated from the unreimbursed status to the locked status. Wherein, after the target invoice is bound to any reimbursement document identifier and is updated to a locked state, the blockchain node can only perform reimbursement processing on the target invoice based on the reimbursement document corresponding to any reimbursement document identifier. Further, after the invoice status of the target invoice is updated from the unreimbursed state to the locked state, the invoice reimbursement logic declared in the smart contract published on the blockchain can be called to perform reimbursement processing for the target invoice. In one embodiment, if it is determined that the invoice status of the target invoice is the reimbursed status or the locked status, a prompt message indicating that the reimbursement failed is returned to the client. Wherein, when the invoice status is the reimbursed status, the returned reimbursement failure reminder information can be used to remind the user that the target invoice has been reimbursed; when the invoice status is locked, the returned reimbursement failed reminder information can be used for Prompt the user that the target invoice has been locked (that is, the reimbursement process cannot be processed). In one embodiment, after the user submits the invoice reimbursement request through the user terminal and the target invoice is locked, only the user has the authority to release the target invoice from the locked state. Then, when the user submits an invoice reimbursement request through the client to request reimbursement of the target invoice, but the reimbursement fails (for example, it is not within the set reimbursement period, the reimbursement amount exceeds the limit, etc.), because the target invoice is locked (and the reimbursement Document ID binding), if the user needs to request reimbursement of the target invoice (for example, adjust within the set reimbursement period, adjust the reimbursement amount, etc.), the target invoice needs to be unlocked first. Therefore, the blockchain node can receive the unlock request for the target invoice initiated by the user through the client after the target invoice reimbursement fails, and in response to the unlock request, call the invoice unlocking logic declared in the smart contract published on the blockchain , Determine whether the sender of the unlock request is the sender of the invoice reimbursement request (that is, determine whether the sender of the unlock request has the unlocking authority); if so, delete the binding relationship between the reimbursement document ID and the target invoice, and change the invoice of the target invoice The status is updated from the locked status to the unreimbursed status, and a prompt message indicating successful unlocking is returned to the client. Further, after successfully unlocking the target invoice, the user can submit an invoice reimbursement request (including other reimbursement document identifiers) through the user terminal to perform reimbursement processing on the target invoice. In an embodiment, the above-mentioned blockchain may be a consortium chain, and the node members of the consortium chain may include payment platforms, tax authorities, and so on. It should be noted that there are narrow transactions and broad transactions in transactions in the blockchain. A narrowly defined transaction refers to a transfer of value issued by a user to the blockchain; for example, in a traditional Bitcoin blockchain network, a transaction can be a transfer initiated by the user in the blockchain. In a broad sense, a transaction refers to a piece of business data with business intentions released by a user to the blockchain; for example, an operator can build a consortium chain based on actual business needs, and rely on the consortium chain to deploy some other types that are not related to value transfer. Online business (for example, renting business, vehicle dispatching business, insurance claims business, credit service, medical service, etc.), and in this kind of alliance chain, the transaction can be a business message with business intentions or Business request. Fig. 2 is a schematic diagram of the overall structure of an invoice reimbursement solution provided by an exemplary embodiment. As shown in Figure 2, the reimbursement requester can enter the invoice content of the target invoice in the client 21. The client 21 sends an invoice reimbursement request to the server 22 based on the invoice content entered by the user; and the server 22 (as a blockchain node ) After receiving the invoice reimbursement request, determine the invoice status of the target invoice stored in the blockchain, and then reimburse the target invoice when the invoice status of the target invoice is not reimbursed, and update the target invoice after the reimbursement is successful Reimbursed status. For ease of understanding, the following describes the invoice reimbursement scheme of this specification in detail with reference to the operations and functions implemented by the client 21 and the server 22 during the invoice reimbursement process, respectively, with reference to Figs. 3-6. Fig. 3 is an interactive schematic diagram of an invoice on the chain provided by an exemplary embodiment. As shown in FIG. 3, the interaction process may include the following steps: Step 302, the establishment of a binding relationship between the client 21 and the server 22 is realized. In one embodiment, the binding relationship that needs to be established is the binding relationship between the user's identity information and the device information of the client 21. Based on the binding relationship, when the server 22 receives the invoice record request, the invoice creation request, and the invoice reimbursement request subsequently sent by the client 21, it can confirm that these requests correspond to the user. For example, the user may register an account at the server 22 in advance to obtain a registered account uniquely corresponding to the user. Then, the user can log in the registered account on the client 21, and the server 22 determines the difference between the registered account (corresponding to the user) and the client 21 based on the login information of the registered account on the client 21 Established a binding relationship between. In step 304, the client 21 obtains the invoice to be recorded. In one embodiment, after the user completes a transaction and issues an invoice, he can input the invoice content through the client 21, and the client 21 then submits an invoice record request (including the invoice content) to the server 22, so that the server 22 will wait The recorded invoice is posted to the blockchain. Among them, the user can register in advance to obtain a unique corresponding digital identity, which is characterized by a set of public and private key pairs. Correspondingly, after obtaining the content of the invoice input by the user, the user terminal 21 can generate an invoice record request and sign the invoice record request through the private key corresponding to the user's digital identity. In step 306, the client 21 submits an invoice record request to the server 22. In step 308, the server 22 verifies the signature. In an embodiment, the server 22 runs a blockchain client, so that the server 22 is configured as a blockchain node. After the server 22 receives the invoice record request, it can determine the identity of the user based on the binding relationship established in step 302, and verify the signature through the public key corresponding to the user to determine that the invoice record request has been issued by the user. Authorize, instead of sending by pretending to be the user’s identity. In step 310, the server 22 publishes the invoice to the blockchain. In step 312, the server 22 marks the invoice as unreimbursed. In one embodiment, the server 22 may call the mapping creation logic declared in the smart contract, and perform hash calculations based on the unique information in the invoice content (invoice number, invoice code, invoice date, tax excluding amount, etc.) Corresponding hash value (as the invoice identifier), and establish the mapping relationship between the hash value of each invoice and the invoice status. Among them, the invoice issued to the blockchain can be set as unreimbursed by default. Please refer to FIG. 4, which is another schematic diagram of interaction on the chain of invoices provided by an exemplary embodiment. As shown in FIG. 4, the interaction process may include the following steps: Step 402, the establishment of a binding relationship between the client 21 and the server 22 is realized. In step 404, the client 21 obtains transaction information to be recorded. In one embodiment, after completing a transaction, the user can input transaction information through the client 21, and the client 21 then submits a transaction record request (including transaction information) to the server 22, so that the server 22 will record the transaction to be recorded Publish to the blockchain. In step 406, the client 21 submits a transaction record request to the server 22. In step 408, the server 22 verifies the signature. In an embodiment, the principle of the client 21 signing the transaction record request and the server 22 verifying the signature is similar to the above, and will not be repeated here. In step 410, the server 22 publishes the transaction information to the blockchain. In step 412, the client 21 submits an invoice creation request to the server 22. In one embodiment, when a user needs to issue an invoice for a certain transaction, he can submit an invoice creation request for the transaction to the server 22 through the client 21, so that the server 22 can call the invoice creation logic declared in the smart contract as The transaction creates an invoice. Among them, the invoice creation request may include the transaction identifier and the invoice creation information input by the user through the user terminal. In step 414, the server 22 verifies the signature. In step 416, the server 22 invokes the invoice creation logic declared in the smart contract, creates an invoice based on the invoice creation information, and publishes the created invoice to the blockchain. In one embodiment, the smart contract can be pre-deployed on the blockchain by payment institutions and tax authorities. In one embodiment, the invoice creation information input by the user may include the header information and transaction information of the invoice. After receiving the invoice creation request, the server 22 will combine the transaction information included in the invoice creation information with the transaction deposited on the blockchain. Information (corresponding to the transaction identifier) is compared. When the comparison result is the same, the invoice is created directly based on the transaction information and header information contained in the invoice creation information. For example, after the server 22 receives the invoice creation request for the target transaction, it reads the transaction information contained in the invoice creation information and calculates the first hash value, and compares the first hash value with the transaction certified on the blockchain The second hash value of the information (corresponding to the transaction identifier) is compared. When the first hash value is equal to the second hash value, it can be determined that the transaction information input by the user is the transaction information of the target transaction, and then the user input can be directly The transaction information and header information create an invoice for the target transaction without reading the transaction information of the target transaction deposited on the blockchain, thereby improving the efficiency of creating invoices. In step 418, the server 22 marks the invoice as unreimbursed. In one embodiment, the server 22 may call the mapping creation logic declared in the smart contract, and perform hash calculations based on the unique information in the invoice content (invoice number, invoice code, invoice date, tax excluding amount, etc.) Corresponding hash value (as the invoice identifier), and establish the mapping relationship between the hash value of each invoice and the invoice status. Among them, the invoice issued to the blockchain can be set as unreimbursed by default. Based on publishing the invoice to the blockchain, the user can further process the reimbursement for the target invoice request. Please refer to FIG. 5, which is a flowchart of another method for reimbursing invoices based on blockchain according to an exemplary embodiment. As shown in Figure 5, the method is applied to a blockchain node (take the server 22 as an example), and it can include the following steps: Step 502, receiving a target invoice initiated by the user through the client 21 for the deposit in the blockchain Request for invoice reimbursement. In one embodiment, the invoice reimbursement request includes the invoice content of the target invoice, or the user terminal performs the process based on the unique information (invoice number, invoice code, invoice date, tax excluding amount, etc.) in the invoice content entered by the user The hash value calculated by hash, and the reimbursement document identification. Step 504: Obtain the invoice identifier of the target invoice. In one embodiment, when the invoice content of the target invoice is recorded in the invoice reimbursement request, the unique information in the invoice content is read and hashed to obtain the invoice identifier of the target invoice; when the target invoice is recorded in the invoice reimbursement request When the invoice identifier (the hash value obtained by the user's hash calculation based on the unique information in the invoice content entered by the user), the invoice identifier can be directly read. Step 506, if the target invoice corresponding to the obtained invoice identifier is deposited on the blockchain, then proceed to step 510; otherwise, proceed to step 508. In one embodiment, the invoice query logic declared in the smart contract published on the blockchain can be called to query whether the target invoice corresponding to the obtained invoice identifier is stored on the blockchain. Of course, the server 22 itself can also execute the operation of querying the target invoice, which is not limited in this specification. In step 508, a prompt message indicating that the invoice does not exist is returned to the client 21. Step 510: Determine the invoice status corresponding to the obtained invoice identifier according to the mapping relationship between the invoice identifier and the invoice status stored on the blockchain. For example, suppose the mapping relationship of deposit certificates on the blockchain is shown in Table 1: Invoice ID (hash value) Invoice status
Invoice a Unreimbursed status
Invoice b Locked state (invoice b is bound to reimbursement document identification b)
Invoice c Reimbursed status
... ...
Table 1 Step 512, if the status of the invoice is not reimbursed, go to step 514; otherwise, go to step 526. Step 514: Call the invoice locking logic declared in the smart contract published on the blockchain, save the binding relationship between the reimbursement document ID and the target invoice, and after saving the binding relationship, change the invoice status of the target invoice from unreimbursed The status is updated to locked status. Taking invoice a as an example, following the above example, the mapping relationship of the deposit certificate on the blockchain is shown in Table 2: Invoice ID (hash value) Invoice status
Invoice a Locked state (invoice a is bound to reimbursement document identification a)
Invoice b Locked state (invoice b is bound to reimbursement document identification b)
Invoice c Reimbursed status
... ...
Table 2 Step 516, if the target invoice is locked, go to step 520; otherwise, go to step 518. In step 518, a prompt message indicating that the lock failed is returned to the client. In one embodiment, after the operation of locking the target invoice is executed through step 514, the locking failure may occur (it should be noted that this situation is different from the situation where the invoice has been locked before; for example, the server 22 is locked due to Too much processing resources are occupied and the smart contract can no longer be called). Therefore, when the lock operation should be executed (the target invoice is not reimbursed at this time) and the result of the execution is that the lock fails, the lock failure prompt can be returned to the client 21 News. Then, after the user receives the prompt message on the side of the user terminal 21, the user can subsequently resubmit the invoice reimbursement request for the target invoice. Step 520: After updating the invoice status of the target invoice from the unreimbursed state to the locked state, call the invoice reimbursement logic declared in the smart contract on the blockchain to perform reimbursement processing for the target invoice. Step 522, if the reimbursement is successful, go to step 524; otherwise, go to step 526. Step 524: After the reimbursement is successful, the target invoice is updated from the locked state to the reimbursed state. Step 526: Return prompt information of reimbursement failure to the client 21. In one embodiment, proceed to step 512. When the target invoice is locked, it means that the invoice reimbursement request for the target invoice has been received before (step 502); therefore, in order to prevent repeated reimbursement, it can be directly returned to A prompt message prompting the user that the target invoice has been locked. When the invoice status is the reimbursed status, a prompt message can be returned to remind the user that the target invoice has been reimbursed. In one embodiment, in step 522, when reimbursement is performed on the target invoice, reimbursement failure may occur. For example, not within the set reimbursement period, the reimbursement amount exceeds the limit, etc. Therefore, when the reimbursement fails, a prompt message for prompting the user to reimburse the target invoice can be returned (the reason for the reimbursement failure can be specified). In one embodiment, after the user submits the invoice reimbursement request through the user terminal and the target invoice is locked, only the user has the authority to release the target invoice from the locked state. Then, when the user submits an invoice reimbursement request through the client to request reimbursement of the target invoice, but the reimbursement fails (for example, it is not within the set reimbursement period, the reimbursement amount exceeds the limit, etc.), because the target invoice is locked (and the reimbursement Document identification binding), if the user needs to request reimbursement for the target invoice (for example, adjust the reimbursement within the set reimbursement period, adjust the reimbursement amount not to exceed the limit, etc.), the target invoice needs to be unlocked first. Detailed description will be given below in conjunction with FIG. 6. Please refer to FIG. 6, which is a flowchart of unlocking an invoice provided by an exemplary embodiment. As shown in Figure 6, the method is applied to a blockchain node (take the server 22 as an example), and may include the following steps: Step 602, receiving a user-initiated unlock request for the target invoice after the target invoice reimbursement fails. . Step 604, if the user has the unlocking authority, go to step 606; otherwise, go to step 610. In one embodiment, the invoice unlocking logic declared in the smart contract published on the blockchain can be called to determine whether the sender of the unlock request is the sender of the invoice reimbursement request; if so, delete the reimbursement document identifier and the target invoice In the binding relationship, the invoice status of the target invoice is updated from the locked status to the unreimbursed status, and a prompt message indicating that the unlocking is successful is returned to the client 21. Then, after successfully unlocking the target invoice, the user can submit an invoice reimbursement request (including other reimbursement document identifiers) through the user terminal to perform reimbursement processing on the target invoice. The account number registered by the user in the above step 302 can be used to determine whether the sender of the unlock request is the sender of the invoice reimbursement request, and the method of verification in steps 306-308 can also be used. Of course, this specification does not limit this. Step 606: Delete the binding relationship between the reimbursement document identifier and the target invoice, and update the invoice status of the target invoice from the locked status to the unreimbursed status. Take unlocking invoice a as an example, following the above example, the mapping relationship is updated as shown in Table 3: Invoice ID (hash value) Invoice status
Invoice a Unreimbursed status
Invoice b Locked state (invoice b is bound to reimbursement document identification b)
Invoice c Reimbursed status
... ...
Table 3 Step 608, returning prompt information of successful unlocking to the client 21. In step 610, when the user does not have the unlocking authority, a prompt message of unlocking failure is returned to the user terminal 21. Fig. 7 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 7. At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 707, a memory 708, and a non-volatile memory 710. Of course, it may also include hardware required for other services. The processor 702 reads the corresponding computer program from the non-volatile memory 710 to the memory 708 and then runs it to form a blockchain-based invoice reimbursement device on a logical level. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., which means that the execution body of the following processing flow is not limited to Each logical unit can also be a hardware or a logical device. Referring to Fig. 8, in the software implementation, the blockchain-based invoice reimbursement device may include: a reimbursement receiving unit 81, which receives an invoice initiated by a user through the user terminal for a target invoice deposited in the blockchain Reimbursement request; Status determination unit 82, in response to the invoice reimbursement request, determine the invoice status of the target invoice; Reimbursement unit 83, if the invoice status of the target invoice is not reimbursed, call the The invoice reimbursement logic declared in the smart contract performs reimbursement processing for the target invoice, and updates the target invoice to the reimbursed state after the reimbursement is successful. Optionally, the mapping relationship between the invoice identifier and the invoice status is stored in the blockchain; the invoice reimbursement request includes the identification information of the target invoice; the status determining unit 82 is specifically configured to: respond to the In the invoice reimbursement request, call the invoice query logic declared in the smart contract published on the blockchain, and query whether there is a certificate on the blockchain that corresponds to the identification information of the target invoice in the invoice reimbursement request Target invoice; if yes, further query the mapping relationship based on the identification information of the target invoice in the invoice reimbursement request, and determine the invoice status of the target invoice. Optionally, the invoice identifier is a hash value obtained by hashing the content of the invoice or the unique information in the content of the invoice. Optionally, the invoice reimbursement request includes a reimbursement document identifier; before invoking the invoice reimbursement logic declared in the smart contract published on the blockchain, and before reimbursing the target invoice, it further includes: a locking unit 84, calling The invoice locking logic declared in the smart contract published on the blockchain saves the binding relationship between the reimbursement document identifier and the target invoice, and after saving the binding relationship, the invoice status of the target invoice The reimbursement unit 83 is specifically configured to: after updating the invoice status of the target invoice from the unreimbursed state to the locked state, call the invoice reimbursement logic to target the target invoice. The invoice is processed for reimbursement. Optionally, it further includes: a prompting unit 85, if the invoice status of the target invoice is the reimbursed state or the locked state, returning prompt information of the reimbursement failure to the client. Optionally, it further includes: an unlocking receiving unit 86, which receives an unlocking request for the target invoice initiated by the user through the user terminal after the target invoice reimbursement fails; and an authentication unit 87, which calls the release in response to the unlocking request The invoice unlocking logic declared in the smart contract on the blockchain determines whether the sender of the unlock request is the sender of the invoice reimbursement request; the unlocking unit 88, if it is, deletes the reimbursement document identifier and the For the binding relationship of the target invoice, the invoice status of the target invoice is updated from the locked status to the unreimbursed status, and a prompt message indicating successful unlocking is returned to the client. The systems, devices, modules, or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game. A console, a tablet, a wearable device, or a combination of any of these devices. In a typical configuration, a computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory. Memory may include non-permanent memory in computer-readable media, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media. Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), and other types of random access memory (RAM) , Read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only CD-ROM (CD-ROM), digital multi-function Optical disc (DVD) or other optical storage, magnetic cassette tape, magnetic sheet storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media, which can be used to store information that can be accessed by computing devices . According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves. It should also be noted that the terms "including", "including" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element. The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the attached patent application. In some cases, the actions or steps described in the scope of the patent application may be performed in a different order from the embodiment and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired result. In some embodiments, multiplexing and parallel processing are also possible or may be advantageous. The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms "a", "the" and "the" used in one or more embodiments of this specification and the scope of the appended patent application are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more associated listed items. It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to a judgment". The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principle of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. made should be included in the protection scope of one or more embodiments of this specification.
