An invoice archiving method, device and computer-readable storage medium

Abstract

The present application discloses a method, device, and computer-readable storage medium for archiving invoices. The method includes: receiving an archiving instruction for storing an invoice, where the archiving instruction carries an identifier of the invoice; obtaining an electronic file and invoice information of the invoice corresponding to the identifier; uploading the electronic file to the InterPlanetary File System (IPFS) to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by the IPFS; and uploading the file identifier and the invoice information to a blockchain network. By using the present application, it is possible to prevent the invoice from being tampered with after archiving, making the archiving of the invoice meaningful.

Description

Technical Field

[0001] The present invention relates to the field of Internet technologies, and particularly to an invoice archiving method, a server, and a computer-readable storage medium. Background Art

[0002] With the rapid development of information, electronic invoices can be used by merchants in the same form as paper invoices, which are uniformly issued by the tax bureau. However, due to the invoicing habits of merchants, some merchants issue paper invoices when invoicing, and some merchants issue electronic invoices when invoicing. Therefore, when people reimburse the company, they need to submit both to the company. When the finance department saves the invoices, they can archive the invoices in two ways. One way is to print out the electronic invoices and save them together with the paper invoices in the form of paper invoices. The other way is to scan the paper invoices into electronic documents and store them in the company's database for storage. Thus, archiving invoices in paper form or storing them in electronic document form within the company is easily tampered with by humans, making invoice archiving meaningless. Summary of the Invention

[0003] Embodiments of the present application provide an invoice archiving method, device, and computer-readable storage medium, which can prevent invoices from being tampered with by humans after archiving, and can provide verification services for the archived invoices, improving the efficiency and accuracy of invoice verification.

[0004] In a first aspect, embodiments of the present application provide an invoice archiving method, and the invoice archiving method includes:

[0005] Receiving an archiving instruction for storing an invoice, where the archiving instruction carries an identifier of the invoice;

[0006] Obtaining an electronic file and invoice information of the invoice corresponding to the identifier;

[0007] Uploading the electronic file to the InterPlanetary File System (IPFS) to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by the IPFS;

[0008] Uploading the file identifier and the invoice information to a blockchain network.

[0009] In a possible implementation manner, the blockchain network includes N blockchains, and there is a communication connection between the N blockchains, where N is an integer greater than or equal to 1. The uploading the file identifier and the invoice information to the blockchain network includes:

[0010] Upload the file identifier and the invoice information to the first blockchain, where the first blockchain is any blockchain in the blockchain network.

[0011] In a possible implementation, after uploading the file identifier and the invoice information to the blockchain network, the method further includes:

[0012] Obtain the invoice information and the electronic file of the invoice to be verified;

[0013] According to the correspondence between the file identifier and the invoice information, obtain the file identifier corresponding to the invoice information of the invoice to be verified from the first blockchain;

[0014] Download the first electronic file from the IPFS, where the first electronic file is the electronic file corresponding to the obtained file identifier;

[0015] Verify the invoice to be verified according to the first electronic file and the electronic file of the invoice to be verified.

[0016] In a possible implementation, the step of obtaining the file identifier corresponding to the invoice information of the invoice to be verified from the first blockchain according to the correspondence between the file identifier and the invoice information includes:

[0017] Determine the block height according to the invoice information of the invoice to be verified to obtain the block height to be verified;

[0018] According to the correspondence between the file identifier and the invoice information, obtain the file identifier corresponding to the invoice information of the invoice to be verified from the block corresponding to the block height to be verified in the first blockchain.

[0019] In a possible implementation, the step of verifying the invoice to be verified according to the first electronic file and the electronic file of the invoice to be verified includes:

[0020] In the case where the similarity between the first electronic file and the electronic file of the invoice to be verified is greater than or equal to the threshold, determine that the identifier of the invoice to be verified is the same as the identifier of the invoice corresponding to the first electronic file;

[0021] In the case where the similarity between the first electronic file and the electronic file of the invoice to be verified is less than the threshold, determine that the identifier of the invoice to be verified is different from the identifier of the invoice corresponding to the first electronic file.

[0022] In a possible implementation, after determining that the identifier of the invoice to be verified is the same as the identifier of the invoice corresponding to the first electronic file, the method further includes:

[0023] Determine whether the invoice has been tampered with according to the Merkle root value of the block corresponding to the height of the block to be verified in the first blockchain.

[0024] In a possible implementation, the method further includes:

[0025] Determine the block height according to the invoice information;

[0026] Obtain the Merkle root value of the block corresponding to the block height in the first blockchain;

[0027] Upload the Merkle root value to a second blockchain, where the second blockchain is any blockchain other than the first blockchain in the blockchain network;

[0028] The determining whether the invoice has been tampered with according to the Merkle root value of the block corresponding to the height of the block to be verified in the first blockchain includes:

[0029] Obtain the Merkle root value of the block corresponding to the height of the block to be verified, and obtain the Merkle root value to be verified;

[0030] Query whether the Merkle root value to be verified is stored in the database, where the database stores data in the second blockchain;

[0031] When the Merkle root value to be verified is queried in the database, determine that the invoice has not been tampered with.

[0032] In a second aspect, an embodiment of the present application provides an invoice archiving device, and the device includes:

[0033] A receiving unit, configured to receive an archiving instruction for storing an invoice, where the archiving instruction carries an identifier of the invoice;

[0034] A first obtaining unit, configured to obtain the electronic file and invoice information of the invoice corresponding to the identifier;

[0035] A first uploading unit, configured to upload the electronic file to IPFS to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by IPFS;

[0036] A second uploading unit, configured to upload the file identifier and the invoice information to the blockchain network.

[0037] In a possible implementation, the blockchain network includes N blockchains, there is a communication connection between the N blockchains, N is an integer greater than or equal to 1, and the second uploading unit is specifically configured to:

