Adaptive workflow-based piecework data auditing processing system

Abstract

The present application relates to the field of data processing and enterprise production information management, in particular to a piecework reporting data auditing processing system based on adaptive workflow, which runs on a server and comprises the following modules: reporting access, collaborative task identification, workflow driving, suspension processing, token generation, context injection, wake-up reentry, auditing determination and result storage; receives piecework reporting data, parses task identification, performs idempotent check, and obtains expected number of collaborators; when no valid token is hit, creates and loads a workflow instance, suspends the instance and generates a token for writing into cache when neither the unique number of reporters nor the cumulative piecework quantity reaches the target; after subsequent reporting hits the token, injects collaborative context, updates the number of reporters and piecework quantity, wakes up the instance, generates auditing pass, exception or review results, and stores them; the present application realizes real-time merging and auditing of collaborative piecework reporting data, and reduces pseudo-exception caused by unified waiting.

Description

Technical Field

[0001] This invention relates to the field of data processing and enterprise production information management, specifically to a piecework reporting data review and processing system based on adaptive workflow. Background Technology

[0002] As intelligent manufacturing and production execution management systems continue to develop, handheld terminals, workstations, and edge data collectors are being used on production sites, increasing the demand for real-time collection and verification of piecework data. In multi-person collaborative work scenarios, multiple workers submit work data for the same task, creating a technical need in the production management field to aggregate and verify multi-source collaborative work data.

[0003] Traditional piecework reporting data verification currently relies mainly on the following methods: independent verification of each reporting entry, setting a fixed waiting window at the access point, and piecing together reporting records by polling the business database.

[0004] However, methods such as independent review of individual work reports, fixed waiting windows, and polling and stitching of business databases all have certain drawbacks. For example, independent review of individual work reports is difficult to identify collaborative tasks involving multiple people and is prone to generating false anomalies when subsequent work reports have not yet arrived; fixed waiting windows require delaying all work report requests and are difficult to adapt to differences in the arrival of different tasks and processes; polling and stitching of business databases has the problem of processing latency exceeding preset thresholds and data overwriting during concurrent updates, and lacks a mechanism for absorbing subsequent work report data from running workflow instances. Summary of the Invention

[0005] The purpose of this invention is to provide a piecework report data review and processing system based on adaptive workflow, avoiding false anomalies caused by single work report review or data overwriting due to polling and splicing, and absorbing subsequent data to achieve accurate merging and review of collaborative tasks. This invention can be achieved through the following technical solution: A piecework report data review and processing system based on adaptive workflow, running on a server, includes: a work report access module for receiving piecework report data and parsing it to obtain task identifiers; a collaborative task identification module for obtaining the expected number of collaborators corresponding to the task identifier to identify collaborative tasks; a workflow driving module for creating a current workflow instance and loading the piecework report data when no valid token is matched in the cache, and sending it to the context injection module when a valid token is matched; and a suspension processing module for statistical analysis of the current piecework report data. The workflow instance's execution is paused and placed in a wakeable suspended node awaiting subsequent data when the current number of unique workers reporting is less than the expected number of collaborators and the cumulative number of workers reporting is less than the standard task quantity corresponding to the task identifier. The following modules are used: a token generation module to generate tokens based on task identifiers and write them to the cache; a context injection module to append subsequent work reports to the current workflow instance and update the collaboration context data structure when a task identifier match; a wake-up and re-entry module to wake up the current workflow instance in the wakeable suspended node after the collaboration context data structure update; an audit judgment module to generate audit results based on the collaboration context data structure; and a result storage module to associate the audit results with the task identifier and store them as work reports in the business database.

[0006] Preferably, the work reporting access module performs idempotency verification after parsing and obtaining the task identifier; the token generated by the token generation module contains the task index, workflow instance identifier, and validity period, which are used for subsequent work reporting data to be indexed and matched by the task identifier; when the task identifier of subsequent work reporting data matches the task index in the cache, the context injection module appends the operator identifier and piecework quantity of the subsequent work reporting data to the current workflow instance to update the collaborative context data structure containing the number of work reports and the piecework quantity; the review and judgment module generates a review result of approval, exception, or review based on the completeness of the number of work reports and the piecework quantity in the updated collaborative context data structure.

[0007] Preferably, the piecework reporting data includes at least the operator's identifier, piecework quantity, server arrival time, process number, and batch identifier; the collaborative task identification module obtains the expected number of collaborators corresponding to the task identifier according to the priority order of the team operation template, production plan schedule, and historical collaborative reporting records.

[0008] Preferably, the collaborative task identification module determines a collaborative task as such when either the expected number of collaborators is not less than two or the historical frequency of joint reporting within a specified period reaches a preset collaborative task identification threshold. The workflow driving module queries the cache for valid tokens. If the token's validity period has not expired, it is determined to be a valid token and connected to the context injection module. If no token is found or the token has expired, it is connected to the token generation module.

[0009] Preferably, when the suspension processing module determines that neither the current number of unique workers nor the cumulative number of workers has reached the target, it generates a suspension command to keep the current workflow instance in its current state and release computing resources; otherwise, it changes the current workflow instance's state to "under review" and sends it to the review and judgment module for processing.

[0010] Preferably, it also includes a parameter adjustment module. The parameter adjustment module obtains the arrival time difference of historical collaborative work reports according to the work process category, calculates the target duration based on the average arrival delay, delay dispersion and expected number of collaborative workers, and truncates the target duration in combination with the preset upper and lower limits to determine the token validity duration. When the number of newly added historical collaborative work reports reaches the update threshold, the parameter adjustment module re-triggers the calculation and replacement of the token validity duration.

[0011] Preferably, the piecework reporting data also includes a rework round identifier; the token generation module establishes a cache index with the task identifier, process number, and batch identifier as mandatory fields, and adds the rework round identifier to the cache index when it identifies that the piecework reporting data contains a feature value indicating rework; the context injection module matches and locates the corresponding current workflow instance based on the batch identifier, rework round identifier, and task identifier to isolate reporting data from different shifts, batches, or rework rounds.

[0012] Preferably, the work reporting access module generates an idempotent identifier based on the worker identifier, task identifier, piecework quantity, and server arrival time of the piecework reporting data using a hash algorithm, and compares the idempotent identifier with an existing idempotent identifier in the cache; if the idempotent identifier does not exist, the piecework reporting data is allowed to pass and the idempotent identifier is stored in the cache; if it exists, the piecework reporting data is intercepted and injection is rejected, and a duplicate work reporting log record containing the interception time is generated and stored separately.

[0013] Preferably, the token also contains a version number with an initial value of zero; the context injection module reads the current version number of the current workflow instance, updates the current version number to the version incremented by 1 by comparison and exchange; if the version number update is successful, the work report data injection is completed; if the version number update fails, the latest version number of the current workflow instance and the collaboration context data structure are read again and the injection verification is performed again; when the number of retries reaches the preset limit, the injection is terminated and a concurrency conflict exception is thrown.

