WO2020134699A1 - 基于区块链的发票报销方法、装置及电子设备 - Google Patents

基于区块链的发票报销方法、装置及电子设备 Download PDF

Info

Publication number
WO2020134699A1
WO2020134699A1 PCT/CN2019/119112 CN2019119112W WO2020134699A1 WO 2020134699 A1 WO2020134699 A1 WO 2020134699A1 CN 2019119112 W CN2019119112 W CN 2019119112W WO 2020134699 A1 WO2020134699 A1 WO 2020134699A1
Authority
WO
WIPO (PCT)
Prior art keywords
invoice
reimbursement
target
status
blockchain
Prior art date
Application number
PCT/CN2019/119112
Other languages
English (en)
French (fr)
Inventor
肖汉松
阚文虎
刘勤
段金明
张翼翔
张萍
林亮荣
孙震
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2020134699A1 publication Critical patent/WO2020134699A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/10—Tax strategies

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a blockchain-based invoice reimbursement method, device, and electronic equipment.
  • Blockchain technology also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database.
  • Blockchain technology has the characteristics of decentralization, openness and transparency, each computing device can participate in database records, and data synchronization can be quickly performed between computing devices, making blockchain technology widely used in many fields. To apply.
  • one or more embodiments of this specification provide a blockchain-based invoice reimbursement method, device, and electronic equipment.
  • a blockchain-based invoice reimbursement method includes:
  • a blockchain-based invoice reimbursement device comprising:
  • the reimbursement receiving unit receives the invoice reimbursement request initiated by the user through the client for the target invoice stored in the blockchain;
  • a status determination unit in response to the invoice reimbursement request, determining the invoice status of the target invoice
  • the reimbursement unit if the invoice status of the target invoice is unreimbursed, call the invoice reimbursement logic declared in the smart contract published on the blockchain, reimburse the target invoice, and after the reimbursement is successful The target invoice is updated to the reimbursed status.
  • an electronic device including: a processor; a memory for storing processor executable instructions; wherein the processor executes the executable instructions To implement the method as described in any of the above embodiments.
  • FIG. 1 is a flowchart of a blockchain-based invoice reimbursement method provided by an exemplary embodiment.
  • FIG. 2 is a schematic diagram of an overall structure of an invoice reimbursement scheme provided by an exemplary embodiment.
  • FIG. 3 is an interaction diagram of issuing an invoice to a blockchain provided by an exemplary embodiment.
  • FIG. 4 is another interaction diagram for issuing invoices to the blockchain provided by an exemplary embodiment.
  • FIG. 5 is a flowchart of another blockchain-based invoice reimbursement method provided by an exemplary embodiment.
  • FIG. 6 is a flowchart of unlocking an invoice provided by an exemplary embodiment.
  • FIG. 7 is a schematic structural diagram of an apparatus provided by an exemplary embodiment.
  • FIG. 8 is a block diagram of a blockchain-based invoice reimbursement device provided by an exemplary embodiment.
  • the steps of the corresponding method are not necessarily performed in the order shown and described in this specification.
  • the method may include more or fewer steps than described in this specification.
  • the single step described in this specification may be decomposed into multiple steps for description in other embodiments; and the 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 Figure 1, this method is applied to blockchain nodes and can include the following steps:
  • Step 102 Receive an invoice reimbursement request initiated by a user through a client for a target invoice deposited in the blockchain.
  • the client may be any type of electronic device such as a mobile phone, tablet computer, PC, etc. used by the user (the user is the claimant), 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.
  • the user can submit an invoice record request (including the invoice content) to the blockchain node through the client to enable the blockchain node to deposit the invoice content on the blockchain, and then the user exists for the target
  • invoice reimbursement needs the client initiates an invoice reimbursement request to enable the blockchain node to reimburse the target invoice.
  • the user can send a record request to the blockchain node through the client to enable the blockchain node to publish the transaction information of the transaction to the blockchain.
  • the transaction information may include transaction identification, transaction platform, transaction amount, transaction content, transaction participants, transaction time, etc.
  • this specification does not limit the specific content of the transaction information.
  • the user can submit an invoice creation request to the blockchain node through the client, so that the blockchain node invokes the invoice creation logic declared in the smart contract, creates a corresponding invoice based on the stored transaction content, and stores the created invoice The certificate is on the blockchain.
  • the client can initiate an invoice reimbursement request to enable the blockchain node to reimburse the target invoice.
  • each blockchain node By publishing invoices to the blockchain, each blockchain node records a complete invoice, so even if a node has data corruption problems, it will not affect the overall data integrity; at the same time, the area can be fully utilized
  • the data stored in the blockchain cannot be tampered with, thereby preventing the criminals from maliciously modifying the contents of the invoice and ensuring the safety and transparency of the invoice.
  • the blockchain node Based on the invoice deposit on the chain, when the blockchain node receives the 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 implementing a blockchain-based Invoice reimbursement plan.
  • Step 104 In response to the invoice reimbursement request, determine the invoice status of the target invoice.
  • the blockchain node when depositing invoices to the blockchain, may associate the invoice status of the invoices (which may include unreimbursed status, reimbursed status, and locked status).
  • the invoice when linking the invoice status of the certificate invoice, the invoice can be set to the unreimbursed state by default; and when it is determined that the invoice needs to be reimbursed, the invoice can be updated from the unreimbursed state to the locked state to prevent Invoice reimbursement (for example, when receiving an invoice reimbursement request for an invoice, if the invoice is already locked, it means that an invoice reimbursement request for the invoice has been received before; to prevent double reimbursement, you can Directly return the prompt message of reimbursement failure); after reimbursing the invoice and the reimbursement is successful, you can update the invoice to the reimbursed status.
  • Invoice reimbursement for example, when receiving an invoice reimbursement request for an invoice, if the invoice is already locked, it means that an invoice reimbursement request for the invoice has been received before; to prevent double reimbursement, you can Directly return the prompt message of reimbursement failure
  • the invoice status of the certificated invoice can be correlated through the mapping relationship between the certificated invoice identification and the invoice status.
  • the mapping relationship between the invoice identification and the 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 by responding to the invoice reimbursement request, Invoking 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 , Further querying the mapping relationship based on the identification information of the target invoice in the invoice reimbursement request to determine the invoice status of the target invoice.
  • the invoice identifier is a hash value calculated by hashing the invoice content or the unique information in the invoice content.
  • the unique information may include information such as invoice number, invoice code, invoice date, and tax-free amount.
  • this manual does not limit the invoice content and the specific form of unique information in the invoice content.
  • Step 106 if the invoice status of the target invoice is unreimbursed, call the invoice reimbursement logic declared in the smart contract published on the blockchain, perform reimbursement processing for the target invoice, and after the reimbursement is successful The target invoice is updated to the reimbursed status.
  • the user may fill in the reimbursement document identifier (the reimbursement document identifier is included in the invoice reimbursement document identifier) through the client, so that the blockchain node reimburses the target invoice based on the reimbursement document corresponding to the reimbursement document identifier.
  • the reimbursement document identifier is included in the invoice reimbursement document identifier
  • the blockchain node can only reimburse the target invoice based on the reimbursement document corresponding to the any reimbursement document identifier. Further, after updating the invoice status of the target invoice from the unreimbursed status to the locked status, the invoice reimbursement logic declared in the smart contract published on the blockchain can be called to reimburse the target invoice.
  • a prompt message that the reimbursement fails is returned to the client.
  • the prompt information returned for reimbursement failure can be used to prompt the user that the target invoice has been reimbursed; when the invoice status is locked, the prompt information returned for reimbursement failure can be used to Prompt the user that the target invoice has been locked (that is, reimbursement cannot be processed).
  • a user when a user submits an invoice reimbursement request through the client so that the target invoice is locked, only the user has the authority to release the target invoice in the locked state. Then, when the user submits the invoice reimbursement request through the client to request reimbursement processing for the target invoice but the reimbursement fails (for example, not within the set reimbursement period, the reimbursement amount exceeds the limit, etc.), because the target invoice is locked (and Reimbursement document ID binding), if the user needs to request reimbursement processing for the target invoice (for example, adjusting within the set reimbursement period, adjusting the reimbursement amount, etc.), the target invoice needs to be unlocked first.
  • 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 unlock 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 permission to unlock); if it is, delete the binding relationship between the reimbursement document ID and the target invoice, and convert the invoice of the target invoice The status is updated from the locked state to the unreimbursed state, and a prompt message that the unlock is successful is returned to the client. Further, after successfully unlocking the target invoice, the user may submit an invoice reimbursement request (including other reimbursement document identifiers) through the client to reimburse the target invoice.
  • an invoice reimbursement request including other reimbursement document identifiers
  • the above-mentioned blockchain may be a consortium chain, and the node members of the consortium chain may include payment platforms, tax authorities, etc.
  • a narrowly defined transaction refers to a value transfer issued by the user to the blockchain; for example, in the traditional Bitcoin blockchain network, the transaction can be a transfer initiated by the user in the blockchain.
  • the generalized transaction refers to a piece of business data with business intent published by the user to the blockchain; for example, the operator can build an alliance chain based on actual business needs, relying on the alliance chain to deploy some other types not related to value transfer Online business (for example, rental business, vehicle scheduling business, insurance claims business, credit service, medical service, etc.), and in this type of alliance chain, the transaction can be a business with business intent issued by the user in the alliance chain Message or business request.
  • FIG. 2 is a schematic diagram of an overall structure of an invoice reimbursement scheme provided by an exemplary embodiment.
  • the reimbursement requester can enter the invoice content of the target invoice in the client 21, and 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 to have been reimbursed after successful reimbursement Reimbursement status.
  • FIG. 3 is a schematic diagram of an invoice upload chain interaction provided by an exemplary embodiment. As shown in FIG. 3, the interaction process may include the following steps:
  • step 302 a binding relationship is established between the client 21 and the server 22.
  • the binding relationship 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, the server 22 can confirm that these requests correspond to the user when receiving the invoice recording request, the invoice creation request, and the invoice reimbursement request subsequently sent by the client 21.
  • the user may register an account with the server 22 in advance to obtain a registered account uniquely corresponding to himself. Then, the user can log in to the registered account on the client 21, and the server 22 determines 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.
  • step 304 the client 21 obtains the invoice to be recorded.
  • the user after completing a transaction and issuing an invoice, the user can enter the invoice content through the client 21, and the client 21 then submits an invoice recording request (including the invoice content) to the server 22, so that the server 22 will record Of invoices are posted on the blockchain.
  • 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.
  • the client 21 can generate an invoice recording request and sign the invoice recording request through the private key corresponding to the user's digital identity.
  • step 306 the client 21 submits an invoice recording request to the server 22.
  • step 308 the server 22 verifies the signature.
  • a blockchain client runs on the server 22, so that the server 22 is configured as a blockchain node.
  • the server 22 may determine the identity of the user based on the binding relationship established in the above step 302, so as to verify the signature through the public key corresponding to the user to determine that the invoice recording request has been made by the user Authorized, not sent by the criminals pretending to be the identity of the user.
  • Step 310 the server 22 issues the invoice to the blockchain.
  • step 312 the server 22 marks the invoice as unreimbursed.
  • the server 22 may establish the logic by calling the mapping declared in the smart contract, and calculate the corresponding hash information according to the unique information in the invoice content (invoice number, invoice code, invoice date, tax-free amount, etc.)
  • the hash value (as the invoice identification), and establish the mapping relationship between the hash value of each invoice and the status of the invoice.
  • the invoices posted to the blockchain can be set to unreimbursed by default.
  • FIG. 4 is another schematic diagram of an interaction of invoice chaining provided by an exemplary embodiment.
  • the interaction process may include the following steps:
  • step 402 a binding relationship is established between the client 21 and the server 22.
  • step 404 the client 21 obtains the transaction information to be recorded.
  • the user can enter 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 publishes the transaction to be recorded Into the blockchain.
  • step 406 the client 21 submits a transaction record request to the server 22.
  • step 408 the server 22 verifies the signature.
  • the client 21 signs the transaction record request, and the principle of the server 22 verifying the signature is similar to the above, and will not be repeated here.
  • Step 410 the server 22 publishes the transaction information to the blockchain.
  • step 412 the client 21 submits an invoice creation request to the server 22.
  • the client 21 can submit an invoice creation request for the transaction to the server 22, so that the server 22 invokes the invoice creation logic declared in the smart contract for the transaction Create an invoice.
  • the invoice creation request may include the transaction identifier and the invoice creation information input by the user through the client.
  • step 414 the server 22 verifies the signature.
  • step 416 the server 22 calls the invoice creation logic declared in the smart contract, creates an invoice according to the invoice creation information, and publishes the created invoice to the blockchain.
  • the smart contract can be pre-deployed on the blockchain by payment institutions and tax authorities.
  • the invoice creation information input by the user may include the header information and transaction information of the invoice.
  • the server 22 After receiving the invoice creation request, the server 22 combines the transaction information contained in the invoice creation information with the transaction information of the certificate stored on the blockchain (Corresponding to the transaction ID) For comparison, when the comparison result is consistent, the invoice is created directly based on the transaction information and header information included in the invoice creation information. For example, after receiving the invoice creation request for the target transaction, the server 22 reads the transaction information included in the invoice creation information and calculates the first hash value, and compares the first hash value with the certificate on the blockchain Compare the second hash value of the transaction information (corresponding to the transaction identifier).
  • the first hash value and the second hash value are equal, it can be determined that the transaction information entered by the user is the transaction information of the target transaction, then the Create an invoice for the target transaction directly based on the transaction information and header information entered by the user, without reading the transaction information of the target transaction on the blockchain, thereby improving the efficiency of creating invoices.
  • step 418 the server 22 marks the invoice as unreimbursed.
  • the server 22 may establish the logic by calling the mapping declared in the smart contract, and calculate the corresponding hash information based on the unique information in the invoice content (invoice number, invoice code, invoice date, tax-free amount, etc.)
  • the hash value (as the invoice identification), and establish the mapping relationship between the hash value of each invoice and the status of the invoice.
  • the invoices posted to the blockchain can be set to unreimbursed by default.
  • FIG. 5 is a flowchart of another invoice reimbursement method based on blockchain provided by an exemplary embodiment. As shown in FIG. 5, this method is applied to blockchain nodes (taking server 22 as an example) and may include the following steps:
  • Step 502 Receive an invoice reimbursement request initiated by the user through the client 21 for the target invoice stored in the blockchain.
  • the invoice reimbursement request includes the invoice content of the target invoice, or for the client based on the unique information (invoice number, invoice code, invoice date, tax-free amount, etc.) in the invoice content entered by the user
  • the hash value calculated by the hash and the identification of the reimbursement document is calculated by the hash and the identification of the reimbursement document.
  • Step 504 Obtain the invoice identifier of the target invoice.
  • the invoice reimbursement request when the invoice reimbursement request records the invoice content of the target invoice, the unique information in the invoice content is read and hashed to obtain the invoice ID of the target invoice; when the invoice reimbursement request records the target invoice Invoice identifier (the hash value calculated by the client based on the hash information calculated by the unique information in the invoice content entered by the user), it is sufficient to read the invoice identifier directly.
  • Step 506 if the target invoice corresponding to the obtained invoice identification is stored on the blockchain, then go to step 510; otherwise, go to step 508.
  • 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.
  • the server 22 itself may also perform the above operation of querying the target invoice, which is not limited in this specification.
  • step 508 a prompt message that the invoice does not exist is returned to the client 21.
  • Step 510 Determine the invoice status corresponding to the obtained invoice ID according to the mapping relationship between the invoice ID stored on the blockchain and the invoice status.
  • Invoice identification Invoice status Invoice a Unreimbursed Invoice b Locked status (invoice b is bound to reimbursement document identifier b) Invoice c Reimbursed status ... ...
  • Step 512 if the invoice status is unreimbursed, then 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 the locked state.
  • Invoice identification Invoice status Invoice a Locked status (invoice a is bound to reimbursement document identifier a) Invoice b Locked status (invoice b is bound to reimbursement document identifier b) Invoice c Reimbursed status ... ...
  • Step 516 if the target invoice is locked, go to step 520; otherwise, go to step 518.
  • step 518 a prompt message indicating that the lock has failed is returned to the client.
  • a locking failure may occur (it should be noted that this situation is different from the case where the invoice has been locked before; for example, the server 22 is occupied due to Too many processing resources lead to the inability to continue to call the smart contract), therefore, when the lock operation should be performed (the target invoice is in an unreimbursed state) and the result of the execution is a lock failure, the client 21 can be returned a lock failure prompt information. Then, after receiving the prompt message on the client 21 side, the user may subsequently resubmit the invoice reimbursement request for the target invoice.
  • step 520 after updating the invoice status of the target invoice from the unreimbursed status to the locked status, the invoice reimbursement logic declared in the smart contract on the blockchain is called to perform reimbursement processing for the target invoice.
  • Step 522 if the reimbursement is successful, then go to step 524; otherwise, go to step 526.
  • Step 524 After the reimbursement is successful, update the target invoice from the locked state to the reimbursed state.
  • step 526 a prompt message indicating that the reimbursement has failed is returned to the client 21.
  • step 512 when the target invoice is in the locked state, it means that the invoice reimbursement request for the target invoice has been received before (step 502); therefore, in order to prevent double reimbursement, it can be directly returned for Prompt message that prompts the user that the target invoice has been locked.
  • a prompt message can be returned to remind the user that the target invoice has been reimbursed.
  • step 522 when reimbursing the target invoice, reimbursement may fail. For example, not within the set reimbursement period, the reimbursement amount exceeds the limit, etc. Therefore, when the reimbursement fails, a prompt message (which may specifically indicate the reason for the reimbursement failure) to remind the user of the target invoice failure is returned.
  • a user when a user submits an invoice reimbursement request through the client so that the target invoice is locked, only the user has the authority to release the target invoice in the locked state. Then, when the user submits the invoice reimbursement request through the client to request reimbursement processing for the target invoice but the reimbursement fails (for example, not within the set reimbursement period, the reimbursement amount exceeds the limit, etc.), because the target invoice is locked (and Reimbursement document ID binding), if the user needs to request reimbursement processing for the target invoice (for example, adjusting within the set reimbursement period, adjusting the reimbursement amount not to exceed the amount, etc.), the target invoice must be unlocked first. Detailed description will be given below with reference to FIG. 6.
  • FIG. 6 is a flowchart of unlocking an invoice provided by an exemplary embodiment. As shown in FIG. 6, this method is applied to blockchain nodes (taking server 22 as an example), and may include the following steps:
  • Step 602 Receive an unlock request for the target invoice initiated by the user through the client after the target invoice fails to be reimbursed.
  • Step 604 if the user has unlocking authority, go to step 606; otherwise, go to step 610.
  • the invoice unlock 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 it is, delete the reimbursement document ID and the target invoice
  • the binding relationship updates the invoice status of the target invoice from the locked status to the unreimbursed status, and returns a prompt message to the client 21 that the unlock is successful.
  • the user can submit an invoice reimbursement request (including other reimbursement document identifiers) through the client to reimburse the target invoice.
  • the account registered by the user in step 302 can be used to determine whether the sender of the unlock request is the sender of the invoice reimbursement request, or the method of checking the signature in steps 306-308. Of course, this manual 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.
  • mapping relationship is updated as shown in Table 3:
  • Invoice identification Invoice status Invoice a Unreimbursed Invoice b Locked status (invoice b is bound to reimbursement document identifier b) Invoice c Reimbursed status ... ...
  • step 608 a prompt message of successful unlocking is returned to the client 21.
  • step 610 when the user does not have the right to unlock, a prompt message indicating that the unlock fails is returned to the client 21.
  • the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710. Of course, it may include hardware required for other services.
  • the processor 702 reads the corresponding computer program from the non-volatile memory 710 into the memory 708 and then runs it to form a blockchain-based invoice reimbursement device at a logical level.
  • one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of hardware and software, etc., that is to say, the execution body of the following processing flow is not limited to each
  • the logic unit may also be a hardware or logic device.
  • the blockchain-based invoice reimbursement device may include:
  • the reimbursement receiving unit 81 receives the invoice reimbursement request initiated by the user through the client for the target invoice deposited in the blockchain;
  • the status determination unit 82 in response to the invoice reimbursement request, determines the invoice status of the target invoice
  • the reimbursement unit 83 if the invoice status of the target invoice is unreimbursed, invokes the invoice reimbursement logic declared in the smart contract published on the blockchain, performs reimbursement processing on the target invoice, and after the reimbursement is successful The target invoice is updated to the reimbursed status.
  • the mapping relationship between invoice identification and invoice status is stored in the blockchain;
  • the invoice reimbursement request includes identification information of the target invoice;
  • the state determination unit 82 is specifically used to:
  • the invoice identifier is a hash value calculated by hashing the invoice content or the unique information in the invoice content.
  • the invoice reimbursement request includes a reimbursement document identifier
  • the locking unit 84 calls 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 saves the binding relationship
  • the invoice status of the target invoice is updated from the unreimbursed status to the locked status
  • the reimbursement unit 83 is specifically configured to: after updating the invoice status of the target invoice from the unreimbursed status to the locked status, call the invoice reimbursement logic to perform reimbursement processing for the target invoice.
  • Optional also includes:
  • the prompting unit 85 if the invoice status of the target invoice is the reimbursed status or the locked status, returns prompt information of the reimbursement failure to the client.
  • Optional also includes:
  • the unlocking receiving unit 86 receives the unlock request for the target invoice initiated by the user through the client after the target invoice fails to be reimbursed;
  • the authentication unit 87 in response to the unlock request, invokes the invoice unlock logic declared in the smart contract published on the blockchain to determine whether the sender of the unlock request is the sender of the invoice reimbursement request;
  • the unlocking unit 88 if it is, deletes the binding relationship between the reimbursement document identifier and the target invoice, updates the invoice status of the target invoice from the locked status to the unreimbursed status, and returns the unlock success to the client Prompt information.
  • the system, device, module or unit explained in the above embodiments may be specifically implemented by a computer chip or entity, or implemented by a product having a certain function.
  • a typical implementation device is a computer, and the specific form of the computer may 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 sending and receiving device, and a game control Desk, tablet computer, wearable device, or any combination of these devices.
  • the computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-permanent memory, random access memory (RAM) and/or non-volatile memory in a computer-readable medium, such as read only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
  • RAM random access memory
  • ROM read only memory
  • flash RAM flash memory
  • Computer readable media including permanent and non-permanent, removable and non-removable media, can store information by any method or technology.
  • the information may be computer readable instructions, data structures, modules of programs, 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), 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 compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices.
  • computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.
  • first, second, third, etc. may use the terms first, second, third, etc. 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.
  • first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
  • word "if” as used herein may be interpreted as "when” or “when” or “in response to a determination”.