[0038] Upload the file identifier and the invoice information to the first blockchain, where the first blockchain is any blockchain in the blockchain network.

[0039] In a possible implementation, after uploading the file identifier and the invoice information to the blockchain network, the apparatus further includes:

[0040] A second acquisition unit, configured to acquire invoice information and an electronic file of an invoice to be verified;

[0041] A third acquisition unit, configured to acquire, from the first blockchain, a file identifier corresponding to the invoice information of the invoice to be verified according to the correspondence between the file identifier and the invoice information;

[0042] A download unit, configured to download a first electronic file from the IPFS, where the first electronic file is the electronic file corresponding to the acquired file identifier;

[0043] A verification unit, configured to verify the invoice to be verified according to the first electronic file and the electronic file of the invoice to be verified.

[0044] In a possible implementation, the third acquisition unit is specifically configured to:

[0045] Determine a block height according to the invoice information of the invoice to be verified to obtain a block height to be verified;

[0046] Acquire, from the block corresponding to the block height to be verified in the first blockchain, a file identifier corresponding to the invoice information of the invoice to be verified according to the correspondence between the file identifier and the invoice information.

[0047] In a possible implementation, the verification unit is specifically configured to:

[0048] In a case where the similarity between the first electronic file and the electronic file of the invoice to be verified is greater than or equal to a threshold, determine that the identifier of the invoice to be verified is the same as the identifier of the invoice corresponding to the first electronic file;

[0049] In a case where the similarity between the first electronic file and the electronic file of the invoice to be verified is less than the threshold, determine that the identifier of the invoice to be verified is different from the identifier of the invoice corresponding to the first electronic file.

[0050] In a possible implementation, after determining that the identifier of the invoice to be verified is the same as the identifier of the invoice corresponding to the first electronic file, the apparatus further includes:

[0051] A first determination unit, configured to determine whether the invoice has been tampered with according to the Merkle root value of the block corresponding to the block height to be verified in the first blockchain.

[0052] In a possible implementation, the apparatus further includes:

[0053] A second determination unit, configured to determine a block height according to the invoice information;

[0054] A fourth acquisition unit, which acquires the Merkle root value of the block corresponding to the block height in the first blockchain;

[0055] A third upload unit, configured to upload the Merkle root value to a second blockchain, where the second blockchain is any blockchain in the blockchain network other than the first blockchain;

[0056] The first root determination unit is specifically configured to:

[0057] Acquire the Merkle root value of the block corresponding to the to-be-verified block height to obtain a to-be-verified Merkle root value;

[0058] Query whether the to-be-verified Merkle root value is stored in a database, where the database stores data in the second blockchain;

[0059] When the to-be-verified Merkle root value is queried in the database, it is determined that the invoice has not been tampered with.

[0060] In a third aspect, an embodiment of the present application provides an electronic device, which includes an output device, an input device, a processor, a memory, and a transceiver, and the output device, the input device, the processor, the memory, and the transceiver are interconnected. The transceiver is configured to receive information from other devices outside the apparatus and output information to other devices outside the apparatus. The memory is configured to store a computer program for supporting the terminal device to execute the method provided in the first aspect and / or any possible implementation manner of the first aspect. The computer program includes program instructions, and the processor is configured to call the above program instructions to execute the method provided in the first aspect and / or any possible implementation manner of the first aspect.

[0061] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program, and the computer program includes program instructions. When the program instructions are executed by a processor, the processor is caused to execute the method provided in the first aspect and / or any possible implementation manner of the first aspect.

[0062] In the embodiment of the present application, the invoice archiving can receive an archiving instruction for storing the invoice, and the archiving instruction carries the identifier of the invoice; obtain the electronic file and invoice information of the invoice corresponding to the identifier; upload the electronic file to IPFS to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by IPFS; upload the file identifier and the invoice information to the blockchain network. It can be seen that if the electronic file of the invoice is directly archived on the blockchain, the consumed resources and costs are relatively large. However, archiving the electronic file of the invoice in the InterPlanetary File System and uploading the hash value that can uniquely download the electronic file of the invoice to the blockchain network for archiving can not only ensure that it is not tampered with but also facilitate subsequent verification of the invoice. And since the hash value corresponding to the invoice is uploaded to the blockchain network, therefore, both the company internal and the tax bureau can view the archived information subsequently, which can further ensure that the invoice has not been tampered with. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0064] Figure 1 It is a system architecture diagram of a method for archiving invoices provided by an embodiment of the present application;

[0065] Figure 2 It is a flowchart of a method for archiving invoices provided by an embodiment of the present application;

[0066] Figure 3a It is a storage schematic diagram of a method for archiving invoices provided by an embodiment of the present application;

[0067] Figure 3b It is another storage scenario schematic diagram of a method for archiving invoices provided by an embodiment of the present application;

[0068] Figure 4 A flowchart of a method for archiving invoices provided by an embodiment of the present application;

[0069] Figure 5a It is an application scenario schematic diagram for verifying a method for archiving invoices provided by an embodiment of the present application;

[0070] Figure 5b It is another application scenario schematic diagram for verifying a method for archiving invoices provided by an embodiment of the present application;

[0071] Figure 6It is a schematic structural diagram of an invoice archiving device provided by an embodiment of the present application;