[0014] Preferably, the wake-up and re-entry module generates a wake-up command when any one of the following three conditions is met: the number of current unique workers reaches the expected number of collaborators, the cumulative number of workers reaches the standard task quantity, or the token validity period expires. It remains suspended if none of the three conditions are met. The review and judgment module generates an integrity score based on multi-dimensional features including the number of workers, piecework quantity, and token validity period. The integrity score is obtained by weighting and summing the ratio of the current unique worker count to the expected number of collaborators, the ratio of the cumulative number of workers to the standard task quantity, and the ratio of the remaining token validity period to the token validity period, respectively, according to the weights of the number of workers, quantity, and validity period. The review and judgment module generates an approval result when there are no inconsistencies in process numbers among the work reports in the collaborative context data structure, and the integrity score reaches a preset pass threshold. It generates an abnormal result when the integrity score is lower than a preset abnormal threshold, and a review result when the integrity score is greater than or equal to the preset abnormal threshold but less than the preset pass threshold.

[0015] The beneficial technical effects of this invention are as follows:

[0016] 1. This invention receives and parses piecework reporting data containing operator identifiers, task identifiers, piecework quantity, server arrival time, process number, and batch identifier. It then identifies collaborative tasks and expected number of collaborators according to the priority of team work templates, production schedule tables, and historical collaborative reporting records. This effectively improves the accuracy of identifying multi-person collaborative tasks and reduces false anomalies caused by subsequent reporting not yet arriving.

[0017] 2. This invention creates a workflow instance for the first work request that does not hit a valid token, and places the workflow instance in a wakeable suspended node when neither the number of unique work requests nor the cumulative piece count reaches the corresponding target. At the same time, a token containing the task index and workflow instance identifier is generated and written to the cache, so that subsequent work requests can directly hit and be injected into the suspended workflow instance, avoiding the need to set a uniform waiting window for all work requests, reducing entry blocking and processing latency.

[0018] 3. This invention statistically analyzes the historical collaborative work reporting arrival time difference according to work process category, and adaptively determines the token validity period by combining the average arrival delay, delay dispersion, expected number of collaborators, and preset upper and lower limits of time, so that the waiting range can adapt to the differences in work reporting arrival time of different work processes and number of collaborators. Attached Figure Description

[0019] The above and other objects, features and advantages of the present invention will become clearer from the following description of embodiments of the invention with reference to the accompanying drawings, in which:

[0020] Figure 1This is a schematic diagram of the structure of the piecework reporting data review and processing system based on adaptive workflow provided in the embodiments of this application.

[0021] Figure 2 This is a flowchart of the piecework reporting data review and processing method provided in the embodiments of this application.

[0022] Figure 3 This is a schematic diagram of workflow instance state transitions provided in the embodiments of this application. Detailed Implementation

[0023] To make the above and other objects, features and advantages of the present invention more apparent and understandable, preferred embodiments will be described in detail below with reference to the accompanying drawings.

[0024] Please see Figure 1 This is a piece-rate work report data review and processing system based on adaptive workflow, running on a server. It includes: a work report access module for receiving piece-rate work report data and parsing it to obtain task identifiers; a collaborative task identification module for obtaining the expected number of collaborators corresponding to the task identifier to identify collaborative tasks; a workflow driving module for creating a current workflow instance and loading piece-rate work report data when no valid token is matched in the cache, and sending it to the context injection module when a valid token is matched; a suspension processing module for calculating the current unique work report count and cumulative work report count of the current workflow instance based on the piece-rate work report data, pausing the execution of the current workflow instance and placing it in a wakeable suspended node waiting for subsequent data when the current unique work report count is less than the expected number of collaborators and the cumulative work report count is less than the standard task count corresponding to the task identifier; a token generation module for generating tokens based on the task identifier and writing them to the cache; and a context injection module for appending subsequent work report data to the current workflow instance when a task identifier match is found. The workflow instance updates the collaborative context data structure; the wake-up and re-entry module wakes up the current workflow instance in the wakeable suspended node after the collaborative context data structure is updated; the review and judgment module generates review results based on the collaborative context data structure; the result storage module associates the review results with the task identifier and stores them as work reports in the business database; the work report access module performs idempotency verification after parsing the task identifier; the token generation module generates a token containing the task index, workflow instance identifier, and validity period, which is used for subsequent work report data to be indexed and matched using the task identifier; the context injection module appends the operator identifier and piecework quantity of the subsequent work report data to the current workflow instance when the task identifier of the subsequent work report data matches the task index in the cache, so as to update the collaborative context data structure containing the number of work reports and the piecework quantity; the review and judgment module generates review results of approval, exception, or review based on the completeness of the number of work reports and the piecework quantity in the updated collaborative context data structure.

[0025] Piecework reporting data includes at least the operator's identifier, piecework quantity, server arrival time, process number, and batch identifier. The collaborative task identification module obtains the expected number of collaborators corresponding to the task identifier according to the priority order of the team operation template, production plan schedule, and historical joint reporting records. The collaborative task identification module determines a task as a collaborative task if either the expected number of collaborators is not less than two or the historical joint reporting frequency within a specified period reaches the preset collaborative task identification threshold. The workflow-driven module queries the cache for valid tokens. If the token's validity period has not expired, it is determined to be a valid token and connected to the context injection module. If no token is found or the token has expired, it is connected to the token generation module.

[0026] In this implementation, the server receives structured work reports submitted by the terminal through a network interface. The reports use a field-based data format and include at least the task identifier, worker identifier, piecework quantity, server arrival time, process number, and batch identifier. The system first performs task identifier parsing and idempotency verification on the access side, and then identifies whether it belongs to a collaborative task based on the task identifier. For the first work report that fails to find a valid token, a workflow instance is created and the current work report context is loaded, and then the system proceeds to determine whether to suspend the task. Only when the instance is initially determined to need to wait for subsequent members will a token be generated and written. Cache; for subsequent work reports with a valid token, directly inject them into the suspended workflow instance; if neither the current number of unique work reports nor the cumulative number of work reports reaches the expected target, transfer the workflow instance to a wakeable suspended node and generate a token to be written to the cache; after subsequent data arrives and the context is updated, wake up the workflow instance for re-review, and finally output the review pass, exception, or re-review result, and write the result to the business database after associating it with the task identifier. The above processing flow of receiving work reports, querying valid tokens, creating workflow instances, injecting collaborative context, suspending and generating tokens, and review judgment is as follows: Figure 2 As shown.

