Blockchain-based invoice data storage intelligent processing system

Abstract

The present application relates to the technical field of blockchain invoice data processing, and specifically relates to an invoice data storage intelligent processing system based on blockchain. When the system is running, the following is executed: write the fragment storage voucher and original invoice association relationship into the blockchain to form an invoice fragment storage voucher set; write the matching result into the blockchain to generate an invoice use occupation chain; aggregate the invalid sealing, replacement acceptance result or conflict isolation result into a current callable invoice storage section, and write it into the blockchain, so that the subsequent business system only calls the invoice data according to the current callable invoice storage section. The present application effectively prevents the same invoice amount or tax amount from being repeatedly reimbursed, repeatedly deducted or repeatedly archived in multiple business systems, and improves the accuracy of invoice data calling and the security of financial and tax business processing.

Description

Technical Field

[0001] This invention relates to the field of blockchain invoice data processing technology, and in particular to a blockchain-based intelligent invoice data storage and processing system. Background Technology

[0002] With the widespread use of electronic invoices and digital invoices, invoice data has become an important electronic voucher for enterprise reimbursement, accounting, deduction, archiving, and auditing. To improve the credibility of invoice data, existing technologies include solutions that write invoice hash values, invoicing information, or circulation records into the blockchain to achieve tamper-proof evidence storage and traceability management of invoice data.

[0003] However, most existing blockchain invoice storage methods treat the entire invoice as the smallest unit of processing. They typically only record whether the entire invoice has been uploaded to the blockchain, reimbursed, deducted, or voided, which is insufficient to meet the fragmented usage needs of invoices in actual business operations. For example, the same invoice may correspond to multiple detailed lines, multiple projects, multiple departments, multiple contract nodes, or different price and tax purposes. If managed as a whole invoice, it is easy to cause some amounts to be occupied while the remaining amounts cannot be accurately accessed, or the same invoice value to be reused by multiple business systems.

[0004] Meanwhile, during the invoice circulation process, subsequent events may occur such as red-ink cancellation, correction, return, duplicate reimbursement, or cross-system reuse. The existing whole-invoice-level on-chain method makes it difficult to accurately distinguish which segments are already in use, which segments should be invalidated, which segments need to be replaced, and which segments should be isolated from conflicts. This leads to problems such as the continued use of old invoices after red-ink cancellation, the incorrect use of old segments after correction, and the difficulty in timely identification of duplicate reimbursements. Summary of the Invention

[0005] This invention provides a blockchain-based intelligent invoice data storage and processing system. It fragments invoices according to detailed lines, price and tax attribution, and business usage boundaries, and continuously records the occupancy status and subsequent status changes of each invoice fragment based on the blockchain. This improves the controllability of invoice data in scenarios involving multi-business system calls, partial occupancy, and status changes.

[0006] A blockchain-based intelligent invoice data storage and processing system performs the following operations during system operation: Receive invoices to be stored, split the invoices to be stored into non-overlapping minimum usable fragments according to invoice details, price and tax attribution, and business purpose boundaries, generate fragment storage vouchers for each minimum usable fragment, and write the fragment storage vouchers and the original invoice association relationship into the blockchain to form a set of fragmented invoice storage vouchers. When the business system initiates a call request for the invoice to be stored, it matches the smallest available unoccupied invoice fragment for this call based on the invoice fragmented storage voucher set, and writes the matching result into the blockchain to generate an invoice usage occupancy chain; the invoice usage occupancy chain is used to record the occupied, unoccupied, replaced, or isolated status of each smallest available invoice fragment. When a status change event or a cross-system re-call event is received for the same invoice to be stored, the affected minimum available fragment of the invoice is located along the invoice usage occupancy chain. The unoccupied minimum available fragment of the invoice is invalidated and sealed. The occupied minimum available fragment of the invoice is replaced with an alternative acceptance result or a conflict isolation result. The invalidation and sealing, alternative acceptance results or conflict isolation results are summarized into the current callable invoice storage section and written into the blockchain, so that subsequent business systems can only call invoice data based on the current callable invoice storage section.

[0007] Optionally, the invoice to be stored is structured data. The structured data of the invoice to be stored is parsed to extract all invoice detail lines and the total price and tax information of the entire invoice. For each invoice detail line, the amount excluding tax and the tax amount are separated to form a price and tax attribution sub-segment. According to a preset business purpose boundary template, each price and tax attribution sub-segment is further divided into several minimum business units that can be independently occupied by a single business item. The sum of the amounts of each minimum business unit is equal to the amount of the original price and tax attribution sub-segment, and the amounts between different minimum business units are mutually exclusive. All the minimum business units obtained in this way constitute the non-overlapping minimum usable fragment of the invoice, and cover the entire usable value of the original invoice.

[0008] Optionally, each of the smallest usable segments of the invoice is assigned a globally unique segment identifier. The segment attribute information is extracted, including at least the original invoice code, original invoice number, the corresponding line number, price and tax mark, amount, tax rate, tax amount, business purpose category, and timestamp. A digital digest of the segment attribute information is calculated, and the digital digest is signed using the system private key to generate a segment storage certificate that includes the segment identifier, attribute information, digital digest, and digital signature.

[0009] Optionally, the fragment identifiers and their digital digests of all the smallest usable fragments of the invoice are organized into a Merkle tree indexed by the original invoice's unique identifier. A Merkle root hash is calculated, and the original invoice hash and the Merkle root hash are written into a first blockchain transaction. Each fragment storage certificate and its verification path in the Merkle tree are written into a second blockchain transaction, and an association pointer pointing to the first blockchain transaction is recorded in the second blockchain transaction, forming the fragmented storage certificate set of the invoice that includes all fragment storage certificates and verifies the ownership relationship between the original invoice and the fragments.

[0010] Optionally, the system receives a call request from a business system. The call request includes at least a target invoice identifier, a call business type, a required amount excluding tax, and a required tax amount. The call business type includes accounting, reimbursement, deduction, or archiving. Based on the target invoice identifier, the system queries the invoice fragmented storage voucher set to obtain the identifiers and attribute information of all the smallest usable segments of the invoice corresponding to the invoice. The system traverses the invoice usage occupancy chain recorded on the blockchain and associated with the target invoice identifier to obtain the current occupancy status of each smallest usable segment of the invoice. The occupancy status includes occupied, unoccupied, replaced, and isolated.

[0011] Optionally, based on the business type of the call, the corresponding business purpose category is determined, and a set of candidate fragments matching the tax-inclusive price and the required tax-exclusive amount and required tax amount are selected from the smallest available fragments of the invoice that are currently unoccupied. Fragments that are occupied, replaced, or isolated are excluded during the selection process. A preset fragment matching strategy is adopted to determine the target occupied fragment set from the candidate fragment set: if there is a single unoccupied fragment whose tax-exclusive amount and tax amount are equal to the requested tax-exclusive amount and tax amount, respectively, then the fragment is directly used as the target occupied fragment; if there is no single fragment with completely equal amounts, then the unoccupied fragment with the smallest difference between its tax-exclusive amount and the requested tax-exclusive amount is selected, and it is split into occupied sub-fragments and fractional sub-fragments. The amount of the occupied sub-fragment is equal to the requested tax-exclusive amount and the corresponding tax amount. The fractional sub-fragment is used as the minimum available fragment of the new unoccupied invoice, and a new fragment storage voucher is generated for the fractional sub-fragment.

[0012] Optionally, for each occupied segment or sub-segment involved in the target occupied segment set, an occupation transaction is generated. The occupation transaction includes segment identifier, calling business identifier, occupation type, occupation amount, tax amount, timestamp, and state link hash calculated based on the hash of the previous state record of the segment and the current occupation information. The occupancy transaction is written into a new block as a blockchain transaction. The status of the occupied fragment on the invoice purpose occupancy chain is updated to occupied. The status of the split sub-fragments is initialized to unoccupied and included in the maintenance scope of the invoice purpose occupancy chain. This allows the invoice purpose occupancy chain to continuously record the occupied, unoccupied, replaced, or isolated status of each smallest usable fragment of the invoice. Furthermore, each status record forms a traceable chain structure through status link hashing.