[0072] Figure 7 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0073] Next, the technical solutions in the present application will be clearly and completely described in conjunction with the accompanying drawings in the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0074] To better understand an invoice archiving method, device, and computer-readable storage medium provided by an embodiment of the present application, the system architecture used in the embodiment of the present application will be described first. Please refer to Figure 1 , Figure 1 It is a schematic system architecture diagram of an invoice archiving method provided by the present application. As Figure 1 shown, the system architecture may include: IPFS and a blockchain network. Among them, the InterPlanetary File System includes multiple node devices, and the blockchain network also includes multiple node devices. Among them, when archiving an invoice, a user can upload an electronic file of the invoice to IPFS through an IPFS node device. IPFS will store the file and return a file identifier, and then upload the file identifier and the invoice information extracted from the invoice to the blockchain network. Specifically, the blockchain network may include two or more blockchains. The blockchain node devices can upload data to any blockchain in the blockchain network respectively. After storing the file information and the file identifier in the first blockchain, the hash value of the Merkle root value of the block where the currently stored information is located can be calculated and stored in other chains except this blockchain for subsequent verification. When verifying an invoice, the file identifier can be obtained from the blockchain storing the file information and the file identifier, and the corresponding file can be downloaded from IPFS according to the file identifier. The downloaded file is compared with the invoice to be verified. When the comparison similarity is greater than the threshold, it is determined that the invoice to be verified corresponds to the same invoice as the downloaded file, that is, the identifiers of the invoices are the same. Then, it is further verified whether the invoice has been tampered with. By querying the hash value of the Merkle root value of the block where the invoice information and the file identifier are queried in other blockchains, when it is found, it is determined that the current invoice has not been tampered with, and the verification is completed.

[0075] In the embodiment of the present application, the invoice archiving can receive an archiving instruction for storing an invoice, and the archiving instruction carries the identifier of the invoice; obtain the electronic file and invoice information of the invoice corresponding to the identifier; upload the electronic file to IPFS to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by IPFS; upload the file identifier and the invoice information to the blockchain network. It can be seen that if the electronic file of the invoice is directly archived on the blockchain, the consumed resources and costs are relatively large. However, archiving the electronic file of the invoice in the InterPlanetary File System and uploading the hash value that can uniquely download the electronic file of the invoice to the blockchain network for archiving can not only ensure that it is not tampered with but also facilitate subsequent verification of the invoice. And since the hash value corresponding to the invoice is uploaded to the blockchain network, therefore, both within the company or the tax bureau can view the archived information subsequently, which can better ensure that the invoice has not been tampered with.

[0076] Please refer to Figure 2 , which is a schematic flowchart of a method for archiving invoices provided by the present application. As Figure 2 shown, the above method may include:

[0077] 201. Receive an archiving instruction for storing an invoice, and the archiving instruction carries the identifier of the invoice.

[0078] Specifically, the user can directly trigger an archiving instruction for storing an invoice through a node device, or can also trigger an archiving instruction for storing an invoice through other terminals. When the node device (which is both a node device of IPFS and a node device in the blockchain network) receives an archiving instruction for storing an invoice, and the instruction carries the identifier of the invoice, the node device can obtain the electronic file and invoice information of the invoice according to the identifier. The identifier can be the invoice number, or the information generated to identify the invoice, or the information extracted from the invoice that can uniquely identify it.

[0079] 202. Obtain the electronic file and invoice information of the invoice corresponding to the identifier.

[0080] Specifically, the electronic file of the corresponding invoice and invoice information are obtained according to the identifier. Among them, the electronic file of the invoice can be a scanned copy of the invoice uploaded by the user or a file of an electronic invoice. The format of the electronic file of the invoice can be a portable document format (PDF) or a portable network graphics (PNG), etc. There is no limit to the format of the electronic file of the invoice here. For the invoice information, it can be extracted from the invoice information, which can be the invoice information obtained by optical character recognition of the electronic file of the invoice, or the invoice information uploaded together when the user uploads the electronic file of the invoice. Among them, after obtaining the electronic file of the invoice and the invoice information, the electronic file of the invoice is uploaded to IPFS.

[0081] 203. Upload the above electronic file to IPFS to obtain a file identifier.

[0082] Specifically, the IPFS node device uploads the electronic file of the invoice to IPFS. For reference, please also see Figure 3a , Figure 3a which is a storage schematic diagram of an invoice archiving method provided by an embodiment of the present application. As Figure 3a shown, IPFS is a network transmission protocol designed to create persistent and distributed storage and sharing of files. It is a content-addressable peer-to-peer hypermedia distribution protocol. Content-addressable means that files are identified by generating a unique hash value through the file content, rather than by the file storage location. Files with the same content will only exist once in the system, thus saving storage space. The nodes in IPFS will form a distributed file system. Therefore, the scanned copy or electronic file of the invoice is actually a file containing the invoice image, which is relatively large. Storing it on the blockchain consumes a large amount of costs and resources, and it is not the optimal choice to store the entire invoice file on the blockchain. Therefore, the present application proposes to store the file in IPFS, which can save the resources stored on the blockchain, and store the file identifier returned by IPFS in the blockchain network for subsequent verification, while also ensuring the immutability of the archive.

[0083] Among them, when IPFS stores a file, the following steps will be experienced: The electronic file of the uploaded invoice is fragmented, and the electronic file of the invoice is split into several blocks of equal size (such as 256 kb, which is not limited here, and the size can be set manually). Calculate the hash value of each split file, and encode the calculated hash value. Here, it can be encoded with base58 to obtain the encoded hash value, which is the file identifier of the file block. After obtaining the hashes of all file blocks included in the electronic file of the invoice, these file blocks are combined, which can be pieced together into an array, and then the hash value is calculated again and encoded to obtain the final file identifier corresponding to the electronic file of the invoice. Among them, in IPFS, when the node device calculates the file identifier of the current file, the file identifier and the directory structure under the file identifier are synchronized to IPFS for subsequent reading. Here, the directory structure is that the hash values of these file blocks can be queried from the current file identifier, and the directory structure of the entire file can be obtained according to the hash value of each file block. As Figure 3a shown, after uploading the invoice to IPFS, the node device can split the file into several file blocks of 256 kb size, Figure 3a Taking 3 file blocks as an example, calculate the hash values of these three file blocks respectively to obtain three hash values. Among them, the three obtained hash values are strings composed of letters and numbers. Then, encode these three strings respectively (using the base58 encoding method) to obtain the file identifiers of the file blocks starting with "Qm...". Then, combine the obtained file identifiers into an array, calculate the hash value of the combined value, and obtain the identifier of the uploaded invoice file. This identifier is synchronized by the IPFS node device in the IPFS network for each IPFS node to read, and the file identifier can be further stored in the blockchain network.

