WO2020119287A1

WO2020119287A1 - Blockchain-based invoice creation method and apparatus, and electronic device

Info

Publication number: WO2020119287A1
Application number: PCT/CN2019/113422
Authority: WO
Inventors: 段金明; 孙震; 阚文虎; 肖汉松; 杜华兵; 邓福喜; 陈锐; 潘强
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2018-12-13
Filing date: 2019-10-25
Publication date: 2020-06-18
Also published as: TWI762818B; TW202022857A; CN110060112A

Abstract

A blockchain-based invoice creation method and apparatus and an electronic device; the method may comprise: receiving an invoice creation request submitted by a user by means of a client terminal, the invoice creation request comprising a transaction ID and invoice creation information inputted by the user (102); in response to the invoice creation request, determining whether evidence of a target transaction corresponding to the transaction ID and at least one item of key information used for indicating that the target transaction is a valid transaction are stored on a blockchain (104); and, if it is determined that evidence of the target transaction and the key information are stored on the blockchain, then invoking invoice creation logic stated in a smart contract, creating an invoice for the target transaction on the basis of the invoice creation information, and publishing the created invoice to the blockchain (106).

Description

Blockchain-based invoice creation method and device, and electronic equipment

Technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular to a blockchain-based invoice creation method and device, and electronic equipment.

Background technique

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.

Summary of the invention

In view of this, one or more embodiments of this specification provide a blockchain-based invoice creation method and device, and electronic equipment.

To achieve the above purpose, one or more embodiments of this specification provide technical solutions as follows:

According to a first aspect of one or more embodiments of this specification, a blockchain-based invoice creation method is proposed, which is applied to blockchain nodes. The method includes:

Receiving an invoice creation request submitted by a user through a client; wherein the invoice creation request includes a transaction identifier and invoice creation information input by the user;

In response to the invoice creation request, determining whether a target transaction corresponding to the transaction identifier is deposited on the blockchain; and, at least one piece of key information for indicating that the target transaction is a valid transaction;

If it is determined that the target transaction and the key information are stored on the blockchain, call the invoice creation logic declared in the smart contract, create an invoice for the target transaction based on the invoice creation information, and then create the invoice Publish to the blockchain.

According to a second aspect of one or more embodiments of this specification, a blockchain-based invoice creation device is proposed, which is applied to a blockchain node. The device includes:

The first receiving unit receives an invoice creation request submitted by a user through a client; wherein the invoice creation request includes a transaction identifier and invoice creation information input by the user;

A determining unit, in response to the invoice creation request, determining whether a target transaction corresponding to the transaction identifier is deposited on the blockchain; and, at least one piece of key information for indicating that the target transaction is a valid transaction ;

The creation unit, if it is determined that the target transaction and the key information are stored on the blockchain, call the invoice creation logic declared in the smart contract, create an invoice for the target transaction based on the invoice creation information, and The created invoice is posted to the blockchain.

According to a third aspect of one or more embodiments of this specification, an electronic device is provided, including:

processor;

Memory for storing processor executable instructions;

Wherein, the processor executes the executable instruction to implement the method as described in any one of the above embodiments.

BRIEF DESCRIPTION

FIG. 1 is a flowchart of a blockchain-based invoice creation method provided by an exemplary embodiment.

FIG. 2 is a schematic diagram of the overall architecture of an invoice creation solution provided by an exemplary embodiment.

FIG. 3 is a schematic diagram of interaction of transaction on-chain provided by an exemplary embodiment.

4 is a flowchart of a blockchain-based invoice creation method provided by an exemplary embodiment.

FIG. 5 is a flowchart of a blockchain-based invoice declaration method provided by an exemplary embodiment.

6 is a schematic structural diagram of an apparatus provided by an exemplary embodiment.

7 is a block diagram of a blockchain-based invoice creation device provided by an exemplary embodiment.

detailed description

Exemplary embodiments will be described in detail here, examples of which are shown in the drawings. When referring to the drawings below, unless otherwise indicated, the same numerals in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. In addition, 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 creation 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 creation request submitted by a user through a client; wherein the invoice creation request includes a transaction identifier and invoice creation information input by the user.

In an embodiment, the client may be any type of electronic device such as a mobile phone, tablet computer, smart watch, etc. used by the transaction participants, which is not limited in this specification. Participants in the transaction can interact with the blockchain nodes connected to the electronic device by logging in the registered account on the electronic device.

