Full-amount transaction query method and device, product and storage medium

Abstract

The invention discloses a total transaction query method and device, a product and a storage medium. The method comprises the following steps: in response to a plurality of accounts selected and queried by a user and query conditions for the plurality of accounts, analyzing respective categories of the plurality of accounts to obtain a unique identifier and an account attribute of each account; on the basis of the account attribute of each account, obtaining intraday transaction details and historical transaction details of each account; combining the intraday transaction details and the historical transaction details of each account into corresponding complete transaction details; performing standardized operation on the complete transaction details corresponding to each account based on a query time period in the query condition to obtain account dimension data of each account; generating account summary data of the plurality of accounts according to the account dimension data of each account; and outputting the account dimension data and the account summary data of each account based on the account attribute and the query condition of each account. According to the method and the device, the efficiency of total transaction query of multiple accounts can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and specifically to a method, apparatus, product, and storage medium for full transaction query. Background Technology

[0002] In banking and payment operations, users frequently need to initiate full transaction queries for multiple accounts over extended time spans. Existing systems often retrieve data on an account-by-account basis, lacking a unified execution plan and resource isolation across accounts. This leads to repeated parsing and scanning of the same conditions, linearly amplifying network round trips and I / O. When both the number of accounts and the time range increase, queries and result output often share connections and threads with other services, resulting in head-blocking phenomena where front-end queries are overwhelmed by back-end output resources. Furthermore, inconsistencies in the timing and encoding rules of data returned from multiple sources introduce additional overhead for merging, sorting, and duplicate filtering. These combined factors result in high average response times, large tail latency fluctuations, and unstable throughput for full, multi-account, long-range detailed queries under current technology, making it difficult to meet the efficiency requirements of high-concurrency scenarios. Summary of the Invention

[0003] The purpose of this application is to provide a method, apparatus, product, and storage medium for full transaction query, in order to solve the problem of low efficiency in full transaction query for multiple accounts in the prior art.

[0004] To achieve the above objectives, the first aspect of this application provides a method for querying all transactions, including: In response to the user selecting multiple accounts and query conditions for multiple accounts, the system parses the categories of each account to obtain the unique identifier and account attributes of each account; Retrieve daily and historical transaction details for each account based on its account attributes; The daily transaction details and historical transaction details of each account are merged into the corresponding complete transaction details; Based on the query time period in the query conditions, a standardized operation is performed on the complete transaction details corresponding to each account to obtain the account dimension data for each account; Generate summary account data for multiple accounts based on the account-level data of each account; Based on the account attributes and query conditions of each account, the account dimension data and account summary data of each account are output.

[0005] In this application embodiment, the account attributes include at least one or more of the following: transaction visibility, currency, amount decimal places, inventory threshold, output mode, public / private account identifier, and this agent identifier.

[0006] In this embodiment of the application, the query conditions include output information; the step of outputting the account dimension data and account summary data of each account based on the account attributes and query conditions of each account includes: when both the output information and the output mode are print output, determining whether the query time period exceeds the in-database threshold; if it does not exceed the threshold, outputting the account dimension data and account summary data of each account synchronously; if it exceeds the threshold, outputting the account dimension data and account summary data of each account asynchronously.

[0007] In this embodiment of the application, the step of outputting the account dimension data and account summary data of each account based on the account attributes and query conditions of each account further includes: generating a corresponding query condition summary based on the query conditions when both the output information and the output mode are electronic export; filling the query condition summary into the account dimension data and account summary data; and sending the filled account dimension data and account summary data to the user.

[0008] In this embodiment of the application, the step of performing a standardization operation on the complete transaction details corresponding to each account based on the query time period in the query conditions to obtain the account dimension data of each account includes: determining the intersection of all time periods included in the complete transaction details with the query time period; determining the first detail in the complete transaction details based on the intersection; the first detail includes multiple transaction records, each of which contains a serial number; deduplicating the first detail based on the serial number of each transaction record to obtain the second detail; and using the second detail as the account dimension data of each account.

[0009] In this embodiment of the application, the step of deduplicating the first details based on the serial number of each transaction record to obtain the second details includes: selecting multiple first records with duplicate serial numbers from the first details, and using the records other than the multiple first records as the second records; determining the source of each first record; and concatenating all the first records whose source is the transaction details of the day with the second records to form the second details.

