Bill processing method and device, equipment and storage medium

Abstract

The invention provides a bill processing method and device, equipment and a storage medium, and can be applied to the technical field of data processing. The method comprises the steps of obtaining bill data of each target account in at least one target account, and obtaining task processing features of each target account; the task processing features comprise a target paging strategy and a target field customization strategy; performing paging operation on the bill data according to the data paging size indicated by the target paging strategy, and generating a target task corresponding to each target account based on the obtained at least one data paging; and according to the target field customization strategy of each target account, screening field data from at least one data page corresponding to the target task, and determining a task processing result of each target task based on the screened field data.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a billing processing method, apparatus, device, medium, and program product. Background Technology

[0002] In some examples, personalized bank statement generation typically employs a scheduled task batch processing model. This model tightly couples account information management with transaction data processing, making it difficult for the system to flexibly handle drastic fluctuations in transaction volume for individual accounts. Furthermore, fixed allocation of processing resources leads to idle and wasted resources during off-peak periods and processing delays during peak periods, resulting in poor system scalability and resource economy. Summary of the Invention

[0003] In view of the above problems, this disclosure provides billing processing methods, apparatus, devices, media and program products.

[0004] According to a first aspect of this disclosure, a billing processing method is provided, comprising: acquiring billing data for each target account in at least one target account, and acquiring task processing characteristics for each target account; the task processing characteristics include a target pagination strategy and a target field customization strategy; performing pagination on the billing data according to the data pagination size indicated by the target pagination strategy, and generating a target task corresponding to each target account based on the obtained at least one data pagination; filtering field data from at least one data pagination corresponding to the target task according to the target field customization strategy for each target account, and determining the task processing result for each target task based on the filtered field data.

[0005] According to embodiments of this disclosure, billing data is paginated according to the data page size indicated by the target pagination strategy, and a target task corresponding to each target account is generated based on the obtained at least one data page. This includes: dividing the billing data into at least one data page according to the page size indicated by the target pagination strategy; generating a target subtask corresponding to each data page in the at least one data page, thereby obtaining at least one target subtask; and determining the target task corresponding to each target account based on the at least one target subtask.

[0006] According to embodiments of this disclosure, obtaining task processing characteristics for each target account includes: determining a target pagination strategy from a plurality of predefined pagination strategies based on the amount of billing data; wherein the amount of data is negatively correlated with the page size indicated by the target pagination strategy.

[0007] According to embodiments of this disclosure, based on a target field customization strategy for each target account, field data is filtered from at least one data page corresponding to a target task, and the task processing result for each target task is determined based on the filtered field data. This includes: determining a target field list and target data format defined by the target field customization strategy; for any target subtask in the target task, extracting the field data indicated by the target field list from the data page corresponding to any target subtask; assembling the extracted field data into structured data fragments according to the target data format; and in response to the completion of processing of all target subtasks in the target task, aggregating all data fragments belonging to the same target task to obtain the task processing result for each target task.

[0008] According to embodiments of this disclosure, the method further includes: during the processing of each target subtask in the target task, obtaining the integrity check value of the data segment corresponding to each target subtask; when aggregating all data segments of the target task, verifying whether the continuity check values ​​between adjacent data segments match; in response to detecting an abnormal integrity check value or detecting a mismatch in continuity check values, identifying an abnormal data segment; and reprocessing the target subtask corresponding to the abnormal data segment.

[0009] According to embodiments of this disclosure, the method further includes: generating a task queue based on the target tasks of each target account; determining at least one target task from the task queue based on a target threshold, wherein the target threshold represents the upper limit of the number of tasks concurrently executing the target task; and processing at least one target task in parallel according to the task processing characteristics corresponding to the target task until there are no target tasks to be processed in the task queue, thereby obtaining the task processing result for each target account.

[0010] According to embodiments of this disclosure, at least one target task is processed in parallel based on the task processing characteristics corresponding to the target task until there are no target tasks to be processed in the task queue, and the task processing result of each target account is obtained, including: in response to the existence of a target task that has been processed in at least one target task, selecting a target task to be processed from the task queue for parallel processing; and in response to the existence of a target task to be processed in the task queue, obtaining the task processing result of each target account.

[0011] A second aspect of this disclosure provides a billing processing apparatus, comprising: an acquisition module for acquiring billing data for each of at least one target account, and acquiring task processing characteristics for each target account; the task processing characteristics including a target pagination strategy and a target field customization strategy; a generation module for performing pagination operations on the billing data according to the data pagination size indicated by the target pagination strategy, and generating a target task corresponding to each target account based on the obtained at least one data pagination; and a processing module for filtering field data from at least one data pagination corresponding to the target task according to the target field customization strategy of each target account, and determining the task processing result of each target task based on the filtered field data.

[0012] A third aspect of this disclosure provides an electronic device comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0013] A fourth aspect of this disclosure also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the methods described above.