In an embodiment, after completing a transaction, the transaction participant may 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. For example, the transaction information may include transaction identification, transaction platform, transaction amount, transaction content, transaction participants, transaction time, etc. Of course, this specification does not limit the specific content of the transaction information. By publishing transaction information to the blockchain, each blockchain node records a complete transaction information, then even if a node has data corruption problems, it will not affect the overall data integrity; at the same time, it can be fully The non-tampering modification of the data stored on the blockchain prevents the criminals from maliciously modifying the transaction information, guarantees the security and transparency of the recorded transaction information, and facilitates the traceability of users.

Step 104: In response to the invoice creation request, determine whether a target transaction corresponding to the transaction identifier is deposited on the blockchain; and, at least one piece of key information for indicating that the target transaction is a valid transaction .

In one embodiment, it is possible to find whether there is a corresponding target transaction on the blockchain based on the transaction identifier. In other words, it is necessary to determine whether the transaction corresponding to the transaction identifier exists objectively. Further, if the target transaction is stored on the blockchain, it is necessary to further determine whether the target transaction is a valid transaction; if so, call the invoice creation logic declared in the smart contract. By determining that the target transaction is an objectively existing transaction, and further determining whether the target transaction is a valid transaction (it can be understood that the target transaction is a transaction that has actually occurred), it can effectively prevent users from invoicing.

When determining whether the target transaction is a valid transaction, at least one kind of key information of the target transaction stored on the blockchain can be used. After a transaction participant completes a transaction, in addition to the transaction information, it can also send at least one kind of key information indicating that the transaction is a valid transaction to the blockchain node, so that the blockchain node uses the key Information is posted to the blockchain. Further, the blockchain node can publish the transaction information and key information of the transaction on the blockchain in association. Based on the above deposit of key information of the transaction, in one case, it can be determined whether at least one piece of key information indicating that the target transaction is a valid transaction is stored on the blockchain, and if so, the target transaction can be determined as Effective transaction. In another case, it may be determined whether at least one piece of key information indicating that the target transaction is a valid transaction is stored on the blockchain. If it is determined that the at least one piece of key information is stored on the blockchain, it may be It is further determined whether the various key information in the at least one key information is complete, and if so, the target transaction can be determined to be a valid transaction, and then the invoice creation logic declared in the smart contract can be called. The at least one piece of key information may include at least one of the following: order records, logistics records, payment records corresponding to the target transaction; and identity information of the participant corresponding to the target transaction.

It should be noted that the above-mentioned operation to determine whether the target transaction is a valid transaction can be performed by the blockchain node itself, or it can be a smart contract (declared with verification logic, which is used to determine whether any transaction is pre-deployed on the blockchain) For effective transactions), this manual does not limit this.

Step 106, if it is determined that the target transaction and the key information are stored on the blockchain, call the invoice creation logic declared in the smart contract, create an invoice for the target transaction based on the invoice creation information, and The created invoice is posted to the blockchain.

In one case, the invoice creation information may include the header information of the invoice and the transaction information of the transaction corresponding to the transaction identifier (entered by the user), and the blockchain node receives the transaction included in the invoice creation information after receiving the invoice creation request The information is compared with the transaction information (corresponding to the transaction identifier) stored on the blockchain. When the comparison result is consistent, the invoice is directly created for the target transaction based on the transaction information and header information contained in the invoice creation information. For example, after receiving the invoice creation request, the blockchain node reads the transaction information contained in the invoice creation information and calculates the first hash value, and then compares the first hash value with the transaction information stored on the blockchain (Corresponding to the transaction identifier) the second hash value is compared, when 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 it can be directly The transaction information and header information entered by the user creates an invoice for the target transaction without reading the transaction information of the target transaction on the blockchain.

In another case, the invoice creation information may include only the header information of the invoice. After receiving the invoice creation request and determining that there is a target transaction on the blockchain, the blockchain node further reads the certificate on the blockchain The transaction information of the target transaction, and then create an invoice for the target transaction based on the read transaction information and the header information of the invoice.

In one embodiment, after the invoice is created for the target transaction, the target transaction can be further marked as invoice created. Among them, a field can be added to the field of the target transaction for certificate registration to mark the invoice creation status, and the invoice creation status of the target transaction can also be associated and stored on the blockchain. This specification does not limit this. By recording the invoice creation status of the transaction, when receiving the invoice creation request submitted by the user through the client, you can first determine the invoice creation status of the transaction corresponding to the invoice creation request; if it is the invoice creation status, you can directly report to the customer The terminal will return a prompt message that an invoice has been issued, otherwise enter the above-mentioned invoice creation process.