[0084] 204. Upload the above file identifier and the above invoice information to the blockchain network.

[0085] Specifically, please refer to Figure 3b together, Figure 3b which is another schematic diagram of the storage scenario of an invoice archiving method provided by an embodiment of the present application. As Figure 3bAs shown, the file identifier and invoice information are uploaded to the blockchain network. Here, the blockchain network in this application is a blockchain network that includes at least two blockchains, and the content stored in at least two blockchains in this blockchain network is not all the same. Taking two blockchains as an example for explanation, the blockchain node device uploads the file identifier and invoice information to the first blockchain, and the first blockchain here can be any blockchain in the blockchain network. After the upload is completed, in order to verify whether the invoice has been tampered with subsequently, the Merkle root value corresponding to the block storing the file identifier and invoice information is obtained. Here, the Merkle root value is not the Merkle root value in the current block header data, but the Merkle root value calculated based on all the data in this block. It can be the Merkle root value calculated from the content stored in the current block, or the Merkle root value in the block header data of the block adjacent (plus one) to the block height of this block. The Merkle root value is stored on the second blockchain, thus completing the storage. As Figure 3b shown, after obtaining and determining the currently stored block in blockchain A, Figure 3a taking the calculation of the Merkle root value based on the stored data in the block body as an example, the Merkle root value is calculated pairwise from the data stored in the current block, and the calculated Merkle root value is stored in the second blockchain. Optionally, the second blockchain also synchronizes the data on this blockchain to the database. The synchronization method can be that when a new block is generated, the data of this block is stored in the database.

[0086] Specifically, calculating the Merkle root value can be to obtain the corresponding hash values according to the chronological order of the storage time in the current block, and then calculate the hash values pairwise until the last calculated hash value is the Merkle root value. As Figure 3b shown, in the block body in Figure 3b taking the example that four data are stored, the hash values of the two "invoice information + file identifier" stored are further calculated to obtain a hash value, and this hash value is calculated with the hash values of the "Merkle root value of block B chain 1" and "Merkle root value of block B chain 2" stored to obtain two hash values. Further calculations are performed on these two hash values, and finally a hash value is obtained, that is, the Merkle root value. This value is stored in the second blockchain. It can be understood that through layer-by-layer operations, it can be ensured that when the invoice is checked subsequently, the invoice is not tampered with.

[0087] Among them, the way to determine the block can be obtained by querying after uploading the file identifier and invoice information to the first blockchain, or the database synchronizes the content of each block in each blockchain network in the blockchain network to the database after each block is generated, and uses the block height of the block as the identifier of the current block. When obtaining the stored file identifier and hash value, it can be obtained from the database. Here, the method of obtaining the block height is not limited.

[0088] Further, this application is described by taking two blockchains included in the blockchain network as an example. In fact, multiple blockchains can be included. In blockchain A, the uploaded invoice information, file identifier, and Merkle root values of blocks on other chains are stored.

[0089] In the embodiment of this application, the archiving of invoices can receive an archiving instruction for storing invoices, and the above archiving instruction carries the identifier of the above invoice; obtain the electronic file and invoice information of the invoice corresponding to the above identifier; upload the above electronic file to IPFS to obtain a file identifier, and the above file identifier is the identifier of the above electronic file returned by the above IPFS; upload the above file identifier and the above invoice information to the blockchain network. It can be seen that if the electronic file of the invoice is directly archived on the blockchain, the consumed resources and costs are relatively large. However, archiving the electronic file of the invoice in the InterPlanetary File System and uploading the hash value that can uniquely download the electronic file of the invoice to the blockchain network for archiving can not only ensure that it is not tampered with but also facilitate subsequent verification of the invoice. And since the hash value corresponding to the invoice is uploaded to the blockchain network, therefore, both within the company and the tax bureau can view the archived information subsequently, which can further ensure that the invoice has not been tampered with.

[0090] Please refer to Figure 4 , which is another schematic flow diagram of a method for archiving invoices provided by this application. As Figure 4 shown, the above method may include:

[0091] 401. Obtain the invoice information and electronic file of the invoice to be verified.

[0092] In a possible implementation manner, after archiving is completed, it can be verified whether the invoice has been tampered with. The invoice information and electronic file of the invoice can be obtained. Among them, obtaining the information and electronic file of the invoice can be scanning the paper invoice into an electronic file, or obtaining the electronic invoice file from other terminals or servers. Among them, the invoice information can be recognized from the electronic file of the invoice, such as by scanning the QR code in the invoice, or by optical character recognition.

[0093] 402. According to the correspondence between the file identifier and the invoice information, obtain the file identifier corresponding to the invoice information of the invoice to be verified from the above first blockchain.

[0094] In a possible implementation manner, please refer to Figure 5a , Figure 5a which is a schematic diagram of an application scenario for verifying the archiving of a method for archiving invoices provided by an embodiment of this application. As Figure 5aAs shown, the file identifier corresponding to the invoice information can be queried in the database corresponding to the first blockchain according to the invoice information of the invoice to be verified.

[0095] 403. Download the first electronic file from the above IPFS. The above first electronic file is the electronic file corresponding to the obtained file identifier.