[0027] The aforementioned implementation process of connecting the unfounded token or expired token to the token generation module includes: creating a workflow instance triggered by the first work report, and generating a token when the instance is determined to be suspended to receive subsequent work report data; wherein, the reviveable suspended node refers to the state in which the workflow instance has retained the task context but released the processing resources currently occupied by the execution, such as the workflow temporarily not continuing to advance the review node, and only retaining key contexts such as instance identifier, current number of work reports, and current cumulative piece count.

[0028] The collaborative context data structure refers to a data set that gradually converges around the same task identifier, such as a set of work reports submitted by multiple workers in the same batch or under the same process. Unlike the method of setting a fixed waiting window at the access point, this implementation suspends task instances that need to wait for subsequent members to arrive and absorbs subsequent work reports according to the task. Thus, the same collaborative task is merged and reviewed based on workflow instance suspension and subsequent data injection, so as to provide a mechanism for running instances to absorb subsequent data.

[0029] Furthermore, piecework reporting data is obtained, and the piecework reporting data is parsed according to the field definitions in the terminal submission message to generate the current reporting object; the task identifier is used to identify the work order, process segment or collaborative task to which the reporting data belongs; the server arrival time refers to the timestamp recorded when the reporting data enters the server-side access channel, which is used to uniformly compare the order of arrival.

[0030] In practice, the server can receive work messages through the Hypertext Transfer Protocol interface or message access channel. After the message enters the access module, it is first deserialized into a memory object, and then the task identifier is extracted as the basic field for subsequent cache index and workflow addressing.

[0031] This implementation retains the task identifier, process number, and batch identifier in the memory context for subsequent collaborative identification and instance merging. Furthermore, the task identifier is obtained, and collaborative task identification is performed based on the priority order of the team operation template, production plan scheduling table, and historical joint work reporting records to determine the expected number of collaborative personnel.

[0032] The expected number of collaborators refers to the number of personnel who should participate in reporting work under normal production conditions; the team work template is used to describe the typical collaboration mode of fixed processes; the production plan scheduling table is used to reflect the temporary work organization in the current production batch; historical collaborative reporting records are used to supplement and identify long-term stable collaboration modes when the template and schedule are not explicitly configured.

[0033] The system determines the expected number of collaborators for each task identifier. When the work group template or production schedule has given the number of collaborators, the configuration is directly used as the expected number of collaborators. When the template and schedule do not give the number of collaborators directly, but the historical frequency of joint reporting within a specified period reaches the collaborative task identification threshold, the system continues to extract the stable number of joint reporting workers for the same type of task from the historical joint reporting records, and supplements the expected number of collaborators for the current task accordingly, preferably using the number of joint reporting workers that appears most frequently within the period.

[0034] If there are two or more common worker reports with the same frequency, the common worker report with the largest value shall be selected as the expected number of collaborators; if the final number is still less than two, then it shall be determined as at least two.

[0035] Historical joint reporting frequency is used to identify collaborative tasks, and stable joint reporting number is used to supplement the personnel benchmark required for subsequent review, so as to provide a personnel reference for subsequent suspension judgment, integrity judgment and wake-up control; historical joint reporting frequency is used to characterize the stability of the same task being jointly submitted by multiple operators in the actual workshop; collaborative task identification threshold is used to prevent occasional proxy reporting, temporary helper and other noise behaviors from being mistakenly identified as normal collaborative mode.

[0036] The specified period is a pre-defined historical collaborative work reporting data statistical time period, such as the past 7 days or the past 30 days, used to define the data extraction range of historical collaborative work reporting records; the preset collaborative task identification threshold can be determined by a fixed value pre-entered in the system configuration interface, or by extracting the average collaborative work reporting frequency of similar tasks within the specified historical period. The specific mathematical mapping function is dynamically determined as follows: ;in, Identify thresholds for collaborative tasks. The frequency adjustment coefficient preset by the system and (0,1]; This is the rounding up operator; therefore, based on the priority order, the expected number of collaborators is obtained, and the expected collaborative task parameters are determined by combining this with the historical frequency of joint work reporting.

[0037] Furthermore, the current workflow object is obtained, and a valid token is retrieved from the cache based on the task identifier. Workflow routing is performed on the current workflow object to determine whether to create a new workflow instance or inject an existing workflow instance. The cache stores tokens corresponding to workflow instances in a suspended state. The token contains at least the task index, workflow instance identifier, and validity period. A valid token refers to a cache record whose validity period has not expired and which can address the corresponding suspended workflow instance. The workflow instance identifier is used to locate the reference to the created instance within the workflow engine.

[0038] In the specific implementation, the workflow driver module performs a cache lookup on the task identifier. If no token is found or the token has expired, the current work request is regarded as the first triggering data. The workflow initialization function is called first to create and load the current workflow instance. Then, the decision on whether to continue into the token generation and suspension path is based on whether the current context is incomplete. If a valid token is found, the current work request object will not create a workflow instance again, but will instead be transferred to the context injection module. Thus, subsequent work request data is injected by hitting the existing instance through the cached token.

[0039] Furthermore, the set of reported work items in the current workflow instance is obtained. Based on the unique operator identifier and the cumulative piece count, the completeness of the current workflow instance is initially judged, and a suspension instruction or a review continue instruction is generated. The number of unique reported work items refers to the number of operators after deduplication in the same task context. The cumulative number of reported work items refers to the sum of the piece count of all reported work items in the current context. The standard task quantity refers to the piece count completion target that the task should achieve under the process configuration.

[0040] The system maintains a set of collaborative contexts formed around the same task identifier and continuously counts the current number of unique workers reporting and the current cumulative number of workers reporting. At the same time, it reads the expected number of collaborators and the standard number of tasks from the process configuration. If the current number of workers reporting does not reach the expected number of collaborators and the current cumulative number of workers reporting is lower than the standard number of tasks, it is determined that the current context is incomplete, the workflow instance is paused and placed in a wakeable suspended node. The system separates the incomplete set state and the abnormal quantity state by concurrently monitoring the number of workers reporting and the piece count.

[0041] Furthermore, the task identifier and the current workflow instance identifier are obtained. Based on the subsequent absorption requirements, a token is generated for the current workflow instance to determine the cached content. The task index in the token is used for subsequent work reports to hit the instance according to the task identifier. The workflow instance identifier is used to restore the cache hit result to a wakeable instance within the workflow engine. The effective duration is used to limit the absorption range during which the instance is allowed to continue waiting for subsequent work reports.

[0042] In practical implementation, the token object should at least store the task identifier, the workflow instance context addressing identifier, and the token's validity duration. Additionally, the version number and task metadata summary can be stored as internal attributes of the token object for subsequent concurrency control and task isolation. After the token is written to the cache, the cached item remains queryable throughout its lifecycle. It is retained even after the token is read and the addressing is completed, until the workflow is awakened and ultimately ends or the token expires. Thus, by storing instance addressing information through token caching, subsequent work requests can be located without scanning the business database.