[0014] The fifth aspect of this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0015] Based on the billing processing method, apparatus, equipment, media, and program products provided in this disclosure, the billing processing flow is deconstructed into two core stages: data pagination and task generation, and field filtering and result determination. The entire processing process is guided by the unique task processing characteristics (target pagination strategy and target field customization strategy) of each target account. This effectively solves the technical problems of poor system scalability and low resource utilization caused by rigid processing logic and inability to adapt to dynamic changes in data volume and personalized needs in traditional billing processing systems. Specifically, the target pagination strategy scientifically paginates billing data, decomposing massive data processing tasks into appropriately granular and easily manageable parallel units. This lays a solid foundation for efficient and elastic allocation of system resources, significantly improving the system's ability to cope with data volume fluctuations and overall processing efficiency. The target field customization strategy guides the precise filtering of required fields from the paginated data, achieving the goal of meeting highly personalized billing content customization needs while ensuring processing performance, thus ensuring the accuracy of output results and customer satisfaction. This application is based on a strategy-driven processing model, which enables the system to adapt to the data scale and customization requirements of different accounts, optimizes resource consumption, and achieves a synergistic improvement in processing efficiency, resource elasticity, and business flexibility. Attached Figure Description

[0016] The foregoing contents, as well as other objects, features, and advantages of this disclosure, will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0017] Figure 1 The illustration schematically depicts an application scenario of a billing processing method, apparatus, device, medium, and program product according to embodiments of the present disclosure;

[0018] Figure 2 A flowchart illustrating a billing process according to an embodiment of the present disclosure is shown schematically.

[0019] Figure 3 A flowchart illustrating a billing process according to another embodiment of the present disclosure is shown.

[0020] Figure 4 A schematic block diagram of a billing processing apparatus according to an embodiment of the present disclosure is shown; and

[0021] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a billing method according to an embodiment of the present disclosure. Detailed Implementation

[0022] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0024] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0025] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0026] In the technical solutions disclosed herein, the collection, storage, use, processing, transmission, provision, disclosure, and application of data (including but not limited to user personal information) comply with the provisions of relevant laws and regulations, necessary measures have been taken, and they do not violate public order and good morals.

[0027] It should be noted that in the embodiments of this disclosure, certain existing solutions in the industry, such as software, components, and models, may be mentioned. These should be considered as exemplary, and their purpose is merely to illustrate the feasibility of implementing the technical solutions of this disclosure, but does not mean that the applicant has already used or necessarily used such solutions. Embodiments of this disclosure provide a billing processing method.

[0028] Figure 1 The illustration schematically depicts an application scenario of a billing processing method, apparatus, device, medium, and program product according to embodiments of the present disclosure.

[0029] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0030] Users can interact with server 105 via network 104 using at least one of the first terminal device 101, second terminal device 102, and third terminal device 103 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, second terminal device 102, and third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0031] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0032] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0033] It should be noted that the billing processing method provided in this embodiment can generally be executed by server 105. Correspondingly, the billing processing device provided in this embodiment can generally be located in server 105. The billing processing method provided in this embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the billing processing device provided in this embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0034] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0035] The following will be based on Figure 1 The described scene, through Figures 2-5 The billing processing method of the disclosed embodiments will be described in detail.

[0036] Figure 2 A flowchart illustrating a billing process according to an embodiment of the present disclosure is shown schematically.

[0037] like Figure 2 As shown, the billing method of this embodiment includes operations S210 to S230.

[0038] In operation S210, the billing data of each target account in at least one target account is obtained, as well as the task processing characteristics of each target account are obtained; the task processing characteristics include the target pagination strategy and the target field customization strategy.

[0039] In the embodiments of this application, the target account refers to a specific account that requires billing processing. For example, in a bank statement generation scenario, it could refer to one or more financial accounts held by a large corporate client who has signed up for personalized statement services with the bank.

[0040] In the embodiments of this application, billing data refers to metadata or control information related to the billing processing of a target account. The billing data defines the basic scope and context of the billing processing. For example, billing data may include the target account's account identifier, the transaction date targeted by the billing processing, the account status, etc. This data is used to determine which account and time period's transactions need to be aggregated.

[0041] In embodiments of this application, task processing features refer to personalized parameters or configuration information used to guide how to process specific target account billing data. For example, a task processing feature can be a "target field list" that defines customer-customized transaction detail fields that need to be displayed in the statement, such as only including fields like "transaction time," "transaction amount," and "counterparty name," while filtering out other unnecessary fields.

[0042] In the embodiments of this application, a target task refers to an independent and clearly defined unit of work created based on the billing data of a specific target account. The task processing result refers to the final output generated after completing the billing processing for a target account. For example, the task processing result could be a text file containing all filtered transaction details for that account on a specified date, or a compressed file containing these detail files for customers to download and reconcile their accounts.

[0043] In embodiments of this application, billing data for each target account in at least one target account, as well as task processing characteristics for each target account, are obtained. The system first needs to determine the set of target accounts to be processed, and for each account in the set, obtain the billing data required for this billing process and the personalized characteristics defining the processing method.

[0044] For example, the processing system queries the contract management system daily for a list of all large customer accounts that have signed up for personalized billing services. For each account in the list, the system reads its preset billing generation configuration to obtain the account's identifier and processing date as billing data, and also obtains the list of customized fields in the customer's contract as the account's task processing characteristics.

[0045] In the embodiments of this application, the target pagination strategy is a rule that defines the granularity of data processing, and its core parameter is the data page size. For example, the target pagination strategy can specify a page size of 5000 transaction records per page. The target field customization strategy is a rule that defines the content and format of the bill output. For example, it can be specified that only the three fields ["Transaction Time", "Transaction Amount", "Balance"] should be output, using a comma-separated value format.