[0096] In a possible implementation manner, the electronic file can be downloaded from IPFS through the file identifier, and this file is the electronic file queried from the invoice to be verified. Among them, downloading the electronic file from IPFS and storing the electronic file are reciprocal processes. According to the file identifier, the directory structure corresponding to the file identifier can be searched. According to the file identifiers of multiple file blocks included in the directory structure, each file block corresponding to the stored file identifier is downloaded from the IPFS node respectively, and the downloaded file blocks are spliced in the order formed during storage, that is, the file blocks can be spliced well according to the order of the previously spliced array to obtain the entire required file. For the IPFS node, when the local node sends a search request, it will first search for the requested data from the locally stored data. If it cannot be found, it will send a request to the network to find the node that has the data. Once a node that has the requested data is found, the node will feedback the data. Then, the local node will cache a copy of the received file block data locally. In this way, there is an additional copy of the original data in the entire network. When more nodes request this data, the number of nodes that can respond to this request increases, and it becomes easier to request this data. And because more and more nodes store this data, the data becomes almost non-lost.

[0097] 404. Verify the invoice to be verified according to the above first electronic file and the electronic file of the invoice to be verified.

[0098] It is understandable that the invoices stored in the company are stored in the form of files or in paper form. When a third party (such as the tax bureau or the company's archive department) wants to verify whether the invoices stored locally in the company have been tampered with, it can obtain the file identifier corresponding to the current invoice information from Blockchain A in the blockchain network according to the one-to-one correspondence between the invoice information and the file identifier, that is, the file identifier of the invoice to be verified. According to the file identifier of the invoice to be verified, the electronic file of the invoice stored at the time of archiving can be obtained from IPFS. In order to verify whether the electronic file of the invoice to be verified and the downloaded electronic file correspond to the same invoice, that is, the identifiers of the invoices are the same, the similarity between the two electronic invoice files can be calculated. It can be the text similarity of the text information contained in the two invoices, or the image similarity between the two electronic invoice files, and it is judged whether the two electronic invoice files correspond to the same invoice identifier according to a preset threshold. If the similarity is greater than or equal to the threshold, it is determined that the downloaded electronic file corresponds to the same invoice identifier as the electronic file of the invoice to be verified. If the similarity is less than the threshold, it is determined that the downloaded electronic file does not correspond to the same invoice identifier as the electronic file of the invoice to be verified. If it is judged that they correspond to the same invoice identifier, it is further verified whether the invoice has been tampered with. If it is judged that they do not correspond to the same invoice identifier, it is necessary to first find the invoice corresponding to the same one and then proceed with the next verification.

[0099] In a possible implementation manner, when it is judged that the electronic file of the invoice to be verified corresponds to the same identifier as the downloaded electronic file, it can be verified whether it has been tampered with in the second blockchain by using the obtained file identifier and invoice information. Among them, the Merkle root value of the current block can be calculated according to the data of the block storing the file identifier and invoice information in the first blockchain and queried in the corresponding database of the second blockchain. When the corresponding Merkle root value is queried, it is determined that the invoice has not been tampered with. When the corresponding Merkle root value cannot be queried, it is determined that the invoice has been tampered with. Among them, such as Figure 5aAs shown, the file identifier corresponding to the invoice information to be verified is obtained, the file is queried in IPFS according to the file identifier, and the downloaded invoice file is compared with the invoice to be verified for similarity. When the similarity obtained is greater than the threshold, it is determined that the identifier of the invoice to be verified is the same as that of the invoice corresponding to the downloaded electronic file, that is, they correspond to the same invoice, and verification is performed according to the Merkle root value of block a storing the current invoice information and file identifier in blockchain A. Among them, obtaining the Merkle root value of block a may be the Merkle root value calculated according to the data stored in the block body of block a, or the Merkle root value of block a obtained from the block header of the block adjacent to block a in blockchain A. The block adjacent to block a refers to the next block of block a, that is, the block corresponding to the block height of block a plus one. After obtaining the Merkle root value of block a, query the Merkle root value in the database, which is the database corresponding to blockchain B and stores all the data on blockchain B. When the Merkle root value is queried, it is determined that there has been no tampering.

[0100] In a possible implementation, please also refer to Figure 5b , Figure 5b which is another schematic diagram of an application scenario for the inspection of an invoice archiving method provided by an embodiment of the present application. As Figure 5b shown, the solution of the present application can be applied to the application program shown in the figure (such as an instant messaging application: WeChat), and can also be applied to official accounts, mini programs in application programs, etc., which are not limited here. Taking the application in a WeChat mini program as an example for explanation, invoice archiving and invoice inspection can be performed through the "WeChat Invoice Assistant". As Figure 5b shown, in the WeChat Invoice Assistant, the user's invoices, that is, "My Invoices", can be displayed; the invoice headers saved by the user, that is, "My Invoice Headers", can also be displayed. When the user clicks the "+ Invoice Archiving" button, the electronic invoice file can be obtained from the local, or the camera can be called to take a picture of a paper invoice, and then archived according to steps 201-204 of the embodiment of the present application and displayed in "My Invoices" in the figure. After archiving, the invoice can be inspected. The invoice for inspection can also be a document obtained from the local or a file of an invoice taken by calling the camera. Then, the electronic invoice file downloaded from IPFS and the current invoice file to be verified can be displayed on the interface of the mini program for comparison display.

[0101] In the embodiments of the present application, the invoice archiving can receive an archiving instruction for storing an invoice, and the archiving instruction carries the identifier of the invoice; obtain the electronic file and invoice information of the invoice corresponding to the identifier; upload the electronic file to IPFS to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by IPFS; upload the file identifier and the invoice information to the blockchain network. It can be seen that if the electronic file of the invoice is directly archived on the blockchain, the consumed resources and costs are relatively large. However, archiving the electronic file of the invoice in the InterPlanetary File System and uploading the hash value that can uniquely download the electronic file of the invoice to the blockchain network for archiving can not only ensure that it is not tampered with but also facilitate subsequent inspection of the invoice. And since the hash value corresponding to the invoice is uploaded to the blockchain network, therefore, both the company's internal and tax authorities can view the archived information subsequently, which can better ensure that the invoice has not been tampered with.

[0102] Please refer to Figure 6 , Figure 6 FIG. 6000 is a schematic structural diagram of an invoice archiving device 6000 provided by an embodiment of the present application. The invoice archiving device 6000 provided by the embodiment of the present application includes:

[0103] A receiving unit 601, configured to receive an archiving instruction for storing an invoice, where the archiving instruction carries the identifier of the invoice;

[0104] A first obtaining unit 602, configured to obtain the electronic file and invoice information of the invoice corresponding to the identifier;

[0105] A first uploading unit 603, configured to upload the electronic file to IPFS to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by IPFS;

[0106] A second uploading unit 604, configured to upload the file identifier and the invoice information to the blockchain network.

[0107] In a possible implementation manner, the blockchain network includes N blockchains, and there is a communication connection between the N blockchains, where N is an integer greater than or equal to 1. The second uploading unit 604 is specifically configured to:

[0108] Upload the file identifier and the invoice information to the first blockchain, where the first blockchain is any blockchain in the blockchain network.

[0109] In a possible implementation manner, after uploading the file identifier and the invoice information to the blockchain network, the device 6000 further includes:

[0110] The second acquisition unit 605 is configured to acquire invoice information and an electronic document of the invoice to be verified;

[0111] The third acquisition unit 606 is configured to acquire a file identifier corresponding to the invoice information of the invoice to be verified from the first blockchain according to the correspondence between the file identifier and the invoice information;

[0112] The download unit 607 is configured to download a first electronic document from the IPFS, where the first electronic document is the electronic document corresponding to the acquired file identifier;

[0113] The verification unit 608 is configured to verify the invoice to be verified according to the first electronic document and the electronic document of the invoice to be verified.

[0114] In a possible implementation manner, the third acquisition unit 606 is specifically configured to:

[0115] Determine a block height according to the invoice information of the invoice to be verified to obtain a to-be-verified block height;

[0116] Acquire a file identifier corresponding to the invoice information of the invoice to be verified from the block corresponding to the to-be-verified block height in the first blockchain according to the correspondence between the file identifier and the invoice information.

[0117] In a possible implementation manner, the verification unit 608 is specifically configured to:

[0118] When the similarity between the first electronic document and the electronic document of the invoice to be verified is greater than or equal to a threshold, determine that the identifier of the invoice to be verified is the same as the identifier of the invoice corresponding to the first electronic document;

[0119] When the similarity between the first electronic document and the electronic document of the invoice to be verified is less than the threshold, determine that the identifier of the invoice to be verified is different from the identifier of the invoice corresponding to the first electronic document.

[0120] In a possible implementation manner, after determining that the identifier of the invoice to be verified is the same as the identifier of the invoice corresponding to the first electronic document, the apparatus 6000 further includes:

[0121] The first determination unit 609 is configured to determine whether the invoice is tampered with according to the Merkle root value of the block corresponding to the to-be-verified block height in the first blockchain.

[0122] In a possible implementation manner, the apparatus 6000 further includes:

[0123] The second determination unit 610 is configured to determine a block height according to the invoice information;

[0124] The fourth acquisition unit 611 acquires the Merkle root value of the block corresponding to the block height in the first blockchain;

[0125] The third upload unit 612 uploads the Merkle root value to a second blockchain, where the second blockchain is any blockchain other than the first blockchain in the blockchain network;

[0126] The first root determination unit 609 is specifically configured to:

[0127] Acquire the Merkle root value of the block corresponding to the to-be-verified block height to obtain a to-be-verified Merkle root value;

[0128] Query whether the to-be-verified Merkle root value is stored in a database, where the database stores data in the second blockchain;

[0129] When the to-be-verified Merkle root value is queried in the database, it is determined that the invoice has not been tampered with. For the detailed descriptions of the above receiving unit 601, first acquisition unit 602, first upload unit 603, second upload unit 604, second acquisition unit 605, third acquisition unit 606, download unit 607, verification unit 608, first determination unit 609, second determination unit 610, fourth acquisition unit 611, and third upload unit 612, reference can be directly made to the relevant descriptions in the method embodiment shown above Figures 2 to 5b and will not be elaborated here.

[0130] In the embodiment of the present application, an invoice archiving device can receive an archiving instruction for storing an invoice, where the archiving instruction carries an identifier of the invoice; acquire an electronic file and invoice information of the invoice corresponding to the identifier; upload the electronic file to IPFS to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by IPFS; and upload the file identifier and the invoice information to a blockchain network. It can be seen that if the electronic file of the invoice is directly archived on the blockchain, the consumed resources and costs are relatively large. However, archiving the electronic file of the invoice in the InterPlanetary File System and uploading the hash value that can uniquely download the electronic file of the invoice to the blockchain network for archiving can not only ensure that it is not tampered with but also facilitate subsequent inspection of the invoice. And since the hash value corresponding to the invoice is uploaded to the blockchain network, both the company internal and the tax bureau can view the archived information subsequently, thus further ensuring that the invoice has not been tampered with.

[0131] Please refer to Figure 7 , Figure 7 which is a schematic structural diagram of an electronic device provided in an embodiment of the present application. As Figure 7 shown, the electronic device 7000 may include:

[0132] One or more processors 701, an input device 702, an output device 703, a memory 704, and a transceiver 705. The above-mentioned processors 701, input device 702, output device 703, memory 704, and transceiver 705 are connected via a bus. Among them, the input device 702 may include a touch screen, a keyboard, a microphone, etc., the output device 703 may include a display screen, a speaker, etc., and the transceiver 705 is used to receive and send data. The memory 704 is used to store a computer program, and the computer program includes program instructions. The processor 701 is used to execute the program instructions stored in the memory 704. Among them, the processor 701 is configured to call the program instructions to execute the following steps:

[0133] Receive an archiving instruction for storing an invoice, and the above-mentioned archiving instruction carries the identifier of the above-mentioned invoice;

[0134] Obtain the electronic file and invoice information of the invoice corresponding to the above-mentioned identifier;

[0135] Upload the above-mentioned electronic file to IPFS to obtain a file identifier, and the above-mentioned file identifier is the identifier of the above-mentioned electronic file returned by IPFS;

[0136] Upload the above-mentioned file identifier and the above-mentioned invoice information to the blockchain network.

[0137] In a possible implementation, the above-mentioned blockchain network includes N blockchains, and there is a communication connection between the above-mentioned N blockchains. The above-mentioned N is an integer greater than or equal to 1. The above-mentioned uploading the above-mentioned file identifier and the above-mentioned invoice information to the blockchain network includes:

[0138] Upload the above-mentioned file identifier and the above-mentioned invoice information to the first blockchain, and the first blockchain is any blockchain in the above-mentioned blockchain network.

[0139] In a possible implementation, after the above-mentioned uploading the above-mentioned file identifier and the above-mentioned invoice information to the blockchain network, the above-mentioned method further includes:

[0140] Obtain the invoice information and electronic file of the invoice to be verified;

[0141] According to the correspondence between the file identifier and the invoice information, obtain the file identifier corresponding to the invoice information of the above-mentioned invoice to be verified from the above-mentioned first blockchain;

[0142] Download a first electronic file from the above-mentioned IPFS, and the first electronic file is the electronic file corresponding to the obtained file identifier;

[0143] Verify the above-mentioned invoice to be verified according to the above-mentioned first electronic file and the electronic file of the above-mentioned invoice to be verified.

[0144] In a possible implementation manner, obtaining the file identifier corresponding to the invoice information of the to-be-verified invoice from the first blockchain according to the corresponding relationship between the file identifier and the invoice information includes:

[0145] Determining a block height according to the invoice information of the to-be-verified invoice to obtain a to-be-verified block height;

[0146] Obtaining the file identifier corresponding to the invoice information of the to-be-verified invoice from the block corresponding to the to-be-verified block height in the first blockchain according to the corresponding relationship between the file identifier and the invoice information.

[0147] In a possible implementation manner, verifying the to-be-verified invoice according to the first electronic file and the electronic file of the to-be-verified invoice includes:

[0148] When the similarity between the first electronic file and the electronic file of the to-be-verified invoice is greater than or equal to a threshold, determining that the identifier of the to-be-verified invoice is the same as the identifier of the invoice corresponding to the first electronic file;

[0149] When the similarity between the first electronic file and the electronic file of the to-be-verified invoice is less than the threshold, determining that the identifier of the to-be-verified invoice is different from the identifier of the invoice corresponding to the first electronic file.

[0150] In a possible implementation manner, after determining that the identifier of the to-be-verified invoice is the same as the identifier of the invoice corresponding to the first electronic file, the processor 701 is configured to call program instructions to execute the following steps:

[0151] Determining whether the invoice is tampered with according to the Merkle root value of the block corresponding to the to-be-verified block height in the first blockchain.

[0152] In a possible implementation manner, the processor 701 is configured to call program instructions to execute the following steps:

[0153] Determining a block height according to the invoice information;

[0154] Obtaining the Merkle root value of the block corresponding to the block height in the first blockchain;

[0155] Uploading the Merkle root value to a second blockchain, where the second blockchain is any blockchain other than the first blockchain in the blockchain network;

[0156] The determining whether the invoice is tampered with according to the Merkle root value of the block corresponding to the to-be-verified block height in the first blockchain includes:

[0157] Obtain the Merkle root value of the block corresponding to the height of the block to be verified, and obtain the Merkle root value to be verified;

[0158] Query whether the Merkle root value to be verified is stored in the database, and the database stores the data in the second blockchain;

[0159] When the Merkle root value to be verified is found in the database, it is determined that the invoice has not been tampered with.

[0160] It should be understood that in some possible implementation manners, the above-mentioned processor 701 may be a central processing unit (CPU), and this processor 701 may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or this processor may also be any conventional processor, etc.

[0161] The memory 704 may include a read-only memory and a random access memory, and provide instructions and data to the processor. A part of the memory 704 may also include a non-volatile random access memory.

[0162] In specific implementation, the above-mentioned electronic device 7000 may execute the implementation manners provided by the respective steps as described above Figures 1 to 5b in the respective steps. For details, reference may be made to the implementation manners provided by the respective steps, which will not be elaborated herein.

[0163] In an embodiment of the present application, an electronic device for invoice archiving can receive an archiving instruction for storing an invoice, where the archiving instruction carries an identifier of the invoice; obtain an electronic file and invoice information of the invoice corresponding to the identifier; upload the electronic file to IPFS to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by IPFS; and upload the file identifier and the invoice information to a blockchain network. It can be seen that if the electronic file of the invoice is directly archived on the blockchain, the consumed resources and costs are relatively large. However, archiving the electronic file of the invoice in the InterPlanetary File System and uploading the hash value that can uniquely download the electronic file of the invoice to the blockchain network for archiving can not only ensure that it is not tampered with but also facilitate subsequent verification of the invoice. And since the hash value corresponding to the invoice is uploaded to the blockchain network, both the company internal and the tax bureau can view the archived information subsequently, thus further ensuring that the invoice has not been tampered with.

[0164] In addition, it should be noted here that: The present application also provides a computer-readable storage medium, and the computer-readable storage medium stores a computer program executed by the aforementioned electronic device, and the computer program includes program instructions. When the processor executes the program instructions, it can execute the description of the data verification method in the corresponding embodiment mentioned above. Therefore, it will not be elaborated here. In addition, the description of the beneficial effects of using the same method will not be elaborated either. For the technical details not disclosed in the embodiment of the computer storage medium involved in the present application, please refer to the description of the method embodiment of the present application. Figures 2 - 5b For the terms "first", "second", etc. in the claims, the description, and the drawings of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products, or devices. Referring to "embodiment" in this article means that a specific feature, structure, or characteristic described in combination with the embodiment can be included in at least one embodiment of the present invention. The phrase shown at various positions in the description does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments. The term "and / or" used in the description and the appended claims of the present invention refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0165]

