Historical task model generation method and application

Abstract

This invention relates to the field of historical task modeling technology, specifically to a method and application for generating historical task models, comprising the following steps: collecting ERP operation logs and locating field reading, updating, and condition judgment behaviors in chronological order; deduplicating repeatedly triggered fields within the same transaction to form a field trigger behavior sequence; calculating the dependency strength by statistically analyzing the frequency and recurrence relationship of field combinations; determining the model hierarchy by combining field business semantic analysis of dependency distribution; and correcting the structure using state transition characteristics during multiple task executions to generate a stable and reusable historical task model master. In this invention, by analyzing the field trigger sequence and dependency relationship in ERP logs, the execution order and business semantic modeling are unified, and the model structure is corrected by combining multiple task state transitions, prompting the task model to shift from static splicing to behavior dependency hierarchy construction, thereby improving process stability and matching reliability.

Description

Technical Field

[0001] This invention relates to the field of historical task modeling technology, and in particular to the method and application of generating historical task models. Background Technology

[0002] Historical task modeling technology refers to a set of technologies that organize, abstract, and structure the data generated during the formation, flow, and recording of tasks in information systems. Its core aspects include the formation conditions of task processes, the field composition of task elements, the task execution order, and the mapping relationship of task-related information between different systems. It usually relies on the basic field data in business systems to uniformly model the source, content, and context of tasks, providing a referenceable task structure foundation for subsequent similar tasks.

[0003] The traditional method for generating and applying historical task models refers to a method of constructing a model to describe historical tasks based on task-related data in the user enterprise's existing information system when the business system is first connected or when there is a lack of available historical models. This method is usually used in scenarios where there is no historical task model to match after the Magic Cube system is integrated with the user enterprise's ERP system. By reading basic fields, price information, date information, and notes (including global and local notes) from the ERP system, the task process generated by the enterprise for the first time is organized. The above field information is combined according to the established task expression rules to form a task process master, and a corresponding historical task model is generated accordingly. This model can then be used as a reference model for subsequent tasks of the same type entering the system when matching historical task types.

[0004] The existing historical task model generation relies on the manual organization and rule combination of basic ERP fields, prices, and remarks information when enterprises first access the system. Its operation is based on static field snapshots and lacks dynamic depiction of field triggering order, condition judgment path, and actual dependencies between fields. It is difficult to reflect the sequence and hierarchical changes of field behavior during actual task execution, resulting in insufficient sensitivity of the model structure to changes in business processes. In multi-condition and multi-branch task scenarios, it is prone to problems such as chaotic field hierarchy, rough task path expression, and limited model generalization ability, which in turn affects the accuracy of subsequent task matching and the reuse effect of historical models. Summary of the Invention

[0005] To address the technical problems existing in the prior art, embodiments of the present invention provide a method for generating a historical task model, comprising the following steps: S1: Collect ERP operation logs, extract and parse field read, update and condition judgment records, analyze the field triggering order, calculate trigger discrimination for multiple triggers of the same field in a transaction, and generate a field triggering behavior sequence; S2: Based on the field-triggered behavior sequence, combine them according to the field identifier, count the frequency of the fields appearing sequentially and the frequency of recurrence within the time window, calculate the confidence of the field combination and compare the field combinations to generate field triggering dependency results; S3: Based on the field-triggered dependency results, perform a structured mapping on the field combinations and their corresponding confidence levels, use the confidence level as the dependency strength and map and sort it, record zero values ​​for field groups with no dependency relationship, and generate field-triggered relationship data; S4: Obtain the business attribute description of the ERP field, analyze the dependency distribution of the same business semantic field in the field trigger relationship data, determine the level based on the dependency strength and determine the upper and lower level field identifiers, and construct the initial task model structure; S5: Obtain multiple task execution records, count the number of field entry judgments, condition judgments and result records, calculate the field state transition probability, correct the initial task model structure hierarchy, and generate a historical task model master.

[0006] As a further embodiment of the present invention, the field triggering behavior sequence includes a field read triggering order index, a field update triggering order index, and a condition judgment triggering order index; the field triggering dependency result includes field sequential association pairs, time window reproduction association pairs, and field combination confidence values; the field triggering relationship data includes a field dependency strength sorting sequence, zero-value records of no-dependency field pairs, and field relationship index identifiers; the initial task model structure includes a field hierarchy identifier set, field hierarchical association relationships, and business semantic grouping identifiers; and the historical task model master includes a field state transition probability set, corrected field hierarchy identifiers, and an entry judgment field marker set.

[0007] As a further aspect of the present invention, the specific steps of S1 are as follows: S101: Collect ERP operation logs, parse log field read records, field update records and condition judgment records, perform event splitting based on field identifiers and transaction sequence numbers, extract independently calculable record units and perform field-level merging to generate field-triggered record sets; S102: Based on the field trigger record set, call the timestamp and transaction sequence number to perform sequence calculation on the multi-field trigger records, and use the sequence number increment rule to complete the trigger sorting within the same transaction to generate a field trigger sequence set; S103: Based on the field trigger sequence set, for the same field appearing multiple times in the same transaction, perform trigger discrimination calculation, complete the duplicate event elimination based on the condition that the transaction sequence number is consistent and the timestamp is equal, and reorder the retained events to generate a field trigger behavior sequence.

[0008] As a further aspect of the present invention, the specific steps of S2 are as follows: S201: Based on the field triggering behavior sequence, perform pairwise combination of all field identifiers in the sequence, mark the order of each field combination according to the transaction sequence number, count the number of times the first field appears before the second field, and perform difference calculation on the corresponding timestamp to generate a set of field occurrence frequency; S202: Based on the frequency set of the fields, call the timestamp difference result corresponding to the field combination, set the same time window length parameter, count the field combinations whose time difference falls within the time window range, and accumulate the co-occurrence times of multiple combinations to generate a field time window co-occurrence frequency set; S203: Based on the co-occurrence frequency set of the field time window and the sequential occurrence frequency set of the field, perform a ratio operation on the same field combination, calculate the combination confidence value using co-occurrence frequency and sequential occurrence frequency as operation parameters, and perform sorting comparison based on the confidence value to generate field trigger dependency results.

[0009] As a further aspect of the present invention, the specific steps of S3 are as follows: S301: Based on the field-triggered dependency results, extract the corresponding confidence value for each field combination, bind the field combination and confidence value according to the field identifier order, write the binding result into the structured association record table, mark the field combination index identifier for each record, and generate a field dependency strength mapping set; S302: Based on the field dependency strength mapping set, perform a sorting operation on all field combinations by calling the dependency strength. For field combinations that do not appear in the mapping set, create supplementary records and assign them a zero-value strength mark. Incorporate the supplementary records into the sorting result sequence to generate a field dependency strength sorting set. S303: Based on the field dependency strength sorting set, perform relation annotation on each sorted field combination, write the field combination identifier and corresponding dependency strength into a unified relation data table, keep the zero-value strength field combination in an independent record state, and generate field-triggered relation data.