[0046] In the embodiments of this application, a target task refers to a unit of work created based on data pagination to represent the processing of complete billing data for a target account. A target task may contain multiple subtasks with finer granularity. Field data refers to the values ​​of specific fields filtered from the data pagination according to a target field customization strategy. The task processing result refers to the final output generated after completing the target task. For example, the task processing result is a file containing all filtered transaction details for the target account.

[0047] In operation S220, the billing data is paginated according to the data pagination size indicated by the target pagination strategy, and a target task corresponding to each target account is generated based on at least one obtained data pagination.

[0048] In the embodiments of this application, the billing data is paginated according to the data page size indicated by the target pagination strategy, and a target task corresponding to each target account is generated based on at least one obtained data page. The system uses the target pagination strategy to divide the massive dataset of each target account into multiple easily manageable data pages, and then constructs corresponding target tasks based on these pages, laying the foundation for subsequent parallel processing.

[0049] For example, when processing the billing data for account "ACCT_20240001", the system finds 15,250 transaction records on May 20, 2024. Based on a page size of 5,000, the system divides the data into four pages (records 1-5,000, 5,001-10,000, 10,001-15,000, and 15,001-15,250). The system generates a target task "TASK_ACCT_20240001_20240520" corresponding to these four pages, and this task is associated with each of them.

[0050] In operation S230, a strategy is customized based on the target fields of each target account, field data is filtered from at least one data page corresponding to the target task, and the task processing result of each target task is determined based on the filtered field data.

[0051] In the embodiments of this application, based on the target field customization strategy for each target account, field data is filtered from at least one data page corresponding to the target task, and the task processing result for each target task is determined based on the filtered field data. The system schedules processing resources to perform specific field filtering and data processing for each data page associated with the target task, according to the target field customization strategy, and finally summarizes the processing results of all pages to generate the final bill for the account.

[0052] For example, the processing engine executes the target task. It processes the four data pages corresponding to the target task sequentially. For each transaction record in each page, it retains only the values ​​of the "Transaction Time," "Transaction Amount," and "Balance" fields, formatting them as comma-separated value rows. The comma-separated value data from the four pages are then merged sequentially to generate a complete comma-separated value file as the task processing result for that account.

[0053] Through the embodiments of this application, by introducing a target pagination strategy and a target field customization strategy, the billing process is clearly separated into three stages: data pagination, task generation, and personalized processing. The method of this embodiment effectively handles massive amounts of data through dynamic pagination, improving processing efficiency and system resource utilization. Field customization meets personalized needs, ensuring the accuracy of the results. This strategy-driven processing model decouples processing logic from business rules, enabling the system to flexibly adapt to fluctuations in data volume and diverse customer needs, thereby significantly improving the system's scalability, flexibility, and overall processing performance.

[0054] Figure 3 A flowchart illustrating a billing process according to another embodiment of the present disclosure is shown.

[0055] like Figure 3 As shown, the billing data is paginated according to the data pagination size indicated by the target pagination strategy, and a target task corresponding to each target account is generated based on at least one obtained data pagination, including operations S310 to S330.

[0056] In operation S310, the billing data is divided into at least one data page according to the page size indicated by the target pagination strategy.

[0057] In the embodiments of this application, the target paging strategy refers to a rule used to control the granularity of data processing, and the core parameter of the target paging strategy is the page size. The target paging strategy defines the way to divide a large amount of data into smaller processing units.

[0058] In embodiments of this application, the page size refers to the maximum number of data records allowed in each processing unit (i.e., data page). For example, the page size can be set to 500 records, meaning that no more than 500 transaction records are processed each time.

[0059] In the embodiments of this application, data pagination refers to a subset of data obtained by dividing the complete bill data set according to the page size. For example, a bill data containing 1500 transaction records can be divided into 3 data pages according to the page size of 500.

[0060] In embodiments of this application, billing data is divided into at least one data page according to the page size indicated by the target pagination strategy. The system first assesses the total amount of data (such as the total number of transaction records) of the target account within a specified processing date, and then calculates how many data blocks (i.e., data pages) need to be divided according to the preset page size.

[0061] For example, the billing data indicates that the transaction for account "Acct_001" on "2024.05.20" was processed. A query revealed that this account had 1200 transaction records on that day. The target pagination strategy specifies a page size of 500 records. The system divides the total data into three pages: Page 1 (records 1-500), Page 2 (records 501-1000), and Page 3 (records 1001-1200).

[0062] In operation S320, a target subtask corresponding to each data page in at least one data page is generated, resulting in at least one target subtask.

[0063] In the embodiments of this application, a target subtask refers to the finest-grained unit of work corresponding to a specific data page. Each target subtask is responsible for processing its associated data page.

[0064] In embodiments of this application, a target subtask corresponding to each data page in at least one data page is generated, resulting in at least one target subtask. The system creates an independent target subtask for each data page partitioned in the preceding steps. This target subtask contains all the information required to process the corresponding data page.

[0065] For example, the system generates three target subtasks. Target subtask 1: Associated data page 1 (records 1-500). Target subtask 2: Associated data page 2 (records 501-1000). Target subtask 3: Associated data page 3 (records 1001-1200). Each subtask can include an account identifier, processing date, and the starting position and size of the data page it is responsible for.