[0043] Furthermore, subsequent work reporting data is obtained, and context injection is performed on the current workflow instance based on the matching results between the task identifier and the task index in the cache, updating the collaborative context data structure. Context injection is not simply overwriting old data, but rather appending the worker identifier and piecework quantity from the subsequent work reporting data to the work reporting set maintained by the current workflow instance. The updated collaborative context data structure is still organized around the same task identifier and continues to store the number of reported workers and the cumulative quantity.

[0044] In the specific implementation, if the subsequent work report data hits the token, the work report data will be merged into the pre-injection context set to form the post-injection context set. That is, without creating a new process instance, the asynchronously arriving work report data will be merged into the same task review data set. After the update is completed, the system will re-count the number of unique operators and the cumulative piece count, and write the new statistical results back to the memory context of the current workflow instance.

[0045] Furthermore, the updated collaborative context data structure is obtained, and based on the re-statistical number of reported workers and the cumulative number of pieces, the suspended workflow instances are re-entered and reviewed, and review results are generated. The re-entry process sends a continue execution instruction to the instance that has been placed in the re-enterable suspended node, so that the instance re-enters the review decision path. The review results include approval, exception, or review.

[0046] After being woken up, the system recalculates the completeness of the reported number of workers and piecework quantity, and checks whether the current context is consistent with fields such as process number and batch identifier. If the recalculation meets the passing conditions, the system directly generates an approval result. If the current context does not reach the preset completeness threshold or there is a process number inconsistency, an exception or review result is generated. The review result is associated with the task identifier and written to the business database as a work report record. Data storage operations are performed after the workflow instance forms the final result. Thus, the review process is executed after the context is updated.

[0047] As an application implementation method, this implementation method can be deployed in the production execution management server. The access layer continuously receives work reporting messages from handheld terminals, workstations, or edge collectors. The first work reporting triggers the creation of a workflow instance and is suspended if necessary. Subsequent work reporting is injected into the instance after the corresponding token is hit by the task index in the cache. After the instance is awakened, it completes the re-review and finally writes the review approval, exception, or review result to the business database. The result is then provided to the payroll calculation, process tracking, or review interface. Thus, after new work reporting data enters the system, it can automatically trigger review and result update along the predetermined path, meeting the deployment requirements of actual workshop collaborative piece-rate scenarios.

[0048] In this embodiment, when the suspension processing module determines that neither the current number of unique workers nor the cumulative number of workers has reached the target, it generates a suspension command to keep the current workflow instance in its current state and release computing resources. Otherwise, it changes the current workflow instance's state to "under review" and sends it to the review and judgment module for processing.

[0049] It also includes a parameter adjustment module, which obtains the arrival time difference of historical collaborative work reports according to the work process category, calculates the target duration based on the average arrival delay, delay dispersion and expected number of collaborators, and truncates the target duration with preset upper and lower limits to determine the token's valid duration; when the number of newly added historical collaborative work reports reaches the update threshold, the parameter adjustment module re-triggers the calculation and replacement of the token's valid duration; piecework work reports also include rework round identifiers.

[0050] The token generation module establishes a cache index with task identifier, process number, and batch identifier as required fields. When it identifies that piecework reporting data contains feature values ​​indicating rework, it adds the rework round identifier to the cache index. The context injection module matches and locates the corresponding current workflow instance based on the batch identifier, rework round identifier, and task identifier to isolate reporting data from different shifts, batches, or rework rounds.

[0051] In this implementation, the system does not simply decide to suspend based on a single number of people. Instead, it simultaneously calculates the ratio of the current number of unique workers to the expected number of collaborators, and the ratio of the cumulative number of workers reported to the number of standard tasks, and makes a combined judgment: only when both ratios are less than 1, the current workflow instance remains in its original state and enters suspension, while releasing the current computing resources; otherwise, the instance status is directly changed to under review. At the same time, the system maintains historical collaborative work arrival time difference samples by work process category, calculates the average arrival delay and delay dispersion, and determines the token validity period in combination with the expected number of collaborators, so that the waiting range under different work processes and different number of collaborators can be adjusted.

[0052] For rework scenarios, the cache index adds a rework round identifier, which, together with the task identifier, process number, and batch identifier, forms the location conditions. This is used to isolate the reporting data of different shifts, batches, or rework rounds to their respective corresponding workflow instances. Among them, releasing computing resources means that after suspension, the current execution thread will no longer be continuously occupied, and only the necessary context of the instance will be retained. The rework round identifier is a field used to distinguish the rounds between the first production and subsequent rework of the same task. For example, the first production is one round, and the reprocessing after quality inspection is returned is another round.

[0053] This implementation method performs layered processing of suspension timing, waiting time, and instance location based on task characteristics; thereby, collaborative work reporting and review are carried out based on dual-ratio suspension determination, adaptive duration, and composite index isolation.

[0054] When calculating the validity period of the token, the parameter adjustment module only counts the arrival time difference of historical collaborative work reports under the same work process category. The time difference is obtained by the difference between the timestamps of two adjacent collaborative work reports arriving at the server. The average arrival delay is used to characterize the normal waiting time, the delay dispersion is used to characterize the arrival fluctuation range, and the coefficient is used to linearly amplify the waiting time with the expected number of collaborative workers.

[0055] If the target duration exceeds the preset duration upper limit, which refers to the maximum waiting time allowed by the system (e.g., 15 minutes), the duration will be truncated at the upper limit. If it is lower than the preset duration lower limit, which refers to the minimum waiting time enforced by the system (e.g., 1 minute), the duration will be truncated at the lower limit. The update threshold refers to the number of historical new samples required to trigger the recalculation of the valid duration of the trigger token (e.g., 100 new samples will trigger the replacement). This can be triggered when the historical samples are accumulated enough to cover the common fluctuation range of the process category.

[0056] For rework round identifiers, if the work report contains a rework reason code, rework mark, or rework count field, the system determines that it indicates a rework and then incorporates the rework round identifier into the cache index to avoid cross-hitting of the first instance and the rework instance; the above-mentioned suspension determination, effective duration setting, and rework isolation are implemented through corresponding data sources and feature rules.

[0057] Specifically, the suspension processing module first reads the current number of unique workers, the expected number of collaborators, the cumulative number of reported workers, and the number of standard tasks, and then calculates the ratio of the number of workers and the ratio of the number of tasks respectively. The ratio of the number of workers is equal to the current number of unique workers divided by the expected number of collaborators, and the ratio of the number of tasks is equal to the cumulative number of reported workers divided by the number of standard tasks. The system uses a ratio of the number of workers and a ratio of the number of tasks that are both less than 1 as the only suspension condition. As long as either ratio is not less than 1, the system writes the status of "under review" to the workflow engine and sends a review continuation instruction.