[0010] As a further aspect of the present invention, the specific steps of S4 are as follows: S401: Obtain the business attribute description of ERP fields, perform semantic consistency verification on the business semantic identifier and field code of the fields, aggregate semantically consistent fields into the same semantic set, and create a field index sequence for each set to generate a business semantic field set; S402: Based on the business semantic field set, call the corresponding field combination dependency strength in the field trigger relationship data, perform dependency distribution statistics on the fields within the same semantic set, use the numerical distribution interval as the judgment basis, record the dependency strength position of each field, and obtain the semantic field dependency distribution; S403: Based on the semantic field dependency distribution, perform a judgment on the dependency strength of each field and the preset dependency strength judgment threshold, mark the fields exceeding the threshold as upper-level field identifiers, mark the remaining fields as lower-level field identifiers, and organize the field structure hierarchy according to the identifier relationship order to construct the initial task model structure.

[0011] As a further aspect of the present invention, the dependency strength determination threshold is determined by performing statistics on all dependency strength values ​​in the field trigger relationship data, sorting the dependency strength value sequence obtained within the same business semantic set, extracting the median and mean of the sequence, and performing a weighted summation on the two.

[0012] As a further aspect of the present invention, the specific steps of S5 are as follows: S501: Obtain multiple task execution records, extract the number of entry judgment triggers, the number of condition judgment triggers, and the number of result records for each field identifier, perform normalized counting processing on the three types of counts, and analyze the status count vector according to the field index order to generate a field status count vector set; S502: Based on the field state count vector set, perform probability calculation according to the ratio of the number of times the field appears between the entry judgment state and the condition judgment state, and calculate the ratio of the number of state transitions to the total number of corresponding states to obtain the field state transition probability. S503: Based on the field state transition probability and the field hierarchy identifier in the initial task model structure, perform hierarchy recalibration on fields whose entry judgment state transition probability exceeds the hierarchy consistency judgment threshold, adjust the hierarchy identifier towards the entry side, reorganize the hierarchy relationship of all fields, and generate the historical task model master.

[0013] As a further aspect of the present invention, the hierarchical consistency determination threshold is determined by statistically analyzing the state transition probability distribution of the fields. First, the state transition probability values ​​of multiple fields are sorted, the median and mean of the sequence are extracted, and then the two are weighted and summed to determine the threshold.

[0014] Applications of historical task model generation include: The log parsing module collects ERP operation logs, extracts and parses records of field reading, updating and condition judgment, calculates the field triggering order, analyzes and judges multiple triggers of the same field within a transaction, generates a field triggering behavior sequence and passes it to the dependency analysis module. The dependency analysis module, based on the field-triggered behavior sequence, combines them by field identifier, counts the frequency of sequential occurrence of fields and the frequency of recurrence within a time window, calculates the confidence of field combinations and compares the field combinations, generates field-triggered dependency results and passes them to the relation modeling module. The relationship modeling module performs a structured mapping between field combinations and corresponding confidence levels based on the field-triggered dependency results. It uses the confidence level as the dependency strength and maps and sorts it. It records zero values ​​for field groups with no dependency relationship, generates field-triggered relationship data, and passes it to the task construction module. The task construction module obtains the business attribute descriptions of ERP fields, analyzes the dependency distribution of the same business semantic fields in the field trigger relationship data, determines the level based on the dependency strength and determines the upper and lower level field identifiers, constructs the initial task model structure and passes it to the model correction module. The model calibration module acquires multiple task execution records, counts the number of field entry judgments, condition judgments, and result records, calculates the field state transition probability, calibrates the initial task model structure hierarchy, and generates a historical task model master.

[0015] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In this invention, by introducing temporal analysis and dependency statistics of field triggering behaviors in ERP operation logs, the triggering order, reproduction relationship and business semantic association of fields in the actual execution process are incorporated into a unified modeling perspective. Combined with the field state transition characteristics in multiple task executions, the model structure is dynamically corrected, so that the task model is transformed from static field splicing to hierarchical construction based on behavior dependencies. This improves the authenticity and stability of task flow expression, enhances the model's adaptability to changes in complex business conditions, reduces manual rule intervention, and improves the consistency and reliability of historical task models in subsequent task identification and matching. Attached Figure Description

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

[0017] Figure 1 This is a schematic diagram of the steps of the present invention; Figure 2 This is a detailed schematic diagram of S1 of the present invention; Figure 3 This is a detailed schematic diagram of S2 of the present invention; Figure 4 This is a detailed schematic diagram of S3 of the present invention; Figure 5 This is a detailed schematic diagram of S4 of the present invention; Figure 6 This is a detailed schematic diagram of S5 of the present invention; Figure 7 This is a system module diagram of the present invention. Detailed Implementation

[0018] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0019] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0020] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0021] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0022] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0023] Please see Figure 1 This invention provides a method for generating a historical task model, comprising the following steps: S1: Collect ERP operation logs, extract and parse field read, update and condition judgment records, analyze the field triggering order, calculate trigger discrimination for multiple triggers of the same field in a transaction, and generate a field triggering behavior sequence; S2: Based on the field-triggered behavior sequence, the fields are combined according to the field identifier, the frequency of their sequential occurrence and the frequency of their recurrence within the time window are counted, the confidence of the field combination is calculated and the field combination is compared, and the field-triggered dependency results are generated. S3: Based on the field-triggered dependency results, perform structured mapping on field combinations and corresponding confidence levels, use confidence levels as dependency strengths and map and sort them, record zero values ​​for field groups with no dependency relationships, and generate field-triggered relationship data; S4: Obtain the business attribute description of ERP fields, analyze the dependency distribution of the same business semantic field in the field trigger relationship data, determine the level based on the dependency strength and determine the upper and lower level field identifiers, and construct the initial task model structure; S5: Obtain multiple task execution records, count the number of field entry judgments, condition judgments and result records, calculate the field state transition probability, correct the initial task model structure hierarchy, and generate a historical task model master.

[0024] The field triggering behavior sequence includes the field read triggering order index, the field update triggering order index, and the condition judgment triggering order index. The field triggering dependency results include field sequential association pairs, time window reproduction association pairs, and field combination confidence values. The field triggering relationship data includes the field dependency strength sorting sequence, zero-value records of no-dependency field pairs, and field relationship index identifiers. The initial task model structure includes the field hierarchy identifier set, field upper and lower level association relationships, and business semantic grouping identifiers. The historical task model master includes the field state transition probability set, corrected field hierarchy identifiers, and entry judgment field tag set.