In an embodiment, based on posting the created invoice to the blockchain in association with the target transaction, a smart contract can be deployed for tax declaration of the invoice, so as to realize the tax declaration of the invoice based on the blockchain. Therefore, the blockchain node can receive the tax declaration request submitted by the user through the client (the tax declaration request includes the invoice identifier), and in response to the tax declaration request, call the invoice declaration logic declared in the smart contract, based on the blockchain The invoice corresponding to the invoice identification is certified to complete the tax declaration. Similarly, after the tax declaration is completed, the invoice corresponding to the invoice identifier can be marked as declared. Among them, you can add a field in the field of the certificate invoice to mark the invoice declaration status, or you can additionally link the certificate invoice declaration status of the transaction on the blockchain. This manual does not limit this. By recording the invoice declaration status of the invoice, when receiving the tax declaration request submitted by the user through the client, you can first determine the invoice declaration status of the invoice corresponding to the tax declaration request; if it is the declared status, you can directly report to the client Return the notification message that has been declared, otherwise enter the above-mentioned tax declaration process.

In an embodiment, the above-mentioned blockchain can be an alliance chain, and the member nodes of the alliance chain can include a payment platform and a tax authority. Among them, the tax authority can act as a supervisor to view information such as transactions and invoices on the blockchain.

FIG. 2 is a schematic diagram of the overall architecture of an invoice creation solution provided by an exemplary embodiment. As shown in FIG. 2, after completing a transaction between transaction participants, the client 21 can send a recording request to the server 22 to enable the server 22 to publish the transaction information of the transaction to the blockchain. Further, when there is a demand for invoicing by the transaction participants, the client 21 can send an invoice creation request to the server 22, and after receiving the invoice creation request (including the transaction identifier and the invoice creation information input by the user), the server 22 Determine whether there is a target transaction corresponding to the transaction ID on the blockchain, and call the invoice creation logic declared in the smart contract to create an invoice for the target transaction when the target transaction is stored on the blockchain. Of invoices are posted to the blockchain.

In order to facilitate understanding, the invoice creation scheme of this specification will be described in detail with reference to FIGS. 3-5 for the operations and functions implemented by the client 21 and the server 22 in the invoice creation process respectively. FIG. 3 is a schematic diagram of interaction of transaction on-chain provided by an exemplary embodiment. As shown in FIG. 3, the interaction process may include the following steps:

In step 302, a binding relationship is established between the client 21 and the server 22.

In an embodiment, the binding relationship to be established is the binding relationship between the identity information of the transaction participant and the device information of the client 21. Based on the binding relationship, when the server 22 receives the transaction record request, the invoice creation request, and the tax declaration request subsequently sent by the client 21, it can confirm that these requests correspond to the transaction participant.

For example, the transaction participant may register an account with the server 22 in advance to obtain a registered account uniquely corresponding to itself. Then, the transaction participant can log in to the registered account on the client 21, and the server 22 determines the registered account (corresponding to the transaction participant) and the client based on the login information of the registered account on the client 21 21 established a binding relationship.

In step 304, the client 21 signs the recorded transaction and key information.

In an embodiment, after completing the transaction between the transaction participants, the client 21 may submit a transaction record request to the server 22, so that the server 22 publishes the transaction information to be recorded and the key information of the transaction to the blockchain in. Among them, the transaction participants 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 transaction information input by the transaction participants and the key information of the transaction, the client 21 can generate a transaction record request (including transaction information and key information) and pass the private key corresponding to the digital identity of the transaction participant Sign the transaction record request.

In step 306, the client 21 submits a transaction record request to the server 22.

In step 308, the server 22 verifies the signature.

In one embodiment, a blockchain client runs on the server 22, so that the server 22 is configured as a blockchain node. After receiving the transaction record request, the server 22 may determine the identity of the transaction participant based on the binding relationship established in the above step 302, so that the public key corresponding to the transaction participant may be checked to determine that the transaction record request has been issued. The transaction participant authorizes it, and it is not sent by a criminal who pretends to be the identity of the transaction participant.

In one embodiment, when the verification fails, because the client is bound to the transaction participant through the registered account in advance, indicating that there may be a criminal who pretends to be the identity of the transaction participant, then an alarm operation can be triggered and the client is temporarily blocked Access to blockchain nodes.