[0013] Optionally, the state change event or cross-system re-call event carries the original invoice identifier. Based on the original invoice identifier, the invoice purpose occupancy chain is traversed to obtain the current state of the smallest usable fragment of all invoices.

[0014] Optionally, based on the current state: Change the status of the fragment that is currently unoccupied to expired, generate an expired sealing certificate, and seal its entire amount so that it will no longer be involved in subsequent calls; For a segment currently in an occupied state, if the event is a red-level conflict or correction, a corresponding negative value replacement segment is generated, and a replacement relationship is established with the original occupied segment; if the event is a conflict caused by duplicate reimbursement or cross-system re-call, a conflict isolation record is generated, and the original occupied segment is marked as isolated.

[0015] Optionally, it also includes all segments under the summary invoice that are in an unoccupied and not expired state, forming the current callable invoice storage segment, and writing the current callable invoice storage segment and the voucher of this state change together into the blockchain as the sole basis for subsequent business system calls.

[0016] The beneficial effects of this invention are: This invention breaks down invoices from traditional whole-invoice-level storage objects into non-overlapping, minimum usable fragments, and further generates a fragmented storage voucher set. This refines the granularity of invoice data storage from the entire invoice to fragments that can be independently occupied by a single business transaction. Compared to existing technologies that only hash and upload the entire invoice or only record the overall state of the invoice, this invention accurately expresses the value boundaries between different detail lines, different price and tax attributions, and different business uses within the same invoice. This avoids the problem that an invoice can only be used as a whole when it is partially reimbursed, partially deducted, recorded by project, or reconciled in installments under a contract.

[0017] This invention establishes an invoice usage occupancy chain, linking the accounting, reimbursement, deduction, or archiving calls in business systems with the current state of the smallest usable fragment of an invoice. This allows for continuous recording and precise control of the invoice's value usage process. Upon receiving a call request, instead of simply determining whether the entire invoice has been used, the system queries the fragmented storage voucher set based on the target invoice identifier. It then filters fragments currently in an unused state using the invoice usage occupancy chain and determines the target set of occupied fragments through a preset fragment matching strategy. This method prioritizes precise matching of entire fragments. When precise matching is not possible, it achieves precise occupancy through single-fragment splitting or multi-fragment combination, and writes the occupancy transaction to the blockchain, ensuring that the occupied, unused, replaced, or isolated states of each fragment have chain-like traceability. This effectively prevents the same invoice amount or tax from being repeatedly reimbursed, deducted, or archived in multiple business systems, improving the accuracy of invoice data retrieval and the security of financial and tax business processing.

[0018] This invention addresses subsequent status change events of invoices, such as red-ink cancellations, corrections, refunds, duplicate reimbursements, and cross-system re-calls, by establishing mechanisms for fragment-level invalidation and sealing, negative value substitution, conflict isolation, and generation of currently callable invoice storage segments. For unused segments, the system can promptly generate invalidation and sealing vouchers after an invoice undergoes a red-ink cancellation, correction, or refund, ensuring that the remaining unused value is no longer used in subsequent calls. For used segments, the system can generate negative value substitution segments or conflict isolation records based on the event type, preventing the original used segments from continuing to be used as valid vouchers after their business validity has changed. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only for this invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the execution logic of the processing system according to an embodiment of the present invention. Detailed Implementation

[0021] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. For some well-known technologies, those skilled in the art may also use other alternative methods to implement the invention. Moreover, the accompanying drawings are only for more specific description of the embodiments and are not intended to specifically limit the present invention.

[0022] This invention differs from conventional solutions that hash and update the status of invoices on the blockchain. Its core improvement lies in transforming the invoice from a complete voucher into a minimum usable fragment that can be used by business processes, can be located by red-ink corrections, and can be isolated and traced. This avoids the situation where the remaining amount, remaining details, red-ink correction portion, and reimbursed portion of an invoice are mixed in multiple systems after it has been partially used.

[0023] like Figure 1 As shown, the blockchain-based intelligent invoice data storage and processing system executes the following three parts during system operation: The first part involves receiving invoices to be stored, splitting the invoices into non-overlapping minimum usable segments according to invoice details, price and tax attribution, and business purpose boundaries, generating a segment storage certificate for each minimum usable segment, and writing the segment storage certificate and the original invoice association relationship into the blockchain to form a set of invoice segmented storage certificates.

[0024] In one implementation, the invoices to be stored are subjected to fragmented storage processing to form a fragmented storage voucher set. The fragmented storage processing does not directly write the entire invoice as a single voucher to the blockchain, but rather breaks the invoice down into the smallest usable fragments that can be independently used by subsequent business transactions according to the details, price and tax attribution, and business purpose boundaries. This allows the specific affected invoice fragments to be located during subsequent reimbursement, accounting, deduction, archiving, red-ink reversal, correction, or repeated retrieval, rather than just processing the entire invoice in a general way.

[0025] Specifically, after receiving the invoices to be stored, the system parses their structured data. This structured data includes original electronic invoice data, parsed format file data, data returned from the tax control interface, or standardized invoice data from the enterprise's financial and tax system. The system extracts all invoice detail lines and the total price and tax information for the entire invoice from the structured data. The invoice detail lines represent the invoiced content of each good, service, or business item in the invoice, while the total price and tax information for the entire invoice is used to verify the completeness of subsequent segmentation results, preventing omissions or duplications in the segmented amounts. During parsing, the data source type of the invoice to be stored is identified. If it is raw electronic invoice data or tax control interface data, the invoice code, invoice number, invoice date, seller information, buyer information, detail line fields, amount fields, and tax amount fields are directly read according to the preset invoice field dictionary. If it is OFD, PDF, or image format files, the text layer and field labels in the format file are read first, and the corresponding fields are extracted according to the layout positioning rules of the header area, detail area, and total area. If it is standardized invoice data from the enterprise's financial and tax system, the fields from different systems are uniformly converted into the standard fields required by this method through a field mapping table. After the field reading is completed, the names of goods or services, the amount excluding tax, the tax rate, the tax amount, and the total amount including tax are merged at the row level according to the detail line number to obtain structured invoice data that can be used for subsequent fragment splitting.

[0026] Suppose that the parsed invoices to be stored contain all the invoice details: ;in, This represents the set of invoice detail lines for invoices to be stored. Indicates the first Invoice details line, This indicates the total number of invoice detail lines in the invoices to be stored. Indicates the invoice line number, and .

[0027] For each invoice detail line The system extracts fields such as the amount excluding tax, tax amount, tax rate, total price including tax, and name of goods or services corresponding to the invoice details line. It then separates the amount excluding tax from the tax amount, forming a price-tax attribution sub-segment. This price-tax attribution sub-segment is used to separate the price and tax portions of the same invoice details line as the basis for subsequent segmentation, thus preventing the subsequent business system from mixing the price and tax amounts when handling partial reimbursement, partial deduction, or separate tax processing. For the first... The price-tax relationship of a single invoice detail line is expressed as follows: ;in, Indicates the first The total price including tax in the details line of the invoice. Indicates the first The amount excluding tax in the details line of the invoice. Indicates the first The tax amount in the details line of the invoice. This indicates the serial number of the invoice details line.

[0028] After completing the price and tax separation, the system will... Each invoice detail line is split into a price sub-segment and a tax sub-segment. The price sub-segment corresponds to the amount excluding tax, and the tax sub-segment corresponds to the tax amount. Therefore, the same invoice detail line is no longer stored as a single, unified amount, but rather as separate price and tax sub-segments that can be identified and used for different business purposes.