[0010] In this embodiment of the application, before the step of outputting the account dimension data and account summary data of each account, the method further includes: generating a desensitization rule for each account based on the account attributes of each account; desensitizing the part of the account dimension data and account summary data corresponding to each account based on the desensitization rule of each account, and outputting the desensitized dimension data and account summary data of each account.

[0011] A second aspect of this application provides a full transaction query device, comprising: a parsing module, configured to, in response to a user selecting multiple accounts for query and query conditions for the multiple accounts, parse the respective categories of the multiple accounts to obtain a unique identifier and account attributes for each account; an acquisition module, configured to acquire the daily transaction details and historical transaction details of each account based on the account attributes of each account; a merging module, configured to merge the daily transaction details and historical transaction details of each account into corresponding complete transaction details; a standardization module, configured to perform a standardization operation on the complete transaction details corresponding to each account based on the query time period in the query conditions to obtain account dimension data for each account; a generation module, configured to generate account summary data for multiple accounts based on the account dimension data of each account; and an output module, configured to output the account dimension data and account summary data of each account based on the account attributes and query conditions of each account.

[0012] A third aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0013] A fourth aspect of this application provides a machine-readable storage medium storing instructions that cause a machine to perform the methods described above.

[0014] The above technical solution firstly categorizes and uniquely identifies multiple accounts selected by the user at once, along with the query conditions for those accounts, at the entry point, ensuring that the same account has a consistent locator and unified rule definition across different sources and media. Then, based on account attributes, it retrieves the daily transaction details and historical transaction details separately, and merges the two sets of data into corresponding complete transaction details for each account, eliminating the risk of inconsistent definitions for the same account and duplicate or omitted data across sources. Furthermore, based on the query time period specified in the query conditions, it performs standardized operations on the complete transaction details for each account, forming a data set that can be directly used for statistical analysis. The system ensures consistency and reproducibility of field meanings, measurement accuracy, and time boundaries with the displayed account dimension data. Furthermore, it generates summary data for multiple accounts using the account dimension data as input, enabling parallel comparability and rapid overview of multiple accounts within the same time period. Finally, the output is trimmed and assembled based on each account's attributes and query conditions, ensuring consistency between the account dimension data and the summary data. This reduces redundant parsing and invalid scanning, lowers the overhead of cross-source merging and deduplication, stabilizes sorting and pagination consistency, improves query efficiency and output timeliness, and enhances the accuracy, comparability, and traceability of the results.

[0015] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0016] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings: Figure 1 A flowchart illustrating a full transaction query method according to an embodiment of this application is shown schematically. Figure 2 A flowchart illustrating a full transaction query method according to a first embodiment of this application is shown schematically. Figure 3 A flowchart illustrating a full transaction query method according to a second embodiment of this application is shown schematically. Figure 4 The diagram illustrates the structure of a full transaction query device according to an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0018] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0019] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0020] Figure 1 A flowchart illustrating a method for querying all transactions according to an embodiment of this application is shown schematically. Figure 1As shown in the figure, this application provides a method for querying all transactions, which may include the following steps.

[0021] Step 101: In response to the user's selection of multiple accounts and query conditions for multiple accounts, parse the categories of each account to obtain the unique identifier and account attributes of each account.

[0022] In this embodiment, "multiple accounts" refers to multiple account objects selected by the user at one time, including both financial accounts based on account numbers and collections of similar accounts based on cards, account sets, etc.; the query conditions are unified retrieval and presentation constraints for these accounts, including at least one or more of the following: query start, amount range, income and expenditure direction, keywords, channel type, and output information; the category is a classification used to determine the identification generation rules and attribute sources for each account, such as product type or medium form, to distinguish between current accounts, fixed deposits, account sets, cards, fund pools, dedicated accounts, loans, etc.; the unique identifier is a one-to-one correspondence between a single account under the accounting caliber. The system's internal location key is generated using pre-defined field combinations based on different categories, ensuring that the same account is uniquely identified across any channel and data source. Account attributes are a set of rules and restrictions bound to the account, including at least one or more of the following: transaction visibility, currency, amount decimal places, inventory threshold, output mode, public / private account identifier, and agent identifier. By parsing the categories of multiple accounts and generating unique identifiers and account attributes accordingly, the system completes the mapping and standardization from external user selections to internal standard objects, eliminating ambiguity caused by different interpretations for the same account and multiple media, and ensuring that the location and strategy relied upon for subsequent processing of each account are determined and consistent from the source.