In step 310, the server 22 publishes the transaction information and key information in association with the blockchain.

For example, transaction information may include transaction identification, transaction platform, transaction amount, transaction content, transaction participants, transaction time, etc.; key information may include order records, logistics records, payment records, identity information of transaction participants, etc. Among them, the order information can be the contract signed between the transaction participants, the details of the transaction objects (such as commodities, technical support, etc.); the logistics record can be the logistics information of the transaction object; the payment record can be the transaction participants Payment and collection details, the name of the account opening bank, account number of the account opening bank, etc.; the identity information of the transaction participants can be the company name, taxpayer identification number, registered address, etc. Of course, this manual does not limit the specific content of transaction information and key information.

Please refer to FIG. 4, which is a flowchart of a blockchain-based invoice creation method provided by an exemplary embodiment. As shown in FIG. 4, this method is applied to blockchain nodes (taking server 22 as an example), and may include the following steps:

Step 402: Receive an invoice creation request submitted by a user through the client 21.

In one embodiment, the invoice creation request includes the transaction identification and the invoice creation information input by the user through the client.

Step 404, if there is a target transaction on the blockchain, then go to step 406B; otherwise, go to step 406A.

Step 406A: Return a prompt message to the client 21 that the transaction does not exist.

In one embodiment, it can be determined whether there is a target transaction corresponding to the transaction identifier on the blockchain according to the transaction identifier. When the target transaction is not stored on the blockchain, it means that the transaction corresponding to the invoice created by the client 21 at this time (ie, the target transaction) is not an objectively existing transaction, so the prompt message can be returned to remind the user that the transaction does not exist.

Step 406B, if the target transaction on the blockchain is marked as invoice created, then go to step 408A; otherwise, go to step 408B.

Step 408A: Return a prompt message to the client 21 that the invoice has been issued.

Step 408B, if there is key information about the target transaction associated with the certificate on the blockchain, then go to step 410B; otherwise, go to step 410A.

In step 410A, a prompt message indicating that the transaction is invalid is returned to the client 21.

In step 408B, when the key information of the target transaction on the blockchain is not associated, it means that the transaction corresponding to the invoice created by the client 21 at this time (ie, the target transaction) is not a valid transaction (ie, the target transaction is not a real transaction The transaction that occurred; in other words, the target transaction has false information), so the prompt message can be returned to remind the user that the transaction is an invalid transaction.

Following step 410B, when the key information of the associated deposit certificate on the blockchain is incomplete, it means that the transaction corresponding to the invoice created by the client 21 at this time (ie, the target transaction) is not a valid transaction (ie, the target transaction is not a real occurrence In other words, there is at least a part of false information in the target transaction), so the prompt message can be returned to remind the user that the transaction is an invalid transaction. For example, the key information includes order records, logistics records, payment records, and identity information of transaction participants. It is assumed that when the blockchain only associates the order records, payment records, and identity information of transaction participants with the target transaction, and If the payment record is not associated with a certificate, the target transaction can be determined to be an invalid transaction.

Step 410B, if the key information is complete, then go to step 412; otherwise, go to step 410A.

In an embodiment, the above-mentioned operation of determining whether the target transaction is a valid transaction (steps 406B-410B) can be performed by the server 22 itself, or it can be a smart contract (declared with verification logic, used to pre-deploy on the blockchain) In order to determine whether any transaction is a valid transaction), this manual does not limit this. It can be seen that through the above process of determining whether the target transaction is a valid transaction, it can effectively prevent users from invoicing falsely.

In step 412, the invoice creation logic declared in the smart contract is called, and an invoice is created for the target transaction according to the invoice creation information.

In one embodiment, the smart contract can be pre-deployed on the blockchain by payment institutions and tax authorities.