[0029] No. The price and tax attribution sub-segment corresponding to the details line of an invoice can be represented as: ;in, Indicates the first The set of price and tax attribution sub-fragments corresponding to each line of the invoice details. Indicates the first The price attribution sub-segment corresponding to the details line of the invoice. Indicates the first The tax attribution sub-segment corresponding to the details line of the invoice. This indicates the serial number of the invoice details line.

[0030] Based on a pre-defined business purpose boundary template, the system further divides each price and tax attribution sub-segment into several minimum business units that can be independently occupied by a single business transaction. The business purpose boundary template describes the boundaries of invoice value occupancy for different purposes in a company's financial and tax operations, such as expense reimbursement, cost accounting, input tax deduction, project aggregation, asset accounting, contract payment write-off, or special audit retention. Through the business purpose boundary template, the system can identify whether the same price and tax attribution sub-segment needs further subdivision according to business project, expense account, cost center, department affiliation, contract affiliation, or deduction affiliation.

[0031] For any price-tax attribution sub-segment, its decomposition result satisfies: ;in, Indicates the first A sub-segment of price and tax attribution in the details line of an invoice. Indicates price and tax symbol, when When indicates the sub-fragment of price attribution, when Time indicates the sub-fragment of tax attribution. Indicates by The division obtained by the first The smallest business unit, This represents the minimum number of business units obtained by dividing the price and tax attribution sub-segment. This indicates the sequence number of the smallest business unit.

[0032] The smallest business units must satisfy both monetary integrity and monetary exclusivity. Monetary integrity means that the sum of the amounts of all the smallest business units obtained from the same price and tax attribution sub-segment equals the original amount of that price and tax attribution sub-segment; monetary exclusivity means that there is no situation where the same amount is repeatedly attributed between different smallest business units. Their relationship is expressed as follows: ;in, Indicates the first The price and tax mark in the details line of the invoice is The The amount of the smallest business unit, Indicates the first The price and tax mark in the details line of the invoice is The amount of the price and tax attributable to the sub-fraction, Indicates the invoice line number. This represents the sequence number of the smallest business unit. The mutual exclusion relationship between different smallest business units is expressed as follows: ;in, Indicates the first The price and tax mark in the details line of the invoice is The The smallest business unit, Indicates the first The price and tax mark in the details line of the invoice is The The smallest business unit, This indicates that there are no overlapping amounts or duplicate business transactions occupying the boundary. and This indicates the sequence number of the different smallest business units.

[0033] Through the above processing, all the smallest business units obtained together constitute a unique minimum usable segment of the invoice, which does not overlap. This minimum usable segment covers all usable value of the original invoice; that is, the value of the original invoice that can be called, used, verified, deducted, or archived by subsequent business systems can all correspond to a unique minimum usable segment. Therefore, when partial reimbursement, partial deduction, partial red-ink cancellation, or partial correction occurs later, the system can accurately locate the affected minimum usable segment of the invoice without needing to invalidate or re-store the entire invoice.

[0034] The smallest usable segment for all invoices is: ;in, This represents the minimum set of usable fragments of an invoice obtained by splitting the invoice to be stored. Indicates the first The minimum usable segment of an invoice This represents the minimum total number of usable invoice fragments corresponding to the invoice to be stored. This indicates the sequence number of the smallest usable segment of the invoice.

[0035] After obtaining the minimum usable segment of an invoice, a globally unique segment identifier is assigned to each segment. This segment identifier is used to uniquely locate the corresponding minimum usable segment in subsequent invoice usage chains, red-ink reversal acceptance, correction acceptance, repeated call isolation, and the currently callable invoice storage segment. The segment identifier can be generated based on the original invoice's unique identifier, its corresponding detail line number, price and tax flag, business usage category, segment number, and timestamp, ensuring that there are no identifier conflicts between different minimum usable segments under the same original invoice. The segment identifier can be represented as: ; in, Indicates the first The segment identifier of the smallest usable segment of an invoice. Represents the hash calculation function. This indicates the unique identifier of the original invoice. Indicates the first The invoice detail line number to which the smallest usable segment of an invoice belongs. Indicates the first The price and tax mark of the smallest usable segment of an invoice. Indicates the first The business purpose category corresponding to the smallest usable segment of an invoice. Indicates the first The smallest usable segment of an invoice is the segment number within the same price and tax attribution sub-segment. Indicates the first The timestamp corresponding to the generation of the smallest usable fragment of an invoice. This indicates field concatenation.

[0036] Further extract the fragment attribute information for each minimum usable fragment of an invoice. The fragment attribute information includes at least the original invoice code, original invoice number, line number, price and tax indicator, amount, tax rate, tax amount, business purpose category, and timestamp. The fragment attribute information describes the source relationship, amount relationship, and business purpose relationship between the minimum usable fragment of the invoice and the original invoice, enabling subsequent business systems to directly determine whether the minimum usable fragment of the invoice can be used by the current business transaction without reading all the details of the entire invoice. The fragment attribute information for the r-th minimum usable fragment of the invoice is represented as follows: ; in, Indicates the first Fragment attribute information of the minimum usable fragment of an invoice. Indicates the first The original invoice code corresponding to the smallest usable segment of an invoice. Indicates the first The original invoice number corresponding to the smallest usable segment of the invoice. Indicates the first The invoice detail line number to which the smallest usable segment of an invoice belongs. Indicates the first The price and tax mark of the smallest usable segment of an invoice. Indicates the first The amount of the smallest usable segment for an invoice. Indicates the first The tax rate corresponding to the smallest usable segment of an invoice. Indicates the first The tax amount corresponding to the smallest usable segment of an invoice.

[0037] After obtaining the fragment attribute information, the system calculates a digital digest of that fragment attribute information. The digital digest is used to represent the immutability verification value of the fragment attribute information. When any fragment attribute field is modified, the recalculated digital digest will be inconsistent with the digital digest recorded in the blockchain, thus enabling the identification of whether the minimum usable fragment of the invoice has been tampered with. The digital digest is represented as: ;in, Indicates the first A digital summary of the smallest usable fragment of an invoice. Indicates the first Fragment attribute information of the minimum usable fragment of an invoice. The hash calculation function is indicated. To facilitate adaptation to domestic cryptographic systems, the SM3 hash calculation function is preferred. When performing digital digest hash calculation, the fragment attribute information of the smallest usable fragment of the invoice is first standardized and concatenated according to the preset field order. Then, the SM3 calculation is performed on the concatenated standardized string to obtain the digital digest of the fragment attribute information.

[0038] A digital signature is generated by signing the digital digest using the system's private key. The digital signature proves that the digital digest of the smallest usable fragment of the invoice was generated by a legitimate system, preventing external systems from forging fragment storage credentials. A digital signature can be represented as: ;in, Indicates the first The digital signature corresponding to the smallest usable fragment of an invoice. Indicates the system private key. Indicates the first A digital summary of the smallest usable fragment of an invoice. The signature function, preferably executed using the SM2 digital signature algorithm, specifically generates a digital digest of the smallest usable fragment of the r-th invoice. Then, the pre-configured system private key is invoked. Perform a signature operation on the digital digest to generate a digital signature. The digital signature, along with the fragment identifier, fragment attribute information, and digital digest, is written into the fragment storage credential. During subsequent verification, the business system or on-chain verification node uses the system public key corresponding to the system private key to verify the data. The signature verification is performed. If the signature verification is successful, it confirms that the storage certificate for the segment was generated by a legitimate system and that the digital digest has not been forged. If the signature verification fails, the corresponding storage certificate for the segment is determined to be an abnormal certificate and subsequent use is rejected.

[0039] After completing the above processing, the system generates a fragment storage certificate. The fragment storage certificate simultaneously records the fragment identifier, fragment attribute information, digital digest, and digital signature. Because the fragment storage certificate can indicate the source and business affiliation of the smallest usable fragment of an invoice, and can also verify integrity and legality through digital digests and digital signatures, it can serve as a trusted basis for subsequent invoice retrieval, occupancy, replacement, or isolation.