[0066] In operation S330, the target task corresponding to each target account is determined based on at least one target sub-task.

[0067] In the embodiments of this application, a target task refers to a logical set or container of all target sub-tasks generated for the same target account, representing the overall work of processing the complete billing data of that account.

[0068] In embodiments of this application, a target task corresponding to each target account is determined based on at least one target sub-task. The system organizes all target sub-tasks belonging to the same target account together to form a higher-level target task that represents the complete processing work of that account.

[0069] For example, the system creates a main target task "Task_Acct_001_20240520" and includes the above three subtasks as its components. This target task represents the complete job of "generating a bank statement for account Acct_001 for May 20, 2024".

[0070] The embodiments of this application introduce a pagination strategy to divide massive amounts of billing data into small blocks and generate corresponding subtasks, thereby achieving fine-grained processing units. This method lays the foundation for subsequent parallel processing, significantly improving the processing efficiency for large-volume accounts while effectively avoiding system resource pressure caused by processing excessively large amounts of data at once.

[0071] In embodiments of this application, obtaining the task processing characteristics of each target account includes: determining a target pagination strategy from a plurality of predefined pagination strategies based on the amount of billing data; wherein the amount of data is negatively correlated with the pagination size indicated by the target pagination strategy.

[0072] In the embodiments of this application, the data volume refers to the total number of transaction records that need to be processed for a specific target account within the processing date specified in the billing data.

[0073] For example, if account "Acct_001" has 150,000 transaction details on "2024.05.20", then its data volume is 150,000.

[0074] In the embodiments of this application, the predefined multiple paging strategies refer to a set of paging strategy schemes that are pre-configured and selectable by the system. Each strategy scheme explicitly specifies a fixed page size.

[0075] For example, the system predefines three strategies: Strategy A (page size of 1000 items), Strategy B (page size of 5000 items), and Strategy C (page size of 20000 items).

[0076] In the embodiments of this application, the target pagination strategy refers to the most suitable pagination strategy dynamically selected by the system from a plurality of predefined pagination strategies based on the amount of data to be processed. For example, for an account with 150,000 data entries, the system may select strategy B (page size = 5,000 entries) as the target pagination strategy for this processing.

[0077] In the embodiments of this application, a target pagination strategy is determined from a set of predefined pagination strategies based on the volume of billing data. The system does not apply a fixed pagination size to all accounts; instead, it first assesses the scale (volume) of the data to be processed for each account. Based on the principle that "the larger the data volume, the smaller the pagination size should be," the pagination strategy that best suits the current data volume level is selected from the predefined strategy set as the actual strategy for this processing.

[0078] For example, assessing the data volume, the system processes the billing data for account "Acct_X" (processing date "2024.05.20"), and the query reveals that the account had a total of 250,000 transaction records on that day. Strategy selection decision: The system predefines pagination strategies: Small (page size = 2000 records, suitable for >200,000 records), Medium (page size = 8000 records, suitable for 50,000 to 200,000 records), and Large (page size = 20,000 records, suitable for <50,000 records). Determining the target pagination strategy: Since the data volume of 250,000 records is greater than 200,000 records, based on the negative correlation principle, the system selects the Small strategy as the target pagination strategy for this processing, i.e., the page size is determined to be 2000 records. The data processing work (250,000 records) will be broken down into more (125) but smaller task units to improve concurrency efficiency and stability.

[0079] By establishing a negative correlation between data volume and page size and dynamically selecting a paging strategy through the embodiments of this application, intelligent adjustment of processing granularity is achieved. The method of this embodiment enables the system to automatically adapt to different data volumes, employing finer granularity to improve concurrency and reliability when dealing with massive amounts of data, and coarser granularity to reduce scheduling overhead when dealing with small amounts of data, thereby optimizing overall resource utilization efficiency and system performance.

[0080] In the embodiments of this application, based on the target field customization strategy task processing characteristics of each target account, field data is filtered from at least one data page corresponding to the target task, and the target task corresponding to each target account is processed based on the filtered field data to obtain the task processing result for each target task account. This includes: determining the target field list and target data format defined by the target field customization strategy; for any target subtask in the target task, extracting the field data indicated by the target field list from the data page corresponding to any target subtask; assembling the extracted field data into structured data fragments according to the target data format; and in response to the completion of processing of all target subtasks in the target task, aggregating all data fragments belonging to the same target task to obtain the task processing result for each target task.

[0081] In the embodiments of this application, the target field customization strategy refers to a set of rules that defines the content and format of bill data output, used to achieve personalized bill generation.

[0082] In embodiments of this application, the target field list refers to a set of field names that need to be retained from the complete transaction record, as specified by the target field customization strategy.

[0083] For example, Customer A's customized list might be ["Transaction Time", "Transaction Amount", "Balance"], while Customer B's list might be ["Transaction Time", "Transaction Type", "Counterparty Name"].

[0084] In embodiments of this application, the target data format refers to the organization specification of the output data defined by the strategy. For example, it can be specified as a comma-separated value format, with the field order specified as "transaction time, transaction amount, balance", or it can be specified as a fixed-width text format.

[0085] In the embodiments of this application,

[0086] For example, a data fragment refers to a structured block of data processed for a specific subtask, filtered according to a target field list and assembled according to the target data format. A data fragment is a component of the final complete invoice file.

