Bill query method and device, computer equipment and storage medium

Abstract

The invention discloses a bill query method and device, computer equipment and a storage medium, through a node-level hash link and chain storage mode, bill data realizes step-by-step association, non-tampering and automatic consistency verification in a forming process; through a concurrent checking and partition archiving mechanism, the system can keep the stability of account book writing and the orderliness of bill version management in a high-concurrency scene; by embedding an encrypted customer identity label and an account book index structure in a chain, a bill can be accurately and quickly positioned according to a user, a time range and a query field; through structural processing of multidimensional fields such as expense detail splitting, transaction timestamps, payment modes, consumption item classification and the like, the bill has analyzability and verifiability with finer granularity after being formed. According to the scheme, credible management of the bill data in the whole life cycle is achieved, data construction is more standard, data circulation is safer, and data query is more efficient.

Description

Technical Field

[0001] This application belongs to the field of bill inquiry technology, specifically relating to a bill inquiry method, apparatus, computer equipment, and storage medium. Background Technology

[0002] As a crucial component of the service industry, hotel management plays an indispensable role in enhancing customer experience and operational efficiency. With the continued growth of the tourism and business travel sectors, the hotel industry faces an urgent need to optimize service processes and reduce customer complaints in high-traffic environments. Efficient check-in, check-out, and billing management are not only core aspects of hotel operations but also key factors influencing customer satisfaction. Ensuring service quality in a busy business environment has become a significant challenge that the industry urgently needs to address.

[0003] However, some common methods and processes in current hotel management are ill-equipped to meet the high demands of modern customers for speed and convenience. For example, during peak check-out periods, the system needs to process a large volume of billing information in a short time while ensuring data accuracy. This places extremely high demands on the automation of the process. This issue extends to the long-term storage and secure management of bills. Due to the lack of a unified and efficient storage and retrieval mechanism, billing information is easily lost or difficult to trace due to improper management. For instance, if a customer questions the charges months after checking out, the hotel may be unable to respond promptly because it cannot find the original records, leading to escalating disputes.

[0004] Therefore, how to achieve rapid generation and verification of bills during peak hotel check-out periods, while ensuring the long-term secure storage and convenient traceability of bill information, has become a key issue that this study urgently needs to address. Summary of the Invention

[0005] The purpose of this application is to provide a bill query method, device, computer equipment, and storage medium to solve the technical problem of how to quickly generate and verify bills during peak hotel check-out periods, while ensuring the long-term secure storage and convenient traceability of bill information.

[0006] To address the aforementioned technical problems, this application provides a bill inquiry method, employing the following technical solution: A bill inquiry method includes: Real-time collection of consumption data during peak consumption periods; structuring the consumption data by classifying consumption items and breaking down expense details to obtain an initial bill set; Based on the consumption item categories and payment method records in the initial bill set, perform data integrity verification; If the data integrity verification passes, an encrypted data chain is generated based on the expense details and transaction timestamps in the consumption data. Embed customer identity identifiers in the encrypted data chain and verify the nodes in the encrypted data chain through a concurrent processing mechanism; If the verification results match, the encrypted data chain will be added to the historical ledger archive based on the customer's identity and the bill update status, generating a long-term data bill. Upon receiving a bill query request, the system filters the target transaction timestamp and target fee details from the long-term data bill based on the query time and query field to obtain the target data bill.

[0007] To address the aforementioned technical problems, this application also provides a bill inquiry device, which employs the following technical solution: A bill inquiry device, comprising: The structured processing module is used to collect consumption data during peak consumption periods in real time, and to perform structured processing on the consumption items classification and expense details in the consumption data to obtain an initial bill set. The integrity verification module is used to perform data integrity verification based on the consumption item categories and payment method records in the initial bill set; The encrypted data module is used to generate an encrypted data chain based on the expense details and transaction timestamps in the consumption data when the data integrity verification passes. The identity identification module is used to embed customer identity identifiers into the encrypted data chain and to verify the nodes in the encrypted data chain through a concurrent processing mechanism; The data archiving module is used to add the encrypted data chain to the historical ledger archive and generate a long-term data bill when the verification results are consistent, based on the customer's identity and the bill update status. The bill query module receives a bill query request and then filters the target transaction timestamp and target fee details from the long-term data bill based on the query time and query fields to obtain the target data bill.

[0008] To address the aforementioned technical problems, this application also provides a computer device that employs the following technical solution: A computer device includes a memory and a processor, the memory storing computer-readable instructions, the processor executing the computer-readable instructions to implement the steps of the bill query method as described in any of the preceding claims.

[0009] To address the aforementioned technical problems, this application also provides a computer-readable storage medium, employing the technical solution described below: A computer-readable storage medium storing computer-readable instructions that, when executed by a processor, implement the steps of the bill query method as described in any one of the above descriptions.

[0010] Compared with the prior art, the embodiments of this application have the following main advantages: This application discloses a bill query method, apparatus, computer equipment, and storage medium. By constructing a full-chain processing system from consumption data collection, bill structuring processing, data integrity verification, encrypted chain generation, identity embedding, concurrent node verification, to long-term archiving of historical ledgers and efficient querying, the system ensures that bill data maintains a rigorous structure, clear associations, and traceability of origin throughout the generation, transmission, storage, and retrieval processes. Through node-level hash links and chained storage, bill data achieves hierarchical association, immutability, and automatic consistency verification during its formation, ensuring the integrity of the bill structure and the security of the bill content. Through concurrent verification and partitioned archiving mechanisms, the system can maintain the stability of ledger writing and the orderliness of bill version management under high-concurrency scenarios. By embedding encrypted customer identity identifiers and ledger index structures in the chain, bills can be accurately and quickly located according to user, time range, and query fields, greatly improving query efficiency and retrieval accuracy. Through the structuring processing of multi-dimensional fields such as expense detail splitting, transaction timestamps, payment methods, and consumption item classifications, the bills possess more granular analyzability and verifiability after formation. This application solution enables trusted management of billing data throughout its entire lifecycle, making data construction more standardized, data flow more secure, and data querying more efficient. Attached Figure Description

[0011] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 An exemplary system architecture diagram is shown, in which this application can be applied; Figure 2 A flowchart of one embodiment of the bill query method according to this application is shown; Figure 3 It shows Figure 2 A flowchart of an embodiment of step S203; Figure 4 A schematic diagram of the structure of one embodiment of the bill inquiry device according to this application is shown; Figure 5 It shows Figure 4A schematic diagram of the structure of an embodiment of the encrypted data module 403; Figure 6 A schematic diagram of the structure of one embodiment of a computer device according to this application is shown. Detailed Implementation

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0014] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0015] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0016] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables.