[0040] No. Each fragment storage certificate is represented as: ;in, Indicates the first The fragment storage voucher corresponding to the smallest usable fragment of an invoice. Indicates the first The segment identifier of the smallest usable segment of an invoice. Indicates the first Fragment attribute information of the minimum usable fragment of an invoice. Indicates the first A digital summary of the smallest usable fragment of an invoice. Indicates the first The digital signature corresponding to the smallest usable fragment of an invoice.

[0041] After generating all fragment storage vouchers, the system organizes the fragment identifiers and digital digests of all minimum usable fragments of invoices into a Merkle tree indexed by the original invoice's unique identifier. Specifically, the system uses the fragment identifier and digital digest of each minimum usable fragment of an invoice to form Merkle tree leaf nodes, ensuring that each leaf node corresponds to a specific minimum usable fragment of an invoice. Using both the fragment identifier and digital digest in the leaf node calculation simultaneously guarantees the verifiability of both fragment identity and fragment attribute content.

[0042] No. A Merkel leaf node is represented as: ;in, Indicates the first The Merkel leaf node corresponding to the smallest usable fragment of an invoice. Indicates the first The segment identifier of the smallest usable segment of an invoice. Indicates the first A digital summary of the smallest usable fragment of an invoice. This indicates field concatenation. The hash calculation function is denoted as SM3. When calculating the hash of a leaf node in a Merkel tree, the fragment identifier and corresponding digital digest of the smallest usable fragment of the invoice are read first, and the two are concatenated in a fixed order. Then, SM3 calculation is performed on the concatenated result to obtain the hash value of the leaf node of the fragment in the Merkel tree.

[0043] All leaf nodes are aggregated according to the unique identifier of the original invoice to generate the corresponding Merkle tree, and the Merkle root hash is calculated. The Merkle root hash is used to represent the minimum usable fragment of all invoices corresponding to the original invoice on the chain. Subsequent business systems only need to provide a storage certificate for a specific fragment and its verification path in the Merkle tree to verify whether the minimum usable fragment of the invoice indeed belongs to the corresponding original invoice and whether its fragment attribute information is consistent with the on-chain record. The Merkle root hash can be represented as: Where Root represents the Merkle root hash of the invoice to be stored. This represents all Merkle tree leaf nodes corresponding to the invoice to be stored. This represents the minimum total number of usable invoice fragments corresponding to the invoice to be stored. This refers to the Merkle root hash function, which can be executed using a layer-by-layer pairwise hashing method based on SM3: first, according to the fragment identifier or the order of the detail lines to which the smallest usable fragment of the invoice belongs, all leaf nodes are hashed. The system performs a fixed sorting process. Then, starting from the bottom layer, each pair of adjacent leaf nodes is concatenated in a fixed order and subjected to SM3 hash calculation to generate the hash of the parent node at the next higher level. If the number of nodes at a certain level is odd, the last node is copied once before participating in the pairing calculation. The system repeats the process of "sorting and pairing - concatenation - hashing" until only one node remains, which is the Merkle root hash. In this way, any change in the fragment identifier or digital digest of any smallest usable fragment of an invoice will cause the corresponding leaf node, the parent node, and the final Merkle root hash to change synchronously, thereby achieving overall integrity verification of all fragment storage vouchers of the entire invoice.

[0044] Simultaneously, the original invoice hash is calculated. The original invoice hash is used to characterize the integrity of the original structured data of the invoice to be stored, enabling an on-chain correspondence to be established between the original invoice itself and the smallest usable fragment of the invoice obtained by splitting it.

[0045] The original invoice hash can be represented as: ;in, This represents the hash of the original invoice corresponding to the invoice to be stored. This represents the raw structured data of the invoice to be stored. The hash calculation function is defined as follows: When calculating the hash of the original invoice, the original structured data of the invoice to be stored is first normalized according to the unified field format and the order of detail rows to remove irrelevant format differences. Then, SM3 calculation is performed on the normalized complete invoice data to obtain the original invoice hash used to represent the integrity of the entire original invoice.

[0046] After calculating the original invoice hash and Merkle root hash, the system writes the original invoice hash and Merkle root hash into the first blockchain transaction. The first blockchain transaction serves as an on-chain anchor record at the original invoice level, proving that a specific original invoice has been fragmented at a particular time, and that all its smallest usable fragments can be uniformly verified using the Merkle root hash. The first blockchain transaction can be represented as: ;in, Indicates the first blockchain transaction. This indicates a blockchain write operation. This indicates the unique identifier of the original invoice. This represents the hash of the original invoice corresponding to the invoice to be stored. This represents the Merkle root hash of the invoice to be stored.

[0047] Furthermore, the system writes each fragment of the storage certificate and its verification path in the Merkle tree into the second blockchain transaction. The verification path is used to prove that the corresponding fragment of the storage certificate can be calculated step by step from its Merkle tree leaf nodes to the Merkle root hash. In order to enable each fragment of the storage certificate to be traced back to the on-chain anchor record at the original invoice level, the system records an associated pointer to the first blockchain transaction in the second blockchain transaction.

[0048] No. The second blockchain transaction corresponding to the smallest usable fragment of an invoice can be represented as: ; in, Indicates the first The second blockchain transaction corresponding to the smallest usable fragment of an invoice. This indicates a blockchain write operation. Indicates the first The fragment storage voucher corresponding to the smallest usable fragment of an invoice. Indicates the first The verification path of the minimum usable fragment of an invoice in the Merkle tree. This indicates an associated pointer to the first blockchain transaction.

[0049] The verification path is used to verify the attribution relationship between the minimum usable fragment of a single invoice and the original invoice without reading all fragment storage credentials. Specifically, when a subsequent business system needs to verify whether the minimum usable fragment of an invoice belongs to a specific original invoice, the system recalculates the corresponding leaf node based on the fragment identifier and digital digest in the fragment storage credential, and calculates it level by level up to the root hash using the verification path. If the calculated root hash matches the Merkle root hash recorded in the first blockchain transaction, it is confirmed that the minimum usable fragment of the invoice belongs to the original invoice, and that the fragment storage credential has not been tampered with. Fragment attribution verification can be represented as: ;in Indicates the first The Merkel leaf node corresponding to the smallest usable fragment of an invoice. Indicates the first The verification path of the minimum usable fragment of an invoice in the Merkle tree. This indicates the Merkel attribution verification function executed based on the leaf node and verification path. The Merkel attribution verification function is executed by recalculating layer by layer from the leaf node to the root node: First, the corresponding leaf node is recalculated based on the fragment identifier and digital digest in the storage certificate of the fragment to be verified, and the verification path of the fragment in the Merkel tree is read. The verification path records the hashes of the adjacent nodes that need to be concatenated at each level from the bottom to the root node of the leaf node and their left or right direction indicators; then, the system uses the leaf node as the initial calculation value, and according to the hierarchical order recorded in the verification path, if the adjacent node is on the left, the hash of the adjacent node is concatenated before the current calculation value and then the SM3 hash calculation is performed; if the adjacent node is on the right, the hash of the adjacent node is concatenated after the current calculation value and then the SM3 hash calculation is performed, and so on, to obtain the hash of the parent node of the previous level, until the final root hash is calculated; if the final root hash is consistent with the Merkel root hash recorded in the first blockchain transaction, it is confirmed that the smallest usable fragment of the invoice belongs to the corresponding original invoice and the fragment storage certificate has not been tampered with; if they are inconsistent, the attribution relationship between the fragment storage certificate and the original invoice is determined to be invalid.