[0023] Step 102: Obtain the daily transaction details and historical transaction details for each account based on the account attributes of each account.

[0024] In this embodiment, the daily transaction details refer to the set of individual transaction records generated by the daily transaction system and retrieved within the daily accounting cycle, while the historical transaction details refer to the set of individual transaction records stored in historical storage (including data storage facilities such as archives, data warehouses, or data lakes) and retrieved outside the daily accounting cycle. The daily transaction details and historical transaction details of each account are obtained, and both have been standardized according to account attributes in terms of field meaning, measurement accuracy, and visibility, ensuring that the retrieval results for the same account from different sources are consistent and usable.

[0025] Step 103: Merge the daily transaction details and historical transaction details of each account into the corresponding complete transaction details.

[0026] Step 104: Perform standardized operations on the complete transaction details corresponding to each account based on the query time period in the query conditions to obtain the account dimension data for each account.

[0027] In this embodiment, the daily and historical transaction details of each account are aggregated according to the account's unique identifier, and the records within the same account are uniformly sorted and deduplicated to form complete transaction details. Complete transaction details are a set of individual transactions for a single account, directly usable for statistical processing under the same criteria. Based on the query time period in the query conditions, standardization operations are performed on the complete transaction details corresponding to each account. Standardization operations can include deduplication of duplicate records with the same serial number and stable sorting by transaction date and time order, at least including extracting a valid interval based on the query time period and ensuring consistency of amount and currency according to the accuracy requirements of account attributes. Account dimension data is an account-side representation formed based on the standardized set of individual transactions for the same account within the query time period, directly reflecting the available detailed basic data and consistent display criteria for the account within that time period. For each account, account dimension data that can be directly used for display and subsequent statistical processing within the same account scope after merging and standardization is determined, ensuring clear record boundaries, consistent field criteria, elimination of duplicates, and stable order.

[0028] Step 105: Generate summary account data for multiple accounts based on the account dimension data of each account.

[0029] Step 106: Based on the account attributes and query conditions of each account, output the account dimension data and account summary data for each account.

[0030] In this embodiment, generating account summary data for multiple accounts based on account dimension data for each account refers to statistically analyzing each result of the same account within a query period according to account dimension to form a set of overview indicators such as beginning balance, ending balance, total income, total expenditure, and number of transactions. Then, the results are aggregated by account to form a parallel summary result for multiple accounts. Subsequently, based on the account attributes and query conditions of each account, the corresponding account dimension data and account summary data are output. This means that visible fields and decimal places of amounts are pruned according to account attributes, and the returned data payload and presentation format are assembled according to the time and filtering range specified by the query conditions. By centrally generating account summary data and pruning and assembling it on the output side according to account attributes and query conditions, duplicate statistics and invalid field transmission for each account are avoided, data processing and backhaul overhead are reduced, thereby improving query efficiency and output timeliness, and stabilizing response time and throughput.

[0031] The above technical solution firstly categorizes and uniquely identifies multiple accounts selected by the user at once, along with the query conditions for those accounts, at the entry point, ensuring that the same account has a consistent locator and unified rule definition across different sources and media. Then, based on account attributes, it retrieves the daily transaction details and historical transaction details separately, and merges the two sets of data into corresponding complete transaction details for each account, eliminating the risk of inconsistent definitions for the same account and duplicate or omitted data across sources. Furthermore, based on the query time period specified in the query conditions, it performs standardized operations on the complete transaction details for each account, forming a data set that can be directly used for statistical analysis. The system ensures consistency and reproducibility of field meanings, measurement accuracy, and time boundaries with the displayed account dimension data. Furthermore, it generates summary data for multiple accounts using the account dimension data as input, enabling parallel comparability and rapid overview of multiple accounts within the same time period. Finally, the output is trimmed and assembled based on each account's attributes and query conditions, ensuring consistency between the account dimension data and the summary data. This reduces redundant parsing and invalid scanning, lowers the overhead of cross-source merging and deduplication, stabilizes sorting and pagination consistency, improves query efficiency and output timeliness, and enhances the accuracy, comparability, and traceability of the results.