[0017] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0018] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, and a desktop computer, etc.

[0019] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0020] It should be noted that the bill query method provided in this application embodiment is generally executed by a server / terminal device, and correspondingly, the bill query device is generally set in the server / terminal device.

[0021] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative; the system can have any number of terminal devices, networks, and servers depending on implementation needs.

[0022] Continue to refer to Figure 2 A flowchart of an embodiment of a bill query method according to this application is shown. The bill query method includes the following steps: S201: Real-time collection of consumption data during peak consumption periods; structuring the consumption data by classifying consumption items and breaking down expense details to obtain an initial bill set. Specifically, real-time collection of consumption data during peak periods requires establishing a high-concurrency data acquisition channel within the system. This channel must be able to rapidly capture raw consumption records from different payment terminals, POS systems, and online transaction platforms under peak load conditions. To ensure accurate data classification, the system automatically identifies and parses consumption item fields, such as breaking down product codes, service category identifiers, and industry classification tags, and then mapping them to a pre-defined consumption classification system. Simultaneously, for the processing of detailed expense breakdowns, a rule engine or dynamic decomposition algorithm is used to break down a total expense into multiple sub-expense items, such as basic product costs, discount amounts, taxes, and additional service fees, and a structured label is created for each sub-item. The system needs to ensure unified processing capabilities for heterogeneous data during processing; therefore, a unified data structure template is used to standardize and transform data fields from different sources, forming a unified set of initial bill entries that can be parsed. In this overall process, the system may also employ data buffer queues and data batch processing mechanisms to reduce the risk of data loss due to instantaneous peaks and to uniformly log various collection errors, missing fields, and parsing anomalies.

[0023] Taking hotel billing as an example, during peak check-out periods, the system simultaneously receives consumption records from front desk POS machines, mobile payment terminals, room consumption systems, and online booking platforms. Targeting the unique consumption scenarios of the hotel industry, the system pre-sets classification templates for over 20 categories of consumption items, including room fees, minibar consumption, laundry services, and telephone charges, and intelligently parses consumption description fields using regular expression matching technology. For example, when detecting a consumption description of "Deluxe King Room - 2 nights," the system automatically splits it into structured fields such as "Room Type: Deluxe King Room" and "Stay Duration: 2 nights," while also splitting the total room rate into two sub-records based on the daily average price. For additional service fees, the system uses a layered splitting algorithm, first identifying basic service fees and value-added service fees, and then further splitting the value-added services by specific items (such as late check-out and breakfast upgrades).

[0024] During the data standardization process, the system standardizes the currency unit, timestamp format, and encoding specifications for all monetary fields. For example, foreign currency transactions are converted to RMB using the real-time exchange rate, and date formats such as "2024-03-15" and "15 / 03 / 2024" generated by different systems are unified to the ISO standard format. To cope with peak data surges, the system deploys a distributed message queue capable of processing over 5,000 transaction records per second. A sliding window algorithm is used to perform batch verification of the data; when the integrity rate of a batch of data falls below 98%, a compensation mechanism is automatically triggered to retrieve missing records from a backup data source. For data entries with parsing anomalies, the system generates alarm logs containing the error type, original field values, and suggested correction values, which are then pushed to the operations and maintenance terminal for manual intervention. After the entire structured processing is completed, the system generates an initial bill set containing a unique transaction ID, customer identifier, consumption item code, and standardized amount.

[0025] S202, Perform data integrity verification based on the consumption item classification and payment method records in the initial bill set; Specifically, to perform data integrity checks based on the consumption item categories and payment method records in the initial bill set, the system needs to construct a multi-dimensional verification framework, including field integrity checks, category consistency checks, payment method standardization checks, and cross-field association checks. First, the system checks whether each bill contains essential fields, such as amount, consumption category, payment method, and timestamp, and marks any missing fields. Second, based on preset consumption item classification rules, the system verifies whether the consumption item belongs to a valid category by parsing tags, encoding tables, or mapping dictionaries. If there are unidentifiable or category conflicts, the record needs to be marked into a pending list. Next, payment method verification confirms whether the payment type in the record belongs to a system-supported payment system, such as bank card payment, QR code payment, or e-wallet payment, and checks whether the payment identifier format is correct, such as whether the card number hash format meets the length requirements and whether the third-party payment voucher ID conforms to the encoding rules. In addition, the system also performs logical checks on the amount field, including whether the total amount of the consumption item details matches the total amount, whether there are illegal negative values ​​for discount amounts, and whether there are duplicate additions in the split details.

[0026] S203, if the data integrity verification passes, an encrypted data chain is generated based on the expense details and transaction timestamps in the consumption data; Specifically, after data integrity verification, an encrypted data chain needs to be generated based on the breakdown of expense details and transaction timestamps in the consumption data. The system first sorts the expense details by time dimension to ensure the traceability of the chain node construction order. Subsequently, each detail item is hashed as an independent node, typically using SHA series or other cryptographic digest algorithms that satisfy irreversibility and collision resistance to generate a unique hash identifier for each node. During chain construction, the system needs to create an initial node chain structure, arranging each node sequentially and establishing reference relationship fields between nodes to record the hash values ​​of predecessor nodes. Furthermore, the original node data (including amount, type label, timestamp, etc.) needs to be re-encoded to exist as a structured payload in the chain, making the chain not just a pointer relationship chain, but a data chain structure containing detailed billing information. The system also generates chain head and chain tail identifiers and attaches signature data to the entire chain through a chain signature mechanism. The signature can be based on an asymmetric encryption system or key derivation algorithm to ensure that the chain content cannot be modified without authorization during transmission and storage.

[0027] If data integrity verification fails, the system will immediately trigger an exception handling process. Specifically, the system will classify and mark the failed billing data according to preset exception classification rules, such as marking it as a field missing exception, a classification conflict exception, or an illegal payment method exception. For different types of exceptions, the system will adopt differentiated handling strategies: for field missing exceptions, the system will attempt to complete the missing fields from backup data sources or historical records; for classification conflict exceptions, the system will submit the conflict record to the manual review interface, where business personnel will manually classify it according to the actual business scenario; for illegal payment method exceptions, the system will directly reject the transaction record and generate a feedback report containing error details and correction suggestions. Simultaneously, the system will record all exception handling processes and results, forming an exception handling log. After exception handling is completed, the system will re-trigger the data integrity verification process until all billing data passes verification.