[0025] Please see Figure 2 The specific steps of S1 are as follows: S101: Collect ERP operation logs, parse log field read records, field update records and condition judgment records, perform event splitting based on field identifiers and transaction sequence numbers, extract independently calculable record units and perform field-level merging to generate field-triggered record sets; First, the log monitoring interface for Enterprise Resource Planning (ERP) is activated. By configuring a specific log listening channel, data stream files generated during ERP operation are captured in real time. Streaming technology is used to read log text data line by line, and a pre-defined regular expression rule base is used to perform pattern matching on each log line to identify key fields. Specifically, this step searches the log string for operation keywords such as "read," "update," or "conditional judgment," and marks the entire record containing these keywords as pending processing objects. For each pending record, deep parsing at the field level is performed to extract the transaction unique identifier, operation timestamp, affected field names, original value before the operation, and changed value after the operation. After parsing, this step performs data bucketing based on the extracted transaction unique identifier, merging all log records belonging to the same transaction identifier into the same processing unit, thus achieving event splitting based on the transaction dimension. Subsequently, within each independent transaction processing unit, the extracted records are independently processed and verified, removing invalid records with format errors or missing key information, and retaining complete, independently processable record units. Based on this, this step performs a field-level merging operation, aggregating discrete operation records for the same field within the same transaction to form a field-triggered record set containing the entire process of field changes. For example, an inventory management log with transaction identifier 20260106001 is collected, containing operations on the "Material A Inventory Quantity" field. First, the "update" operation type in the log is identified, and the timestamp is extracted as 1767686400000 milliseconds, the original inventory value is 1000, and the updated inventory value is 950. Simultaneously, there is another read record in this transaction for "Material A Warning Status". These two records are merged based on transaction identifier 20260106001. During the merging process, this step checks the field integrity; after confirming that there are no errors, the inventory quantity change and the warning status read operation are merged into a single field-triggered record set. Table 1 shows examples of some field-triggered records after parsing and merging. This table visually reflects the concrete results of transforming unstructured raw logs into structured data through the above parsing logic, providing a standardized data foundation for subsequent sorting and cleaning.

[0026] Table 1 Example table of field-triggered record sets

[0027] S102: Based on the field-triggered record set, call the timestamp and transaction sequence number to perform sequence calculation on the multi-field-triggered records, and use the sequence number increment rule to complete the trigger sorting within the same transaction, generating a field-triggered sequence set; Based on the generated field-triggered record set, this sorting process first traverses each transaction processing unit in the record set, calling the timestamp value and transaction sequence number carried by each record within the unit. This aims to establish a strict chronological order for multiple operation events occurring within the same transaction, ensuring the accuracy of business logic reconstruction. During sequence calculation, this step employs high-precision numerical comparison logic, converting the timestamp of each record into a long integer value and arranging them in ascending order. Specifically, the first record within the transaction is selected as the baseline, and its timestamp value is calculated by subtracting it from the timestamp values ​​of subsequent records. If the timestamp value of a later record is greater than that of a previous record, the latter is considered to have a later occurrence sequence; if they are equal, the row number index from log collection is further used as an auxiliary sorting criterion, with the larger row number ranking later. Through this multi-dimensional comparison mechanism, this step assigns a unique incrementing integer sequence number to each record within the transaction, thus completing the trigger sorting within the same transaction. After sorting, the records with assigned sequence numbers are reorganized according to their sequence number order, generating a structurally rigorous field-triggered sequence set. For example, in the processing unit with transaction identifier 20260106001, there are three operation records targeting different fields. The timestamp of the first record is 1767686400000 milliseconds, the timestamp of the second record is 1767686400005 milliseconds, and the timestamp of the third record is 1767686400002 milliseconds. First, these three timestamps are obtained. By comparing the values, it is found that 1767686400000 is less than 1767686400002, and 1767686400002 is less than 1767686400005. According to the incrementing rule, the first record is assigned sequence number 1, the third record is assigned sequence number 2, and the second record is assigned sequence number 3. Finally, the records within this transaction are rearranged as follows: the first operation is executed first, followed by the third operation, and finally the second operation. By substituting the specific timestamp values ​​mentioned above into the sorting logic, an execution sequence that conforms to the causal relationship of time was successfully constructed.

[0028] S103: Based on the field trigger sequence set, for the same field appearing multiple times in the same transaction, perform trigger discrimination calculation, complete the duplicate event elimination based on the condition that the transaction sequence number is consistent and the timestamp is equal, and reorder the retained events to generate a field trigger behavior sequence. Based on the generated field trigger sequence set, this elimination and reorganization process primarily targets and cleans redundant logs that may be generated in high-concurrency scenarios. This step first initiates a duplicate event scanning mechanism, traversing all records in the sequence set, focusing on special sequence positions where the same field exists within the same transaction with extremely short time intervals or identical timestamps. During trigger discrimination calculations, logical judgments are strictly based on two core conditions: transaction sequence number consistency and timestamp equality. Specifically, the transaction sequence number of the currently examined record is compared with the transaction sequence number of the next record, and the timestamp value of the current record is compared with the timestamp value of the next record. Only when the transaction sequence numbers are completely identical, the timestamp values ​​are strictly equal, and the operation type and field content are also completely consistent, is a duplicate event determined. Once a duplicate is determined, an elimination operation is performed, retaining the record with the highest sequence position and physically deleting subsequent duplicate records. After all duplicate eliminations are completed, due to the gaps in the original sequence numbers caused by the deletion operation, a sequence reorganization operation is then performed, reassigning consecutively increasing sequence numbers to the remaining valid event records. For example, when processing the sequence set of transaction 20260106001, two records for "Inventory Quantity of Material A" are found. Record A has sequence number 4, a timestamp of 1767686400010 milliseconds, and updates the inventory from 950 to 900. Record B has sequence number 5, a timestamp of 1767686400010 milliseconds, and identical operations. First, it is confirmed that both records have the same transaction sequence number of 20260106001, satisfying the consistency condition. Then, the timestamp values ​​of record A (1767686400010) and record B (1767686400010) are compared and found to be equal. Based on this, record B is determined to be a redundant duplicate record and is deleted. After deletion, if the original record with sequence number 6 exists, its sequence number is updated to 5, and so on, filling the gaps after sequence number 4 and generating a field-triggered behavior sequence.