[0032] In this application embodiment, account attributes may include at least one or more of the following: transaction visibility, currency, amount decimal places, inventory threshold, output mode, public / private account identifier, and this agent identifier.

[0033] In this embodiment, account attributes are a set of rules bound to a single account, used to limit the scope and boundaries of the same account in the query and output stages; transaction visibility is used to specify whether the account is allowed to return transaction records one by one and the range of fields that can be returned, which is a control over the granularity of information and the visibility range of fields; currency is used to indicate the currency unit used for pricing of the account, as the basic encoding for amount measurement and symbol display; decimal places of amount are used to specify the measurement precision and rounding rules of the amount fields of the account, ensuring that the amount expression is consistent within the same account; the in-database threshold is used to define the time boundary between the account's transaction data in the database and the archive, as the data source and access path. The selection criteria for the path; the output mode is used to specify the allowed external output methods for this account, such as print output or electronic export; the public / private identifier is used to mark the customer subject category of this account, so that different fields can be displayed and security controls can be applied according to the subject category; the agency identifier is used to mark whether the handling relationship of this account in the current query is handled by the person or by an agent, thereby restricting the visible fields and calling criteria; a set of executable and verifiable attribute parameters is established for each account, so that subsequent retrieval, field processing and external output of this account are based on the same set of rules, ensuring the consistency of the criteria and access compliance of the same account from the source and reducing the return of invalid data.

[0034] In this embodiment of the application, the query conditions include output information; the step of outputting the account dimension data and account summary data of each account based on the account attributes and query conditions of each account may include: when both the output information and the output mode are print output, determining whether the query time period exceeds the in-database threshold; if it does not exceed the threshold, then outputting the account dimension data and account summary data of each account synchronously; if it exceeds the threshold, then outputting the account dimension data and account summary data of each account asynchronously.

[0035] In this embodiment, the query conditions are a set of retrieval and presentation constraints set by the user for multiple accounts. Output information indicates the desired external output format and medium; output mode is a control parameter in the account attributes, used to limit the allowed external output methods for the account; print output refers to the physical media output format using a printing device; the query time period is the time range to be covered by this query; the inventory threshold is a time threshold in the account attributes used to distinguish between inventory and archive boundaries; synchronous printing is a method where the printing channel is occupied immediately upon task triggering and paper output is completed within the same processing flow; asynchronous printing is a method where a print request is registered upon task triggering and handed over to a background queue for scheduling, and paper output is completed in an independent process. When both output information and output mode point to print output, the system selects between synchronous and asynchronous printing based on whether the query time period exceeds the inventory threshold. Thus, using account attributes as constraints and query conditions as triggers, the system determines the specific printing path and execution timing for each account's account-dimensional data and account summary data. By linking output channels with time boundaries in a rule-based manner, manual judgment and redundant configuration are reduced, unnecessary occupation of front-end resources is avoided, and the selection and execution of print jobs are guaranteed to comply with account-side permissions and device-side capabilities, thereby improving the determinism of output paths and processing efficiency.

[0036] In this embodiment of the application, the step of outputting the account dimension data and account summary data of each account based on the account attributes and query conditions of each account may further include: when the output information and output mode are both electronic export, generating a corresponding query condition summary based on the query conditions; filling the query condition summary into the account dimension data and account summary data, and sending the filled account dimension data and account summary data to the user.

[0037] In this embodiment, electronic export refers to the output method of transmitting and presenting electronic files externally, encompassing downloadable or accessible electronic file carriers provided to users via network channels. The query condition summary is a metadata identifier formed by structurally summarizing the query conditions, typically consisting of standardized expressions or summary values ​​of key fields such as account scope, query time period, and filtering elements, used to mark the request scope and retrieval boundaries in the output payload. When both the output information and output mode are electronic export, a query condition summary is first generated based on the query conditions, and this summary is then filled into the metadata fields or reserved fields of the account dimension data and account summary data before being sent to the user. This achieves explicit binding and self-description of the results and request scope on the output side, facilitating user verification of the source scope, improving the traceability and verifiability of the results, and avoiding interpretation bias caused by ambiguity in the scope.