[0028] S204 embeds customer identity identifiers into the encrypted data chain and verifies the nodes in the encrypted data chain through a concurrent processing mechanism; Specifically, the process of embedding customer identity identifiers into an encrypted data chain and verifying the nodes in the chain through a concurrent processing mechanism requires the system to reserve an identity loading position in the chain structure. This position could be the chain head, chain tail, or a node with specific rules, where the customer identity identifier is written in an encrypted format. The identity identifier typically undergoes multiple security measures, such as using symmetric encryption for field protection, generating irreversible signatures through key mapping, or generating dedicated identity credentials through public key encryption, to ensure that the identity data cannot be directly reverse-engineered. After the identity is written, the system initiates a concurrent verification mechanism, splitting the chain nodes into several parallel processing tasks. Each task is responsible for verifying whether the node's hash value, link reference field, identity attachment field, and basic data fields are consistent. To ensure the orderly execution of tasks in a concurrent environment, the system uses thread pools, task queues, or asynchronous execution frameworks, and assigns priorities to chain nodes by sequence number or timestamp to prevent race conditions during verification. During the execution of each node's verification task, it is necessary to compare whether the predecessor hash of the current node's record is consistent with the hash of the previous node, and check whether the node with the embedded identity identifier contains the correct encrypted identity field. Finally, the system collects the results of all parallel tasks and generates a verification report.

[0029] S205 If the verification results are consistent, the encrypted data chain is added to the historical ledger archive based on the customer identity and bill update status to generate a long-term data bill. Specifically, when the node verification results are consistent, the system needs to add the encrypted data chain to the historical ledger archive based on the customer's identity and the bill update status. The system will locate the corresponding ledger partition from the ledger storage system based on the customer's identity and determine whether the chain is a new record, a supplementary record of a historical bill, or an overwrite update record based on the bill update status. If it is a new record, the system will append the chain to the end of the ledger; if it is a supplementary record, the insertion position needs to be located based on the timestamp; if it is an update, the data block corresponding to the original chain needs to be overwritten. During the write process, the system needs to fully archive the chain node structure and link fields, including node hash values, reference relationships, encrypted data payloads, and identity fields. During the ledger write process, a ledger index table also needs to be established to generate a quickly searchable index key for the chain, including user ID, transaction date, and bill number. After the write is completed, the system must perform version calibration on the ledger partition and verify the consistency of the link structure to ensure that all node reference relationships are complete and there are no broken links. Ultimately, the system will update the ledger's version number, archive time, chain count, and other status fields, enabling long-term data ledgers to enter a stable storage state within the system.

[0030] When node verification results are inconsistent, the system immediately initiates an anomaly correction process. First, it traces and locates the inconsistent nodes through logs, comparing differences in node hash values, link reference fields, and identity identifier fields to determine the anomaly type: data tampering, transmission error, or concurrent conflict. For data tampering, the system triggers a chain verification mechanism, recalculating hash values ​​starting from the head node and comparing node by node until the tampering point is found, marking the abnormal node and chain as suspicious data. For transmission errors, the system invokes the data retransmission protocol to retrieve the node's data from the original data source and re-embed it into the chain. For concurrent conflicts, the system checks parallel processing records in the task queue, identifying verification order errors caused by task scheduling delays, and reordering nodes according to timestamps. After all anomaly handling is complete, the system generates a correction report containing the anomaly type, handling measures, and correction results, and resubmits the corrected chain to the concurrent verification mechanism for secondary verification until the verification results are completely consistent. Simultaneously, the system records the anomaly handling process in the blockchain audit log to ensure all operations are traceable and tamper-proof. Finally, the encrypted data chain that passes secondary verification is rewritten into the historical ledger archive.

[0031] S206, upon receiving a bill query request, the system filters the target transaction timestamp and target fee details from the long-term data bill based on the query time and query field to obtain the target data bill.

[0032] Specifically, when the system receives a bill query request, it needs to filter the corresponding target transaction timestamps and target expense details from long-term data bills based on the query time and query fields. First, the system parses the query request parameters, including query start and end times, consumption type filters, payment method filters, amount ranges, service tags, and other query conditions, and locates the corresponding ledger partition based on the customer's identity. Then, the system quickly locates the chain nodes within the target time range using the ledger index table and filters the node payloads based on the query fields, such as filtering only specific consumption categories, specific merchant numbers, or bill items matching specific tags. During the filtering process, the node payloads in the chain need to be decoded one by one, and each expense detail item is compared to ensure that the filtering results accurately correspond to the user's query intent. When the number of nodes is large, the system may use multi-threaded queries, segmented ledger reading, and batch filtering mechanisms to improve query efficiency. After filtering, the system reassembles the matching transaction timestamps and expense details into a structured bill format, adding chain-related encrypted identifiers, timestamp fields, and ledger index information, ultimately returning the target data bill to the calling client.

[0033] Continuing with the hotel billing example, steps S201-S206 of this application solution achieve efficient and accurate billing management in a hotel setting. When a guest checks out at the front desk, the system simultaneously receives consumption data from multiple channels, including room charges, food and beverage services, and minibar usage. In step S201, the system automatically identifies consumption descriptions such as "Deluxe Suite - 3 nights - including breakfast for two," breaks them down into structured fields such as room type, stay duration, and additional services, and splits the total room rate into three sub-records based on the daily average price. Simultaneously, the breakfast cost is split into an independent item based on the single-person standard. For hotel-specific value-added services such as "late check-out fee" and "luggage storage fee," the system uses a layered splitting algorithm, first identifying the basic service fee and the value-added service fee, and then further splitting the value-added service by specific item.

[0034] In step S202, the data integrity verification process checks whether each bill contains essential fields such as room number, consumption time, and payment method. It also verifies the compliance of timestamp formats like "2024-03-20 14:30" using regular expression matching. For cross-border settlements, the system automatically converts USD consumption to RMB at the real-time exchange rate and verifies that the card number hash format meets the 16-digit length requirement. When a discrepancy is detected between the total and the minimum dining expense details on a bill, the system immediately marks it as an abnormal amount and triggers a compensation mechanism to retrieve the transaction record from the original POS data.

[0035] In the encrypted data chain generation stage of step S203, the system arranges all consumption records in chronological order of transaction time and generates a SHA-256 hash identifier for each detailed item such as "Room Service - 2024-03-18". By creating an initial node chain structure, the system points breakfast consumption nodes to room consumption nodes, forming a traceable chain relationship. For credit card payment records of foreign guests, the system uses an asymmetric encryption system to generate chain signatures to ensure that payment information cannot be tampered with during transmission. When a chain tail identifier is found to be missing, the system will restore the complete chain structure from the backup database.

