Bill file generation method and device, electronic equipment and storage medium
By generating library-level billing tasks and dynamically allocating file merging tasks in the task management system, the problems of excessive number of detailed billing files and low fault tolerance in multi-site, multi-center distributed architectures are solved, realizing an efficient, reliable, and simplified processing flow for billing file generation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NETSUNION CLEARING CORP
- Filing Date
- 2024-10-18
- Publication Date
- 2026-04-21
AI Technical Summary
The existing multi-site, multi-center distributed architecture of the reconciliation platform results in an excessive number of detailed billing files. The number of files increases linearly with the number of data centers and databases, which increases the complexity of the file download and processing process for member institutions. Furthermore, it has low fault tolerance, as the failure of any institution to generate a file will affect the billing generation of all member institutions.
The task management system generates database-level billing tasks, calculates the amount of data in the database for participating institutions, generates database-level detailed files, and dynamically allocates file merging tasks based on the data volume to generate data center-level detailed files, thereby reducing the number of detailed billing files and improving task fault tolerance.
It reduces the complexity of billing for member organizations, improves the fault tolerance of task execution, ensures that the failure of document generation in any organization does not affect other organizations, and improves operational efficiency and business continuity.
Smart Images

Figure CN121901150A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for generating billing documents. Background Technology
[0002] The reconciliation platform employs a multi-site, multi-center distributed architecture, setting up multiple data centers across multiple regions. Each region has one or more data centers to process massive transaction flows in batches, providing participating institutions with timely and accurate invoicing files. These invoicing files include detailed files and summary files. For example, transaction data is distributed across six data centers. Each data center uses a database sharding and table partitioning strategy to store transaction flows. The invoicing files are processed in three stages: each data center queries local transactions and performs local calculations based on the participating institution's dimension to generate a database-level detailed file; local summary data is calculated to generate a center-level detailed file; and the summaries of the six data centers are calculated to generate a summary file.
[0003] However, this approach results in an excessive number of detailed billing files, with the number of files increasing linearly with the number of data centers and databases. This increases the complexity of the file download and processing processes for member institutions. Furthermore, if any institution fails to generate a file, it will affect the generation of bills for all member institutions, resulting in low fault tolerance. Summary of the Invention
[0004] This application provides a billing file generation method, apparatus, electronic device, and storage medium to achieve the technical effects of reducing the number of detailed billing files, reducing the complexity of file download and processing processes for member institutions, and improving task fault tolerance and operational efficiency.
[0005] The embodiments of this application adopt the following technical solutions:
[0006] In a first aspect, embodiments of this application provide a billing file generation method, applied to a task management system. The task management system provides billing tasks to each processing node of a billing processing system. Each processing node corresponds to a transaction data center, and each transaction data center deploys multiple databases. The method includes:
[0007] In response to the clearing completion notification, a database-level billing task corresponding to each of the databases is generated, enabling each of the processing nodes to count the amount of data of each transaction participant in each database and generate a database-level detailed file for each transaction participant.
[0008] Based on the amount of data in each database of each participating institution, a file merging task corresponding to each data center is generated, so that each processing node can merge and generate a data center-level detailed file for each participating institution based on the generated database-level detailed file.
[0009] Optionally, the method further includes: receiving task status update notifications from each processing node;
[0010] The step of generating file merging tasks corresponding to each data center based on the data volume of each participating institution in each database includes:
[0011] After all the library-level billing tasks in each of the data centers have been executed successfully, a file merging task is generated based on the transaction count information of each of the data centers.
[0012] Optionally, generating file merging tasks corresponding to each of the data centers based on the amount of data in each database held by each participating institution includes:
[0013] Based on the cluster resource status of the billing processing system, determine the number of file merging tasks for each processing node;
[0014] Based on the number of file merging tasks and the amount of data in each database of each transaction participant, the transaction participant corresponding to each file merging task is determined.
[0015] Optionally, the method further includes:
[0016] Receive transaction count information from all database-level billing tasks of the data centers.
[0017] Based on the number of transactions, the organization information for each file merging task is calculated using the bucket sort principle;
[0018] Based on the institutional information of each file merging task, the total transaction volume processed by each file merging task is balanced to dynamically allocate the participating institutional information of the transactions to be merged.
[0019] Optionally, after generating file merging tasks corresponding to each of the data centers based on the data volume of each participating institution in each database, the process further includes:
[0020] Based on the detailed data center files of each participating institution, a summary task corresponding to the current data center is generated, so that each processing node can merge and generate the summary task of the current participating institution according to the detailed data center files.
[0021] Optionally, after generating file merging tasks corresponding to each of the data centers based on the data volume of each participating institution in each database, the process further includes:
[0022] Determine if there are any instances where the merging of database-level detailed files from participating institutions failed;
[0023] If the merging of library-level detail files fails, the information of the failed transaction participants will be reported, and a summary task will be generated based on the transaction participants that were successfully merged into the library-level detail files.
[0024] Optionally, after generating file merging tasks corresponding to each of the data centers based on the data volume of each participating institution in each database, the process further includes:
[0025] Determine if there are any instances where the merging of database-level detailed files from participating institutions failed;
[0026] If the merging of library-level detail files fails, a corresponding rerun task is generated so that each processing node can re-merge and generate the data center-level detail files of the corresponding transaction participants based on the already generated library-level detail files.
[0027] Secondly, embodiments of this application provide a billing document generation apparatus applied to a task management system, the apparatus being used to implement the billing document generation method as described in any of the first aspects above.
[0028] Thirdly, embodiments of this application provide an electronic device, including: a processor; and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform a billing file generation method as described in any of the first aspects above.
[0029] Fourthly, embodiments of this application provide a computer-readable storage medium storing one or more programs that, when executed by an electronic device including multiple applications, cause the electronic device to perform the billing document generation method as described in any of the first aspects above.
[0030] The above-mentioned at least one technical solution adopted in the embodiments of this application can achieve the following beneficial effects: The billing file generation method, apparatus, electronic device and storage medium disclosed in the embodiments of this application generate library-level billing tasks corresponding to each database, enabling each processing node to count the amount of data of each transaction participant in each database and generate library-level detailed files for each transaction participant, thereby improving the fault tolerance capability of task execution. When the file generation of any participant fails, it does not affect the generation of detailed billing files of other participants, reducing the cost of task restart and improving operation and maintenance efficiency; By generating file merging tasks corresponding to each data center, each processing node can merge and generate data center-level detailed files for each transaction participant based on the generated library-level detailed files, reducing the number of detailed billing files and reducing the complexity of billing for transaction participants. Attached Figure Description
[0031] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0032] Figure 1 This is a schematic diagram of the system architecture of an account reconciliation platform;
[0033] Figure 2 This is a flowchart illustrating a billing document generation method according to an embodiment of this application;
[0034] Figure 3 This is a schematic diagram of the task-driven process of a task management system according to an embodiment of this application;
[0035] Figure 4 This is a schematic diagram of the structure of a bill document generation device according to an embodiment of this application;
[0036] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation
[0037] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0038] To facilitate understanding of the various embodiments of this application, firstly, in conjunction with... Figure 1 Explain the problems existing in the reconciliation platform. Figure 1 A system architecture diagram of a reconciliation platform is provided. This platform adopts a multi-location, multi-center distributed architecture, meaning multiple data centers are set up in multiple regions, with one or more data centers in each region. It processes massive transaction flows in batches, providing participating institutions with timely and accurate invoice files, including detailed and summary files. For example, transaction data may be distributed across six data centers, with each data center employing a database sharding and table partitioning strategy for storing transaction flows. Figure 1 As shown, the billing files are processed in three stages: each data center queries local transactions and performs local calculations based on participating institutions to generate a library-level detailed file; local summary data is calculated to generate a center-level detailed file; and summary data from the six data centers is calculated to generate a summary file. These three stages of billing tasks are uniformly managed and driven by the task management system.
[0039] The three phases of the task are progressive. The next phase depends on the temporary files and calculation results generated in the previous phase. The first phase task generates library-level files for the second phase task, and the second phase task provides the center's transaction summary data for the third phase task.
[0040] In other words, after the library-level files are generated, they are not merged with the central-level files. Instead, the library-level billing details are provided to external entities. The maximum number of details files for a participating organization is: number of data centers × number of libraries. For example, if there are 6 data centers and 15 libraries per center, then a participating organization will have a maximum of 90 files.
[0041] Therefore, this approach has the following drawbacks:
[0042] First, there is a large number of detailed billing documents. The number of documents increases linearly with the number of data centers and databases, thereby increasing the complexity of the document download and processing processes for member organizations.
[0043] Second, it has low fault tolerance. The task is not broken down according to the participating institutions, so the failure to generate a file for any participating institution will affect the generation of invoices for all participating institutions.
[0044] Based on the aforementioned technical issues, the billing file generation method, apparatus, electronic device, and storage medium provided in this application generate billing tasks through a task management system and provide them to each processing node of the billing processing system. This enables each transaction data center to execute summary tasks from the perspective of participating institutions, thereby reducing the number of detailed billing files, lowering the complexity of billing processing for participating institutions, and improving task fault tolerance and operational efficiency.
[0045] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.
[0046] This application provides a billing file generation method, applied to a task management system. The task management system is used to provide billing tasks to each processing node of the billing processing system. Each processing node is set up in correspondence with each transaction data center, and multiple databases are deployed in each transaction data center. Figure 2 This is a flowchart illustrating a billing document generation method according to an embodiment of this application, such as... Figure 2 As shown, the method includes steps S210 to S220:
[0047] Step 210: In response to the clearing completion notification, generate a database-level billing task corresponding to each of the databases, so that each processing node can count the amount of data of each transaction participant in each database and generate a database-level detailed file for each transaction participant.
[0048] Specifically, after receiving the batch clearing completion notification, the task management system sends the file merging task instruction message to the billing processing system in the data center.
[0049] First, the billing processing system executes the database-level billing task. After execution, it retrieves the number of databases for each participating institution within the data center. Then, it counts the number of transactions in each database for each participating institution, obtaining the total number of transactions for each institution within the data center. Finally, the billing processing system generates a database-level file for each participating institution within the data center based on the transaction counts in each database. After generating the database-level file, the system notifies the task management system to update the task status and reports the total number of transactions for all institutions in the current database task.
[0050] Step 220: Based on the amount of data in each database of each trading participant, generate a file merging task corresponding to each data center, so that each processing node can merge and generate a data center-level detail file for each trading participant based on the generated database-level detail files.
[0051] Specifically, after all database-level billing tasks in this data center have been successfully executed, the task management system generates a file merging task based on the number of transactions for each institution within this data center. In this embodiment, the reconciliation platform still adopts a multi-site, multi-center distributed architecture, and the file merging task generation has the ability to dynamically allocate tasks based on the volume of transaction data. Since all data centers process data on a per-institutional basis, if a file merging failure occurs for one participating institution, it does not affect the file merging of other participating institutions, thereby improving the reliability of the system.
[0052] Therefore, the billing file generation method disclosed in this application enables each transaction data center to execute library-level billing tasks and file merging tasks from the perspective of transaction participants, realizing dynamic allocation of data volume, reducing the number of detailed billing files, and reducing the complexity of billing processing for participating institutions; the library-level detailed files of each participating institution in a single data center are merged according to the specified file size, improving the fault tolerance of task execution, and if the file generation of any participating institution fails, it will not affect the generation of detailed billing files of other participating institutions, ensuring that billing files of other institutions are provided in a timely manner and reducing the impact on business.
[0053] In one embodiment of this application, the method further includes: receiving task status update notifications from each processing node; generating file merging tasks corresponding to each data center based on the amount of data in each database of each transaction participant includes: generating file merging tasks based on the number of transactions in each data center after all database-level billing tasks in each data center have been successfully executed.
[0054] Specifically, after the billing processing system completes the generation of the database-level detailed files, it notifies the task management system to update the task status and reports the total number of institutional transactions for the current database task. Additionally, after successfully completing the aggregation task, the billing processing system can also notify the task management system to update the task status.
[0055] In one embodiment of this application, generating a file merging task corresponding to each of the data centers based on the amount of data in each database held by each transaction participant includes:
[0056] Based on the cluster resource status of the billing processing system, determine the number of file merging tasks for each processing node; based on the number of file merging tasks and the amount of data in each database of each transaction participant, determine the transaction participant corresponding to each file merging task.
[0057] The principle behind generating file merging tasks is as follows: First, the number of merging tasks can be dynamically configured according to the cluster size, making full use of cluster resources and avoiding uneven task distribution. Second, the time taken for each file merging task is proportional to the amount of transactions it processes; the larger the transaction volume, the longer the task takes. That is, all participating institutions involved in the number of database-level transactions reported in Phase 1 need to undergo file merging, and the number of file merging tasks is limited. Third, the institutional information for each file merging task is calculated based on the number of transactions reported by all database-level billing tasks in this data center, thereby balancing the total transaction volume processed by each merging task and achieving dynamic allocation of data volume.
[0058] In one embodiment of this application, the method further includes: receiving transaction count information of transaction participants reported by all database-level billing tasks in each of the data centers; calculating the institution information of each file merging task based on the transaction count information using the bucket sort principle; and balancing the total transaction volume processed by each file merging task based on the institution information of each file merging task to dynamically allocate the transaction participant information to be merged.
[0059] Specifically, based on the number of transactions reported by all database-level billing tasks in this data center, the participating institution information for each merge task is calculated using the bucket sort principle. This balances the total transaction volume processed by each merge task and dynamically allocates the participating institution information to be merged. In other words, it determines which data center is responsible for generating the summary tasks for which participating institutions. For example, if 300 participating institutions have transactions, and the number of file merge tasks (one file merge task for each participating institution per data center) is 50, then the transaction volume of the 300 participating institutions needs to be reasonably distributed across 50 merge tasks (data centers) to avoid the overall time consumption of the batch tasks being affected by an excessively large transaction volume processed by any one task.
[0060] In this embodiment of the application, by balancing the total transaction volume processed by the merging task in each data center, the imbalance in the total transaction volume processed by the merging task between data centers can be effectively avoided, thus shortening the total processing time and improving efficiency.
[0061] In one embodiment of this application, after generating file merging tasks corresponding to each of the data centers based on the data volume of each transaction participant in each database, the method further includes:
[0062] Based on the detailed data center files of each participating institution, a summary task corresponding to the current data center is generated, so that each processing node can merge and generate the summary task of the current participating institution according to the detailed data center files.
[0063] Specifically, the billing system obtains the merge task, downloads and merges the library-level files of participating institutions based on the institution list, and calculates the summary data for this data center. If the file merge of a participating institution fails, it does not affect the file merge of other participating institutions, and the information of the failed participating institutions is reported to the task management system. The task management system generates summary tasks for the participating institutions whose file merges were successfully completed.
[0064] In one embodiment of this application, after generating the file merging task corresponding to each data center based on the amount of data in each database of each transaction participant, the method further includes: determining whether there are any cases where the database-level detailed files of a transaction participant have failed to be merged; if there are cases where the database-level detailed files have failed to be merged, then the information of the failed transaction participants is reported, and a summary task is generated based on the transaction participants whose database-level detailed files have been successfully merged.
[0065] In other words, if the file merging of any participating institution fails, it will not affect the generation of invoice files for other institutions. This ensures that invoice files for other institutions are provided in a timely manner, improves the fault tolerance of the task, and reduces the impact on business operations.
[0066] In another embodiment of this application, after generating the file merging task corresponding to each data center based on the data volume of each transaction participant in each database, the method further includes: determining whether there is a case where the database-level detailed file merging of a transaction participant fails; if there is a case where the database-level detailed file merging fails, then generating a corresponding rerun task so that each processing node can re-merge and generate the corresponding data center-level detailed file of the transaction participant based on the generated database-level detailed file.
[0067] Specifically, in this embodiment, if the billing file generation of any transaction participant fails, the specified failed participant can rerun the task. That is, the rerun task is regenerated to obtain a new library-level detail file, which is then merged to generate a data center-level detail file. Based on the transaction participants whose library-level detail files have been successfully merged, a summary task is generated for that participant. This reduces the cost of rerunning the task and ensures the continuity of billing services.
[0068] The following explanation assumes that each data center includes a task management system and a billing system.
[0069] Figure 3 This is a schematic diagram of a task-driven process of a task management system according to an embodiment of this application, such as... Figure 3 As shown, after batch clearing is complete, the task management system will receive a notification. Upon receiving this notification, the task management system will begin generating tasks for each stage, including:
[0070] Phase 1: Generate database-level billing tasks for each transaction data center based on the number of databases;
[0071] Phase Two: After all the library-level billing tasks for any data center are successfully executed, generate a central-level file merging task corresponding to each data center according to the transaction participating institutions.
[0072] Phase 3: After the file merging tasks of all data centers associated with the transaction participants are successfully executed, a summary task is generated for each successfully executed institution in multiple data centers.
[0073] Therefore, the billing document generation method disclosed in this application has the following technical effects:
[0074] First, by generating and providing billing tasks to each processing node of the billing system through the task management system, the data center can perform summary tasks from the perspective of participating institutions, reducing the number of detailed billing files and lowering the complexity of billing processing for participating institutions. Second, the library-level detailed files of each participating institution within a single data center are merged according to a specified file size, improving task execution fault tolerance. If the generation of a file by any participating institution fails, it does not affect the generation of detailed billing files by other participating institutions, ensuring timely provision of billing files for other institutions and minimizing business impact. Third, if the generation of a billing file by any participating institution fails, the task can be restarted by a designated participating institution, reducing the cost of task restarts, ensuring billing business continuity, and improving operational efficiency.
[0075] Figure 4 This is a schematic diagram of the structure of a billing document generation device according to an embodiment of this application, such as... Figure 4As shown, this application embodiment provides a billing document generation device 400, applied to a task management system, including a library-level billing task generation module 410 and a central-level task generation module 420, wherein:
[0076] The database-level billing task generation module 410 is used to generate database-level billing tasks corresponding to each of the databases in response to the clearing completion notification, so that each of the processing nodes can count the amount of data of each transaction participant in each database and generate database-level detailed files for each transaction participant.
[0077] The central-level task generation module 420 is used to generate file merging tasks corresponding to each data center based on the amount of data in each database of each transaction participant, so that each processing node can merge and generate data center-level detailed files of each transaction participant based on the generated database-level detailed files.
[0078] Preferably, in some embodiments, the billing document generation device further includes a summary task generation module, which is used to generate a summary task corresponding to the current data center based on the data center-level detail files of the current transaction participant, so that each processing node can merge and generate the summary task of the current transaction participant based on the data center-level detail files.
[0079] In one embodiment of this application, the billing document generation device includes an update module, which is used to receive task status update notifications from each processing node;
[0080] The central-level task generation module 420 further includes a first generation unit, which is used to generate a file merging task based on the transaction count information of each data center after all the library-level billing tasks in each data center have been successfully executed.
[0081] Optionally, in some embodiments, the central-level task generation module 420 further includes a first determining unit and a second determining unit.
[0082] The first determining unit is used to determine the number of file merging tasks for each processing node based on the cluster resource status of the billing processing system.
[0083] The second determining unit is used to determine the transaction participating institution corresponding to each file merging task based on the number of file merging tasks and the amount of data of each transaction participating institution in each database.
[0084] The second determining unit is further configured to receive transaction count information of transaction participating institutions reported by all database-level billing tasks in each of the data centers; calculate the institution information of each file merging task based on the transaction count information using the bucket sort principle; and balance the total transaction volume processed by each file merging task based on the institution information of each file merging task to dynamically allocate the transaction participating institution information to be merged.
[0085] Optionally, in some embodiments, the billing file generation device further includes a judgment module, which is used to determine whether there is a failure to merge the library-level detail files of any transaction participants. If there is a failure to merge the library-level detail files, the information of the failed transaction participants will be reported.
[0086] The summary task generation module is also used to generate summary tasks based on the successfully merged transaction participants in the library-level detailed files.
[0087] The central-level task generation module 420 also includes a rerun unit, which is used to generate corresponding rerun tasks so that each processing node can re-merge and generate the corresponding data center-level detail files of the transaction participants based on the generated library-level detail files.
[0088] It is understood that the billing document generation apparatus provided in this application embodiment can implement all the method steps implemented by the method embodiment with the billing document generation apparatus as the execution subject, and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.
[0089] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Figure 5 As shown, at the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or it may include non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.
[0090] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.
[0091] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.
[0092] The processor reads the corresponding computer program from non-volatile memory into memory and then executes it, forming a processing device for account limit data at the logical level. The processor executes the program stored in memory and specifically performs the following operations:
[0093] In response to the clearing completion notification, a database-level billing task corresponding to each of the databases is generated, enabling each of the processing nodes to count the amount of data of each transaction participant in each database and generate a database-level detailed file for each transaction participant.
[0094] Based on the amount of data in each database of each participating institution, a file merging task corresponding to each data center is generated, so that each processing node can merge and generate a data center-level detailed file for each participating institution based on the generated database-level detailed file.
[0095] The billing document generation method described in the above embodiments can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application-Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.
[0096] The electronic device can also perform Figure 4 The method executed by the billing document generation device, and the implementation of the billing document generation device in Figure 4 The functions of the embodiments shown are not described in detail here.
[0097] This application also proposes a computer-readable storage medium that stores one or more programs, each program including instructions that, when executed by an electronic device including multiple applications, enable the electronic device to perform the billing document generation method described in the above embodiments, specifically for performing:
[0098] In response to the clearing completion notification, a database-level billing task corresponding to each of the databases is generated, enabling each of the processing nodes to count the amount of data of each transaction participant in each database and generate a database-level detailed file for each transaction participant.
[0099] Based on the amount of data in each database of each participating institution, a file merging task corresponding to each data center is generated, so that each processing node can merge and generate a data center-level detailed file for each participating institution based on the generated database-level detailed file.
[0100] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention 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.
[0101] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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 illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0102] 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.
[0103] 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.
[0104] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0105] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory. Memory is an example of computer-readable media.
[0106] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by 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 magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media do not include transient computer-readable media, such as modulated data signals and carrier waves.
[0107] 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 a process, method, article, or apparatus. Without further limitation, 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 said element.
[0108] 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.
[0109] The above description is merely an embodiment of this application and is 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 generating billing documents, applied to a task management system, characterized in that, The task management system is used to provide billing tasks to each processing node of the billing processing system. Each processing node is configured to correspond to a transaction data center, and multiple databases are deployed in each transaction data center. The method includes: In response to the clearing completion notification, a database-level billing task corresponding to each of the databases is generated, enabling each of the processing nodes to count the amount of data of each transaction participant in each database and generate a database-level detailed file for each transaction participant. Based on the amount of data in each database of each participating institution, a file merging task corresponding to each data center is generated, so that each processing node can merge and generate a data center-level detailed file for each participating institution based on the generated database-level detailed file.
2. The method according to claim 1, characterized in that, The method further includes: receiving task status update notifications from each processing node; The step of generating file merging tasks corresponding to each data center based on the amount of data in each database of each participating institution includes: After all the library-level billing tasks in each of the data centers have been executed successfully, a file merging task is generated based on the transaction count information of each of the data centers.
3. The method according to claim 1, characterized in that, The step of generating file merging tasks corresponding to each data center based on the amount of data in each database of each participating institution includes: Based on the cluster resource status of the billing system, determine the number of file merging tasks for each processing node; Based on the number of file merging tasks and the amount of data in each database of each transaction participant, the transaction participant corresponding to each file merging task is determined.
4. The method according to claim 3, characterized in that, The method further includes: Receive transaction count information from all database-level billing tasks of the data centers. Based on the number of transactions, the organization information for each file merging task is calculated using the bucket sort principle; Based on the institutional information of each file merging task, the total transaction volume processed by each file merging task is balanced to dynamically allocate the participating institutional information of the transactions to be merged.
5. The method according to claim 1, characterized in that, After generating file merging tasks corresponding to each data center based on the data volume of each participating institution in each database, the process further includes: Based on the detailed data center files of each participating institution, a summary task corresponding to the current data center is generated, so that each processing node can merge and generate the summary task of the current participating institution according to the detailed data center files.
6. The method according to claim 1, characterized in that, After generating file merging tasks corresponding to each data center based on the data volume of each participating institution in each database, the process further includes: Determine if there are any instances where the merging of database-level detailed files from participating institutions failed; If the merging of library-level detail files fails, the information of the failed transaction participants will be reported, and a summary task will be generated based on the transaction participants that were successfully merged into the library-level detail files.
7. The method according to claim 1, characterized in that, After generating file merging tasks corresponding to each data center based on the data volume of each participating institution in each database, the process further includes: Determine if there are any instances where the merging of database-level detailed files from participating institutions failed; If the merging of library-level detail files fails, a corresponding rerun task is generated so that each processing node can re-merge and generate the data center-level detail files of the corresponding transaction participants based on the already generated library-level detail files.
8. A billing document generation device, applied to a task management system, characterized in that, The apparatus is used to implement the method according to any one of claims 1 to 7.
9. An electronic device, comprising: processor; as well as A memory configured to store computer-executable instructions, characterized in that, when executed, the executable instructions cause the processor to perform any one of the methods described in claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs that, when executed by an electronic device including multiple applications, cause the electronic device to perform the method of any one of claims 1 to 7.