[0038] In this embodiment of the application, the step of performing a standardization operation on the complete transaction details corresponding to each account based on the query time period in the query conditions to obtain the account dimension data of each account may include: determining the intersection of all time periods included in the complete transaction details with the query time period; determining the first detail in the complete transaction details based on the intersection; the first detail includes multiple transaction records, each transaction record containing a serial number; deduplicating the first detail based on the serial number of each transaction record to obtain the second detail; and using the second detail as the account dimension data of each account.

[0039] In this embodiment, the query time period in the query conditions refers to the start and end time boundaries defined by this retrieval. The complete transaction details are a set of individual transactions for a single account, organized according to a unified field standard. The intersection is the overlapping interval between the entire time period covered by the complete transaction details and the query time period. The first detail is a time-constrained subset extracted from the complete transaction details based on this intersection. The transaction record is a single entry in the first detail arranged in chronological order. The serial number is an identifier key used to distinguish individual entry under the same account. Deduplication is the process of excluding duplicate entries within the first detail based on the serial number. The second detail is the result set after deduplication. Only transactions that match the query time period and are not duplicates are retained, ensuring that each account receives account-dimensional data with clear boundaries, consistent standards, and direct representation of the account's actual transaction facts within the specified time period. This improves the accuracy and efficiency of the query and provides a stable data foundation for subsequent processing.

[0040] In this embodiment of the application, the step of deduplicating the first details based on the serial number of each transaction record to obtain the second details may include: selecting multiple first records with duplicate serial numbers from the first details, and using the records other than the multiple first records as the second records; determining the source of each first record; and concatenating all first records whose source is the transaction details of the day with the second records to form the second details.

[0041] In this embodiment, multiple first records refer to a set of two or more records corresponding to the same serial number after grouping by serial number within the first detail. A second record refers to a set of records that appear only once in the first detail, excluding multiple first records. The source refers to the data source identifier to which the record belongs, used to distinguish between daily transaction details and historical transaction details. Specifically, multiple first and second records are first identified within the first detail. Then, the source of each multiple first record is determined, and the record whose source is the daily transaction detail is selected as the retained record for that serial number. Finally, all the retained first and second records are concatenated in a predetermined order to form the second detail. This source-first strategy eliminates duplicates at the serial number granularity and avoids accidental deletion of unique records, ensuring that the second detail, under the same account caliber, has clear deduplication, consistent source, and stable order, thereby improving the accuracy and efficiency of data processing in this step.

[0042] In this embodiment of the application, before the step of outputting the account dimension data and account summary data of each account, the method may further include: generating a desensitization rule for each account based on the account attributes of each account; desensitizing the part of the account dimension data and account summary data corresponding to each account based on the desensitization rule of each account, and outputting the desensitized dimension data and account summary data of each account.

[0043] In this embodiment, the anonymization rules can be generated based on account attributes. Transaction visibility, currency, decimal places, inventory threshold, output mode, corporate / private account identifier, and agent identifier can be used as master control parameters. The anonymization rules are a set of executable mapping relationships. One side of the mapping is a Cartesian set of parameter combination keys, i.e., corporate / private account identifier, agent identifier, transaction visibility, output mode, and decimal places. The other side is a set of processing actions for the field or field group, including visibility, partial masking, complete hiding, and numerical precision pruning. For example: when a private account is processed by the individual, transaction visibility is enabled, and the output mode is electronic export, the first character of the counterparty's name is retained with the remaining mask; the last four digits of the ID number are retained with the remaining mask; the first three and last four digits of the mobile phone number are retained with the middle mask; the amount is displayed with decimal places; and the serial number retains the first eight and last four digits. For example: When dealing with a private transaction through an agent and with transaction-by-transaction visibility enabled, only a summary of transaction elements and the counterparty category are returned, excluding counterparty account information and document information. The first twenty characters of the remarks field are retained, while the rest are hidden. The amount is still displayed with decimal places. For example: When dealing with a corporate transaction through the individual and the output mode is printout, the company name, bank information, and bill number are fully displayed to meet reconciliation needs. The contact person and phone number are hidden, and the amount is displayed with decimal places and currency symbol. For example: When dealing with a corporate transaction through an agent, regardless of the transaction-by-transaction visibility value, only the necessary transaction summary elements and the anonymized counterparty summary are provided, without displaying counterparty account information and contact information. Based on this, after generating and applying the anonymization rules, consistent and verifiable field-level processing can be implemented on the parts of the account dimension data and account summary data corresponding to each account without changing the data facts. This makes the visibility scope and display accuracy boundaries clear for the four scenarios of individual and agent transactions, and private and corporate transactions, reducing unauthorized exposure and providing compliant and stable input for subsequent presentation and delivery.