[0166] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in connection with the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of function in the above description. Those skilled in the art can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present invention.

[0167] The above-disclosed are only the preferred embodiments of the present invention, and of course, the scope of the rights of the present invention cannot be limited thereby. Therefore, equivalent changes made in accordance with the claims of the present invention still fall within the scope covered by the present invention.

Claims

1. An invoice archiving method, characterized in that, Including: Receiving an archiving instruction for storing an invoice, where the archiving instruction carries the identifier of the invoice; Obtaining the electronic file and invoice information of the invoice corresponding to the identifier; Uploading the electronic file to the InterPlanetary File System (IPFS) to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by the IPFS; Uploading the file identifier and the invoice information to a first blockchain in the blockchain network, and storing the file identifier and the invoice information correspondingly; Determining a block height according to the invoice information, obtaining the Merkle root value of the block corresponding to the block height in the first blockchain, and uploading the Merkle root value to a second blockchain, where the second blockchain is any blockchain in the blockchain network other than the first blockchain; When it is determined that the identifier of the invoice to be verified is the same as the identifier of the invoice corresponding to the first electronic file, obtaining the Merkle root value of the block corresponding to the block height to be verified to obtain a Merkle root value to be verified; the first electronic file is downloaded from the IPFS based on the file identifier corresponding to the invoice information of the invoice to be verified; the block height to be verified is determined according to the invoice information of the invoice to be verified; Querying whether the Merkle root value to be verified is stored in the database corresponding to the second blockchain, where the database stores the data in the second blockchain; When the Merkle root value to be verified is queried in the database, determining that the invoice has not been tampered with.