[0058] To avoid the inability to calculate when the standard task quantity or expected number of collaborators is zero, the system will directly mark the corresponding ratio as satisfied when the configuration value is zero, without triggering the suspension condition for that dimension. For example, when the expected number of collaborators is 3, the current number of unique workers is 2, the standard task quantity is 100, and the cumulative number of workers is 60, the two ratios are respectively... If the cumulative number of work reports reaches 100, even if the number of unique work reports is still 2, the quantity ratio reaches 1, and the instance will be put into review.

[0059] The parameter adjustment module filters historical collaborative work reports according to work process category, and uses the difference in server arrival time of two adjacent work reports in the same collaborative task as a time difference sample. The filtered samples are accumulated one by one and divided by the number of samples to obtain the average arrival delay. Then, the average of the squares of the deviations between each sample and the average arrival delay is calculated and the square root is taken to obtain the delay dispersion.

[0060] Target duration Based on average arrival delay Adding delay dispersion The result is calculated by multiplying the expected number of collaborators N by the number coefficient k. The mathematical formula is as follows: ×N×k; After the calculation is completed, if the target duration is less than the preset lower limit, the preset lower limit is used; if it is greater than the preset upper limit, the preset upper limit is used; otherwise, the target duration is used directly.

[0061] When the number of new samples reaches the update threshold, the sample set containing the new samples is used to recalculate, and the truncated result is replaced with the validity duration of subsequent new tokens. Tokens that have already been generated and are waiting continue to use the validity duration saved when they were generated. For example, if the average arrival delay of a certain process is 4 minutes, the delay dispersion is 1 minute, the expected number of collaborators is 3, and the number coefficient is 0.5, then the target duration is 7.5 minutes. If the preset lower limit is 5 minutes and the upper limit is 10 minutes, then the validity duration of the token is determined to be 7.5 minutes.

[0062] In practice, the number of people coefficient is given in advance by the process category configuration table. Its dimension is human⁻¹, i.e., 1 / person, which is used to eliminate the dimension of the expected number of people to collaborate and participate in the calculation as a non-negative number. When there are no historical time difference samples for the same process category, the initial average arrival delay and initial delay dispersion in the process category configuration table are used, both of which are saved in time units. When the number of samples is insufficient to calculate the standard deviation, the delay dispersion is set to zero. Time difference samples that are zero or negative are not included in the statistics to avoid server time anomalies causing the effective duration to exceed the preset duration limit.

[0063] For the cache index, the system first concatenates the required fields in a fixed order of task identifier, process number, and batch identifier, and then uses field separators to form the basic index. When the message contains any rework characteristic value in the rework reason code, rework mark, or rework count field, the rework round identifier is then appended in the same order.

[0064] If no rework feature value is identified, no rework round identifier is added. The first production report can only be matched with the first production instance that also has no rework round identifier added. When a rework feature value is identified, only production reports with the same task identifier, process number, batch identifier, and rework round identifier can match the corresponding token.

[0065] Before matching, the context injection module compares each of the above fields. If any required field is inconsistent, it is determined as a miss, thus preventing data from different batches, different processes, or different rework rounds from entering the same workflow instance. When concatenating fields, each field is length-encoded before writing the field value, and they are combined in a fixed order. Therefore, even if the task identifier contains field separators, it will not cause ambiguity in the index boundaries. When the rework feature value does not exist, the first-order index format is used. When the rework feature value exists but the rework round identifier is empty, it is determined as an invalid index and injection is rejected.

[0066] In this embodiment, the work reporting access module generates an idempotent identifier based on the worker identifier, task identifier, piecework quantity, and server arrival time of the piecework reporting data using a hash algorithm. The idempotent identifier is then compared with an existing idempotent identifier in the cache. If the idempotent identifier does not exist, the piecework reporting data is allowed to proceed and the idempotent identifier is stored in the cache. If the idempotent identifier exists, the piecework reporting data is intercepted and injection is rejected. At the same time, a duplicate work reporting log record containing the interception time is generated and stored separately.

[0067] The token also contains a version number with an initial value of zero; the context injection module reads the current version number of the current workflow instance, updates the current version number to the version incremented by 1 by comparison and swapping; if the version number update is successful, the work report data injection is completed; if the version number update fails, the latest version number of the current workflow instance and the collaboration context data structure are read again and the injection verification is performed again. When the number of retries reaches the preset limit, the injection is terminated and a concurrency conflict exception is thrown.

[0068] The wake-up and re-entry module generates a wake-up command when any one of the following conditions is met: the number of current unique workers reaches the expected number of collaborators, the cumulative number of workers reaches the standard number of tasks, or the token's validity period expires. If none of the three conditions are met, the module remains suspended.

[0069] The review and judgment module generates an integrity score based on multi-dimensional features including the number of reported workers, piecework quantity, and token validity period. The integrity score is obtained by weighting and summing the ratio of the current unique number of reported workers to the expected number of collaborators, the ratio of the cumulative number of reported workers to the number of standard tasks, and the ratio of the remaining validity period of the token to the validity period of the token, respectively, according to the weight of the number of workers, the weight of the quantity, and the weight of the validity period. The review and judgment module generates an approval result when there are no inconsistencies in the process numbers among the reported work data in the collaborative context data structure, and the integrity score reaches the preset pass threshold. It generates an abnormal result when the integrity score is lower than the preset abnormal threshold, and generates a review result when the integrity score is greater than or equal to the preset abnormal threshold and less than the preset pass threshold.

[0070] In this implementation, the access module generates an idempotent identifier based on the worker identifier, task identifier, piecework quantity, and server arrival time, and performs an existence comparison in the cache to intercept duplicate work reports caused by terminal retries, network retransmissions, or repeated clicks. For duplicate arrival requests submitted for the same service, the system reuses the server arrival time in the initial acceptance record for hashing to ensure that the same service submission generates the same idempotent identifier. For subsequent injections of suspended workflow instances, the token contains a version number with an initial value of zero. During injection, the version number is updated by comparison and exchange to ensure that multiple subsequent work reports do not overwrite each other when they arrive concurrently.

[0071] After each injection, the wake-up and re-entry module decides whether to wake up the workflow instance based on one of three conditions: the number of people reaches the expected level, the quantity reaches the standard level, or the token expires. The review and judgment module then performs a weighted summation of the context integrity, piecework quantity completion rate, and remaining valid token duration to form an integrity score, and outputs the review pass, exception, or re-review result in conjunction with the process number conflict detection. Among these, the idempotency identifier refers to a unique digest used to identify whether the same work report has been received and processed by the system. The compare and swap refers to the atomic update method that allows writing to the new version only when the current version number is consistent with the expected old version.