[0050] Through the coordination of the first and second blockchain transactions, the system forms a fragmented storage certificate set for invoices. This set includes not only the fragment storage certificates corresponding to the smallest usable fragments of all invoices, but also the Merkel verification relationship between each fragment storage certificate and the original invoice, and the association pointers from the second blockchain transactions to the first blockchain transactions. Therefore, invoice data in the blockchain is no longer merely represented as hash-based evidence at the whole-invoice level, but rather forms a trusted storage structure capable of supporting fragment-level occupancy, fragment-level traceability, and fragment-level verification.

[0051] The fragmented storage voucher set of invoices can be represented as: ;in, This represents a fragmented storage set of invoice vouchers. Indicates the first The fragment storage voucher corresponding to the smallest usable fragment of an invoice This indicates an associated pointer to the first blockchain transaction.

[0052] In this implementation, the technical role of the fragmented invoice storage voucher set is twofold: firstly, it achieves immutable anchoring at the original invoice level through the original invoice hash and Merkle root hash; secondly, it enables independent verification of the smallest usable fragment of the invoice through fragmented storage vouchers and verification paths. Subsequent business systems, when performing accounting, reimbursement, deduction, or archiving calls, can directly use the smallest usable fragment of the invoice as the object of occupancy, without needing to occupy the entire invoice. When red-ink cancellations, corrections, refunds, or duplicate reimbursements occur, the specific affected smallest usable fragment of the invoice can be located along the fragmented invoice storage voucher set, thereby providing a reliable data foundation for subsequently generating the invoice usage occupancy chain and the currently callable invoice storage segment.

[0053] It needs to be clarified that the aforementioned business purpose boundary template is understood as follows: A price and tax attribution sub-segment is further broken down into rule tables that can be individually occupied by a specific business transaction. This breakdown is based on the boundaries of invoice usage in actual business operations. For example, if a specific line in an invoice might simultaneously correspond to two projects, two departments, two contract payment nodes, or one deductible portion and one non-deductible portion, then the price and tax attribution sub-segments corresponding to that line need to be further broken down into multiple mutually exclusive minimum business units. The business purpose boundary template should include at least the following: 1. Business Purpose Category: Used to determine which type of business transaction will subsequently occupy this price and tax attribution sub-segment, such as: expense reimbursement purpose, cost accounting purpose, input tax deduction purpose, project collection purpose, asset accounting purpose, contract payment write-off purpose, special audit retention purpose, budget occupancy purpose, etc.

[0054] 2. Applicable Price and Tax Marks: This determines whether the template applies to the price attribution sub-segment, the tax attribution sub-segment, or both. For example, expense reimbursement usually involves both price and tax; input tax deduction primarily applies to the tax attribution sub-segment; and cost recording primarily applies to the price attribution sub-segment.

[0055] 3. Business Unit Boundary: This defines the boundary for splitting the smallest business unit. This boundary can be a project number, contract number, expense category, cost center, department number, employee expense report number, asset card number, deduction purpose identifier, payment node number, etc. Two business items cannot share the same smallest business unit if they differ on any of these key boundaries.

[0056] 4. Splitting Trigger Conditions: Used to determine whether further splitting is necessary. For example, project boundary splitting is triggered when the same invoice detail line corresponds to multiple project numbers; deduction boundary splitting is triggered when the same detail line corresponds to both deductible and non-deductible tax amounts; payment node boundary splitting is triggered when the same contract invoice corresponds to multiple payment nodes.

[0057] 5. Amount Allocation Rules: These rules determine how the price and tax-attributable sub-segment amount is allocated to different smallest business units. They can be determined based on contract allocation ratios, actual project costs, departmental expense ratios, reimbursement details, asset recording amounts, or tax deduction ratios. The sum of the amounts in each of the split smallest business units must equal the original price and tax-attributable sub-segment amount.

[0058] 6. Mutual Exclusion Validation Rules: These rules ensure that different smallest business units cannot repeatedly use the same amount, the same tax amount, or the same business boundary. In other words, once a smallest business unit is used for a reimbursement, accounting, deduction, or archiving transaction, other business transactions cannot use that portion of the value again.

[0059] 7. Output Field Rules: These rules specify the fields that each smallest business unit must carry, such as the original invoice unique identifier, detail line number, price and tax flag, business purpose category, occupancy boundary identifier, amount, tax amount, tax rate, generation time, and occupancy status.

[0060] Business purpose boundary templates are constructed as follows: 1. Pre-read the enterprise's financial and tax business rules, expense reimbursement rules, project cost collection rules, contract payment rules, input tax deduction rules, asset recording rules, and audit filing rules to form a set of identifiable business usage categories. In other words, the system first determines which business scenarios an invoice might be used for within the enterprise, such as reimbursement, recording, deduction, payment verification, and asset recording.

[0061] 2. For each type of business purpose, determine the key boundaries upon which the actual invoice value is based. For example, expense reimbursement mainly relies on the reimbursement form number, the person submitting the reimbursement, the expense category, and the department number; project aggregation mainly relies on the project number and cost category; contract payment verification mainly relies on the contract number and payment milestone; and input tax deduction mainly relies on the purpose of deduction, the tax rate, and the deductible status. These key boundaries constitute the business usage boundaries.

[0062] 3. The system configures splitting trigger conditions and amount allocation rules for each type of business purpose. When the same price and tax attribution sub-segment corresponds to multiple business occupancy boundaries simultaneously, the system triggers splitting and generates multiple minimum business units according to the corresponding allocation basis. For example, if a price attribution sub-segment is 10,000 yuan, of which 6,000 yuan belongs to project A and 4,000 yuan belongs to project B, it is split into two minimum business units according to the project boundaries; if part of the corresponding tax amount is deductible and part is not deductible, the tax attribution sub-segment is also further split according to the deduction boundaries.

[0063] 4. The system performs integrity and mutual exclusion checks on the splitting results. Integrity checks confirm that the sum of the amounts of all the smallest business units equals the original price and tax-attributed sub-segment amount; mutual exclusion checks confirm that there is no overlap in amounts, duplicate tax attribution, or overlapping business boundaries between different smallest business units. After successful checks, the system solidifies this rule into a business purpose boundary template and calls it during subsequent invoice fragmentation processing.

[0064] Table 1 Example of Business Purpose Boundary Template T01 Purpose of expense reimbursement Price attribution sub-segment, tax attribution sub-segment Expense form number, expense category, department number, and person submitting the expense report. The same line of details may correspond to multiple expense reports, multiple expense categories, or multiple departments. Allocation based on reimbursement details or departmental contribution ratio Generate the smallest business unit by "reimbursement form number + expense category + department number". T02 Project collection purpose Price Attribution Sub-fragment Project number, cost item, project stage The same line expense needs to be aggregated into multiple projects or multiple project phases. Allocation based on the actual amount borne by the project or the project's apportionment ratio. Generate the smallest business unit by "Project Number + Cost Item + Project Stage". T03 Use of input tax deduction Tax attribution sub-fragment Deduction purpose identification, deduction status, tax rate Within the same tax attribution sub-segment, there exist deductible and non-deductible portions. Allocation based on deductible percentage or tax-confirmed amount Generate the smallest business unit based on "Deduction Purpose Identifier + Deduction Status + Tax Rate". T04 Contract payment write-off purpose Price attribution sub-segment, tax attribution sub-segment Contract number, payment schedule, supplier identification The same invoice corresponds to multiple contract payment points or multiple contract items. Allocation based on contract payment milestones Generate the smallest business unit by "contract number + payment node + supplier identifier". T05 Purpose of asset recording Price attribution sub-segment, tax attribution sub-segment Asset card number, asset category, and department using the asset. The same line of detail corresponds to multiple fixed assets or multiple user departments. Allocation based on asset recording amount or asset allocation ratio Generate the smallest business unit by "Asset Card Number + Asset Category + User Department". T06 Purpose of Special Audit Retention Price attribution sub-segment, tax attribution sub-segment Audit project number, retained items, and responsible entity Invoices involving special audits, special funds, or regulatory retention requirements Allocation based on the corresponding amount of the audited item or regulatory scope. Generate the smallest business unit by "Audit Project Number + Retained Items + Responsible Entity". In the second part, when the business system initiates a call request for the invoice to be stored, it matches the smallest available unoccupied invoice fragment for this call based on the invoice fragmented storage certificate set, and writes the matching result into the blockchain to generate an invoice usage occupancy chain; the invoice usage occupancy chain is used to record the occupied, unoccupied, replaced or isolated status of each smallest available invoice fragment.