In one case, the invoice creation information input by the user may include the header information of the invoice and the transaction information of the target transaction. After receiving the invoice creation request, the server 22 deposits the transaction information contained in the invoice creation information with the blockchain certificate The transaction information (corresponding to the transaction ID) is compared. When the comparison result is consistent, the invoice is created directly for the target transaction based on the transaction information and header information contained in the invoice creation information. For example, after receiving the invoice creation request, the server 22 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 information stored on the blockchain (and The second hash value corresponding to the transaction ID is compared. When 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 user can directly input The transaction information and header information create an invoice for the target transaction without reading the transaction information of the target transaction on the blockchain, thereby improving the efficiency of creating invoices.

In another case, the invoice creation information entered by the user may include only the header information of the invoice. After receiving the invoice creation request and determining that there is a target transaction on the blockchain, the server 22 further reads the deposit on the blockchain. Confirm the transaction information of the target transaction, and then create an invoice for the target transaction based on the read transaction information and the header information of the invoice.

Step 414: Publish the created invoice to the blockchain.

In step 416, the target transaction is marked as invoice created.

In one embodiment, the target transaction can be marked as created invoice status after the invoice is created, or the target transaction can be marked as created invoice status after the created invoice is posted to the blockchain. This specification is not correct. This is restricted.

In an embodiment, a field may be added to the field of the target transaction for certificate registration to mark the invoice creation status, or an invoice creation status of the target transaction for certificate deposit may be additionally associated on the blockchain, which is not carried out in this specification limit. By recording the invoice creation status of the transaction, when receiving the invoice creation request submitted by the user through the client, you can first determine the invoice creation status of the transaction corresponding to the invoice creation request; if it is the invoice creation status, you can directly report to the customer The terminal will return a prompt message that an invoice has been issued, otherwise enter the above-mentioned invoice creation process.

Please refer to FIG. 5, which is a flowchart of a blockchain-based invoice declaration method 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 a tax declaration request submitted by a user through the client 21.

In one embodiment, the tax declaration request includes the transaction identification.

Step 504, if the invoice corresponding to the invoice identifier stored on the blockchain is marked as declared, then go to step 510; otherwise, go to step 506.

In step 506, the invoice declaration logic declared in the smart contract is invoked to complete the tax declaration based on the invoice corresponding to the invoice identifier stored on the blockchain.

In step 508, the invoice corresponding to the invoice identifier is marked as declared.

In one embodiment, a field can be added in the field of depositing the invoice to mark the invoice declaration status, and the invoice declaration status of the invoice depositing the invoice can also be associated on the blockchain. This specification does not limit this . By recording the invoice declaration status of the invoice, when receiving the tax declaration request submitted by the user through the client, you can first determine the invoice declaration status of the invoice corresponding to the tax declaration request; if it is the declared status, you can directly report to the client Return the notification message that has been declared, otherwise enter the above-mentioned tax declaration process.

In step 510, a prompt message that the invoice has been declared is returned to the client 21.

It should be noted that there are narrow transactions and broad transactions in the transactions in the blockchain. The narrow sense of the 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 that have nothing to do with 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.

6 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 6. At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610. Of course, it may include hardware required for other services. The processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs it to form a blockchain-based invoice creation device at a logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as a logic device or a combination of software and hardware, 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.

Please refer to FIG. 7. In the software implementation, the blockchain-based invoice creation device may include:

The first receiving unit 71 receives an invoice creation request submitted by a user through a client; wherein the invoice creation request includes a transaction identifier and invoice creation information input by the user;

The determining unit 72, in response to the invoice creation request, determines whether a target transaction corresponding to the transaction identifier is deposited on the blockchain; and, at least one key for indicating that the target transaction is a valid transaction information;

The creation unit 73, if it is determined that the target transaction and the key information are stored on the blockchain, invokes the invoice creation logic declared in the smart contract, creates an invoice for the target transaction based on the invoice creation information, and Publish the created invoice to the blockchain.

Optionally, the creating unit 73 is specifically used to:

If it is determined that the target transaction and the at least one key information are stored on the blockchain, it is further determined whether the various key information in the at least one key information is complete;

If yes, call the invoice creation logic declared in the smart contract.

Optionally, the at least one piece of key information includes at least one of the following: order records, logistics records, payment records corresponding to the target transaction; and identity information of the participant corresponding to the target transaction.

Optional, also includes:

The second receiving unit 74 receives the tax declaration request submitted by the user through the client; wherein the tax declaration request includes an invoice identifier;

The declaration unit 75, in response to the tax declaration request, invokes the invoice declaration logic declared in the smart contract, and completes the tax declaration based on the invoice stored on the blockchain and corresponding to the invoice identifier.

Optional, also includes:

The marking unit 76 marks the invoice corresponding to the invoice identifier as declared after the tax declaration is completed.

Optionally, the blockchain is an alliance chain; the member nodes of the alliance chain include: a payment platform and a tax authority.

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 with 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.

In a typical configuration, the computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include non-permanent memory, random access memory (RAM) and/or non-volatile memory in computer-readable media, such as read only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

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. As defined in this article, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

It should also be noted that the terms "include", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device that includes a series of elements includes not only those elements, but also includes Other elements not explicitly listed, or include elements inherent to this process, method, commodity, or equipment. Without more restrictions, the element defined by the sentence "include one..." does not exclude that there are other identical elements in the process, method, commodity or equipment that includes the element.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the particular order shown or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only, and is not intended to limit one or more embodiments of this specification. The singular forms "a", "said" and "the" used in one or more embodiments of the present specification and the appended claims are also intended to include the majority 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 one or more embodiments in this specification 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. 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 determination".

The above 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. Anything within the spirit and principle of one or more embodiments of this specification, Any modifications, equivalent replacements, improvements, etc., should be included within the scope of protection of one or more embodiments of this specification.

Claims

A blockchain-based invoice creation method is applied to blockchain nodes. The method includes:

Receiving an invoice creation request submitted by a user through a client; wherein the invoice creation request includes a transaction identifier and invoice creation information input by the user;

In response to the invoice creation request, determining whether a target transaction corresponding to the transaction identifier is deposited on the blockchain; and, at least one piece of key information for indicating that the target transaction is a valid transaction;

If it is determined that the target transaction and the key information are stored on the blockchain, call the invoice creation logic declared in the smart contract, create an invoice for the target transaction based on the invoice creation information, and then create the invoice Publish to the blockchain.
According to the method of claim 1, if it is determined that the target transaction and the key information are certified on the blockchain, calling the invoice creation logic declared in the smart contract includes:

If it is determined that the target transaction and the at least one key information are stored on the blockchain, it is further determined whether the various key information in the at least one key information is complete;

If yes, call the invoice creation logic declared in the smart contract.
The method according to claim 1, wherein the at least one key information includes at least one of the following: an order record, a logistics record, and a payment record corresponding to the target transaction; and, the participant's corresponding to the target transaction Identity Information.
The method of claim 1, further comprising:

Receive a tax declaration request submitted by a user through a client; wherein the tax declaration request includes an invoice identifier;

In response to the tax declaration request, the invoice declaration logic declared in the smart contract is invoked, and the tax declaration is completed based on the invoice stored on the blockchain and corresponding to the invoice identifier.
The method of claim 4, further comprising:

After completing the tax declaration, the invoice corresponding to the invoice identifier is marked as declared.
According to the method of claim 1, the blockchain is a consortium chain; the member nodes of the consortium chain include: payment platforms and tax authorities.
A blockchain-based invoice creation device applied to blockchain nodes, the device includes:

The first receiving unit receives the invoice creation request submitted by the user through the client; wherein the invoice creation request includes a transaction identifier and invoice creation information input by the user;

A determining unit, in response to the invoice creation request, determining whether a target transaction corresponding to the transaction identifier is deposited on the blockchain; and, at least one piece of key information for indicating that the target transaction is a valid transaction ;

The creation unit, if it is determined that the target transaction and the key information are stored on the blockchain, call the invoice creation logic declared in the smart contract, create an invoice for the target transaction based on the invoice creation information, and The created invoice is posted to the blockchain.
The apparatus according to claim 7, the creation unit is specifically configured to:

If it is determined that the target transaction and the at least one key information are stored on the blockchain, it is further determined whether the various key information in the at least one key information is complete;

If yes, call the invoice creation logic declared in the smart contract.
The apparatus according to claim 7, the at least one piece of key information includes at least one of the following: an order record, a logistics record, and a payment record corresponding to the target transaction; and, the participant's corresponding to the target transaction Identity Information.
The apparatus according to claim 7, further comprising:

The second receiving unit receives the tax declaration request submitted by the user through the client; wherein the tax declaration request includes an invoice identifier;

The declaration unit, in response to the tax declaration request, invokes the invoice declaration logic declared in the smart contract, and completes the tax declaration based on the invoice stored on the blockchain and corresponding to the invoice identifier.
The apparatus according to claim 10, further comprising:

The marking unit, after completing the tax declaration, marks the invoice corresponding to the invoice identifier as declared.
The device according to claim 7, wherein the blockchain is an alliance chain; member nodes of the alliance chain include: a payment platform and a tax authority.
An electronic device, including:

processor;

Memory for storing processor executable instructions;

Wherein, the processor executes the executable instruction to implement the method according to any one of claims 1-6.