[0072] This implementation method performs duplicate reporting control at the access layer and cache layer, and performs concurrent consistency control at the instance injection stage; thus, it performs multi-person collaborative reporting review under concurrent conditions based on idempotency verification, version control, and scoring judgment.

[0073] Furthermore, the operator identifier, task identifier, piecework quantity, and server arrival time are obtained from the piecework report data. Based on the hash algorithm, the piecework report data is subjected to idempotency calculation to generate an idempotency identifier. The idempotency identifier refers to the digest value that uniquely merges the same work report request. The server arrival time is used to distinguish the reception time of different requests entering the system, thereby avoiding the incorrect merging of different work reports. In specific implementation, the server arrival time participating in the hash calculation is preferably the reception timestamp written by the access module when the work report request is first accepted.

[0074] For the same work request caused by terminal timeout retransmission, link retransmission, or repeated page submission, the access module first checks whether there is a corresponding first acceptance record based on the work personnel identifier, task identifier, piece count quantity, and other business loads and existing transmission request association information. When it is determined that it belongs to the same business submission, the server arrival time in the first acceptance record is reused for idempotency calculation, instead of being replaced by the receiving time point regenerated when the repeated arrival occurs.

[0075] For new requests that cannot be confirmed to belong to the same business submission, the idempotency identifier is calculated using the server arrival time written during the initial acceptance. In this way, the server arrival time can distinguish between different work submission requests, and the idempotency input will not be artificially changed due to repeated arrivals of the same request. The hash algorithm used is, for example, Message Digest Algorithm Version 5, Secure Hash Algorithm 1, or Secure Hash Algorithm 256, to generate the same result for the same input. Thus, an idempotency identifier is generated in the access module to identify duplicate work submission data.

[0076] Furthermore, the idempotency identifier of the current application is obtained, and the current application is compared with the existing set of idempotency identifiers in the cache to determine the release or blocking result; the set of idempotency identifiers in the cache refers to the set of application summaries that have been accepted by the system within the current validity period; the separately stored duplicate application log records refer to the record objects that do not enter the normal review process but retain the fact of blocking.

[0077] In its implementation, the piecework reporting module compares the current idempotent identifier with existing identifiers in the cache. If the identifier does not exist, the piecework reporting data is allowed, and the current idempotent identifier is written to the cache. If the identifier already exists, the piecework reporting data is intercepted and injection is rejected. At the same time, a duplicate reporting log record containing the interception time is generated and stored separately. The comparison and writing of the idempotent identifier adopts an atomic existence write operation on the cache side. That is, the write is completed and the allowance result is returned only when the current identifier does not exist, avoiding duplicate allowance after two concurrent requests query empty at the same time.

[0078] The interception time is used to record the system point at which duplicate requests are identified, which facilitates subsequent investigation of terminal retries, duplicate page submissions, or link jitter. After the idempotency flag is written to the cache, it participates in subsequent comparisons within its effective lifespan. It does not need to be deleted after the comparison is completed, and it can be left to expire naturally by the cache policy. Thus, duplicate requests are intercepted based on cache comparison.

[0079] Furthermore, the system retrieves the version number from the current token and the collaboration context data structure of the current workflow instance. Based on the comparison and exchange rules, it performs concurrent injection control on the current workflow instance to determine whether the injection is successful. The version number in the token is initially zero and is used to mark the number of times the workflow instance has been successfully updated. The comparison and exchange rules require that the next version can only be written if the old version number read matches the current actual version number of the instance. Before the current thread starts injection, it reads the instance status sequence number and the collaboration context data structure, and forms the update context to be written based on the reading result. The system verifies the old version number through the same atomic update operation, updates the status sequence number to the next sequence number, and submits the complete collaboration context containing the newly added work report data.

[0080] If the comparison is successful, the current thread gains the right to update the instance, completes the injection of the work data, and submits the new version. If the comparison fails, it means that another thread has already completed the update. The current thread must not write to the original context, but instead rereads the latest version number and the collaborative context data structure, and performs the injection verification and update again. When the number of retries reaches the preset limit, the injection is terminated and a concurrency conflict exception is thrown. The preset limit is used to limit the retry consumption in abnormal concurrency scenarios, and its size can be set by the system according to the concurrency capacity. In a specific configuration, the preset limit is 3 times. After the first read fails, the latest version number and the latest collaborative context are used to reconstruct the data to be written. Thus, controlled update operations are performed through version number increment, comparison and exchange, and version number and context synchronous submission mechanism.

[0081] Furthermore, the system obtains the updated current number of unique workers reporting, the cumulative number of reported workers, and the token validity period status. Based on the wake-up conditions, it controls the wake-up of suspended workflow instances, generating a wake-up command or maintaining the suspended state. The wake-up conditions include three categories: the current number of unique workers reporting reaches the expected number of collaborators, the cumulative number of reported workers reaches the standard number of tasks, and the token validity period expires. A wake-up command is generated when any one of the three conditions is met. When all personnel have arrived, or the number of tasks has reached the standard, or the token waiting period has ended, the system will no longer maintain the suspension. When none of the above conditions are met and the token is still within the valid period, the suspended state is maintained.

[0082] The current number of unique work reports reflects the availability of personnel; the cumulative number of work reports reflects the amount of tasks completed; the expiration of the token's validity period indicates that the absorption interval during which the system allows waiting for subsequent members to arrive has ended, and a final judgment must be made; therefore, the above three conditions are used as the basis for triggering a wake-up to trigger a re-review of the workflow; when a wake-up is triggered by the token expiration, even if no new subsequent work reports arrive, the wake-up re-entry module will perform a final review based on the collaboration context of the most recent successful atomic submission in the current workflow instance; before issuing the wake-up command, the token is marked as pending closure or removed from the valid index, and subsequent data cannot be injected into the instance that has entered the final review.

[0083] When a wake-up is triggered by personnel or quantity conditions, the context to be reviewed is first determined based on the latest version of the read results, and then the instance status is changed to "under review". This avoids duplicate review or status rollback when wake-up and subsequent injection are executed concurrently. For subsequent work reports with expired tokens found in the cache, the workflow driver module does not inject the data into the original instance. Instead, it first checks whether the original instance is already under review or has been completed. Only after the original instance completes the final review and closes is the subsequent work report allowed to create a new workflow instance according to the path where no valid token was found.

[0084] If the original instance has not yet been shut down, the creation of the new instance is temporarily suspended, and the route verification is re-executed after the shutdown event. This ensures that the order between token expiration wake-up and expired token routing is maintained, preventing the same task from creating two valid audit instances simultaneously. The state transitions of the above workflow instance between creation, suspension, injection, wake-up, and audit, as well as the relationship between audit results (pass, review, or exception) are as follows: Figure 3 As shown.