[0036] After the concurrent verification mechanism in step S204 is activated, the system splits the chain nodes into 8 parallel processing tasks. Each task is responsible for verifying the node's hash value, predecessor reference field, and encrypted identity identifier. Through thread pool management technology, the system ensures that guest room consumption nodes complete verification before additional service nodes. When a discrepancy is detected between the identity identifier hash value embedded in a node and the ledger record, the system immediately isolates the node and traces the operation record through the blockchain audit log, ultimately confirming that the anomaly was caused by a concurrent write conflict.

[0037] In step S205, the ledger archiving process, the system locates the international customer ledger partition based on the customer's passport number and inserts the verified encrypted chain into the March 2024 bill block according to its timestamp. During the writing process, the system generates a ternary index key for each chain, containing the user ID, transaction date, and bill number, improving query efficiency. When an update record is found to overlap with a historical bill in time, the system initiates an overwrite update mechanism, preserving the hash reference relationship of the original chain while writing the new data to a separate data block.

[0038] Finally, in the query response phase of step S206, when a customer queries "dining consumption on March 18th" via the mobile app, the system quickly locates the three relevant chains for that date using the ledger index table, decodes the node payload, and filters out the detailed record for "Chinese restaurant - lunch - 2 people". For complex bills containing "service charge 15%", the system expands and displays the broken-down sub-items, while also showing the mapping relationship between the original consumption description and standardized fields. The entire query process is completed within 300ms, and the returned target data bill contains 12 structured fields, including transaction ID, encrypted identifier, and standardized amount, ensuring that customers can clearly verify the details of each consumption.

[0039] Furthermore, based on the consumption item categories and payment method records in the initial bill set, the data integrity verification steps include: Based on the preset consumption item classification rules, the labels of each consumption item in the initial bill set are checked to confirm whether the classification label is consistent with the consumption type, and the consumption item classification verification result is obtained. The payment method field in the payment method record is parsed in a standardized manner to identify abnormal formats or missing information and generate a list of payment methods to be verified. Cross-compare the results of the consumption item classification verification with the list of payment methods to be verified to detect whether there are classification conflicts, inconsistent amounts, or multiple payments for the same transaction, and identify abnormal transaction data. If abnormal transaction data is found, automatic error correction or completion processing will be performed on the abnormal transaction data, and a data integrity verification result will be generated.

[0040] Specifically, the system first loads a pre-defined rule base for classifying consumer items. This rule base contains standard classification identifiers and corresponding feature keywords for various consumer items. For each consumer record in the initial bill set, the system extracts its consumer description field and uses natural language processing technology to perform keyword matching and semantic analysis to determine its appropriate standard classification identifier. Subsequently, the system compares the analyzed classification identifier with the original classification identifiers in the bill. If the two are inconsistent, it is marked as a classification anomaly, and the details of the difference are recorded.

[0041] During the standardization and parsing of the payment method field, the system defines a standard payment method coding system covering various payment methods such as cash, bank cards, third-party payment platforms, and points redemption. For the payment method field in each billing record, the system first performs format validation to check whether it conforms to preset coding specifications, such as length limits and character types. If the format is abnormal, it is directly marked as a format error; if the format is correct, it further parses the specific payment method and matches it with the standard coding system to identify missing or incorrect payment method information and generate a list of payment methods to be validated.

[0042] Next, the system will cross-compare the results of the consumption item classification verification with the list of payment methods to be verified. During this process, the system will focus on classification conflicts, i.e., situations where there is a logical contradiction between the consumption item classification and the payment method classification within the same transaction, such as incorrectly classifying a food and beverage consumption as an accommodation consumption while using a specific food and beverage payment method. Simultaneously, the system will also check for inconsistencies in amounts, i.e., discrepancies between the consumption item amount and the payment amount, or multiple payments within the same transaction with the total amount exceeding the consumption amount. Through intelligent algorithm analysis, the system can accurately identify these abnormal transaction data and record their specific type and location.

[0043] For identified abnormal transaction data, the system will perform automatic error correction or completion processing according to preset error correction strategies. For classification conflicts, the system will automatically adjust the consumption item category or payment method category based on the consumption description and payment method characteristics to ensure consistency. For inconsistent amounts, the system will prioritize the consumption item amount, adjust the payment amount record, or split multiple payment records to match the actual consumption amount. For missing information, the system will attempt to complete the missing fields from related billing records or system logs. After processing, the system will generate a detailed data integrity verification report, including the anomaly type, handling measures, and a comparison before and after correction.

[0044] If no abnormal transaction data is detected, the system will directly determine that the data integrity verification of the initial bill set has passed and generate a data integrity verification report. This report will record basic information about the verification, such as the verification time, the number of bills involved, the consumption item classification rules, and the payment method coding system used. Simultaneously, the system will mark the initial bill set that has passed verification as data usable for subsequent processes, such as successfully entering the encrypted data chain generation stage. Afterwards, the system will continue to process this data according to the established process, including generating encrypted data chains, performing concurrent verification, and adding the encrypted data chains to the historical ledger archive, to ensure that the bill data can be stored and managed accurately and securely. Furthermore, the system will periodically evaluate and optimize the data integrity verification process and rules, updating the preset consumption item classification rule library and payment method coding system based on actual business development and changes in data characteristics, further improving the accuracy and efficiency of data integrity verification and ensuring the stable operation of the entire bill management system. Further, please refer to Figure 3 The steps for generating an encrypted data chain based on the expense details and transaction timestamps in the consumption data include: S301, associate each expense item in the expense details breakdown with the corresponding transaction timestamp according to the order of generation, forming a set of original bill nodes arranged in time sequence; S302, Perform a hash digest operation on each node in the original bill node set, and use the resulting hash value as the node identifier to construct the initial node chain structure; S303, link the identifiers of adjacent nodes in the initial node chain structure level by level, write the hash value of the previous node into the link field of the next node, and form a data chain with forward and backward association relationships. S304 performs overall signature processing on the data chain to generate an encrypted data chain.

[0045] Specifically, in step S301, the system will meticulously analyze the breakdown of expenses in the consumption data to clarify the chronological order in which each expense was incurred. For example, in a bill that includes multiple expenses such as room charges, food and beverage charges, and minibar charges, the system will arrange the room charges, food and beverage charges, minibar charges, etc., in chronological order according to the actual time of occurrence of the expenses, and accurately associate each expense with the corresponding transaction timestamp, ultimately forming a set of original bill nodes arranged in time sequence.

[0046] In step S302, the system performs a hash digest operation on each node in the original billing node set. Taking the common SHA-256 algorithm as an example, the system takes detailed information about each node, such as the fee amount, consumption type, and transaction timestamp, as input, and performs complex calculations using this algorithm to obtain a fixed-length hash value. This hash value serves as the unique identifier for that node. Using these node identifiers, the system begins to build an initial node chain structure, initially connecting the various nodes.