[0044] Figure 2 A flowchart illustrating a full transaction query method according to a first embodiment of this application is shown schematically. Figure 2As shown, in one embodiment, customer identification first involves access from counter or non-counter channels, collecting identity information and performing media identification to generate customer information. After entering business identification, the user selects the object to be queried (account) from various entry points such as Account All-in-One, Card Single Selection, Loan / Repayment Details, Repayment All-in-One, Current Account Statement, Card Statement, Product Statement, Single Transaction Details, and Funding Channel Statement. The system responds accordingly to the user's selection of multiple accounts and query conditions for those accounts, parsing the categories of each account to obtain a unique identifier and account attributes. In the details query, based on the account attributes, the system obtains the daily transaction details and historical transaction details for each account, and integrates the two sets of data using standardized query conditions to form the corresponding complete transaction details. Then, based on the query conditions... The query period performs standardized operations on the complete transaction details corresponding to each account to obtain account-dimensional data for each account, and generates summary data for multiple accounts based on the account-dimensional data of each account. In the file output, based on the account attributes and query conditions of each account, the account-dimensional data and summary data of each account are output. When the output information and output mode are print output, the process is executed in the print initiation and print appointment branches. If electronic export is selected, an EXCEL, PDF or TXT file is generated and an electronic seal is affixed to the PDF. Then, the file is distributed according to whether the file is sent separately. Finally, the delivery is completed through counter printers, peripheral printers, customer mobile phone printing, customer email, or remote peripheral printing. The status of the above steps is tracked and recorded by the monitoring system.

[0045] Figure 3 A flowchart illustrating a full transaction query method according to a second embodiment of this application is shown schematically. Figure 3As shown, in one embodiment, after completing identity verification / media verification, the user selects multiple accounts. The system parses the categories of each account based on the medium form such as bank card, sub-account information, passbook / deposit slip, etc., to obtain the unique identifier and account attributes of each account. In the recurring details scenario, the system distinguishes between single recurring details and full details based on the business entry point (requiring input of invoice number / voucher number or query time). In the special account details scenario, the account sub-number needs to be entered. In the current account details scenario, the query is directly entered based on the account list. The above entry points converge to the sub-account information and sub-account information nodes. Combining sub-account query and personalized rule configuration, as well as input product type and input filter conditions, query conditions for multiple accounts are formed. Subsequently, according to the technical solution... The solution obtains the daily and historical transaction details for each account based on its account attributes. These details are then merged into a complete transaction record. Standardization operations are performed on the complete transaction details for each account based on the query time period specified in the query criteria, yielding account-dimensional data for each account. This data is then used to generate summary data for multiple accounts. Finally, based on the account attributes and query criteria, the account-dimensional data and summary data for each account are output. The output channels are presented in three ways: detail query, print, and email, indicating that results can be delivered regardless of whether the output information and mode are set to detail display, print output, or electronic export.

[0046] Figure 4 The diagram schematically illustrates a structural diagram of a full transaction query device according to an embodiment of this application. Figure 4 As shown in the figure, this application embodiment provides a full transaction query device, which may include: a parsing module 410, used to parse the categories of the multiple accounts in response to the user's selection of multiple accounts and query conditions for the multiple accounts to obtain the unique identifier and account attributes of each account; an acquisition module 420, used to acquire the daily transaction details and historical transaction details of each account based on the account attributes of each account; a merging module 430, used to merge the daily transaction details and historical transaction details of each account into the corresponding complete transaction details; a standardization module 440, used to perform a standardization operation on the complete transaction details corresponding to each account based on the query time period in the query conditions to obtain the account dimension data of each account; a generation module 450, used to generate account summary data of multiple accounts based on the account dimension data of each account; and an output module 460, used to output the account dimension data and account summary data of each account based on the account attributes and query conditions of each account.