[0087] In embodiments of this application, the target field list and target data format defined by the target field customization strategy are determined. The system parses the target field customization strategy from the task processing characteristics configured for the target account and obtains two key elements from it: which fields need to be retained (target field list) and in what format these fields should be organized (target data format).

[0088] For example, for account "Acct_001", after its target field customization strategy is parsed, the target field list is obtained as ["Transaction Time", "Transaction Amount", "Balance"], and the target data format is "comma-separated value format, field order is in list order".

[0089] In the embodiments of this application, for any target subtask in the target task, the field data indicated by the target field list is extracted from the data page corresponding to any target subtask. When the system processes each target subtask under the target task, it scans each record one by one from the specific data page corresponding to that subtask (e.g., 5000 original transaction records), but only reads and retains the values ​​of those fields specified in the target field list, filtering out other irrelevant fields.

[0090] For example, the target subtask X corresponds to a data pagination containing 5000 complete transaction records. The system iterates through these 5000 records, and for each record, extracts only the values ​​of the three fields: "transaction time," "transaction amount," and "balance," forming 5000 filtered records.

[0091] In the embodiments of this application, the extracted field data is assembled into structured data fragments according to the target data format. The system assembles the extracted and filtered field data from the previous step into standardized data blocks according to the requirements of the target data format.

[0092] In the embodiments of this application, in response to the completion of processing of all target subtasks in the target task, all data fragments belonging to the same target task are aggregated to obtain the task processing result of each target task. The system monitors the execution status of all target subtasks under a target task. When all subtasks have been completed, that is, after all have generated their respective data fragments, the system merges these data fragments according to their corresponding data pagination order to form a complete and continuous billing file.

[0093] For example, the task objective for account "Acct_001" is divided into three subtasks, generating data fragment A (corresponding to records 1-5000), fragment B (records 5001-10000), and fragment C (records 10001-15000). Once all three subtasks are completed, the system concatenates fragments A, B, and C in sequence to generate a complete file, which represents the final task processing result for that account.

[0094] Through the embodiments of this application, by introducing a target field customization strategy, personalized customization of bill content and standardization of output format are achieved. The system generates standardized data fragments through field filtering and data format assembly, and finally aggregates them into a complete result, ensuring the accuracy and flexibility of the processing and efficiently meeting the differentiated billing needs of different customers.

[0095] In embodiments of this application, the method further includes: during the processing of each target subtask in the target task, obtaining the integrity check value of the data segment corresponding to each target subtask; when aggregating all data segments of the target task, verifying whether the continuity check values ​​between adjacent data segments match; in response to detecting an abnormal integrity check value or detecting a mismatch in continuity check values, identifying an abnormal data segment; and reprocessing the target subtask corresponding to the abnormal data segment.

[0096] In the embodiments of this application, the integrity check value refers to a check value used to verify whether a single data segment remains intact, undamaged, or untampered after its generation. For example, the integrity check value may be a hash value or a cyclic redundancy check code obtained by calculating the content of the data segment.

[0097] In the embodiments of this application, the continuity check value refers to the verification information used to verify whether two adjacent data segments are logically continuous and without data loss. For example, the continuity check value can be the identifier (such as a transaction serial number) or the end timestamp of the last record of the previous data segment.

[0098] In the embodiments of this application, an abnormal data segment refers to a data segment that is identified as having an integrity problem during the verification process, or a data segment that has a continuity interruption with adjacent segments.

[0099] In the embodiments of this application, during the processing of each target subtask in the target task, the integrity verification value of the data segment corresponding to each target subtask is obtained. Whenever a target subtask is completed and a data segment is generated, the system immediately calculates a unique verification value based on the entire content of the data segment.

[0100] In the embodiments of this application, when aggregating all data fragments of the target task, the continuity check value between adjacent data fragments is verified to ensure they match. When the system sequentially splices data fragments, it checks whether the last record of the previous fragment and the first record of the next fragment are logically continuous.

[0101] For example, suppose data segment A contains records 1-5000, with the last record having a serial number of TX1005000. Data segment B should contain records 5001-10000. During aggregation, the system checks if the serial number of the first record in segment B is TX1005001. If they match, the continuity check passes. If the first record in segment B is TX1006001, it indicates that 1000 records are missing, and the continuity check fails.

[0102] In embodiments of this application, in response to detecting an abnormal integrity check value or a mismatch in continuity check values, an abnormal data segment is identified. Based on the aforementioned check results, the system determines which data segment(s) are problematic.

[0103] For example, if the system finds during verification that the current hash value of data segment C is inconsistent with the hash value stored when it was generated, then segment C is determined to be an integrity anomaly. Alternatively, if a continuity check mismatch is found when aggregating segments B and C, it may be determined that there is an anomaly at the end of segment B or the beginning of segment C, requiring further location of the specific anomaly segment.

[0104] In the embodiments of this application, the target subtask corresponding to the abnormal data fragment is reprocessed. The system does not reprocess the entire target task due to partial failure, but precisely reschedules and executes the specific target subtask that generated the abnormal data fragment in order to regenerate the correct data fragment.