[0065] In one implementation, after forming a fragmented invoice storage voucher set, the system further performs purpose matching and occupancy record processing on the smallest usable fragment of the invoice based on the call request sent by the business system, in order to generate an invoice purpose occupancy chain. The purpose of this processing is to prevent invoices from being occupied all at once as a whole, but to accurately match them according to the amount, tax amount, business purpose category, and current occupancy status of the smallest usable fragment of the invoice, thereby avoiding duplicate reimbursement, duplicate deduction, incorrect archiving, or continued use of invalid fragments for the same invoice value.

[0066] Specifically, the system receives a call request from the business system. The call request includes at least the target invoice identifier, the call business type, the required amount excluding tax, and the required tax amount. The target invoice identifier is used to identify the original invoice corresponding to this call; the call business type is used to determine which business scenario (accounting, reimbursement, deduction, or archiving) this call belongs to; the required amount excluding tax and the required tax amount are used to determine the range of invoice value to be used in this call. The call request can be represented as: ;in, This indicates a call request sent by the business system. Indicates the target invoice identifier. Indicates the type of business call. This indicates the amount required for this call, excluding tax. This indicates the amount of tax required for this transaction.

[0067] The system queries the fragmented storage voucher set based on the target invoice identifier to obtain the fragment identifiers and attribute information of all the smallest usable fragments corresponding to the target invoice. The fragment attribute information records at least the original invoice code, original invoice number, line number, price and tax indicator, amount, tax rate, tax amount, business purpose category, and timestamp. By querying the fragmented storage voucher set, the system can obtain the callable basic data of the target invoice at the fragment level, rather than just obtaining the total amount or total tax of the entire invoice.

[0068] After obtaining all minimum usable fragments of the target invoice, the system iterates through the invoice usage occupancy chain recorded on the blockchain and associated with the target invoice identifier. It reads the latest status record of each minimum usable fragment and determines its current occupancy status accordingly. The current occupancy status includes occupied, unoccupied, replaced, and isolated. Occupied indicates that the fragment has already been used by a business transaction; unoccupied indicates that the fragment can still be matched by subsequent business transactions; replaced indicates that the fragment is no longer a valid fragment due to correction, invoice cancellation, or replacement of the invoice; isolated indicates that the fragment has been restricted from entering the valid business process due to duplicate calls, abnormal calls, or invalid references.

[0069] To facilitate subsequent filtering, a correspondence is established between the smallest usable segment of each invoice and its current occupancy status. This correspondence is represented as follows: ;in, This indicates the mapping relationship of the fragment status corresponding to the target invoice. Indicates the first The segment identifier of the smallest usable segment of an invoice. Indicates the first The current occupancy status of the smallest available segment of an invoice.

[0070] Subsequently, the system determines the corresponding business purpose category based on the call business type. For example, when the call business type is expense reimbursement, the corresponding business purpose category can be determined as expense reimbursement; when the call business type is input tax deduction, the corresponding business purpose category can be determined as input tax deduction; when the call business type is project cost aggregation, the corresponding business purpose category can be determined as project aggregation; and when the call business type is archiving, the corresponding business purpose category can be determined as archiving retention. Through the mapping between call business types and business purpose categories, the system can ensure that this call selects only the smallest usable fragment of an invoice that matches the purpose.

[0071] After determining the business purpose category, the system filters a set of candidate fragments from the minimum available invoice fragments currently in an unoccupied state. During the filtering process, the system excludes minimum available invoice fragments in an occupied, replaced, or isolated state, retaining only fragments in an unoccupied state whose business purpose category, price and tax attribution, amount, and tax amount meet the requirements of this call. This generates a candidate fragment set. The candidate fragment set serves as the basis for subsequently determining the target occupied fragment set.

[0072] The candidate fragment set can be represented as: ; in, Represents the set of candidate segments. Indicates the first The minimum usable segment of an invoice Indicates the first The current occupancy status of the smallest available segment of an invoice. Indicates an unoccupied state. Indicates the first The business use category of the minimum usable segment of an invoice This indicates the category of business purpose determined based on the type of business being invoked.

[0073] After obtaining the candidate fragment set, a preset fragment matching strategy is used to determine the target fragment set from the candidate fragment set. The preset fragment matching strategy is executed in the order of "prioritizing exact matching of whole fragments, followed by single fragment splitting and matching, and then multi-fragment combination matching" to minimize the number of fragment splits and the number of occupancy chain records, and to ensure that this call can accurately occupy the required amount excluding tax and the required tax amount. Details are as follows: First, the system determines whether a single unoccupied fragment exists in the candidate fragment set, whose tax-exclusive amount and tax amount are equal to the required tax-exclusive amount and tax amount in the call request, respectively. If such a fragment exists, the system directly uses this unoccupied fragment as the target occupied fragment without further splitting it. This approach maintains the original integrity of the minimum usable fragment of the invoice and reduces the subsequent state chain maintenance cost.

[0074] The exact matching relationship of a single chip is represented as: ; in, Indicates the first The minimum usable segment of an invoice corresponds to the tax-exclusive amount. Indicates the first The tax amount corresponding to the smallest usable segment of an invoice. Represents the first segment in the candidate fragment set. The minimum usable segment of an invoice This indicates the amount required for this call, excluding tax. This indicates the amount of tax required for this transaction.

[0075] If no single unoccupied segment has an exact equal amount, the system checks if there exists an unoccupied segment in the candidate segment set whose tax-exclusive amount is greater than the required tax-exclusive amount and whose tax amount can meet the requirements of this call according to the corresponding tax rate. If so, the system prioritizes selecting the unoccupied segment with the smallest amount difference as the segment to be split, and splits it into an occupied sub-segment and a fractional sub-segment. The amount of the occupied sub-segment is equal to the tax-exclusive amount and corresponding tax amount required for this call, and is used to add it to the target occupied segment set; the fractional sub-segment inherits the remaining amount and remaining tax amount of the original unoccupied segment that was not occupied by this call, and continues to be maintained by the invoice purpose occupancy chain as the new smallest available unoccupied invoice segment.

[0076] The selection of the segment to be split can be represented as: ;in, This represents the segment to be split selected from the candidate segment set. This indicates selecting the segment that minimizes the difference. Indicates the first The minimum usable segment of an invoice corresponds to the tax-exclusive amount. This represents the minimum usable invoice fragment in the candidate fragment set; the expression is applicable to... The unoccupied segment. When the segment to be split is split into occupied sub-segments and fractional sub-segments, it can be represented as: ;in, This indicates the segment to be split. This represents the occupied sub-fragment generated from the fragment to be split. This represents a small fragment generated from the fragment to be split.

[0077] The occupied sub-fraction and the fractional sub-fraction should maintain mutual exclusivity of amount and integrity of value. That is, the occupied sub-fraction bears the value required for this call, and the fractional sub-fraction bears the value not used in this call. The system regenerates the fragment identifier, fragment attribute information, digital digest, and digital signature for the fractional sub-fraction and writes it to a new fragment storage certificate, so that the fractional sub-fraction can continue to participate in subsequent calls as the minimum usable fragment of a new unoccupied invoice.