[0085] Furthermore, the system obtains the current number of unique workers reporting, the expected number of collaborators, the cumulative number of reported workers, the number of standard tasks, and the remaining validity period of the token. Based on the weighted summation rule, it scores the collaboration context and generates an integrity score. Context integrity refers to the degree to which the current number of unique workers reporting is achieved relative to the expected number of collaborators. Piecework completion refers to the degree to which the cumulative number of reported workers is achieved relative to the number of standard tasks. The ratio of the remaining validity period of the token to the total validity period is used to characterize whether continuing to wait is still reasonable.

[0086] The remaining valid time ratio is used to represent the indicator weight for continuing to suspend pending judgment; the review and judgment module calculates the completeness score by weighting the above three indicators according to the preset weights. Each weight is used to balance the impact of the number of people in the set, the quantity achieved, and the remaining waiting space on the final review and judgment; specifically, the ratio of the current number of unique workers to the expected number of collaborators, the ratio of the cumulative number of workers to the number of standard tasks, and the ratio of the remaining valid time of the token to the total valid time are first limited to the range of 0 to 1, and then the weights of the number of people, the quantity, and the timeliness are multiplied by the corresponding ratios and then added together to obtain the completeness score; all three weights are non-negative and the weight sum is 1.

[0087] The integrity score uses a penalty mechanism for weighting, where the timeliness weight is multiplied by the percentage of lost time and deducted from the total score as a penalty. For example, the weight of the number of people is 0.4, the weight of the quantity is 0.4, and the weight of timeliness is 0.2. In a scenario where the current number of unique workers is 2, the expected number of collaborators is 3, the cumulative number of workers reported is 60, the number of standard tasks is 100, the remaining valid token time is 3 minutes, and the total valid time is 10 minutes, the three indicators are respectively... 0.6 and 0.3, with an integrity score of 0.4× +0.4×0.6+0.2×0.3, the calculated result is approximately 0.567.

[0088] The weights are determined according to the process category configuration table: Historical audit records are statistically analyzed by process category for automatic approval, exceptions, and review results. After meeting the preset minimum sample size, the weights are calculated in the range [0,1] with a preset step size. Weight of the number of people Quantity weight and timeliness weight Perform a grid search traversal with strict constraints. =1; For each weight combination, calculate the misclassification cost function in the historical samples: L= Among them, the loss function L covers all serious cross-boundary misjudgments, and the core term... This includes the number of times actual abnormal results were mistakenly converted to pass and the number of times review results were mistakenly converted to pass. This includes the number of times the actual pass result was mistakenly converted to an anomaly and the number of times the review result was mistakenly converted to an anomaly.

[0089] Select the set of weights that minimizes the cost function L. If multiple weight combinations exist that minimize L, then select the set that minimizes L. The combination with the largest value; when the sample is insufficient, the initial configuration is set with the number of people, quantity, and timeliness weights as 0.4, 0.4, and 0.2, respectively.

[0090] The weight update only applies to newly created instances or instances that have not yet entered the review process. Instances that have already entered the review process continue to use the weights read at the start of the review. As a result, the proportion of remaining valid time is introduced to prevent tasks that are still in a reasonable waiting period from being classified as abnormal prematurely. At the same time, the input, calculation and output of the scoring can be repeatedly calculated using the same set of data.

[0091] In practice, the context integrity, piece count completion rate, and token remaining validity period ratio are all limited to the range of 0 to 1: when the number of corresponding workers reaches the expected number of collaborators or the cumulative number of workers reaches the standard task quantity, the corresponding completion rate is 1; if not, the value is taken according to the actual degree of completion; the token remaining validity period ratio is compared with the total validity period determined when the token is generated, and the calculation result is limited to between 0 and 1.

[0092] The total valid duration is written when the token is generated and is a positive number; when the token has expired, the total valid duration is abnormal, or the token lacks a valid duration field, the remaining valid duration ratio is uniformly set to 0, and the wake-up audit is performed according to the expiration status; the three indicators are weighted using preset non-negative weights, and the sum of the three weights is 1, so the integrity score ranges from 0 to 1.

[0093] Both the pass threshold and the anomaly threshold are values ​​between 0 and 1, with the pass threshold being greater than the anomaly threshold. A completeness score that reaches the pass threshold indicates that the number of people, the number of items counted, and the waiting time comprehensively meet the automatic pass conditions. A score that is lower than the anomaly threshold indicates that the current task clearly does not meet the collaborative review requirements. A score that is between the two thresholds indicates that the data has a certain degree of completeness but still has uncertainties and needs to be transferred to a review.

[0094] The threshold and abnormal threshold are determined according to the process category configuration table: after the number of historical audit records reaches the preset minimum sample size, the lowest integrity score in the record will be automatically used as the candidate value for the pass threshold, and the highest integrity score in the abnormal record will be used as the candidate value for the abnormal threshold.

[0095] At least a preset review interval is maintained between candidate values. The preset review interval refers to the scoring difference range reserved for manual review, such as 0.1 or 0.15, to ensure the effectiveness of the review interval. If a candidate value does not meet the pass threshold and is greater than the abnormal threshold, the initial pass threshold of 0.8 and the initial abnormal threshold of 0.4 for the corresponding process category are adopted.

[0096] After the threshold and weight configuration is changed, it will only take effect on subsequent audit instances. Instances that have already entered the audit process will continue to use the parameters read at the start of the audit, so as to avoid the result drift of the same instance due to parameter changes during the audit process.

[0097] Furthermore, the process number in the integrity score and collaborative context data structure is obtained. Based on the conflict detection results and threshold comparison, the audit results are classified and judged to generate audit pass results, abnormal results, or review results. The process number inconsistency conflict refers to the difference in process number that should not be merged into the same task instance in the same collaborative context. The threshold and abnormal threshold are used to divide the scoring space into an automatic pass area, an abnormal area, and an intermediate review area.

[0098] In its implementation, the review and judgment module first checks whether there are any inconsistencies in the process numbers among the reported work data in the collaborative context data structure. If a conflict exists, even if the score is high, it will not be directly judged as passed, but will instead proceed to the review result. If there is no conflict, the integrity score will be compared with the preset pass threshold and the abnormal threshold. When the integrity score reaches the pass threshold, an approval result will be generated. When the integrity score is lower than the abnormal threshold, an abnormal result will be generated. When the integrity score is between the two thresholds, a review result will be generated.

[0099] The threshold represents the minimum integrity requirement that the system is allowed to pass automatically, and the abnormal threshold represents the numerical limit that triggers an abnormal result because the collaborative reporting data does not meet the collaborative review requirements; the range between the two is reserved for manual review or secondary review; thus, the final review result is generated based on conflict checking and scoring segments.