[0105] For example, if data fragment C is determined to be abnormal, the system will not reprocess the entire account's task. Instead, it will find the target subtask C that generated fragment C, reset its state, and re-add it to the processing queue. Only after the target subtask C is successfully reprocessed and generates a new, validated data fragment will the aggregation operation continue.

[0106] Through the embodiments of this application, an effective fault-tolerant control process is constructed by introducing a dual verification mechanism of integrity and continuity checks, combined with a precise reprocessing strategy. The method of this embodiment enhances the reliability of the system when processing massive amounts of data, ensuring the integrity and accuracy of the final task processing results.

[0107] In embodiments of this application, the method further includes: generating a task queue based on the target task of each target account; determining at least one target task from the task queue based on a target threshold, wherein the target threshold represents the upper limit of the number of tasks concurrently executing the target task; and processing at least one target task in parallel according to the task processing characteristics corresponding to the target task until there are no target tasks to be processed in the task queue, thereby obtaining the task processing result for each target account.

[0108] In the embodiments of this application, a task queue refers to an ordered set used to store and manage multiple target tasks that have been generated but not yet executed. The task queue serves as a buffer and work list for tasks to be processed. For example, the system places the target tasks Task_A, Task_B, and Task_C generated for target accounts A, B, and C into a list in the order of their generation, awaiting processing.

[0109] In the embodiments of this application, the target threshold refers to a preset numerical parameter used to control the maximum number of target tasks that the system can execute in parallel at the same time. The target threshold characterizes the system's concurrent processing capability. For example, depending on the system resources (such as the number of processor cores and memory), the target threshold can be set to 10, indicating that a maximum of 10 target tasks are allowed to execute simultaneously.

[0110] In the embodiments of this application, at least one target task refers to a batch of target tasks that the system retrieves from the task queue based on a target threshold, and whose number does not exceed the target threshold, and which are ready to be executed immediately.

[0111] In the embodiments of this application, a task queue is generated based on the target tasks of each target account. The system organizes the scattered target task objects generated for each target account in the aforementioned steps into a unified data structure for management.

[0112] For example, after the system generates target tasks Task_A, Task_B, and Task_C for target accounts A, B, and C respectively, it adds these task objects in order (such as the order they were generated) to a list named "Pending Task Queue". This queue contains three tasks: [Task_A, Task_B, Task_C].

[0113] In embodiments of this application, at least one target task is determined from the task queue based on a target threshold. The system retrieves a certain number of tasks from the head of the task queue according to a preset concurrency capability (target threshold), preparing them for allocation to the processing unit for execution. The number of retrieved tasks does not exceed the target threshold.

[0114] For example, suppose the target threshold N=2. The system retrieves up to two tasks from the head of the "task queue" (e.g., [Task_A, Task_B, Task_C]). The target tasks identified in this case are Task_A and Task_B. Task_C remains in the queue waiting.

[0115] In the embodiments of this application, at least one target task is processed in parallel according to the task processing characteristics corresponding to the target task until there are no more target tasks to be processed in the task queue, thus obtaining the task processing result for each target account. The system allocates the batch of target tasks determined in the previous step to different processing units or threads for simultaneous execution. The execution of each task must follow its corresponding task processing characteristics. Whenever a task is completed, the system immediately retrieves a new task from the task queue to replenish it, keeping the system busy until all tasks in the queue have been processed.

[0116] For example, the system starts two processing threads to execute tasks Task_A and Task_B in parallel. Assuming Task_A finishes executing first, the system immediately retrieves Task_C from the task queue (currently [Task_C]) and assigns it to the idle processing thread for execution. Once both Task_B and Task_C have finished executing, the task queue is empty, meaning that task processing results for all accounts have been generated.

[0117] Through the embodiments of this application, by introducing task queues and a concurrency control mechanism based on target thresholds, smooth scheduling of processing tasks and elastic utilization of system resources are achieved. The solution in this embodiment improves efficiency through parallel processing and ensures system stability under high load.

[0118] In some embodiments, at least one target task is processed in parallel according to the task processing characteristics corresponding to the target task until there are no target tasks to be processed in the task queue, and the task processing result of each target account is obtained, including: in response to the existence of a target task that has been processed in at least one target task, selecting a target task to be processed from the task queue for parallel processing; and in response to the existence of a target task to be processed in the task queue, obtaining the task processing result of each target account.

[0119] In the embodiments of this application, a completed target task refers to a target task that has been retrieved from the task queue and executed according to its task processing characteristics. At this time, the task processing result for the target account corresponding to the task has been successfully generated. For example, the target task Task_A generated for target account A, after going through steps such as data processing and file generation, changes its status to "execution successful", which is considered as completed.

[0120] In the embodiments of this application, the target task to be processed refers to a target task that has been generated and exists in the task queue, but has not yet been retrieved by the system for execution. For example, Task_C, Task_D, etc., which are waiting in the task queue.

[0121] In embodiments of this application, in response to the existence of a completed target task among at least one target task, a target task to be processed is selected from the task queue for parallel processing. The system continuously monitors the status of a batch of target tasks currently being processed in parallel. Upon detecting that any one of the tasks has been completed, the system responds to this event by automatically retrieving a new task to be processed from the head of the task queue and putting it into execution to supplement the set of tasks being processed in parallel.