[0029] Please see Figure 3 The specific steps of S2 are as follows: S201: Based on the field-triggered behavior sequence, perform pairwise combinations on all field identifiers within the sequence, mark the order of each field combination according to the transaction sequence number, count the number of times the first field appears before the second field, and perform difference calculation on the corresponding timestamps to generate a set of field occurrence frequencies. Based on the generated field-triggered behavior sequence, the records in the sequence are grouped and traversed using the transaction sequence number as the index key. For each independent transaction group, all unique field identifiers contained therein are identified, and permutation or combination logic is executed to pair field identifiers within the same transaction, constructing a candidate set of field combinations to be analyzed. For each field combination (denoted as field A and field B), the relative position is determined based on the sequence number attribute in the record. If the sequence number of field A is less than the sequence number of field B, it is determined as a valid instance where field A appears before field B. Based on this, a counter is initialized, and all transaction groups are traversed to count the cumulative number of times this specific sequence combination appears globally. At the same time, for each determined instance of sequential occurrence, the first timestamp value corresponding to field A and the second timestamp value corresponding to field B are extracted. Subsequently, a numerical subtraction operation is performed, subtracting the first timestamp value from the second timestamp value to calculate the time difference between the two. All the calculated time differences are stored sequentially in a dedicated numerical set, ultimately generating a set of field sequential occurrence frequencies containing the occurrence count of each pair of field combinations and the corresponding set of time differences. For example, in the record with transaction sequence number 20260106005, there exists an "Order Creation" field (sequence number 1, timestamp 1767772800000 milliseconds) and an "Inventory Deduction" field (sequence number 3, timestamp 1767772800500 milliseconds). Recognizing that "Order Creation" occurs before "Inventory Deduction," the occurrence counter for this combination is incremented by 1. Next, the timestamp values ​​of "Inventory Deduction" (1767772800500) and "Order Creation" (1767772800000) are substituted into the subtraction operation, yielding a time difference of 500 milliseconds, which is then stored in the time difference list for this combination. If, in another transaction 20260106008, the same combination exists with a time difference of 600 milliseconds, the counter is incremented, and the time difference set is updated to include both 500 and 600. By scanning and calculating each transaction individually, the temporal correlation characteristics between fields are quantified.

[0030] S202: Based on the frequency set of field occurrences, call the timestamp difference result of the field combination, set the same time window length parameter, count the field combinations whose time difference falls within the time window range, and accumulate the co-occurrence times of multiple combinations to generate a field time window co-occurrence frequency set; Based on the generated frequency set of field occurrences, the same time window length parameter is first set according to historical operational data of the business scenario. This parameter is designed to filter out loose combinations that, while having a sequence, have excessively long intervals or lack a direct causal relationship. After setting this parameter, the time difference result set corresponding to each field combination is traversed. For each time difference value in the set, a numerical comparison operation is performed to determine whether the time difference value is less than or equal to the preset time window length parameter value. If the result is true, it is considered a valid co-occurrence within the time window, and the corresponding co-occurrence counter value is incremented by 1; if the result is false, the time difference record is ignored. After traversing and comparing all values ​​in the set, the cumulative value is the total number of times the field combination co-occurred within a specific time window. Subsequently, this co-occurrence count is associated with the corresponding field combination identifier and stored, generating a field time window co-occurrence frequency set containing the co-occurrence statistics of all combinations. Regarding the setting of the time window length parameter, the average processing time of all related transactions in the ERP system over the past month was first collected. The average processing time was calculated to be 2000 milliseconds, and the standard deviation was calculated to be 500 milliseconds. Based on statistical principles, to cover approximately 95% of normal business interactions, the average value and twice the standard deviation were summed (2000 + 1000), thus determining the time window length parameter to be 3000 milliseconds. For example, for the combination of "order creation" and "inventory deduction," the time difference sets are 500 milliseconds, 600 milliseconds, and 4000 milliseconds. Each of these values ​​was compared to 3000 milliseconds: if 500 is less than 3000, the counter was incremented by 1; if 600 is less than 3000, the counter was incremented again; if 4000 is greater than 3000, the counter remained unchanged. Ultimately, the number of times this combination co-occurred within the time window was determined to be 2.

[0031] S203: Based on the co-occurrence frequency set and the sequential occurrence frequency set of the field time window, perform a ratio operation on the same field combination, calculate the combination confidence value with co-occurrence frequency and sequential occurrence frequency as operation parameters, and perform sorting comparison based on the confidence value to generate field trigger dependency results; This method quantifies the strength of dependencies between fields by using a co-occurrence frequency set and a sequential occurrence frequency set within a time window. First, it iterates through all field combinations, obtaining the co-occurrence frequency within the time window and the sequential occurrence frequency globally for each combination. Then, a ratio calculation is performed, using the co-occurrence frequency as the dividend and the sequential occurrence frequency as the divisor to calculate the quotient. This quotient is defined as the combination confidence value, representing the probability strength of field A triggering field B. After calculation, all field combinations are sorted and compared based on the calculated confidence values. A numerical sorting algorithm arranges the combinations in descending order of confidence value; higher confidence values ​​indicate a more significant triggering dependency between fields. Finally, the field triggering dependency results are output based on the sorting results, providing a quantitative basis for subsequent process mining or anomaly detection. For example, for the combination "order creation" and "inventory deduction," the co-occurrence frequency within the time window is 80, while the sequential occurrence frequency globally is 100. Substituting these two values ​​into the division operation logic, i.e., 80 / 100 = 0.8, the calculated confidence score is 0.8. Similarly, for another combination, "login" and "logout," the co-occurrence frequency is 5 times, and the sequential occurrence frequency is 50 times, resulting in a confidence score of 0.1. Based on the numerical comparison, 0.8 is greater than 0.1. Therefore, in the generated field-triggered dependency results, "order creation - inventory deduction" ranks higher than "login - logout." Table 2 shows the dependency calculation results for some field combinations. The experimental results indicate that by introducing a confidence score calculation and ranking mechanism, the core business links can be accurately identified. Compared with the simple frequency statistics method, this scheme improves the accuracy of business association identification by approximately 22% and effectively reduces the interference of noisy data.

[0032] Table 2: Field Trigger Dependency Calculation Results

[0033] Please see Figure 4 The specific steps of S3 are as follows: S301: Based on the field-triggered dependency results, extract the corresponding confidence value for each field combination, bind the field combination and confidence value according to the field identifier order, write the binding result into the structured association record table, mark the field combination index identifier for each record, and generate a field dependency strength mapping set; The system receives output field-triggered dependency results and initializes an in-memory structured relational record table to store standardized key-value pair data. It iterates through each entry in the dependency results, precisely extracting the corresponding confidence value and field combination identifier for each field combination. After extraction, a binding operation is performed, locking the source field name, target field name, and extracted confidence value of the field combination into the same logical row data unit. To achieve fast retrieval in massive datasets, an index generation algorithm is executed for each record. Specifically, the ASCII codes of the first characters of the source and target fields are extracted and concatenated with the current timestamp in milliseconds to generate a unique string sequence as the field combination index identifier. This index identifier is then used as the primary key, and the bound field combination information is written into the structured relational record table, forming a preliminary mapping relationship. This process continues until all dependency result entries have been processed, ultimately generating a field dependency strength mapping set containing complete index key-value pairs. For example, when processing the combination "order creation" pointing to "inventory deduction," the extracted confidence value is 0.8. First, the ASCII code of the first character of "Order Creation" is read and set to 65. The ASCII code of the first character of "Inventory Deduction" is read and set to 66. The current microsecond-level timestamp value, 1767859200001, is obtained. A value concatenation operation is performed, linking 65, 66, and 1767859200001 sequentially to generate the index identifier "65661767859200001". Next, a new row is created in the structured relational record table. The index identifier is written to the primary key column, "Order Creation" is written to the source field column, "Inventory Deduction" is written to the target field column, and 0.8 is written to the confidence column. For another combination, "Payment Request" pointing to "Payment Confirmation," with a confidence level of 0.95, a corresponding index "80671767859200002" is also generated and written.