2. The method according to claim 1, characterized in that The blockchain network includes N blockchains, and there is a communication connection between the N blockchains, where N is an integer greater than 2.

3. The method according to claim 2, characterized in that After uploading the file identifier and the invoice information to the first blockchain in the blockchain network, the method further includes: Obtaining the invoice information and electronic file of the invoice to be verified; Obtaining the file identifier corresponding to the invoice information of the invoice to be verified from the first blockchain according to the correspondence between the file identifier and the invoice information; Downloading a first electronic file from the IPFS, where the first electronic file is the electronic file corresponding to the obtained file identifier; Verifying the invoice to be verified according to the first electronic file and the electronic file of the invoice to be verified.

4. The method according to claim 3, wherein The obtaining the file identifier corresponding to the invoice information of the invoice to be verified from the first blockchain according to the correspondence between the file identifier and the invoice information includes: Obtaining the file identifier corresponding to the invoice information of the invoice to be verified from the block corresponding to the block height to be verified in the first blockchain according to the correspondence between the file identifier and the invoice information.

5. The method according to claim 4, wherein The verifying the invoice to be verified according to the first electronic file and the electronic file of the invoice to be verified includes: When the similarity between the first electronic file and the electronic file of the invoice to be verified is greater than or equal to a threshold, determining that the identifier of the invoice to be verified is the same as the identifier of the invoice corresponding to the first electronic file; When the similarity between the first electronic file and the electronic file of the invoice to be verified is less than the threshold, determining that the identifier of the invoice to be verified is different from the identifier of the invoice corresponding to the first electronic file.