[0078] If no suitable segment for single-segment splitting exists in the candidate segment set, the system further performs multi-segment combination matching. Specifically, the system selects multiple unused segments, ensuring that the sum of the tax-exclusive amount and the tax amount of the selected segments can cover the required tax-exclusive amount and the required tax amount in this call request; if the combined amount exceeds the requirements of this call, one of the segments is split to form an exact match. Multi-segment combination matching is suitable for scenarios where multiple smaller segments from a single invoice jointly satisfy a single reimbursement, accounting, deduction, or archiving call.

[0079] The matching relationship of multiple pieces can be represented as: ;in, This represents the set of combined segments selected from the candidate segment set.

[0080] After the above-mentioned single-fragment exact matching, single-fragment split matching, or multi-fragment combination matching, the system finally obtains the target occupied fragment set. The target occupied fragment set can consist of a complete minimum usable fragment of an invoice, a single occupied sub-fragment, or multiple minimum usable fragments of invoices combined with necessary occupied sub-fragments. Regardless of the method used, the tax-exclusive amount and tax amount corresponding to the target occupied fragment set will match the call request.

[0081] After determining the target set of occupied fragments, the system generates an occupation transaction for each occupied fragment or sub-fragment involved in the target set. The occupation transaction records which business transaction occupies the fragment, the occupation type, the occupation amount and tax amount, and the state link relationship of this occupation behavior in the invoice usage occupation chain. An occupation transaction includes at least the fragment identifier, the calling business identifier, the occupation type, the occupation amount, the tax amount, the timestamp, and the state link hash. An occupation transaction can be represented as: ; in, Indicates the first The occupying transaction corresponding to each occupied segment or sub-segment. A segment identifier that indicates an occupied segment or sub-segment. Indicates the business identifier to be invoked. Indicates the type of occupancy. Indicates the first The amount occupied by each occupied segment or sub-segment. Indicates the first The amount of tax levied on each occupied segment or sub-segment. This indicates the timestamp used to generate the transaction. Indicates the first The state link hash corresponding to an occupied segment or sub-segment.

[0082] The state link hash is calculated based on the hash of the previous state record of the segment and the current occupancy information. Specifically, the system reads the hash of the previous state record of the segment in the invoice usage occupancy chain, concatenates the hash of the previous state record with the current occupancy information according to a fixed field order, and performs a hash calculation to generate the state link hash. The state link hash is used to connect the previous state of the segment with the current occupancy state, making the state changes of the segment form a traceable chain structure. If any historical state record is tampered with, the subsequent state link hash will not be consistent, thus enabling the identification of abnormal modifications.

[0083] The state link hash is represented as: ;in, Indicates the first The state link hash corresponding to each occupied segment or sub-segment Choose the SM3 hash calculation function. Indicates the first The hash of the previous state record of an occupied segment or sub-segment on the invoice usage occupancy chain. This indicates field concatenation.

[0084] After the occupancy transaction is generated, the system writes the occupancy transaction as a blockchain transaction into a new block. Once written, the system updates the status of the occupied fragment on the invoice purpose occupancy chain to "occupied." For any fractional fragments generated from splitting, the system initializes their status to "unoccupied" and includes their fragment identifier, fragment attribute information, digital digest, digital signature, and corresponding initial status record within the maintenance scope of the invoice purpose occupancy chain. Therefore, these fractional fragments can continue to be queried, filtered, occupied, replaced, or isolated as independent, minimum usable fragments of an invoice during subsequent business calls.

[0085] In this implementation, the invoice usage occupancy chain does not record only the result of a single business call, but continuously records the state changes of each minimum usable segment of an invoice. For each minimum usable segment of an invoice, its state may change from unoccupied to occupied, or it may change to being replaced or isolated in subsequent red-ink reversal, correction, or exception call processing. Each state change is associated with the previous state record through a state link hash, making the minimum usable segments of invoice form an independent state traceability chain.

[0086] The state record chain of the smallest usable fragment of an invoice is represented as follows: ;in, Indicates the first The invoice usage chain corresponding to the smallest usable fragment of an invoice. Indicates the first The initial state record of the minimum usable fragment of an invoice. Indicates the first The first of the minimum usable segments of the invoice Next state record. Indicates the status record sequence number.

[0087] Through the above processing, the invoice usage occupancy chain continuously records the occupied, unoccupied, replaced, or isolated status of each minimum usable segment of an invoice, and each status record forms a traceable chain structure through status link hashing. When the business system subsequently calls the same target invoice again, the system can directly read the latest status of each minimum usable segment along the invoice usage occupancy chain, automatically excluding segments that are already occupied, replaced, or isolated, and only matching unoccupied segments, thereby preventing the reuse of the same invoice value.

[0088] The technical advantage of this implementation is that by linking business call requests with the fragmented storage voucher set of invoices and the invoice usage occupancy chain, invoice data storage not only has on-chain evidence storage functionality but also fragment-level occupancy, splitting, traceability, and anti-duplicate call processing capabilities. Especially in scenarios where an invoice is partially reimbursed, partially deducted, accounted for by item, or called by multiple systems, the system can accurately record each occupancy behavior according to the smallest usable fragment of the invoice and ensure the continuity and immutability of the occupancy status through state link hashing, providing a reliable basis for handling subsequent red-ink cancellations, corrections, refunds, duplicate reimbursements, or cross-system call events.

[0089] The third part involves receiving a status change event or a cross-system re-call event for the same invoice to be stored. The affected minimum available fragment of the invoice is located along the invoice usage occupancy chain. Unoccupied minimum available fragments of the invoice are invalidated and sealed. For occupied minimum available fragments of the invoice, alternative acceptance results or conflict isolation results are generated. The invalidation and sealing, alternative acceptance results or conflict isolation results are summarized into the current callable invoice storage section and written into the blockchain, so that subsequent business systems can only call invoice data based on the current callable invoice storage section.

[0090] In one implementation, when the system receives a status change event for the same invoice to be stored (red-ink cancellation, correction, refund, duplicate reimbursement), or a cross-system call event, the system queries and traverses the invoice purpose occupancy chain corresponding to the original invoice based on the original invoice identifier carried by the event, reads the latest status record of all minimum available fragments of invoices under the invoice, and thus determines whether each minimum available fragment of invoice is currently in an occupied, unoccupied, replaced, or isolated state.

[0091] The original invoice identifier is a unique identifier used to identify an original invoice. It can be generated by combining key fields such as invoice code, invoice number, invoice date, seller identification number, and buyer identification number, or it can be a unique number generated by the system when the invoice is first stored in fragmented form. Its function is to link subsequent minimum usable invoice fragments, invoice fragmented storage voucher sets, invoice purpose occupancy chains, and red-ink cancellation or correction events back to the same original invoice, avoiding confusion between fragments, occupancy records, or status change records between different invoices.

[0092] For the smallest usable segment of an invoice that is currently unused, the system changes the segment's status to expired and generates an expired archiving voucher. The expired archiving voucher records the original invoice identifier, segment identifier, reason for expiration, archiving amount, archiving tax amount, and archiving time. After the expired archiving is completed, the entire amount and tax corresponding to that segment will no longer be involved in subsequent accounting, reimbursement, deduction, or archiving, thus preventing unused segments after red-ink cancellations, corrections, or refunds from being incorrectly occupied.

[0093] For the minimum usable fragment of an invoice currently in a "used" state, the system performs different processing based on the event type. If the event is a red-ink reversal or correction, the system generates a corresponding negative value replacement fragment based on the original used amount and tax amount of the used fragment, and establishes a replacement relationship between the negative value replacement fragment and the original used fragment. The replacement relationship indicates that the business validity of the original used fragment has been offset, corrected, or taken over by the negative value replacement fragment. If the event is a conflict caused by duplicate reimbursement or cross-system re-call, the system generates a conflict isolation record and marks the corresponding original used fragment as isolated, so that the fragment can no longer be used as a valid business voucher by subsequent systems.