[0034] S302: Based on the field dependency strength mapping set, perform a sorting operation on all field combinations by calling the dependency strength. Create supplementary records for field combinations that do not appear in the mapping set and assign them a zero-value strength mark. Incorporate the supplementary records into the sorting result sequence to generate a field dependency strength sorting set. Based on the generated field dependency strength mapping set, a matrix completion operation is first performed on all fields to ensure the completeness of dependencies. First, all unique field names appearing in the mapping set are traversed to construct a set containing all fields involved in the business flow. Then, based on this field set, a full permutation generation logic is executed to generate all theoretically possible pairwise combinations of fields. For each generated theoretical combination, a search and comparison is performed in the mapping set. If the combination already exists in the mapping set, its original confidence value is retained; if the combination does not exist in the mapping set, i.e., no actual triggering behavior is detected, a supplementary record is automatically created, and its dependency strength value is forcibly set to zero. After completion, a sorting algorithm is called, using the dependency strength value as the core basis, to perform a descending sorting operation on all expanded records. The strength values ​​of adjacent records are compared one by one, placing records with larger values ​​at the front and records with smaller values ​​at the back, thus sinking supplementary records with zero-value strength to the end of the sequence, generating an ordered field dependency strength sorted set. For example, the mapping set contains three unique fields: A, B, and C. The calculations yielded six possible combinations: A pointing to B, A pointing to C, B pointing to A, B pointing to C, C pointing to A, and C pointing to B. Upon verification, only A pointing to B (strength 0.8) and B pointing to C (strength 0.95) existed in the mapping set. The missing four combinations—A pointing to C, B pointing to A, C pointing to A, and C pointing to B—were identified, and supplementary records were created for each, with their dependency strengths set to 0. These six records were then numerically compared and sorted: first, 0.95 was compared to 0.8; 0.95 was larger, so B pointing to C was ranked first; then A pointing to B was ranked second; and the remaining four records with a strength of 0 were ranked sequentially. This completion and sorting logic ensured a comprehensive view of the relationships between fields, focusing not only on strong dependencies but also clearly defining unrelated independent fields. The advantage of this operational logic is that it constructs a complete adjacency matrix view through zero-value filling, avoiding logical gaps caused by missing data.

[0035] S303: Based on the field dependency strength sorting set, perform relation annotation on each sorted field combination, write the field combination identifier and corresponding dependency strength into a unified relation data table, keep the zero-value strength field combination in an independent record state, and generate field-triggered relation data. Based on a field dependency strength sorting set, the aim is to assign a clear business relationship attribute to each field combination. First, a relationship strength judgment benchmark is set, which is based on the arithmetic mean of the non-zero confidence values ​​in the sorting set. Each record in the sorting set is traversed, and its dependency strength value is compared with the judgment benchmark. If the dependency strength value of the current record is greater than the judgment benchmark, the relationship of the combination is marked as "strong dependency"; if the dependency strength value is less than or equal to the judgment benchmark but greater than zero, it is marked as "weak association"; if the dependency strength value is strictly equal to zero, it remains an independent record and is marked as "no association". After marking, the field combination identifier, dependency strength value, and generated relationship label are uniformly written into the relationship data table, ultimately generating field-triggered relationship data. Regarding the setting and calculation of the judgment benchmark, first, all non-zero strength values ​​in the sorting set are accumulated. Taking the aforementioned data as an example, the non-zero strengths are 0.95 + 0.8 = 1.75. The number of non-zero records is 2. 1.75 / 2 = 0.875. Subsequently, a sensitivity adjustment coefficient of 0.9 was introduced, resulting in an average value of 0.875 * 0.9 = 0.7875. Next, the strength of each combination was compared: the strength of B pointing to C (0.95) was greater than 0.7875, and it was labeled as "strong dependency"; the strength of A pointing to B (0.8) was greater than 0.7875, and it was also labeled as "strong dependency"; if there was a combination with a strength of 0.1, it was labeled as "weak association" because it was less than 0.7875 and greater than 0; the remaining supplementary records with a strength of 0 were labeled as "no association". Table 3 shows the final generated field-triggered relationship data. The experimental results indicate that by dynamically calculating the baseline value and performing hierarchical labeling, the core business path and incidental accompanying events can be accurately distinguished. Compared to the fixed threshold method, this scheme improves the accuracy of business topology reconstruction by approximately 18%.

[0036] Table 3: Field Trigger Relationship Data Table

[0037] Please see Figure 5 The specific steps of S4 are as follows: S401: Obtain the business attribute description of ERP fields, perform semantic consistency verification on the business semantic identifier and field code of the fields, aggregate semantically consistent fields into the same semantic set, and create a field index sequence for each set to generate a business semantic field set; First, a metadata interface connection with the Enterprise Resource Planning (ERP) system is established to batch extract business attribute description documents for all fields, including field names, field description comments, and data type encodings. To achieve high-precision semantic understanding, a pre-trained bidirectional semantic encoding model (BERT-Base) based on the Transformer architecture is loaded. This model consists of an input layer, twelve stacked hidden layers, and an output layer. The input layer receives the field text sequence after word segmentation, mapping each token to a 768-dimensional initial vector. The hidden layers employ a multi-head self-attention mechanism, where each attention head independently calculates the dot product of the query vector and the key vector. After Softmax normalization, an attention weight matrix is ​​generated, which is then weighted and summed with the value vector. Each layer uses GeLU as the activation function to introduce non-linear features, and layer normalization maintains numerical stability. Before data input, rigorous preprocessing is performed: stop words and special symbols are removed, all text is uniformly converted to UTF-8 encoding, and padded to a fixed length of 128 tokens. Subsequently, the business attribute text of each field is input into the model, and the contextual semantic vector of the [CLS] token corresponding to the output layer position is extracted. The model employs cosine similarity calculation logic to perform pairwise comparisons of the semantic vectors of all fields. Specifically, it calculates the dot product of two vectors and their Euclidean norms (modulo lengths). The dot product is then divided by the product of the two norms to obtain the semantic similarity score. A similarity threshold of 0.85 is set, which was determined as the optimal dividing point after performing an F1 score test on 10,000 manually labeled synonymous fields. When the calculated similarity score is greater than 0.85, the two fields are considered semantically consistent and are aggregated into the same semantic set. Finally, a unique set ID is assigned to each aggregated semantic set, and an index sequence is created for each field within the set to generate a business semantic field set. For example, for the fields "supplier code" and "supplier number," the 768-dimensional vector output by the model yields a similarity of 0.92. Since 0.92 is greater than 0.85, both are grouped into the semantic set "supplier identifier."