Abstract

一种基于区块链的发票报销方法、装置及电子设备，该方法包括：接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求（102）；响应于所述发票报销请求，确定所述目标发票的发票状态（104）；如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态（106）。

Description

基于区块链的发票报销方法、装置及电子设备 技术领域
本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种基于区块链的发票报销方法、装置及电子设备。
背景技术
区块链技术，也被称之为分布式账本技术，是一种由若干台计算设备共同参与“记账”，共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性，使得区块链技术已在众多的领域中广泛的进行应用。
发明内容
有鉴于此，本说明书一个或多个实施例提供一种基于区块链的发票报销方法、装置及电子设备。
为实现上述目的，本说明书一个或多个实施例提供技术方案如下：
根据本说明书一个或多个实施例的第一方面，提出了一种基于区块链的发票报销方法，所述方法包括：
接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；
响应于所述发票报销请求，确定所述目标发票的发票状态；
如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。
根据本说明书一个或多个实施例的第二方面，提出了一种基于区块链的发票报销装置，所述装置包括：
报销接收单元，接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；
状态确定单元，响应于所述发票报销请求，确定所述目标发票的发票状态；
报销单元，如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。
根据本说明书一个或多个实施例的第三方面，提出了一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器通过运行所述可执行指令以实现如上述任一实施例中所述的方法。
附图说明
图1是一示例性实施例提供的一种基于区块链的发票报销方法的流程图。
图2是一示例性实施例提供的一种发票报销方案的整体架构示意图。
图3是一示例性实施例提供的一种将发票发布至区块链的交互图。
图4是一示例性实施例提供的另一种将发票发布至区块链的交互图。
图5是一示例性实施例提供的另一种基于区块链的发票报销方法的流程图。
图6是一示例性实施例提供的解锁发票的流程图。
图7是一示例性实施例提供的一种设备的结构示意图。
图8是一示例性实施例提供的一种基于区块链的发票报销装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
图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、网络接口706、内存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)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求 书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (13)

  1. 一种基于区块链的发票报销方法，所述方法包括：
    接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；
    响应于所述发票报销请求，确定所述目标发票的发票状态；
    如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。
  2. 根据权利要求1所述的方法，所述区块链中存证了发票标识与发票状态的映射关系；所述发票报销请求中包括所述目标发票的标识信息；
    所述响应于所述发票报销请求，确定所述目标发票的发票状态，包括：
    响应于所述发票报销请求，调用发布在区块链上的智能合约中声明的发票查询逻辑，查询所述区块链上是否存证了与所述发票报销请求中的所述目标发票的标识信息对应的目标发票；
    如果是，进一步基于所述发票报销请求中的所述目标发票的标识信息查询所述映射关系，确定所述目标发票的发票状态。
  3. 根据权利要求2所述的方法，所述发票标识为针对发票内容，或者发票内容中的唯一性信息进行hash计算得到的hash值。
  4. 根据权利要求1所述的方法，所述发票报销请求包括报销单据标识；
    在调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理之前，还包括：调用发布在区块链上的智能合约中声明的发票锁定逻辑，保存所述报销单据标识与所述目标发票的绑定关系，并在保存所述绑定关系后，将所述目标发票的发票状态由未报销状态更新为已锁定状态；
    调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，包括：在将所述目标发票的发票状态由未报销状态更新为已锁定状态后，调用所述发票报销逻辑，针对所述目标发票进行报销处理。
  5. 根据权利要求4所述的方法，还包括：
    如果所述目标发票的发票状态为已报销状态或者已锁定状态，向所述客户端返回报销失败的提示信息。
  6. 根据权利要求4所述的方法，还包括：
    接收用户在所述目标发票报销失败后通过客户端发起的针对所述目标发票的解锁请求；
    响应于所述解锁请求，调用发布在区块链上的智能合约中声明的发票解锁逻辑，确定所述解锁请求的发送方是否为所述发票报销请求的发送方；
    如果是，删除所述报销单据标识与所述目标发票的绑定关系，将所述目标发票的发票状态由已锁定状态更新为未报销状态，并向所述客户端返回解锁成功的提示信息。
  7. 一种基于区块链的发票报销装置，所述装置包括：
    报销接收单元，接收用户通过客户端发起的针对在所述区块链中存证的目标发票的发票报销请求；
    状态确定单元，响应于所述发票报销请求，确定所述目标发票的发票状态；
    报销单元，如果所述目标发票的发票状态为未报销状态，调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理，并在报销成功后将所述目标发票更新为已报销状态。
  8. 根据权利要求7所述的装置，所述区块链中存证了发票标识与发票状态的映射关系；所述发票报销请求中包括所述目标发票的标识信息；
    所述状态确定单元具体用于：
    响应于所述发票报销请求，调用发布在区块链上的智能合约中声明的发票查询逻辑，查询所述区块链上是否存证了与所述发票报销请求中的所述目标发票的标识信息对应的目标发票；
    如果是，进一步基于所述发票报销请求中的所述目标发票的标识信息查询所述映射关系，确定所述目标发票的发票状态。
  9. 根据权利要求8所述的装置，所述发票标识为针对发票内容，或者发票内容中的唯一性信息进行hash计算得到的hash值。
  10. 根据权利要求7所述的装置，所述发票报销请求包括报销单据标识；
    在调用发布在区块链上的智能合约中声明的发票报销逻辑，针对所述目标发票进行报销处理之前，还包括：
    锁定单元，调用发布在区块链上的智能合约中声明的发票锁定逻辑，保存所述报销单据标识与所述目标发票的绑定关系，并在保存所述绑定关系后，将所述目标发票的发票状态由未报销状态更新为已锁定状态；
    所述报销单元具体用于：在将所述目标发票的发票状态由未报销状态更新为已锁定状态后，调用所述发票报销逻辑，针对所述目标发票进行报销处理。
  11. 根据权利要求10所述的装置，还包括：
    提示单元，如果所述目标发票的发票状态为已报销状态或者已锁定状态，向所述客 户端返回报销失败的提示信息。
  12. 根据权利要求10所述的装置，还包括：
    解锁接收单元，接收用户在所述目标发票报销失败后通过客户端发起的针对所述目标发票的解锁请求；
    鉴权单元，响应于所述解锁请求，调用发布在区块链上的智能合约中声明的发票解锁逻辑，确定所述解锁请求的发送方是否为所述发票报销请求的发送方；
    解锁单元，如果是，删除所述报销单据标识与所述目标发票的绑定关系，将所述目标发票的发票状态由已锁定状态更新为未报销状态，并向所述客户端返回解锁成功的提示信息。
  13. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-6中任一项所述的方法。