[0047] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0048] This application also provides a machine-readable storage medium storing instructions that cause a machine to perform the above-described method.

[0049] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0050] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0051] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0052] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0053] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

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

[0055] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0056] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0057] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for querying all transactions, characterized in that, The method includes: In response to the user selecting multiple accounts and query conditions for the multiple accounts, the categories of each of the multiple accounts are parsed to obtain the unique identifier and account attributes of each account; Based on the account attributes of each account, obtain the daily transaction details and historical transaction details of each account; The daily transaction details and historical transaction details of each account are merged into the corresponding complete transaction details; Based on the query time period in the query conditions, a standardized operation is performed on the complete transaction details corresponding to each account to obtain the account dimension data for each account; Generate summary account data for the multiple accounts based on the account dimension data of each account; Based on the account attributes of each account and the query conditions, the account dimension data and the account summary data of each account are output.

2. The method according to claim 1, characterized in that, The account attributes include at least one or more of the following: transaction visibility, currency, amount decimal places, inventory threshold, output mode, public / private account identifier, and this agency identifier.

3. The method according to claim 2, characterized in that, The query criteria include the output information; The step of outputting the account dimension data and the account summary data for each account based on the account attributes of each account and the query conditions includes: If both the output information and the output mode are printed, determine whether the query time period exceeds the in-database threshold. If the limit is not exceeded, the account dimension data of each account and the account summary data will be output synchronously by printing. If the number of cases exceeds the limit, the account dimension data of each account and the account summary data will be output asynchronously.

4. The method according to claim 3, characterized in that, The step of outputting the account dimension data and the account summary data for each account based on the account attributes of each account and the query conditions further includes: When both the output information and the output mode are electronically exported, a corresponding query condition summary is generated based on the query conditions. The query summary is populated into the account dimension data and the account summary data, and the populated account dimension data and account summary data are sent to the user.

5. The method according to claim 1 or 2, characterized in that, The step of performing a standardization operation on the complete transaction details corresponding to each account based on the query time period in the query conditions to obtain the account dimension data of each account includes: Determine the intersection of all time periods included in the complete transaction details with the query time period; The first detail is determined from the complete transaction details based on the intersection; the first detail includes multiple transaction records, each of which contains a serial number; The first detail is deduplicated based on the serial number of each transaction record to obtain the second detail; The second detail is used as the account dimension data for each account.

6. The method according to claim 5, characterized in that, The step of deduplicating the first detail based on the serial number of each transaction record to obtain the second detail includes: From the first details, select multiple first records with duplicate serial numbers, and use the records other than the multiple first records as second records; Determine the source of each first record; All first records whose source is the transaction details of the day are concatenated with the second record to form the second details.

7. The method according to claim 1 or 2, characterized in that, Before the step of outputting the account dimension data of each account and the account summary data, the method further includes: Anonymization rules for each account are generated based on the account attributes of each account; Based on the anonymization rules for each account, the portions of the account dimension data and the account summary data corresponding to each account are anonymized, and the anonymized dimension data and account summary data for each account are output.

8. A full transaction query device, characterized in that, include: The parsing module is used to parse the categories of each of the multiple accounts selected by the user and the query conditions for the multiple accounts to obtain the unique identifier and account attributes of each account. The acquisition module is used to acquire the daily transaction details and historical transaction details of each account based on the account attributes of each account; The merging module is used to merge the daily transaction details and historical transaction details of each account into the corresponding complete transaction details; The standardization module is used to perform standardization operations on the complete transaction details corresponding to each account based on the query time period in the query conditions, so as to obtain the account dimension data of each account; The generation module is used to generate summary account data for the multiple accounts based on the account dimension data of each account; The output module is used to output the account dimension data and the account summary data of each account based on the account attributes of each account and the query conditions.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 7.

10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to perform the method according to any one of claims 1 to 7.

Images