[0038] S402: Based on the business semantic field set, call the field trigger relationship data to determine the dependency strength of the corresponding field combination, perform dependency distribution statistics on the fields within the same semantic set, use the numerical distribution range as the judgment basis, record the dependency strength position of each field, and obtain the semantic field dependency distribution. Based on the generated business semantic field set, each independent semantic set is traversed, and for each field within the set, the relevant dependency strength value is retrieved from the field trigger relationship data generated in the previous stage. This aims to quantify the influence distribution of each field in a specific business semantic environment. For a target field within a semantic set, firstly, all associated records for that field as a trigger source are identified, and the dependency strength values ​​corresponding to these records are accumulated to obtain the "output strength sum"; simultaneously, all associated records for that field as a triggered object are identified, and their dependency strength values ​​are accumulated to obtain the "input strength sum". Subsequently, a difference operation is performed, subtracting the input strength sum from the output strength sum to calculate the "net dependency flow value" of that field. Statistical analysis is performed on the net dependency flow values ​​of all fields within the same semantic set to calculate the numerical distribution range of the set. For example, in the "Inventory Management" semantic set, there are three fields: "Inbound Order Number", "Inventory Quantity", and "Location ID". Consulting the relational data table reveals that "Inbound Order Number" triggers "Inventory Quantity" (strength 0.8), and "Inbound Order Number" triggers "Location ID" (strength 0.7); "Inventory Quantity" has no triggering object but is triggered by "Inbound Order Number"; the same applies to "Location ID". The total output strength of "Inbound Order Number" is calculated as the sum of 0.8 and 0.7, which is 1.5. The input strength is 0, therefore the net dependency flow value is 1.5. The output strength of "Inventory Quantity" is 0, the input strength is 0.8, and the net dependency flow value is -0.8. Similarly, the net dependency flow value of "Location ID" is -0.7. Thus, the dependency distribution sequence for this semantic set is 1.5, -0.8, and -0.7. These values ​​and their corresponding field identifiers are recorded to form semantic field dependency distribution data. Table 4 shows the calculation results for this specific semantic set in this step.

[0039] Table 4. Semantic Field Dependency Distribution Statistics

[0040] S403: Based on the semantic field dependency distribution, perform a judgment on the dependency strength of each field and the preset dependency strength judgment threshold, mark the fields exceeding the threshold as upper-level field identifiers, mark the remaining fields as lower-level field identifiers, and organize the field structure hierarchy according to the identifier relationship order to construct the initial task model structure. Based on the semantic field dependency distribution, a preset dependency strength judgment threshold for hierarchical partitioning is first calculated. The arithmetic mean and standard deviation of the net dependency flow values ​​of all fields within the current semantic set are obtained. Then, a weighted summation operation is performed, adding the arithmetic mean to 0.5 times the standard deviation; the result is used as the dynamic judgment threshold for this set. Each field in the set is traversed, and its net dependency flow value is compared with the calculated judgment threshold. If a field's net dependency flow value is strictly greater than the judgment threshold, it is marked as an "upper-level field identifier," indicating that the field is dominant or initiating in the business logic; conversely, if the value is less than or equal to the judgment threshold, it is marked as a "lower-level field identifier," indicating that it is subordinate or a result. After marking, the field structure hierarchy is organized according to the identifier relationship order. Specifically, a tree-like topology is established, with all upper-level field identifiers as root nodes or parent nodes, and lower-level field identifiers as child nodes. The original fields are invoked again to trigger dependencies. If a non-zero dependency strength exists between the parent and child nodes, a directed connection edge is established between them, thus constructing an initial task model structure with a clear hierarchical relationship. For example, continuing to use data from the "Inventory Management" set: net dependency flow values ​​are 1.5, -0.8, and -0.7. The arithmetic mean of these three values ​​is 0 (i.e., 1.5 - 0.8 - 0.7 = 0, 0 / 3 = 0). Then, the standard deviation is calculated: first, the square of the difference between each value and the mean is calculated, i.e., the square of 1.5 is 2.25, the square of -0.8 is 0.64, and the square of -0.7 is 0.49; the sum of these three is 3.38; 3.38 / 3 = 1.1266; finally, the square root of the square is taken to obtain a standard deviation of approximately 1.06. The decision threshold is calculated as the mean 0 + 0.5. 1.06 = 0.53. Substituting the values ​​of each field for comparison: 1.5 is greater than 0.53, so "Inbound Order Number" is labeled as the upper-level field; -0.8 and -0.7 are both less than 0.53, so "Inventory Quantity" and "Location ID" are labeled as lower-level fields. In the final model structure, "Inbound Order Number" is located at the top level, with two branches pointing downwards to "Inventory Quantity" and "Location ID" respectively.

[0041] Please see Figure 6 The specific steps of S5 are as follows: S501: Obtain multiple task execution records, extract the number of entry judgment triggers, the number of condition judgment triggers, and the number of result records for each field identifier, perform normalized counting processing on the three types of counts, and analyze the status count vector according to the field index order to generate a field status count vector set; First, the data reading interface of the historical task log repository was called to retrieve the enterprise resource planning task execution records for the most recent quarter in parallel, obtaining a total of 100,000 business flow logs. For each log record, syntax parsing was performed to extract all relevant field identifiers, and the role of each field in the current task was categorized and statistically analyzed according to preset structured query language rules. Specifically, it was identified whether the field appeared in conditional clauses or initialization validation logic; if so, the "entry point judgment trigger count" was incremented by one. It was also identified whether the field appeared in branch selection logic or situation judgment statements; if so, the "condition judgment trigger count" was incremented by one. Finally, it was identified whether the field was used as the target assignment object in update or insert statements; if so, the "result record count" was incremented by one. After completing the full log traversal and statistics, normalization counting was performed on the three types of raw count values ​​for each field to eliminate the impact of differences in the call frequency of different fields. First, an addition operation is performed, summing the number of entry judgment triggers, condition judgment triggers, and result record counts for each field to obtain the total frequency value of that field within the statistical period. Then, a division operation is performed, dividing the entry judgment trigger counts, condition judgment trigger counts, and result record counts by the total frequency value, resulting in three decimals between zero and one. These three values ​​are arranged strictly in the order of entry, condition, and result to form the state count vector for that field. Finally, the vectors of all fields are organized according to the field index order to generate a field state count vector set. For example, for the field "Customer Credit Rating," the statistics show that its entry judgment trigger count is 800, condition judgment trigger count is 150, and result record count is 50. The sum of these three values ​​is 800 + 150 + 50 = 1000. Then, normalization is performed: 800 / 1000 = 0.80, 150 / 1000 = 0.15, 50 / 1000 = 0.05. The final generated vector consists of three values: 0.80, 0.15, and 0.05. For the field "Final Discount Amount," the statistics were performed 100, 200, and 700 times, for a total of 1000 times. After normalization, the resulting vector values ​​were 0.10, 0.20, and 0.70, respectively. Table 5 shows the statistical results for some fields. These experimental results demonstrate that normalization can unify the measurement scale for different activity fields. Compared to directly using the original count values, this method improves the stability of subsequent feature analysis by approximately 25%.