[0094] After completing the above status processing, the minimum usable fragments of all invoices currently in an unused and valid state under the original invoice are summarized to form the currently callable invoice storage section. The currently callable invoice storage section reflects the range of valid fragments of the original invoice that can still be called by subsequent business systems after this status change. The system writes the currently callable invoice storage section, expired sealed vouchers, and records of replacement relationships or conflict isolation to the blockchain, serving as the sole basis for subsequent business systems to call the invoice data. Therefore, subsequent business systems do not need to re-traverse the entire historical record; they can determine which minimum usable fragments of invoices are still usable, and which fragments have expired, been replaced, or isolated based on the latest currently callable invoice storage section. This prevents problems such as continued reimbursement after a red-ink reversal, reuse of old fragments after correction, and repeated cross-system calls.

[0095] This invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of this invention. To provide the public with a thorough understanding of this invention, specific details are described in detail in the following preferred embodiments; however, those skilled in the art will fully understand the invention even without these details. Furthermore, to avoid unnecessary misunderstanding of the essence of this invention, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0096] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A blockchain-based intelligent invoice data storage and processing system, characterized in that, The system executes the following during runtime: Receive invoices to be stored, split the invoices to be stored into non-overlapping minimum usable fragments according to invoice details, price and tax attribution, and business purpose boundaries, generate fragment storage vouchers for each minimum usable fragment, and write the fragment storage vouchers and the original invoice association relationship into the blockchain to form a set of fragmented invoice storage vouchers. When the business system initiates a call request for the invoice to be stored, it matches the smallest available unoccupied invoice fragment for this call based on the invoice fragmented storage voucher set, and writes the matching result into the blockchain to generate an invoice usage occupancy chain; The invoice usage occupancy chain is used to record the occupied, unoccupied, replaced, or isolated status of each minimum available fragment of the invoice. When a status change event or a cross-system re-call event is received for the same invoice to be stored, the affected minimum available fragment of the invoice is located along the invoice usage occupancy chain. The unoccupied minimum available fragment of the invoice is invalidated and sealed. The occupied minimum available fragment of the invoice is replaced with an alternative acceptance result or a conflict isolation result. The invalidation and sealing, alternative acceptance results or conflict isolation results are summarized into the current callable invoice storage section and written into the blockchain, so that subsequent business systems can only call invoice data based on the current callable invoice storage section.

2. The blockchain-based intelligent invoice data storage and processing system according to claim 1, characterized in that, The invoices to be stored are structured data. The structured data of the invoices to be stored is parsed to extract all invoice detail lines and the total price and tax information of the entire invoice. For each invoice detail line, the amount excluding tax and the tax amount are separated to form a price and tax attribution sub-segment. According to the preset business purpose boundary template, each price and tax attribution sub-segment is further divided into several minimum business units that can be independently occupied by a single business item. The sum of the amounts of each minimum business unit is equal to the amount of the original price and tax attribution sub-segment, and the amounts of different minimum business units are mutually exclusive. All the minimum business units obtained in this way constitute the non-overlapping minimum usable fragment of the invoice, and cover the entire usable value of the original invoice.

3. The blockchain-based intelligent invoice data storage and processing system according to claim 2, characterized in that, Each of the smallest usable segments of an invoice is assigned a globally unique segment identifier. The segment attribute information is extracted, including at least the original invoice code, original invoice number, the corresponding line number, price and tax mark, amount, tax rate, tax amount, business purpose category, and timestamp. A digital digest of the segment attribute information is calculated, and the digital digest is signed using the system private key to generate a segment storage certificate that includes the segment identifier, attribute information, digital digest, and digital signature.

4. The blockchain-based intelligent invoice data storage and processing system according to claim 3, characterized in that, The fragment identifiers and their digital digests of all the smallest usable fragments of the invoice are organized into a Merkle tree indexed by the original invoice's unique identifier. The Merkle root hash is calculated, and the original invoice hash and the Merkle root hash are written into a first blockchain transaction. Each fragment storage certificate and its verification path in the Merkle tree are written into a second blockchain transaction, and an association pointer pointing to the first blockchain transaction is recorded in the second blockchain transaction, forming the fragmented storage certificate set of the invoice that includes all fragment storage certificates and can verify the ownership relationship between the original invoice and the fragments.

5. The blockchain-based intelligent invoice data storage and processing system according to claim 1, characterized in that, The system receives a call request from a business system. The call request includes at least a target invoice identifier, a call business type, a required amount excluding tax, and a required tax amount. The call business type includes accounting, reimbursement, deduction, or archiving. Based on the target invoice identifier, the system queries the invoice fragmented storage voucher set to obtain the identifiers and attribute information of all the smallest usable fragments of the invoice corresponding to the invoice. The system traverses the invoice usage occupancy chain recorded on the blockchain and associated with the target invoice identifier to obtain the current occupancy status of each smallest usable fragment of the invoice. The occupancy status includes occupied, unoccupied, replaced, and isolated.

6. The blockchain-based intelligent invoice data storage and processing system according to claim 5, characterized in that, Based on the business type of the call, determine the corresponding business purpose category, and filter out a set of candidate fragments from the smallest available fragments of the invoice that are currently unoccupied, which match the tax-inclusive amount and the required tax amount. Fragments that are occupied, replaced, or isolated are excluded during the filtering process. A preset fragment matching strategy is adopted to determine the target occupied fragment set from the candidate fragment set: if there is a single unoccupied fragment whose tax-exclusive amount and tax amount are equal to the requested tax-exclusive amount and tax amount, respectively, then the fragment is directly used as the target occupied fragment; if there is no single fragment with completely equal amounts, then the unoccupied fragment with the smallest difference between its tax-exclusive amount and the requested tax-exclusive amount is selected, and it is split into occupied sub-fragments and fractional sub-fragments. The amount of the occupied sub-fragment is equal to the requested tax-exclusive amount and the corresponding tax amount. The fractional sub-fragment is used as the minimum available fragment of the new unoccupied invoice, and a new fragment storage voucher is generated for the fractional sub-fragment.

7. The blockchain-based intelligent invoice data storage and processing system according to claim 6, characterized in that, For each occupied segment or sub-segment involved in the target occupied segment set, an occupation transaction is generated. The occupation transaction includes segment identifier, calling business identifier, occupation type, occupation amount, tax amount, timestamp, and state link hash calculated based on the hash of the previous state record of the segment and the current occupation information. The occupancy transaction is written into a new block as a blockchain transaction. The status of the occupied fragment on the invoice purpose occupancy chain is updated to occupied. The status of the split sub-fragments is initialized to unoccupied and included in the maintenance scope of the invoice purpose occupancy chain. This allows the invoice purpose occupancy chain to continuously record the occupied, unoccupied, replaced, or isolated status of each smallest usable fragment of the invoice. Furthermore, each status record forms a traceable chain structure through status link hashing.

8. The blockchain-based intelligent invoice data storage and processing system according to claim 1, characterized in that, The state change event or cross-system re-call event carries the original invoice identifier. Based on the original invoice identifier, the invoice purpose occupancy chain is traversed to obtain the current state of the smallest usable fragment of all invoices.

9. The blockchain-based intelligent processing system for invoice data storage according to claim 8, characterized in that, Based on the current state: Change the status of the fragment that is currently unoccupied to expired, generate an expired sealing certificate, and seal its entire amount so that it will no longer be involved in subsequent calls; For a segment currently in an occupied state, if the event is a red-level conflict or correction, a corresponding negative value replacement segment is generated, and a replacement relationship is established with the original occupied segment; if the event is a conflict caused by duplicate reimbursement or cross-system re-call, a conflict isolation record is generated, and the original occupied segment is marked as isolated.

10. The blockchain-based intelligent invoice data storage and processing system according to claim 9, characterized in that, It also includes all segments under the summary invoice that are in an unused and valid state, forming the currently callable invoice storage segment, and writing the currently callable invoice storage segment and the voucher of this state change together into the blockchain as the sole basis for subsequent business system calls.

Images