PCT/CN2019/119112 2018-12-25 2019-11-18 基于区块链的发票报销方法、装置及电子设备 WO2020134699A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811593698.7A CN110009435A (zh) 2018-12-25 2018-12-25 基于区块链的发票报销方法及装置、电子设备
CN201811593698.7 2018-12-25

Publications (1)

Publication Number Publication Date
WO2020134699A1 true WO2020134699A1 (zh) 2020-07-02

Family

ID=67165245

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/119112 WO2020134699A1 (zh) 2018-12-25 2019-11-18 基于区块链的发票报销方法、装置及电子设备

Country Status (3)

Country Link
CN (1) CN110009435A (zh)
TW (1) TW202025045A (zh)
WO (1) WO2020134699A1 (zh)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110009435A (zh) * 2018-12-25 2019-07-12 阿里巴巴集团控股有限公司 基于区块链的发票报销方法及装置、电子设备
CN110473095A (zh) * 2019-07-31 2019-11-19 阿里巴巴集团控股有限公司 基于区块链的票据状态推送方法及装置、电子设备、存储介质
WO2021017470A1 (zh) * 2019-07-31 2021-02-04 创新先进技术有限公司 基于区块链的状态机维护方法及装置
CN110473081A (zh) * 2019-07-31 2019-11-19 阿里巴巴集团控股有限公司 基于区块链的电子票据报销方法及装置、电子设备
CN110458538B (zh) * 2019-07-31 2021-09-24 创新先进技术有限公司 基于区块链的状态机维护方法及装置、电子设备、存储介质
US11250438B2 (en) 2019-07-31 2022-02-15 Advanced New Technologies Co., Ltd. Blockchain-based reimbursement splitting
CN110443612B (zh) * 2019-07-31 2020-12-22 创新先进技术有限公司 一种基于区块链的报销费用分割方法、装置及电子设备
US10963854B2 (en) 2019-07-31 2021-03-30 Advanced New Technologies Co., Ltd. Blockchain-based electronic bill reimbursement method, apparatus, and electronic device
CN110599276B (zh) * 2019-08-08 2021-07-06 腾讯科技（深圳）有限公司 票据报销方法、装置和设备及计算机存储介质
CN110517098A (zh) * 2019-08-13 2019-11-29 横琴包星人网络科技有限公司 一种高效的发票报销系统
CN111192098A (zh) * 2019-12-27 2020-05-22 航天信息股份有限公司 一种基于增值税发票版式文件的防伪税控方法及系统
CN112488778A (zh) * 2020-10-31 2021-03-12 远光软件股份有限公司 一种票据处理的方法及相关装置
CN112529644A (zh) * 2020-12-23 2021-03-19 安徽航天信息有限公司 一种电子发票开具的方法、装置及存储介质
CN113222725B (zh) * 2021-05-25 2022-08-12 支付宝(杭州)信息技术有限公司 基于区块链的数据处理方法及装置
CN113222555B (zh) * 2021-05-28 2022-05-17 支付宝(杭州)信息技术有限公司 数据处理方法、装置、设备及系统
CN113282671A (zh) * 2021-06-10 2021-08-20 支付宝(杭州)信息技术有限公司 基于区块链的理赔方法及装置、电子设备
CN114049192B (zh) * 2022-01-12 2022-04-12 广东企数标普科技有限公司 基于智能算法的发票数据处理方法及装置
CN117273974B (zh) * 2023-11-21 2024-02-06 中国人寿保险股份有限公司上海数据中心 基于区块链共识的大型企业费用报销数据生成验证方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106952124A (zh) * 2017-03-16 2017-07-14 北京牛链科技有限公司 基于分布式记账的电子发票管理系统和方法
US20180082291A1 (en) * 2016-09-16 2018-03-22 Kountable, Inc. Systems and Methods that Utilize Blockchain Digital Certificates for Data Transactions
CN108648066A (zh) * 2018-04-28 2018-10-12 济南浪潮高新科技投资发展有限公司 一种基于区块链的发票管理系统及方法
CN110009435A (zh) * 2018-12-25 2019-07-12 阿里巴巴集团控股有限公司 基于区块链的发票报销方法及装置、电子设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180101914A1 (en) * 2016-10-10 2018-04-12 Escolhalegal, Llc Systems, methods and machine-readable mediums for data management and payment processing
CN108830600B (zh) * 2018-06-19 2022-02-18 方欣科技有限公司 一种基于区块链的电子发票系统及实现方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180082291A1 (en) * 2016-09-16 2018-03-22 Kountable, Inc. Systems and Methods that Utilize Blockchain Digital Certificates for Data Transactions
CN106952124A (zh) * 2017-03-16 2017-07-14 北京牛链科技有限公司 基于分布式记账的电子发票管理系统和方法
CN108648066A (zh) * 2018-04-28 2018-10-12 济南浪潮高新科技投资发展有限公司 一种基于区块链的发票管理系统及方法
CN110009435A (zh) * 2018-12-25 2019-07-12 阿里巴巴集团控股有限公司 基于区块链的发票报销方法及装置、电子设备