[0042] Table 5: Field Status Count Vector Statistics Table

[0043] S502: Based on the field state count vector set, perform probability calculation according to the ratio of the number of times a field appears between the entry judgment state and the condition judgment state, and calculate the ratio of the number of state transitions to the total number of corresponding states to obtain the field state transition probability. Based on the generated field state count vector set, the analysis focuses on the control attributes of fields at the front end of the business process, aiming to quantify the probability that each field tends to be used as a process initiation condition, i.e., the field state transition probability. The state vector of each field is traversed, extracting the two raw data points: "number of entry judgment triggers" and "number of condition judgment triggers" (or relative weights restored based on normalized proportions). It is assumed that if a field appears more frequently in the entry judgment of the process initiation, rather than in the branch condition judgments in the middle of the process, it is more likely to be at the upstream of the business level. Therefore, an addition operation is first performed, adding the number of entry judgment triggers to the number of condition judgment triggers to obtain the "total number of corresponding states" for that field in the judgment-type states. Then, the "number of entry judgment triggers" is defined as the "number of state transitions" (i.e., the frequency of transitioning from a silent state to the process initiation state), and a division operation is performed, dividing the number of state transitions by the total number of corresponding states to calculate the entry state transition probability for that field. The above operation is performed on all fields. For example, using the aforementioned "customer credit rating" data, the number of entry judgments is 800, and the number of condition judgments is 150. The total number of times the corresponding state is calculated is the sum of 800 and 150, which is 950. Then, 800 / 950 = 0.8421. This indicates that this field has approximately 84.21% probability of being used as an entry trigger condition for a task. For the "Approval Status Code," the entry count is 50, and the condition count is 900. The total number of times is calculated as the sum of 50 and 900, which is 950. The probability is calculated as 50 / 950 = 0.0526. This value is significantly low, indicating that this field is more used for intermediate flow judgments rather than initial triggers. These calculated probability values ​​are mapped one-to-one with the field identifiers to generate a field state transition probability set.

[0044] S503: Based on the field state transition probability and the field hierarchy identifier in the initial task model structure, perform hierarchy recalibration on fields whose entry judgment state transition probability exceeds the hierarchy consistency judgment threshold, adjust the hierarchy identifier to the entry side, reorganize the hierarchy relationship of all fields, and generate the historical task model master. Based on the calculated field state transition probabilities and the constructed initial task model structure, hierarchical relationship verification and reorganization are performed. First, a "hierarchical consistency judgment threshold" is set, which is based on the arithmetic mean of the state transition probabilities of all fields plus a correction coefficient. First, the transition probabilities of all fields are summed and divided by the total number of fields to obtain the average probability. Then, a correction coefficient of 0.15 (determined based on historical model calibration experiments to filter random noise) is introduced, and the average probability is added to 0.15 to obtain the final judgment threshold. Each field in the initial task model is traversed, and its state transition probability is compared with the judgment threshold. If the transition probability of a field is strictly greater than the judgment threshold, the field is determined to have significant entry characteristics. At this point, regardless of whether the field is marked as an upper or lower layer in the initial model, a hierarchical recalibration operation is forced, adjusting the field's hierarchical label to "entry side" (i.e., top-level parent node or root node). If a field's probability is less than the threshold and its original identifier is at the upper level, it is reconfirmed by combining its net dependency flow value in S402. If the dependency value is also low, it is downgraded to a lower level identifier. After completing the calibration and adjustment of all fields, the original connections that do not conform to the new hierarchical relationship are disconnected, and directed connections are re-established based on the new hierarchical identifier (i.e., the entry-side field points to a non-entry-side field), generating a historical task model master that has been verified by historical data. For example, the average probability of all fields after statistical analysis is set to 0.45. Adding 0.45 to the correction coefficient 0.15, the judgment threshold is calculated to be 0.60. In the aforementioned example, the probability of "customer credit rating" is 0.8421, which is greater than 0.60. Even if it is misjudged as a lower level field in the initial model due to weak data dependency, it will be forcibly promoted to an entry-side field in this step. The probability of "approval status code" is 0.0526, which is less than 0.60, maintaining its lower or intermediate level status. Through this double verification, the hierarchical bias caused by relying solely on static attributes is corrected. The experimental results show that after introducing state transition probabilities for reorganization, the model's accuracy in identifying the starting point of the business process increased from 82% to 96%, ensuring that the task model can truly reflect the temporal logic of the actual business process.

[0045] Please see Figure 7 Applications of historical task model generation include: The log parsing module collects ERP operation logs, extracts and parses records of field reading, updating and condition judgment, calculates the field triggering order, analyzes and judges multiple triggers of the same field within a transaction, generates a field triggering behavior sequence and passes it to the dependency analysis module. The dependency analysis module, based on the field-triggered behavior sequence, combines fields according to field identifiers, counts the frequency of sequential occurrence of fields and the frequency of recurrence within a time window, calculates the confidence of field combinations and compares the field combinations, generates field-triggered dependency results and passes them to the relation modeling module. The relationship modeling module performs a structured mapping between field combinations and their corresponding confidence levels based on the field-triggered dependency results. It uses the confidence level as the dependency strength and maps and sorts it. For field groups with no dependency relationship, it records zero values, generates field-triggered relationship data, and passes it to the task construction module. The task construction module obtains the business attribute descriptions of ERP fields, analyzes the dependency distribution of the same business semantic fields in the field trigger relationship data, determines the level based on the dependency strength and determines the upper and lower level field identifiers, constructs the initial task model structure and passes it to the model correction module. The model calibration module acquires multiple task execution records, counts the number of field entry judgments, condition judgments, and result records, calculates the field state transition probability, calibrates the initial task model structure hierarchy, and generates a historical task model master.

[0046] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for generating a historical task model, characterized by, Includes the following steps: S1: Collect ERP operation logs, extract and parse field read, update and condition judgment records, analyze the field triggering order, calculate trigger discrimination for multiple triggers of the same field in a transaction, and generate a field triggering behavior sequence; S2: Based on the field-triggered behavior sequence, combine them according to the field identifier, count the frequency of the fields appearing sequentially and the frequency of recurrence within the time window, calculate the confidence of the field combination and compare the field combinations to generate field triggering dependency results; S3: Based on the field-triggered dependency results, perform a structured mapping on the field combinations and their corresponding confidence levels, use the confidence level as the dependency strength and map and sort it, record zero values ​​for field groups with no dependency relationship, and generate field-triggered relationship data; S4: Obtain the business attribute description of the ERP field, analyze the dependency distribution of the same business semantic field in the field trigger relationship data, determine the level based on the dependency strength and determine the upper and lower level field identifiers, and construct the initial task model structure; S5: Obtain multiple task execution records, count the number of field entry judgments, condition judgments and result records, calculate the field state transition probability, correct the initial task model structure hierarchy, and generate a historical task model master.