6. A device, characterized in that, Including: A receiving unit, configured to receive an archiving instruction for storing an invoice, where the archiving instruction carries an identifier of the invoice; A first obtaining unit, configured to obtain an electronic file and invoice information of the invoice corresponding to the identifier; A first uploading unit, configured to upload the electronic file to the InterPlanetary File System (IPFS) to obtain a file identifier, where the file identifier is the identifier of the electronic file returned by the IPFS; A second uploading unit, configured to upload the file identifier and the invoice information to a first blockchain in a blockchain network, where the file identifier and the invoice information are stored correspondingly; A second determining unit, configured to determine a block height according to the invoice information; A fourth obtaining unit, configured to obtain a Merkle root value of a block corresponding to the block height in the first blockchain; A third uploading unit, configured to upload the Merkle root value to a second blockchain, where the second blockchain is any blockchain other than the first blockchain in the blockchain network; A first determining unit, configured to, when it is determined that the identifier of the invoice to be verified is the same as the identifier of the invoice corresponding to a first electronic file, obtain a Merkle root value of a block corresponding to the block height to be verified to obtain a Merkle root value to be verified; the first electronic file is downloaded from the IPFS based on the file identifier corresponding to the invoice information of the invoice to be verified; the block height to be verified is determined according to the invoice information of the invoice to be verified; query whether the Merkle root value to be verified is stored in a database corresponding to the second blockchain, where the database stores data in the second blockchain; When the Merkle root value to be verified is queried in the database, determine that the invoice has not been tampered with.

7. An electronic device, characterized in that, Including: A processor and a memory; The processor is connected to the memory, where the memory is configured to store program code, and the processor is configured to call the program code to execute the method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more first instructions, and the one or more first instructions are adapted to be loaded and executed by a processor to execute the method according to any one of claims 1-5.

Images