Also Published As

Publication number Publication date
CN110009435A (zh) 2019-07-12
TW202025045A (zh) 2020-07-01

Similar Documents

Publication Publication Date Title
WO2020134699A1 (zh) 基于区块链的发票报销方法、装置及电子设备
US11178151B2 (en) Decentralized database identity management system
TWI762818B (zh) 基於區塊鏈的發票創建方法及裝置、電子設備
JP7141193B2 (ja) ブロックチェーン・ネットワークに対するドキュメント・アクセス
US11070360B2 (en) Parallel transaction validation and block generation in a blockchain
US11240001B2 (en) Selective access to asset transfer data
WO2020119286A1 (zh) 基于区块链的发票创建方法及装置、电子设备
US20200074458A1 (en) Privacy preserving transaction system
EP3864816B1 (en) Blockchain notification board storing blockchain resources
US10997159B2 (en) Blockchain notification board storing blockchain resources
US11849047B2 (en) Certifying authenticity of data modifications
US11196568B2 (en) Identity protection
US11195180B2 (en) Virtual blockchain
US10936445B2 (en) Resource management
US11520773B2 (en) Blockchain notification board storing blockchain resources
US11489672B2 (en) Verification of conditions of a blockchain transaction
US11240000B2 (en) Preservation of uniqueness and integrity of a digital asset
US20200311695A1 (en) Privacy-preserving gridlock resolution
US11487741B2 (en) Preservation of uniqueness and integrity of a digital asset
US11032083B2 (en) Atomic transactional processing
US11269858B2 (en) Information management in a decentralized database including a fast path service
US20200143365A1 (en) Real-time monitoring of objects in blockchain networks
US20200169125A1 (en) Wireless energy transfer
US11418322B2 (en) Information management in a decentralized database including a fast path service
US10783589B2 (en) Detection of abnormal estimates

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19906553

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19906553

Country of ref document: EP

Kind code of ref document: A1