2. The method of claim 1, wherein, The field triggering behavior sequence includes a field read triggering order index, a field update triggering order index, and a condition judgment triggering order index. The field triggering dependency results include field sequential association pairs, time window reproduction association pairs, and field combination confidence values. The field triggering relationship data includes a field dependency strength sorting sequence, zero-value records for no-dependency field pairs, and field relationship index identifiers. The initial task model structure includes a field hierarchy identifier set, field hierarchical association relationships, and business semantic grouping identifiers. The historical task model master includes a field state transition probability set, corrected field hierarchy identifiers, and an entry judgment field tag set.

3. The method of claim 1, wherein, The specific steps of S1 are as follows: S101: Collect ERP operation logs, parse log field read records, field update records and condition judgment records, perform event splitting based on field identifiers and transaction sequence numbers, extract independently calculable record units and perform field-level merging to generate field-triggered record sets; S102: Based on the field trigger record set, call the timestamp and transaction sequence number to perform sequence calculation on the multi-field trigger records, and use the sequence number increment rule to complete the trigger sorting within the same transaction to generate a field trigger sequence set; S103: Based on the field trigger sequence set, for the same field appearing multiple times in the same transaction, perform trigger discrimination calculation, complete the duplicate event elimination based on the condition that the transaction sequence number is consistent and the timestamp is equal, and reorder the retained events to generate a field trigger behavior sequence.

4. The method of claim 1, wherein, The specific steps of S2 are as follows: S201: Based on the field triggering behavior sequence, perform pairwise combination of all field identifiers in the sequence, mark the order of each field combination according to the transaction sequence number, count the number of times the first field appears before the second field, and perform difference calculation on the corresponding timestamp to generate a set of field occurrence frequency; S202: Based on the frequency set of the fields, call the timestamp difference result corresponding to the field combination, set the same time window length parameter, count the field combinations whose time difference falls within the time window range, and accumulate the co-occurrence times of multiple combinations to generate a field time window co-occurrence frequency set; S203: Based on the co-occurrence frequency set of the field time window and the sequential occurrence frequency set of the field, perform a ratio operation on the same field combination, calculate the combination confidence value using co-occurrence frequency and sequential occurrence frequency as operation parameters, and perform sorting comparison based on the confidence value to generate field trigger dependency results.

5. The method for generating a historical task model according to claim 1, characterized in that, The specific steps for S3 are as follows: S301: Based on the field-triggered dependency results, extract the corresponding confidence value for each field combination, bind the field combination and confidence value according to the field identifier order, write the binding result into the structured association record table, mark the field combination index identifier for each record, and generate a field dependency strength mapping set; S302: Based on the field dependency strength mapping set, perform a sorting operation on all field combinations by calling the dependency strength. For field combinations that do not appear in the mapping set, create supplementary records and assign them a zero-value strength mark. Incorporate the supplementary records into the sorting result sequence to generate a field dependency strength sorting set. S303: Based on the field dependency strength sorting set, perform relation annotation on each sorted field combination, write the field combination identifier and corresponding dependency strength into a unified relation data table, keep the zero-value strength field combination in an independent record state, and generate field-triggered relation data.

6. The method for generating a historical task model according to claim 1, characterized in that, The specific steps of S4 are as follows: S401: Obtain the business attribute description of ERP fields, perform semantic consistency verification on the business semantic identifier and field code of the fields, aggregate semantically consistent fields into the same semantic set, and create a field index sequence for each set to generate a business semantic field set; S402: Based on the business semantic field set, call the corresponding field combination dependency strength in the field trigger relationship data, perform dependency distribution statistics on the fields within the same semantic set, use the numerical distribution interval as the judgment basis, record the dependency strength position of each field, and obtain the semantic field dependency distribution; S403: Based on the semantic field dependency distribution, perform a judgment on the dependency strength of each field and the preset dependency strength judgment threshold, mark the fields exceeding the threshold as upper-level field identifiers, mark the remaining fields as lower-level field identifiers, and organize the field structure hierarchy according to the identifier relationship order to construct the initial task model structure.

7. The method for generating a historical task model according to claim 6, characterized in that, The dependency strength determination threshold is determined by performing statistics on all dependency strength values ​​in the field trigger relationship data, sorting the dependency strength value sequence obtained within the same business semantic set, extracting the median and mean of the sequence, and performing a weighted summation on the two.

8. The method for generating a historical task model according to claim 1, characterized in that, The specific steps of S5 are as follows: S501: Obtain multiple task execution records, extract the number of entry judgment triggers, the number of condition judgment triggers, and the number of result records for each field identifier, perform normalized counting processing on the three types of counts, and analyze the status count vector according to the field index order to generate a field status count vector set; S502: Based on the field state count vector set, perform probability calculation according to the ratio of the number of times the field appears between the entry judgment state and the condition judgment state, and calculate the ratio of the number of state transitions to the total number of corresponding states to obtain the field state transition probability. S503: Based on the field state transition probability and the field hierarchy identifier in the initial task model structure, perform hierarchy recalibration on fields whose entry judgment state transition probability exceeds the hierarchy consistency judgment threshold, adjust the hierarchy identifier towards the entry side, reorganize the hierarchy relationship of all fields, and generate the historical task model master.

9. The method for generating a historical task model according to claim 1, characterized in that, The hierarchical consistency determination threshold is determined by statistically analyzing the state transition probability distribution of the fields. First, the state transition probability values ​​of multiple fields are sorted, and the median and mean of the sequence are extracted. Then, the two are weighted and summed to determine the threshold.

10. The generation and application of historical task models, characterized in that, The system is used to implement the method for generating a historical task model according to any one of claims 1-9, the system comprising: The log parsing module collects ERP operation logs, extracts and parses records of field reading, updating and condition judgment, calculates the field triggering order, analyzes and judges multiple triggers of the same field within a transaction, generates a field triggering behavior sequence and passes it to the dependency analysis module. The dependency analysis module, based on the field-triggered behavior sequence, combines them by field identifier, counts the frequency of sequential occurrence of fields and the frequency of recurrence within a time window, calculates the confidence of field combinations and compares the field combinations, generates field-triggered dependency results and passes them to the relation modeling module. The relationship modeling module performs a structured mapping between field combinations and corresponding confidence levels based on the field-triggered dependency results. It uses the confidence level as the dependency strength and maps and sorts it. It records zero values ​​for field groups with no dependency relationship, generates field-triggered relationship data, and passes it to the task construction module. The task construction module obtains the business attribute descriptions of ERP fields, analyzes the dependency distribution of the same business semantic fields in the field trigger relationship data, determines the level based on the dependency strength and determines the upper and lower level field identifiers, constructs the initial task model structure and passes it to the model correction module. The model calibration module acquires multiple task execution records, counts the number of field entry judgments, condition judgments, and result records, calculates the field state transition probability, calibrates the initial task model structure hierarchy, and generates a historical task model master.

Images