[0122] For example, based on a target threshold (N=2), the system retrieves Task_A and Task_B from a task queue containing [Task_A, Task_B, Task_C, Task_D] for parallel processing. Assume Task_A completes first. The system immediately responds to the "Task_A complete" event, then retrieves Task_C from the head of the current task queue (now [Task_C, Task_D]) and begins parallel execution of Task_B and Task_C. This ensures that processing resources are not idle due to the completion of one task.

[0123] In the embodiments of this application, in response to the absence of any pending target tasks in the task queue, the task processing result for each target account is obtained. Each time the system completes a task and attempts to select a new task from the queue, it checks whether the task queue is empty. When there are no pending tasks in the queue, and all retrieved tasks have been executed, it means that the task processing results for all target accounts have been generated, and the entire processing flow ends.

[0124] For example, after Task_B and Task_C have both finished executing, the system attempts to retrieve a new task from the task queue (now [Task_D]) to replenish it. After Task_D is retrieved and executed, the queue becomes empty. When Task_D has also finished executing, since the queue is empty and there are no running tasks, the system determines that the processing is complete. At this point, the task processing results for accounts A, B, C, and D are all ready.

[0125] Through the embodiments of this application, a dynamic task scheduling mechanism ensures that processing resources are continuously and fully utilized, eliminating the window period between the completion of one task and the start of a new task. Based on concurrency control, the method of this embodiment further significantly improves the overall throughput and processing efficiency of the system.

[0126] Based on the above-described billing method, this disclosure also provides a billing apparatus. The following will be combined with... Figure 4 The device is described in detail.

[0127] Figure 4 A schematic block diagram of a billing processing apparatus according to an embodiment of the present disclosure is shown.

[0128] like Figure 4 As shown, the bill processing device 400 of this embodiment includes an acquisition module 410, a generation module 420, and a processing module 430.

[0129] The acquisition module 410 is used to acquire billing data for each target account in at least one target account, and to acquire task processing characteristics for each target account; the task processing characteristics include target pagination strategy and target field customization strategy. In one embodiment, the acquisition module 410 can be used to perform the operation S210 described above, which will not be repeated here.

[0130] The generation module 420 is used to perform pagination operations on the bill data according to the data pagination size indicated by the target pagination strategy, and generate target tasks corresponding to each target account based on at least one obtained data pagination. In one embodiment, the generation module 420 can be used to perform the operation S220 described above, which will not be repeated here.

[0131] The processing module 430 is used to customize strategies based on the target fields of each target account, filter field data from at least one data pagination corresponding to the target task, and determine the task processing result for each target task based on the filtered field data. In one embodiment, the processing module 430 can be used to perform the operation S230 described above, which will not be repeated here.

[0132] According to embodiments of this disclosure, by decoupling the billing process into two stages—independent account task generation and asynchronous task execution based on personalized features—the problem of poor system scalability and low resource utilization caused by strong coupling in traditional solutions is effectively solved. The method of this embodiment enables the system to perform parallel processing with fine-grained task units, significantly improving processing efficiency under massive and fluctuating data. Simultaneously, differentiated execution based on task processing characteristics meets customers' personalized needs, enhancing the system's flexibility and stability. The method of this embodiment optimizes resource utilization while ensuring processing timeliness, exhibiting good economy and scalability.

[0133] According to embodiments of this disclosure, any plurality of modules among the acquisition module 410, generation module 420, and processing module 430 may be combined into one module, or any one of these modules may be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules may be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this disclosure, at least one of the acquisition module 410, generation module 420, and processing module 430 may be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the acquisition module 410, generation module 420, and processing module 430 may be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0134] In some embodiments, the generation module includes: a partitioning submodule, configured to partition the bill data into at least one data page according to the page size indicated by the target pagination strategy; a first generation submodule, configured to generate a target subtask corresponding to each data page in the at least one data page, thereby obtaining at least one target subtask; and a first determination submodule, configured to determine the target task corresponding to each target account based on the at least one target subtask.

[0135] In some embodiments, the acquisition module includes a second determining submodule, configured to determine a target pagination strategy from a plurality of predefined pagination strategies based on the amount of bill data; wherein the amount of data is negatively correlated with the pagination size indicated by the target pagination strategy.

[0136] In some embodiments, the processing module includes: a third determining submodule, configured to determine the target field list and target data format defined by the target field customization strategy; an extraction submodule, configured to extract field data indicated by the target field list from the data pagination corresponding to any target subtask in the target task; a first processing submodule, configured to assemble the extracted field data into structured data fragments according to the target data format; and a second processing submodule, configured to aggregate all data fragments belonging to the same target task in response to the completion of processing of all target subtasks in the target task, to obtain the task processing result of each target task.

[0137] In some embodiments, the apparatus further includes: a first determining module, configured to acquire the integrity check value of the data segment corresponding to each target subtask during the processing of each target subtask in the target task; a verification module, configured to verify whether the continuity check values ​​between adjacent data segments match when aggregating all data segments of the target task; a second determining module, configured to determine abnormal data segments in response to detecting an abnormal integrity check value or detecting a mismatch in continuity check values; and a third determining module, configured to reprocess the target subtask corresponding to the abnormal data segments.