[0047] In step S303, the system performs a step-by-step linking operation on the adjacent node identifiers in the initial node chain structure. Specifically, the system writes the hash value of the previous node into the link field of the next node. For example, the hash value of node A is written into the link field of node B, the hash value of node B is written into the link field of node C, and so on. Through this operation, a data chain with forward and backward associations is formed, ensuring that each node is closely connected to the preceding and following nodes through the link field, thus guaranteeing the continuity and traceability of the data.

[0048] Finally, in step S304, the system performs a comprehensive signature process on the entire data chain. The system employs asymmetric encryption technology, using the private key to sign the data chain. The signing process comprehensively calculates all information within the data chain to generate a unique digital signature. This digital signature is tightly bound to the data chain and can only be verified using the corresponding public key. After this comprehensive signature processing, the original data chain becomes an encrypted data chain, effectively ensuring the security and integrity of data during transmission and storage, and preventing data tampering or forgery.

[0049] Furthermore, the steps of linking adjacent node identifiers in the initial node chain structure level by level, and writing the hash value of the previous node into the link field of the next node to form a data chain with forward and backward associations, specifically include: The initial node chain structure is sorted according to the transaction timestamps of each node to determine the generation order of the links between adjacent nodes. Obtain the hash identifier of the previous node after sorting, and write the hash identifier of the previous node as the link reference information into the forward link field of the next node; Based on the hash identifier of the next node, generate the corresponding backward association reference information and write the backward association reference information back to the backward link field of the previous node; Perform consistency checks on node pairs that have established forward and backward link relationships. The consistency checks are used to confirm that the link reference information and the hash identifier of the corresponding node are completely consistent. After the consistency check passes, the node pair is added to the constructed data chain sequence, and the remaining nodes continue to be linked step by step until a complete data chain is formed.

[0050] Specifically, the system first performs a detailed sorting process on the initial node chain structure based on the transaction timestamps corresponding to each node, ensuring that the generation order of the links between adjacent nodes accurately reflects the chronological order of the transactions. For example, in a bill containing multiple transactions, the system arranges the nodes chronologically according to the actual transaction time of each transaction, thereby clarifying the positional relationship between adjacent nodes.

[0051] After sorting, the system retrieves the hash identifier of the previous node. This hash identifier is a unique identifier obtained by performing a hash digest operation on the previous node, possessing high uniqueness and immutability. The system uses this hash identifier as link reference information and precisely writes it into the forward link field of the next node. This operation allows the next node to clearly know who its predecessor node is, providing the possibility for data traceability.

[0052] Next, the system generates corresponding backward association reference information based on the hash identifier of the next node. This backward association reference information is closely related to the hash identifier of the next node and can uniquely identify the next node. The system writes this backward association reference information back to the backward link field of the previous node, so that the previous node can also know who its successor node is. Through this operation, a close forward and backward association relationship is established between the two nodes.

[0053] To ensure the accuracy of this association, the system performs consistency checks on node pairs with established forward and backward links. The consistency check carefully verifies whether the link reference information completely matches the hash identifier of the corresponding node. If any inconsistency is found, the system immediately investigates and corrects it to ensure the integrity and accuracy of the data chain.

[0054] After the consistency check passes, the system adds this node pair to the constructed data chain sequence. This data chain sequence is a dynamically expanding structure that grows continuously as nodes are linked level by level. The system continues to perform level-by-level linking processing on the remaining nodes, following the same steps and methods to accurately link each node to the data chain. Finally, after a series of processing and verifications, a complete data chain is formed. This data chain not only has forward and backward relationships but has also undergone rigorous consistency checks, ensuring the accuracy and integrity of the data.

[0055] Furthermore, the steps for performing consistency verification on node pairs that have established forward and backward link relationships specifically include: The first comparison result is obtained by comparing the backward link reference information written by the previous node with the hash identifier of the next node in the node pair. By comparing the forward link reference information written by the next node with the hash identifier of the previous node, a second comparison result is obtained. The reference format, field length, and encoding rules of the preceding and following links are verified for standardization, and a third comparison result is obtained. A temporary verification chain is constructed based on the preceding and following link reference information. The temporary verification chain is then used to verify whether it conforms to the link generation rules in terms of logical order and timestamp sequence, thus obtaining the fourth comparison result. If the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result are all consistent, then the node pair is determined to have passed the consistency check.

[0056] Specifically, the system first performs a comparison, carefully comparing the backward link reference information written by the previous node with the hash identifier of the next node. This step is to confirm the accuracy of the successor node information recorded by the previous node. By comparing the recorded backward link reference information with the actual hash identifier of the next node, potential recording errors or tampering can be detected in a timely manner. If the two are completely consistent, the first comparison result is a pass, indicating that the previous node's record of the successor node is correct; if there are differences, the first comparison result is a fail, and the system will record the specific difference information.

[0057] Next, the system performs a second comparison, comparing the forward link reference information written by the subsequent node with the hash identifier of the preceding node. The purpose of this comparison is to verify the accuracy of the predecessor node information recorded by the subsequent node. Similarly, the second comparison is considered successful only if the forward link reference information recorded by the subsequent node completely matches the actual hash identifier of the preceding node; otherwise, it fails, and details of the difference are recorded. Through the first and second comparisons, the system can ensure the accuracy of the link reference information between nodes from both directions.

[0058] Then, the system performs a standardization check on the reference format, field length, and encoding rules of the preceding and following link fields, obtaining a third comparison result. This step is to ensure that the link reference information conforms to preset standard specifications in terms of format and encoding. The system checks, according to predefined rules, whether the reference format of the preceding and following link fields is correct, such as whether it conforms to specific string format requirements; whether the field length is within the allowed range to avoid fields that are too long or too short; and whether the encoding rules are consistent, such as whether the same character encoding method is used. If all checks meet the specifications, the third comparison result is passed; otherwise, it is failed, and the specific reasons for non-compliance are recorded.

[0059] Next, the system constructs a temporary verification chain based on the preceding and following link reference information. It then verifies whether the temporary verification chain conforms to the link generation rules in terms of logical order and timestamp sequence, obtaining the fourth comparison result. When constructing the temporary verification chain, the system connects relevant nodes sequentially according to the preceding and following link relationships between nodes, forming a temporary chain structure. The system then checks whether this temporary chain is logically reasonable, for example, whether there are circular references or incorrect node connection orders. Simultaneously, the system checks whether the transaction timestamp sequence corresponding to each node in the chain conforms to the actual transaction occurrence order, ensuring that the timestamps are incrementing and reasonable. If the temporary verification chain conforms to the link generation rules in both logical order and timestamp sequence, the fourth comparison result is passed; otherwise, it fails, and the specific location and situation of the rule violation are recorded.