[0100] As an application implementation method, after deployment, the access channel first calculates the idempotency flag for each work report and compares it in the cache. Duplicate work reports are intercepted and written to the duplicate work report log. Non-duplicate work reports, after hitting the suspended token, enter the corresponding workflow instance through the injection path with the version number. If the injection is successful, the instance is woken up according to the number of people, quantity, or token expiration conditions, recalculates the integrity score, detects process number conflicts, writes the approval, exception, or review results to the business database, and provides the result data to the subsequent review interface or business status table to complete the review process in the actual production environment.

[0101] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A piece-rate work report data verification and processing system based on adaptive workflow, running on a server, characterized in that: include: The work reporting access module is used to receive piecework reporting data and parse it to obtain the task identifier; The collaborative task identification module is used to obtain the expected number of collaborators corresponding to the task identifier in order to identify the collaborative task; The workflow driving module is used to create the current workflow instance and load the piecework report data when the piecework report data does not match a valid token in the cache, and send it to the context injection module when a valid token is matched. The suspension processing module is used to count the current number of unique workers and the cumulative number of workers reported based on the piecework reporting data. When the current number of unique workers reported is less than the expected number of collaborators and the cumulative number of workers reported is less than the standard number of tasks corresponding to the task identifier, the execution of the current workflow instance is suspended and the current workflow instance is placed in a wakeable suspension node waiting for subsequent data. The token generation module is used to generate a token based on the task identifier and write it to the cache; The context injection module is used to append subsequent work reporting data to the current workflow instance and update the collaborative context data structure when the task identifier is matched. The wake-up reentrancy module is used to wake up the current workflow instance that is in a wakeable suspended node after the collaboration context data structure has been updated. The review and judgment module is used to generate review results based on the collaborative context data structure. The result storage module is used to associate the audit result with the task identifier and store it as a work report record in the business database.

2. The piecework reporting data verification and processing system based on adaptive workflow according to claim 1, characterized in that, The reporting access module performs idempotency verification after parsing and obtaining the task identifier. The token generated by the token generation module contains a task index, a workflow instance identifier, and a validity period, which are used for subsequent work reporting data to be indexed and matched using the task identifier. When the task identifier of subsequent work reports matches the task index in the cache, the context injection module appends the operator identifier and piece count of the subsequent work reports to the current workflow instance to update the collaborative context data structure containing the number of work reports and the piece count. The review and judgment module generates review results (approved, abnormal, or requiring review) based on the completeness of the reported number of workers and piecework quantity in the updated collaborative context data structure.

3. The piecework reporting data verification and processing system based on adaptive workflow according to claim 1, characterized in that, The piecework reporting data shall include at least the worker's identification, piecework quantity, server arrival time, process number, and batch identification. The collaborative task identification module obtains the expected number of collaborators corresponding to the task identifier according to the priority order of the team operation template, production plan schedule, and historical joint work reporting records.

4. The piecework reporting data verification and processing system based on adaptive workflow according to claim 1, characterized in that, The collaborative task identification module determines a collaborative task to be a collaborative task if either of the following conditions is met: the expected number of collaborative participants is not less than two, or the frequency of historical joint reporting within a specified period reaches a preset collaborative task identification threshold. The workflow driving module queries the cache for valid tokens. If the token's validity period has not expired, it is determined to be a valid token and connected to the context injection module. If no token is found or the token has expired, it is connected to the token generation module.

5. The piecework reporting data verification and processing system based on adaptive workflow according to claim 1, characterized in that, When the suspension processing module determines that neither the current number of unique workers nor the cumulative number of workers has reached the target, it generates a suspension command to keep the current workflow instance in its current state and release computing resources. Otherwise, it changes the current workflow instance's state to "under review" and sends it to the review and judgment module for processing.

6. The piecework reporting data verification and processing system based on adaptive workflow according to claim 1, characterized in that, It also includes a parameter adjustment module, which obtains the historical collaborative work arrival time difference according to the work process category, calculates the target duration based on the average arrival delay, delay dispersion and the expected number of collaborative workers, and truncates the target duration in combination with the preset upper and lower limits to determine the token's valid duration. When the number of newly added historical collaborative work reports reaches the update threshold, the parameter adjustment module re-triggers the calculation and replacement of the token's validity period.

7. The piecework reporting data review and processing system based on adaptive workflow according to claim 3, characterized in that, The piecework reporting data also includes rework round identifiers; The token generation module establishes a cache index with the task identifier, the process number, and the batch identifier as required fields, and adds the rework round identifier to the cache index when it detects that the piecework report data contains a feature value indicating rework. The context injection module matches and locates the corresponding current workflow instance based on the batch identifier, the rework round identifier, and the task identifier, so as to isolate the work reporting data of different shifts, batches, or rework rounds.

8. The piecework reporting data verification and processing system based on adaptive workflow according to claim 1, characterized in that, The work reporting access module generates an idempotent identifier based on the worker identifier, task identifier, piece count, and server arrival time of the piecework reporting data using a hash algorithm, and compares the idempotent identifier with an existing idempotent identifier in the cache. If the idempotency flag does not exist, the piecework report data is allowed and the idempotency flag is stored in the cache. If it exists, the piecework report data is intercepted and injection is rejected. At the same time, a duplicate report log record containing the interception time is generated and stored separately.

9. The piecework reporting data verification and processing system based on adaptive workflow according to claim 1, characterized in that, The token also contains a version number with an initial value of zero; The context injection module reads the current version number of the current workflow instance and updates the current version number to the version incremented by 1 by comparing and swapping. If the version number update is successful, the work report data injection is completed. If the version number update fails, the latest version number and collaborative context data structure of the current workflow instance are read again and the injection verification is performed again. When the number of retries reaches the preset limit, the injection is terminated and a concurrency conflict exception is thrown.

10. The piecework reporting data verification and processing system based on adaptive workflow according to claim 1, characterized in that, The wake-up reentry module generates a wake-up command when any one of the following conditions is met: the number of current unique workers reaches the expected number of collaborators, the cumulative number of workers reaches the standard number of tasks, or the token validity period expires. The module remains suspended when none of the three conditions are met. The review and judgment module generates an integrity score based on multi-dimensional features including the number of reported workers, piecework quantity, and token validity period. The integrity score is obtained by weighting and summing the ratio of the current number of unique workers to the expected number of collaborators, the ratio of the cumulative number of workers to the number of standard tasks, and the ratio of the remaining validity period of the token to the validity period of the token, respectively, according to the weight of the number of workers, the weight of the quantity, and the weight of the timeliness. The review and judgment module generates an approval result when there is no conflict in the process number among the various work reports in the collaborative context data structure and the integrity score reaches a preset pass threshold; generates an abnormal result when the integrity score is lower than a preset abnormal threshold; and generates a review result when the integrity score is greater than or equal to the preset abnormal threshold and less than the preset pass threshold.

Images