[0138] In some embodiments, the apparatus further includes: a second generation module, configured to generate a task queue based on the target task of each target account; a fourth determination module, configured to determine at least one target task from the task queue based on a target threshold, wherein the target threshold represents an upper limit on the number of tasks concurrently executing the target task; and a second processing module, configured to process at least one target task in parallel based on the task processing characteristics corresponding to the target task, until there are no target tasks to be processed in the task queue, thereby obtaining the task processing result for each target account.

[0139] In some embodiments, the second processing module includes: a third processing submodule, configured to select target tasks to be processed from the task queue for parallel processing in response to the existence of a target task that has been processed in at least one target task; and a fourth processing submodule, configured to obtain the task processing result for each target account in response to the existence of no target task to be processed in the task queue.

[0140] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a billing method according to an embodiment of the present disclosure.

[0141] like Figure 5 As shown, an electronic device 500 according to an embodiment of the present disclosure includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The processor 501 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0142] RAM 503 stores various programs and data required for the operation of electronic device 500. Processor 501, ROM 502, and RAM 503 are interconnected via bus 504. Processor 501 performs various operations of the method flow according to embodiments of the present disclosure by executing programs in ROM 502 and / or RAM 503. It should be noted that programs may also be stored in one or more memories other than ROM 502 and RAM 503. Processor 501 may also perform various operations of the method flow according to embodiments of the present disclosure by executing programs stored in one or more memories.

[0143] According to embodiments of this disclosure, the electronic device 500 may further include an input / output (I / O) interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0144] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0145] According to embodiments of this disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this disclosure, the computer-readable storage medium may include ROM 502 and / or RAM 503 and / or one or more memories other than ROM 502 and RAM 503 described above.

[0146] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the item recommendation method provided in the embodiments of this disclosure.

[0147] When the computer program is executed by the processor 501, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0148] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0149] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this disclosure embodiment. According to embodiments of this disclosure, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0150] According to embodiments of this disclosure, program code for executing the computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can execute entirely on a user's computing device, partially on a user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0151] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0152] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this disclosure. In particular, the features described in the various embodiments and / or claims of this disclosure can be combined or combined in various ways without departing from the spirit and teachings of this disclosure. All such combinations and / or combinations fall within the scope of this disclosure.

[0153] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A method of bill processing, characterized by, The method comprises: obtaining billing data of each target account in at least one target account, and obtaining task processing characteristics of each target account; the task processing characteristics comprise a target paging strategy and a target field customization strategy; performing a paging operation on the billing data according to a data paging size indicated by the target paging strategy, and generating a target task corresponding to each target account based on at least one data page obtained; screening field data from at least one data page corresponding to the target task according to the target field customization strategy of each target account, and determining a task processing result of each target task based on the screened field data.

2. The method of claim 1, wherein, The method comprises: dividing the billing data into at least one data page according to the paging size indicated by the target paging strategy; generating a target subtask corresponding to each data page in the at least one data page to obtain at least one target subtask; determining the target task corresponding to each target account according to the at least one target subtask.

3. The method of claim 2, wherein, The method comprises: determining the target paging strategy from a plurality of predefined paging strategies according to a data volume of the billing data; wherein the data volume is negatively correlated with the paging size indicated by the target paging strategy.

4. The method of claim 2, wherein, The method comprises: determining a target field list and a target data format defined by the target field customization strategy; for any target subtask in the target task, extracting field data indicated by the target field list from a data page corresponding to the any target subtask; assembling the extracted field data into a structured data segment according to the target data format; in response to completion of processing of all target subtasks in the target task, aggregating all data segments belonging to the same target task to obtain the task processing result of each target task.

5. The method of claim 4, wherein, The method further comprises: obtaining a completeness check value of a data segment corresponding to each target subtask during processing of each target subtask in the target task; when aggregating all data segments of the target task, verifying whether continuity check values between adjacent data segments match; in response to detecting that there is a completeness check value anomaly or that the continuity check values do not match, determining an abnormal data segment; reprocessing a target subtask corresponding to the abnormal data segment.

6. The method according to any one of claims 1 to 5, characterized in that, The method further comprises: generating a task queue according to the target task of each target account; determining at least one target task from the task queue based on a target threshold, wherein the target threshold represents an upper limit of the number of tasks concurrently executed. According to the task processing feature corresponding to the target task, the at least one target task is processed in parallel until there is no target task to be processed in the task queue, and a task processing result of each target account is obtained.

7. The method of claim 6, wherein, According to the task processing feature corresponding to the target task, the at least one target task is processed in parallel until there is no target task to be processed in the task queue, and a task processing result of each target account is obtained. In response to the presence of a target task that has been processed in the at least one target task, a target task to be processed is selected from the task queue for parallel processing; In response to the absence of a target task to be processed in the task queue, a task processing result of each target account is obtained.

8. A bill processing apparatus characterized by comprising: The apparatus comprises: An acquisition module configured to acquire billing data of each target account in at least one target account, and acquire a task processing feature of each target account; the task processing feature comprises a target pagination strategy and a target field customization strategy; A generation module configured to perform a pagination operation on the billing data according to a data pagination size indicated by the target pagination strategy, and generate a target task corresponding to each target account based on at least one data page obtained; A processing module configured to filter field data from at least one data page corresponding to the target task according to the target field customization strategy of each target account, and determine a task processing result of each target task based on the filtered field data. 9.An electronic device, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the method according to any one of claims 1-7. 10.A computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1-7. 11.A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images