[0060] Finally, the system will comprehensively evaluate the first, second, third, and fourth comparison results. Only when all four comparison results are consistent (i.e., all pass), will the system determine that the node pair has passed the consistency check. If any one of the comparison results fails, the consistency check of the entire node pair fails, and the system will take appropriate measures for the failure, such as re-recording link reference information and investigating the cause of data errors, to ensure the accuracy and integrity of the data chain.

[0061] Furthermore, the steps of embedding customer identity identifiers into the encrypted data chain and verifying the nodes in the encrypted data chain through a concurrent processing mechanism specifically include: Based on a preset embedding strategy, the customer identity identifier is written into a specified node or node group of the encrypted data chain in the form of an encrypted tag; Construct a concurrent processing task queue and add nodes containing customer identity identifiers in the encrypted data chain to the concurrent verification task in sequence or in groups; In a concurrent execution environment, the identity identifier, hash identifier, and link reference fields of each node are synchronously verified to check whether the node has been tampered with, is missing, or has mismatched identifiers. Integrate concurrent verification results, mark nodes with anomalies and trigger the repair process, and generate a final verification confirmation flag for nodes that verify the results.

[0062] Specifically, the system first carefully selects designated nodes or groups of nodes within the encrypted data chain based on a preset embedding strategy. The selection of these nodes or groups is not arbitrary but scientifically determined based on the importance and relevance of the data. After determining the location, the system cleverly embeds the customer's identity identifier as an encrypted marker. This encryption method ensures the security of the customer's identity identifier without affecting the normal operation of the data chain. For example, the system might employ an advanced encryption algorithm to convert the customer's identity identifier into a unique encrypted string and then embed it into a specific field of the designated node.

[0063] After embedding customer identities, the system constructs a concurrent processing task queue. This task queue acts like an ordered work list, adding nodes containing customer identities from the encrypted data chain in a specific order or group. The order may be determined by factors such as the node's position in the data chain and transaction timestamps, while the grouping may be based on the node's type, the business module it belongs to, etc. In this way, the system ensures the orderly execution of concurrent verification tasks, improving processing efficiency.

[0064] Next, the system will perform synchronous verification on each node in a concurrent execution environment. This concurrent execution environment acts like a high-efficiency multi-threaded platform, capable of handling verification tasks for multiple nodes simultaneously. During verification, the system carefully checks the identity identifier, hash identifier, and link reference field of each node. The identity identifier confirms the node's owner client, the hash identifier ensures the node's uniqueness and immutability, and the link reference field reflects the association between nodes. The system compares this information to verify whether nodes have been tampered with, are missing, or have mismatched identifiers. For example, the system checks whether the node's identity identifier matches the preset client identity, whether the hash identifier matches the previously calculated result, and whether the link reference field correctly points to the preceding and following adjacent nodes.

[0065] After completing the synchronization verification of all nodes, the system integrates the concurrent verification results. For nodes exhibiting anomalies, the system marks them in detail and immediately triggers a repair process. The repair process takes appropriate measures based on the specific anomaly, such as re-embedding the customer identity identifier, correcting the hash identifier, or repairing the link reference field. For nodes that verify correctly, the system generates a final verification confirmation flag. This flag acts like a stamp of approval, indicating that these nodes have passed rigorous verification and the data is accurate. In this way, the system ensures that every node in the encrypted data chain is authentic and reliable, providing customers with secure and accurate data services.

[0066] Furthermore, the steps of adding the encrypted data chain to the historical ledger archive based on customer identification and bill update status to generate a long-term data bill specifically include: Based on the customer's identity identifier, the corresponding ledger partition is retrieved from the historical ledger to determine the ledger location and ledger index to be written; Determine whether the encrypted data chain belongs to a new bill, a supplementary bill, or an overwritten bill based on the bill update status, and select the corresponding ledger writing mode accordingly; Under the matching ledger write mode, the node information, link structure and encryption tokens of the encrypted data chain are written sequentially to the historical ledger storage area; Update the version number, update timestamp, and customer ledger index information of the ledger partition to generate a long-term data bill.

[0067] Specifically, the system first performs a precise search within the vast database of historical ledgers based on the key information of the customer's identity. Historical ledgers are typically divided into multiple partitions, each corresponding to a different customer group or business category. Through this search, the system can quickly locate the ledger partition matching the customer's identity, thereby determining the specific location in the ledger to be written and the ledger index. The ledger index acts like a detailed directory, helping the system quickly find the exact location where data needs to be written, improving the efficiency of data writing.

[0068] Once the ledger location is determined, the system will assess the nature of the encrypted data chain based on the bill update status. Bill update status typically includes three scenarios: new bill, supplementary bill, and overwritten bill. A new bill refers to the customer's first bill data, which needs to be fully added to the historical ledger; a supplementary bill refers to bill data that was not previously recorded for some reason and now needs to be entered; and an overwritten bill refers to modifying or updating previously recorded bill data. The system will select the appropriate ledger writing mode based on the different bill types. For example, for a new bill, the system will use a completely new writing method, writing all the information of the encrypted data chain completely to the specified ledger location; for a supplementary bill, the system will find a suitable location to insert the data based on the existing ledger data; and for an overwritten bill, the system will first locate the original bill data location and then perform an overwrite operation.

[0069] After selecting a matching ledger write mode, the system sequentially writes the node information, link structure, and encryption tokens of the encrypted data chain into the historical ledger storage area according to a specific order and rules. Node information contains detailed data for each node, the link structure reflects the relationships between nodes, and the encryption token is an encrypted representation of the customer's identity. The system ensures that all this information is accurately written into the historical ledger to guarantee data integrity and accuracy. For example, the system first writes the basic information of the nodes, then sequentially writes the relationship information of adjacent nodes according to the link structure, and finally writes the encryption token into the specified field.

[0070] After the data writing is complete, the system updates the relevant information in the ledger partition. This includes updating the partition's version number, which reflects the number of times the ledger data has been updated and its status; updating the timestamp, which records the specific time of the last data update; and updating the customer's ledger index information to ensure that the index information is consistent with the actual data written. Through these update operations, the system generates a long-term data statement. This long-term data statement acts as a complete historical record, detailing all of the customer's billing information and undergoing rigorous encryption and verification processes, providing customers with secure, reliable, and long-term data storage and retrieval services. Customers can legally access their long-term data statement at any time to understand their spending history and financial situation.

[0071] In this embodiment, the bill query method runs on an electronic device (e.g., Figure 1 The server shown can receive instructions or acquire data via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future wireless connection methods.

[0072] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0073] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0074] Further reference Figure 4 As a response to the above Figure 2 The implementation of the method shown in this application provides an embodiment of a bill inquiry device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0075] like Figure 4 As shown, the bill inquiry device 400 described in this embodiment includes: The structured processing module 401 is used to collect consumption data during peak consumption periods in real time, and to perform structured processing on the consumption items classification and expense details in the consumption data to obtain an initial bill set. The integrity verification module 402 is used to perform data integrity verification based on the consumption item classification and payment method records in the initial bill set; The encrypted data module 403 is used to generate an encrypted data chain based on the expense details and transaction timestamps in the consumption data when the data integrity verification passes. The identity module 404 is used to embed customer identity identifiers in the encrypted data chain and to verify the nodes in the encrypted data chain through a concurrent processing mechanism. The data archiving module 405 is used to add the encrypted data chain to the historical ledger archive and generate a long-term data bill when the verification results are consistent, based on the customer identification and bill update status. The bill query module 406 is used to receive a bill query request and then filter the target transaction timestamp and target fee details from the long-term data bill according to the query time and query field to obtain the target data bill.

[0076] Furthermore, the integrity verification module 402 specifically includes: The tag verification submodule is used to verify the tags of each consumer item in the initial bill set based on the preset consumer item classification rules, to confirm whether the classification label is consistent with the consumption type, and to obtain the consumer item classification verification result. The normalization parsing submodule is used to normalize and parse the payment method field in the payment method record, identify abnormal formats or missing information, and generate a list of payment methods to be verified. The cross-comparison submodule is used to cross-compare the results of the consumption item classification verification with the list of payment methods to be verified, to detect whether there are classification conflicts, inconsistent amounts, or multiple payments for the same transaction, and to identify abnormal transaction data. The exception handling submodule is used to perform automatic error correction or completion processing on abnormal transaction data when abnormal transaction data exists, and to generate data integrity verification results.

[0077] Further, please refer to Figure 5 The encrypted data module 403 specifically includes: The time sequence submodule 501 is used to associate each expense item in the expense details with the corresponding transaction timestamp according to the generation order, forming a set of original bill nodes arranged in time sequence; The hash operation submodule 502 is used to perform a hash digest operation on each node in the original bill node set and use the resulting hash value as the node identifier to construct the initial node chain structure. The link processing submodule 503 is used to link the identifiers of adjacent nodes in the initial node chain structure level by level, write the hash value of the previous node into the link field of the next node, and form a data chain with forward and backward association relationships. The signature processing submodule 504 is used to perform overall signature processing on the data chain and generate an encrypted data chain.

[0078] Furthermore, the link processing submodule 503 specifically includes: The sorting processing unit is used to sort the initial node chain structure according to the transaction timestamps corresponding to each node, and determine the link generation order of adjacent nodes. The first writing unit is used to obtain the hash identifier of the previous node after sorting, and write the hash identifier of the previous node as the link reference information into the forward link field of the next node. The second writing unit is used to generate corresponding backward association reference information based on the hash identifier of the next node, and write the backward association reference information back to the backward link field of the previous node; The consistency verification unit is used to perform consistency verification on node pairs that have established forward and backward link relationships. The consistency verification is used to confirm that the link reference information and the hash identifier of the corresponding node are completely consistent. The step-by-step linking unit is used to add node pairs to the constructed data chain sequence after the consistency check passes, and to continue to perform step-by-step linking processing on the remaining nodes until a complete data chain is formed.

[0079] Furthermore, the consistency verification unit specifically includes: The first comparison subunit is used to compare the backward link reference information written by the previous node with the hash identifier of the next node in the node pair to obtain the first comparison result. The second comparison subunit is used to compare the forward link reference information written by the next node with the hash identifier of the previous node to obtain the second comparison result. The third comparison subunit is used to perform standardization verification on the reference format, field length and encoding rules of the fields in the preceding and following links, and to obtain the third comparison result; The fourth comparison subunit is used to construct a temporary verification chain based on the preceding and following link reference information, verify whether the temporary verification chain conforms to the link generation rules in terms of logical order and timestamp sequence, and obtain the fourth comparison result; The consistency verification subunit is used to determine whether a node pair passes the consistency verification when the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result are all consistent.

[0080] Furthermore, the identity verification module 404 specifically includes: The identifier writing submodule is used to write the customer identity identifier into a specified node or node group of the encrypted data chain in the form of an encrypted tag, based on a preset embedding strategy. The concurrent processing submodule is used to build a concurrent processing task queue, adding nodes containing customer identity identifiers in the encrypted data chain to the concurrent verification task in sequence or in groups; The synchronous verification submodule is used to synchronously verify the identity identifier, hash identifier, and link reference fields of each node in a concurrent execution environment to verify whether the node has been tampered with, is missing, or has mismatched identifiers. The node verification submodule is used to integrate concurrent verification results, mark nodes with abnormalities and trigger the repair process, and generate a final verification confirmation flag for nodes that verify the results.

[0081] Furthermore, the data archiving module 405 specifically includes: The ledger partitioning submodule is used to retrieve the corresponding ledger partition from the historical ledger based on the customer's identity identifier, and determine the ledger location and ledger index to be written; The write mode submodule is used to determine whether the encrypted data chain belongs to a new bill, a supplementary bill, or an overwritten and updated bill based on the bill update status, and select the corresponding ledger write mode. The data writing submodule is used to sequentially write the node information, link structure and encryption tokens of the encrypted data chain into the historical ledger storage area under the matching ledger writing mode. The ledger update submodule is used to update the version number, update timestamp, and customer ledger index information of the ledger partition, and generate long-term data bills.

[0082] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 6 , Figure 6 This is a basic structural block diagram of the computer device in this embodiment.

[0083] The computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are interconnected via a system bus. It should be noted that only the computer device 6 with memory 61, processor 62, and network interface 63 is shown in the figure; however, it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0084] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0085] The memory 61 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 61 may be an internal storage unit of the computer device 6, such as the hard disk or memory of the computer device 6. In other embodiments, the memory 61 may also be an external storage device of the computer device 6, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 6. Of course, the memory 61 may also include both the internal storage unit and its external storage device of the computer device 6. In this embodiment, the memory 61 is typically used to store the operating system and various application software installed on the computer device 6, such as computer-readable instructions for billing query methods. In addition, the memory 61 can also be used to temporarily store various types of data that have been output or will be output.

[0086] In some embodiments, the processor 62 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 62 is typically used to control the overall operation of the computer device 6. In this embodiment, the processor 62 is used to execute computer-readable instructions stored in the memory 61 or to process data, such as executing computer-readable instructions for the billing query method.

[0087] The network interface 63 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 6 and other electronic devices.

[0088] This application also provides an embodiment, namely, a computer device including a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the bill query method described above.

[0089] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the bill query method described above.

[0090] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0091] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0092] It should be noted that the software tools or components not belonging to this company that appear in the various embodiments of this application are merely illustrative examples and do not represent actual use.

[0093] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A bill inquiry method, characterized in that, include: Real-time collection of consumption data during peak consumption periods; structuring of consumption items and expense details in the consumption data to obtain an initial bill set; Based on the consumption item categories and payment method records in the initial bill set, perform data integrity verification; If the data integrity verification passes, an encrypted data chain is generated based on the expense details and transaction timestamps in the consumption data. A customer identity identifier is embedded in the encrypted data chain, and the nodes in the encrypted data chain are verified through a concurrent processing mechanism; If the verification results are consistent, the encrypted data chain is added to the historical ledger archive based on the customer identity identifier and the bill update status to generate a long-term data bill. Upon receiving a bill query request, the system filters the target transaction timestamp and target fee details from the long-term data bill based on the query time and query field to obtain the target data bill.

2. The bill inquiry method as described in claim 1, characterized in that, The step of performing data integrity verification based on the consumption item classification and payment method records in the initial bill set specifically includes: Based on the preset consumption item classification rules, the labels of each consumption item in the initial bill set are checked to confirm whether the classification label is consistent with the consumption type, and the consumption item classification verification result is obtained. The payment method field in the payment method record is parsed in a standardized manner to identify abnormal formats or missing information and generate a list of payment methods to be verified. The results of the consumption item classification verification are cross-compared with the list of payment methods to be verified to detect whether there are classification conflicts, inconsistent amounts, or multiple payments for the same transaction, and to identify abnormal transaction data. If the abnormal transaction data exists, automatic error correction or completion processing is performed on the abnormal transaction data, and a data integrity verification result is generated.

3. The bill inquiry method as described in claim 1, characterized in that, The step of generating an encrypted data chain based on the breakdown of expense details and transaction timestamps in the consumption data specifically includes: Each expense item in the expense details breakdown is associated with its corresponding transaction timestamp based on the order in which it was generated, forming an original bill node set arranged in time sequence; Perform a hash digest operation on each node in the original bill node set, and use the resulting hash value as the node identifier to construct the initial node chain structure; The identifiers of adjacent nodes in the initial node chain structure are linked level by level, and the hash value of the previous node is written into the link field of the next node to form a data chain with forward and backward association relationships. The data chain is then subjected to overall signature processing to generate the encrypted data chain.

4. The bill inquiry method as described in claim 3, characterized in that, The step of linking adjacent node identifiers in the initial node chain structure level by level, and writing the hash value of the previous node into the link field of the next node to form a data chain with forward and backward associations, specifically includes: The initial node chain structure is sorted according to the transaction timestamps corresponding to each node to determine the link generation order of adjacent nodes; Obtain the hash identifier of the previous node after sorting, and write the hash identifier of the previous node as link reference information into the forward link field of the next node; Based on the hash identifier of the next node, generate the corresponding backward association reference information and write the backward association reference information back to the backward link field of the previous node; A consistency check is performed on node pairs that have established forward and backward link relationships, wherein the consistency check is used to confirm that the link reference information and the hash identifier of the corresponding node are completely consistent; After the consistency check passes, the node pair is added to the constructed data chain sequence, and the remaining nodes continue to be linked step by step until a complete data chain is formed.

5. The bill inquiry method as described in claim 4, characterized in that, The step of performing consistency verification on node pairs that have established forward and backward link relationships specifically includes: The first comparison result is obtained by comparing the backward link reference information written by the previous node with the hash identifier of the next node in the node pair. By comparing the forward link reference information written by the next node with the hash identifier of the previous node, a second comparison result is obtained. The reference format, field length, and encoding rules of the preceding and following links are verified for standardization, and a third comparison result is obtained. A temporary verification chain segment is constructed based on the preceding and following link reference information. The temporary verification chain segment is then verified to determine whether it conforms to the link generation rules in terms of logical order and timestamp sequence, thus obtaining the fourth comparison result. If the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result are all consistent, then the node pair is determined to have passed the consistency check.

6. The bill inquiry method as described in claim 4, characterized in that, The step of embedding a customer identity identifier in the encrypted data chain and verifying the nodes in the encrypted data chain through a concurrent processing mechanism specifically includes: Based on a preset embedding strategy, the customer identity identifier is written into a designated node or node group of the encrypted data chain in the form of an encrypted tag; Construct a concurrent processing task queue, and add the nodes containing customer identity identifiers in the encrypted data chain to the concurrent verification task in sequence or in groups; In a concurrent execution environment, the identity identifier, hash identifier, and link reference fields of each node are synchronously verified to check whether the node has been tampered with, is missing, or has mismatched identifiers. Integrate concurrent verification results, mark nodes with anomalies and trigger the repair process, and generate a final verification confirmation flag for nodes that verify the results.

7. The bill inquiry method as described in claim 1, characterized in that, The step of adding the encrypted data chain to the historical ledger archive based on the customer identity identifier and the bill update status to generate a long-term data bill specifically includes: Based on the customer identity identifier, the corresponding ledger partition is retrieved from the historical ledger to determine the ledger location and ledger index to be written; Based on the bill update status, determine whether the encrypted data chain belongs to a new bill, a supplementary bill, or an overwritten bill, and select the corresponding ledger writing mode; In the matching ledger writing mode, the node information, link structure and encryption mark of the encrypted data chain are sequentially written into the historical ledger storage area; Update the version number, update timestamp, and customer ledger index information of the ledger partition to generate the long-term data bill.

8. A bill inquiry device, characterized in that, include: The structured processing module is used to collect consumption data during peak consumption periods in real time, and to perform structured processing on the consumption items classification and expense details in the consumption data to obtain an initial bill set. The integrity verification module is used to perform data integrity verification based on the consumption item classification and payment method records in the initial bill set; The encrypted data module is used to generate an encrypted data chain based on the expense details and transaction timestamps in the consumption data when the data integrity verification passes. An identity identification module is used to embed a customer identity identifier into the encrypted data chain and to verify the nodes in the encrypted data chain through a concurrent processing mechanism; The data archiving module is used to add the encrypted data chain to the historical ledger archive and generate a long-term data bill when the verification results are consistent, based on the customer identity identifier and the bill update status. The bill query module is used to receive a bill query request and then filter the target transaction timestamp and target fee details from the long-term data bill according to the query time and query field to obtain the target data bill.

9. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the bill query method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the bill query method as described in any one of claims 1 to 7.

Images