Multi-terminal cooperative data processing method and system based on two-state cooperation, terminal and medium

Abstract

The application relates to the technical field of data processing, and discloses a multi-terminal collaborative data processing method and system based on double-state cooperation, a terminal and a medium. The method comprises the following steps: obtaining two classification rule sets determined on a business, and constructing a double-state cooperative data model according to the two classification rule sets; determining the type identifier of a user and a preset type template mapping table, matching the type template mapping table according to the type identifier, and generating a dynamic input form corresponding to the type identifier; based on the double-state cooperative data model, responding to an operation instruction of the dynamic input form, executing cross-terminal state cooperation flow conversion and data same-source binding, and controlling an inspection terminal and a supplier terminal to keep consistent in display based on the same data source. The application can accurately distinguish data statistical distortion caused by process stages, accurately locate processing of each link, eliminate multi-terminal data display deviation, and improve data accuracy in a multi-role collaborative processing scene.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a multi-terminal collaborative data processing method, system, terminal and medium based on dual-state collaboration. Background Technology

[0002] In enterprise e-commerce procurement platforms, auditors need to conduct compliance checks on third-party products, record violations, collect evidence, and urge suppliers to rectify issues. Traditional methods typically provide a general violation record ledger or work order system, requiring auditors to manually enter information. When the types of audits are diverse and the evidence requirements are complex, this process is cumbersome and prone to errors. While some existing systems support online audit recording, the use of a single status field to simultaneously represent different dimensions of processing progress (such as internal conclusions and external response progress) in existing business processing systems leads to an inability to accurately distinguish process stages, distorted data statistics, and inconsistent presentation due to the lack of a data source binding mechanism across multiple platforms.

[0003] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0004] The main purpose of this application is to provide a multi-terminal collaborative data processing method, system, terminal and medium based on dual-state collaboration, which aims to solve the problems in the existing technology where business processing uses a single state field to represent the processing progress of different dimensions at the same time, which cannot accurately distinguish process stages, data statistics are distorted and multi-terminal data display is inconsistent, and the insufficient single-dimensional state representation capability leads to data logic confusion and display deviation.

[0005] The first aspect of this application provides a multi-terminal collaborative data processing method based on dual-state collaboration, the method comprising the following steps: Obtain two sets of classification rules that have been determined in the business context, and construct a dual-state collaborative data model based on the two sets of classification rules; Determine the user's type identifier and a preset type template mapping table, and match the type identifier with the type template mapping table to generate a dynamic input form corresponding to the type identifier; Based on the dual-state collaborative data model, in response to the operation instructions of the dynamic input form, cross-terminal state collaborative flow and data source binding are executed to control the audit end and the supplier end to maintain consistent display based on the same data source.

[0006] Optionally, in one embodiment of this application, the two classification rule sets include an inspection conclusion classification rule set and a rectification process classification rule set; The construction of the dual-state collaborative data model based on the two classification rule sets specifically includes: A first state enumeration set is defined according to the inspection conclusion classification rule set, and a second state enumeration set is defined according to the rectification process classification rule set. The first state enumeration set includes pending inspection, inspection violation, and inspection compliance, and the second state enumeration set includes pending push, pending appeal, pending review, pending supplementation, appeal failure, and appeal success. The first state enumeration set and the second state enumeration set are stored in the first physical field and the second physical field of the same database table, respectively, and the first physical field and the second physical field are bound to the same audit record unique identifier to form a dual-field physical isolation storage structure. Set cross-dimensional state transition constraints on the dual-field physically isolated storage structure, and set a directed chain transition path within the second physical field; A dual-state collaborative data model is constructed based on the first physical field, the second physical field, the cross-dimensional state transition constraint, and the directed chain transition path.

[0007] Optionally, in one embodiment of this application, determining the user's type identifier and the preset type template mapping table specifically includes: A pre-defined type template mapping table is provided, wherein the type template mapping table stores the correspondence between the combination of first-level scenarios and second-level types and the form template metadata; Receive the type identifier determined by the user through the cascading selection component, which is the first-level scene and the second-level type.

[0008] Optionally, in one embodiment of this application, the step of matching the type template mapping table according to the type identifier to generate a dynamic input form corresponding to the type identifier specifically includes: The type template mapping table is queried according to the type identifier to obtain the form template metadata corresponding to the type identifier, wherein the form template metadata includes field set definitions and evidence upload rules; Based on the field set in the form template metadata, a dynamic rendering field block is defined to generate a dynamic input form that matches the type identifier.

[0009] Optionally, in one embodiment of this application, the step of performing cross-terminal state collaborative flow and data source binding based on the dual-state collaborative data model in response to the operation instruction of the dynamic input form, and controlling the audit end and the supplier end to maintain consistent display based on the same data source, specifically includes: In response to the supplier push operation instruction triggered by the inspector on the dynamic entry form, according to the cross-dimensional state transition constraints in the dual-state collaborative data model, the first state field value and the second state field value of the current inspection record are obtained. It is verified whether the first state field value is an inspection violation and whether the second state field value is pending push. If the verification passes, the second state field value is changed from pending push to pending appeal along the internal chain transfer path. The push time is generated and the response deadline is calculated. The unique identifier of the inspection record, product information, violation content, push time and response deadline are synchronously written into the supplier-side pending list database table to establish a cross-end data binding relationship. In response to the supplier's submission reply operation instruction triggered on the dynamic entry form, the value of the second status field is verified as pending appeal; if the verification passes, the supplier's reply content is written into the corresponding field of the current audit record, and the value of the second status field is changed from pending appeal to pending review along the internal chain transfer path; In response to the review operation instruction triggered by the inspector on the dynamic entry form, the value of the second status field is checked to be pending review. If the check passes, the value of the second status field is changed to appeal successful, pending supplementation, or appeal failed along the internal chain transfer path according to the type of the review operation instruction. The handling opinion, handling basis, and evidence pictures filled in by the inspector are written into the corresponding field of the current inspection record. Data is read from the same database table on both the audit end and the supplier end based on the unique identifier of the audit record, ensuring that the data displayed on the audit end and the supplier end is consistent in real time.

[0010] Optionally, in one embodiment of this application, the execution of cross-end state collaborative flow and data source binding further includes: Obtain the final status value and corresponding processing conclusion data that have been determined in the current audit record, wherein the final status value is either appeal successful or appeal failed; Based on the associated complaint codes pre-stored in the inspection records, locate the corresponding original complaint record in the main complaint process; The final status value and the processing conclusion data are written back to the investigation response field of the original complaint record, and the business processing status of the main complaint process is advanced to the investigation completed node.

[0011] Optionally, in one embodiment of this application, the multi-terminal collaborative data processing method based on dual-state collaboration further includes: When the main complaint process is created, a complaint suggestion code is generated according to the first numbering rule, which serves as the unique business identifier for the complaint form throughout the entire process; When the auditing side creates a new audit record, it independently generates a unique identifier for the audit record according to the second numbering rule, which serves as the unique identifier for the auditing side to process the record. The first numbering rule and the second numbering rule are independent numbering rules. When the main complaint process is transferred to the investigation department, the complaint suggestion code is written into the associated complaint code field of the investigation record database row to establish a one-to-one binding relationship between the complaint form and the investigation record. When performing the write-back operation after the audit is completed, the original complaint record in the main complaint process is located by the complaint suggestion code stored in the associated complaint code field, and the processing conclusion data is written back to the original complaint record. When performing a rollback operation, the reason for rollback is synchronized to the main complaint process through the complaint suggestion code stored in the associated complaint code field, triggering the main process to reassign processing.

[0012] A second aspect of this application also provides a multi-terminal collaborative data processing system based on dual-state collaboration, wherein the multi-terminal collaborative data processing system based on dual-state collaboration is used to implement the multi-terminal collaborative data processing method based on dual-state collaboration as described in any of the above solutions; the multi-terminal collaborative data processing system based on dual-state collaboration includes: The model building module is used to obtain two sets of classification rules that have been determined in the business, and to build a dual-state collaborative data model based on the two sets of classification rules. The dynamic form generation module is used to determine the user's type identifier and a preset type template mapping table, and to generate a dynamic input form corresponding to the type identifier by matching the type template mapping table according to the type identifier. The cross-end data synchronization processing module is used to respond to the operation instructions of the dynamic input form based on the dual-state collaborative data model, execute cross-end state collaborative flow and data source binding, and control the audit end and the supplier end to maintain consistent display based on the same data source.

[0013] A third aspect of this application also provides a terminal, wherein the terminal includes: a memory, a processor, and a dual-state collaborative multi-terminal collaborative data processing program stored in the memory and executable on the processor, wherein when the dual-state collaborative multi-terminal collaborative data processing program is executed by the processor, it implements the steps of the dual-state collaborative multi-terminal collaborative data processing method described above.

[0014] A fourth aspect of this application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a multi-terminal collaborative data processing program based on dual-state collaboration, and when the multi-terminal collaborative data processing program based on dual-state collaboration is executed by a processor, it implements the steps of the multi-terminal collaborative data processing method based on dual-state collaboration as described above.

[0015] Beneficial effects: This application provides a multi-terminal collaborative data processing method, system, terminal, and medium based on dual-state collaboration. By constructing a dual-state collaborative data model, this application separates internal conclusions and external progress into two independent state dimensions and sets collaborative flow constraints, fundamentally solving the problem of data statistical distortion caused by the inability of a single state field to accurately distinguish process stages. This enables the system to accurately locate the processing documents at each stage. At the same time, by responding to the operation instructions of dynamically entered forms to execute cross-terminal state collaborative flow and data source binding, the audit end and the supplier end maintain real-time consistency based on the same data source throughout the entire chain of state changes, data writing, and query reading. This eliminates multi-terminal data display deviations and improves data accuracy, process traceability, and overall system operating efficiency in multi-role collaborative processing scenarios. Attached Figure Description

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

[0017] Figure 1 This is a flowchart of a preferred embodiment of the multi-terminal collaborative data processing method based on dual-state collaboration in this application; Figure 2 This is a structural diagram of a preferred embodiment of the multi-terminal collaborative data processing system based on dual-state collaboration of this application; Figure 3 This is a structural diagram of a preferred embodiment of the terminal of this application.

[0018] Explanation of reference numerals in the attached figures: 100. Model building module; 200. Dynamic form generation module; 300. Cross-platform data synchronization processing module. Detailed Implementation

[0019] To make the objectives, technical solutions, and effects of this application clearer and more explicit, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only possible technical implementations of this application and not all possible implementations. Based on the embodiments in this application, those skilled in the art can obtain other embodiments without creative effort, and these embodiments are also within the protection scope of this application.

[0020] Currently, mainstream e-commerce platforms and enterprise service marketplaces typically employ the following practices in their product inspection and management systems: They provide a general violation record ledger or work order system, where inspectors manually enter violation information using free-text descriptions without differentiating between inspection types. For scenarios requiring evidence uploads, a unified attachment upload portal is provided, without differentiated evidence upload rules (such as quantity, mandatory uploads, etc.) based on violation types. A single status field (e.g., "Processing" or "Completed") indicates the overall progress of the inspection record and also identifies the supplier's rectification status. After an inspection discovers a problem, the supplier is notified offline (email, telephone), and the supplier's rectification results are recorded separately, lacking an online collaborative process. Complaint and suggestion handling is independent of inspection handling, and there is a lack of a unified status synchronization and result feedback mechanism after a complaint is transferred.

[0021] The shortcomings of the relevant technologies are as follows: Rigid form structure: Different audit types (such as high price, store variety) require significantly different fields, and a unified form easily leads to redundant or missing fields. Furthermore, it lacks structured support for self-audit scenarios without order entry. Lack of differentiated evidence rules: It is impossible to set differentiated evidence upload requirements based on different audit types (e.g., for "high price" categories, a maximum of 5 screenshots of products listed on the platform and 5 mandatory screenshots of market search results must be uploaded), resulting in non-standard evidence collection. Confusing status semantics: A single status field cannot distinguish between audit conclusions (compliant / non-compliant) and supplier rectification progress (pushed, replied, awaiting review, etc.), leading to distorted statistical reports and making it difficult for operations personnel to accurately locate pending orders. Inconsistent data across multiple platforms: Data (push time, deadline, reply content, attachments, etc.) between the audit end and the supplier end lacks a common source binding, easily resulting in version inconsistencies and increasing the cost of evidence collection. The complaint and investigation processes are disconnected: After a complaint is transferred to the investigation department, there is a lack of unified business code association, status filtering and rollback rules, the boundaries of responsibilities between customer service and investigation are unclear, and the processing results are difficult to write back to the main complaint process.

[0022] In this embodiment, a dual-state collaborative model is constructed, storing the audit conclusion state and the rectification process state as two independent dimensions. State transition constraints between the two are defined, and a joint filtering method is provided, resolving the statistical distortion problem caused by the ambiguity of single states. Simultaneously, a type-driven dynamic form engine is designed. This engine automatically associates different audit types with corresponding field sets, evidence rules, and validation logic through the mapping relationship between audit types and form templates. Based on this, a cross-platform data synchronization binding mechanism is used to strongly bind the push time, response deadline, supplier response content, attachments, and communication records with the unique identifier of the audit record when pushing to suppliers, ensuring data consistency between the audit and supplier sides. Finally, a complaint-audit closed-loop write-back method is established. After a complaint is transferred to the audit department, it is associated through a unified business code, supporting the audit side to fill in conclusions, evidence, and rollback operations, and writing the processing results back to the main complaint process, forming a traceable closed loop. This application solves systemic problems in existing technologies such as rigid form adaptation, state ambiguity, inconsistency across multiple platforms, and the disconnect between complaints and audits.

[0023] The technical solutions of this application will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0024] The preferred embodiment of this application describes a multi-terminal collaborative data processing method based on dual-state collaboration, such as... Figure 1 As shown, the multi-terminal collaborative data processing method based on dual-state collaboration includes the following steps: In step S10, two classification rule sets that have been determined in terms of business are obtained, and a dual-state collaborative data model is constructed based on the two classification rule sets.

[0025] In one possible implementation, the two classification rule sets include an inspection conclusion classification rule set and a rectification process classification rule set. Step S10 specifically includes: A first state enumeration set is defined based on the inspection conclusion classification rule set, and a second state enumeration set is defined based on the rectification process classification rule set. The first state enumeration set includes pending inspection, inspection violation, and inspection compliance; the second state enumeration set includes pending push, pending appeal, pending review, pending supplementation, appeal failure, and appeal success. The first and second state enumeration sets are stored in the same database table using a first physical field and a second physical field, respectively. The first and second physical fields are bound to the same inspection record unique identifier, forming a dual-field physically isolated storage structure. Cross-dimensional state transition constraints are set on the dual-field physically isolated storage structure, and a directed chain transition path is set within the second physical field. A dual-state collaborative data model is constructed based on the first physical field, the second physical field, the cross-dimensional state transition constraints, and the directed chain transition path.

[0026] It is understood that the cross-dimensional state transition constraint is: the second physical field is allowed to flow backward from the pending push only when the current value of the first physical field is the inspection violation; the directed chain transition path is specifically: pending push - pending appeal - pending review - appeal successful / pending supplement / appeal failed, and pending supplement - pending review; Specifically, in the steps of constructing the dual-state collaborative data model, the first step is to define an audit status set S_inspect = {to be audited, audited for violations, audited for compliance}, which is used to record audit business conclusions. The second step is to define a rectification process status set S_remedy = {to be pushed, to be appealed, to be reviewed, to be supplemented, appeal failed, appeal successful}, which is used to record the supplier collaboration progress.

[0027] The two states are stored in different fields of the same audit record and are linked by a unique identifier in the audit record. The system defines the following state transition constraints and triggering conditions: Push Constraint: The rectification process status is allowed to flow from "Pending Push" only when the audit status is "Audit Violation". Compliant or pending audit documents cannot be pushed to suppliers. Pending Push - Pending Appeal: Triggered when the auditor performs the "Push Supplier" operation. The system generates a push record, writes the push time, reply deadline (current time + N days), and synchronizes the audit record identifier, product information, violation content, etc. to the supplier's pending list. Pending Appeal - Pending Review: Triggered when the supplier fills in the reply content and uploads attachments and submits it in the "Pending Appeal" status. Pending Review - Appeal Successful: Triggered when the auditor performs "Review Passed". Pending Review - Pending Supplement: Triggered when the auditor performs "Reject Supplement", the supplier can fill in the reply content again, upload attachments and submit it, and re-enter the "Pending Review" state. "Pending Review - Appeal Failed": Triggered when the maximum number of rejections is reached (tentatively set at 1, subject to adjustment) or when the audit personnel manually determine that the application is unsuccessful. "Pending Supplement - Pending Review": Triggered when the supplier submits supplementary response content and uploads attachments in the "Pending Supplement" status. The query interface supports independent and combined filtering of the two status dimensions (e.g., "Inspection Violation and Pending Review"), meeting operational statistical needs.

[0028] In step S20, the user's type identifier and a preset type template mapping table are determined, and the type template mapping table is matched according to the type identifier to generate a dynamic input form corresponding to the type identifier.

[0029] In one possible implementation, step S20 specifically includes: pre-setting a type template mapping table, wherein the type template mapping table stores the correspondence between combinations of primary scenes and secondary types and form template metadata; receiving the type identifier determined by the primary scene and secondary type selected by the user through the cascading selection component; querying the type template mapping table according to the type identifier to obtain the form template metadata corresponding to the type identifier, wherein the form template metadata includes field set definitions and evidence upload rules; dynamically rendering field blocks according to the field set definitions in the form template metadata to generate a dynamic input form matching the type identifier.

[0030] Understandably, a dynamic entry form is generated, and the quantity limit, whether it is mandatory, and the file type in the evidence upload rules are embedded into the validation logic of the front-end file upload component, so that the upload component performs immediate legality interception when the user operates; it checks whether the current audit method is self-audit mode, and if the detection result is yes, it displays a no order entry prompt, switches the order-related fields from mandatory to optional, and forces the mandatory field validation of the alternative fields to be enabled.

[0031] Specifically, in the type-driven dynamic form engine process, the system first pre-defines a type-form template mapping table. The audit types include primary scenarios (commuter uniforms / takeout) and secondary types (high price / supply consistency / brand richness / store richness). After the user selects the primary and secondary types sequentially, the system determines the corresponding form template based on the mapping table. After the user selects a type, the front-end requests the corresponding form template from the back-end and dynamically renders the field blocks. Different templates contain different sets of fields (e.g., "takeout - store richness" contains multiple rows of supplier and dine-in shop information). Evidence upload rules are part of the template; the front-end renders the upload component according to the rules, and the back-end reuses the same rules during verification. For example, the "high price" category requires uploading "screenshots of items on the platform" and "market search results," a maximum of 5 images of each, which are mandatory. In the self-audit scenario: when the system detects "audit method = self-audit," it displays a prompt "No order association required, please manually fill in the product information and supplement the price basis," and enables no-order verification logic (order number and other fields are not mandatory, but product information must be manually filled in).

[0032] In step S30, based on the dual-state collaborative data model, in response to the operation instructions of the dynamic input form, cross-end state collaborative flow and data source binding are executed to control the audit end and the supplier end to maintain consistent display based on the same data source.

[0033] In one possible implementation, step S30 specifically includes: responding to the supplier push operation instruction triggered by the inspector on the dynamic entry form, obtaining the first state field value and the second state field value of the current inspection record according to the cross-dimensional state transition constraints in the dual-state collaborative data model, verifying whether the first state field value is an inspection violation and whether the second state field value is pending push; if the verification passes, changing the second state field value from pending push to pending appeal along the internal chain transfer path, generating a push time and calculating the response deadline, synchronously writing the unique identifier of the inspection record, product information, violation content, push time, and response deadline into the supplier-side pending list database table, establishing a cross-end data binding relationship; responding to the supplier's submission response operation triggered on the dynamic entry form. The system executes an instruction to verify whether the value of the second status field is pending appeal. If the verification passes, the supplier's response is written into the corresponding field of the current audit record, and the value of the second status field is changed from pending appeal to pending review along the internal chain transfer path. In response to the review operation instruction triggered by the auditor on the dynamic entry form, the system verifies whether the value of the second status field is pending review. If the verification passes, the system changes the value of the second status field along the internal chain transfer path to appeal successful, pending supplementation, or appeal failed, depending on the type of the review operation instruction, and writes the processing opinion, processing basis, and evidence images filled in by the auditor into the corresponding field of the current audit record. Data is read from the same database table on both the audit end and the supplier end based on the unique identifier of the audit record, ensuring real-time consistency between the data displayed on the audit end and the supplier end.

[0034] It is understandable that after each state transition, the changed state value and the business data generated by this operation are uniformly written into the current audit record database row, and the database row uses the unique identifier of the audit record as the primary key; the audit end and the supplier end's list and details page share the same data query interface, and the interface uses the unique identifier of the audit record as the input parameter to read data from the database row, so that the data displayed by the audit end and the supplier end is consistent in real time.

[0035] Specifically, the cross-platform data synchronization and status coordination mechanism of this application allows inspectors to "push to supplier" when the inspection status is "inspection violation" and the rectification process status is "pending push." ​​The system generates a push record, including the push time, reply deadline (current time + N days), and synchronizes the inspection record identifier, product information, and violation content to the supplier's pending list. After the supplier submits a reply, the system writes the reply content and attachments to the same inspection record and updates the rectification process status to "pending review." The inspection details page displays the supplier's reply content, attachments, and communication records (timeline). When the inspection performs a review: if the review is successful, the status changes to "appeal successful"; if the supplement is rejected, it changes to "pending supplement," and the supplier can reply again; if the appeal fails, it changes to "appeal failed." The maximum number of rejections is configurable (temporarily set at 1 in the requirement order, but adjustable). All status change records include timestamps and operators, forming a traceable processing trajectory. The lists and details on the inspection and supplier sides are rendered based on the same data source, ensuring consistency.

[0036] Specifically, the system employs the following mechanism to achieve cross-platform data consistency: The audit record details page and the supplier audit processing details page share the same data query interface. This interface uses the unique identifier of the audit record as input parameter and reads fields such as push time, reply deadline, supplier reply content, attachments, and communication records from the same database table. Both pages call the same interface and data structure during rendering. After the supplier submits a reply or the audit side performs a review operation, the system uniformly writes the changed data into the database record corresponding to the audit record, regardless of the data source. After the write is completed, the details page on either side will obtain the latest consistent data upon subsequent requests. The audit list and the supplier list are both filtered and sorted based on the same data model during querying. List fields (such as audit status, rectification process status, reply deadline, etc.) are all taken from the same audit record table with the same name, ensuring that the data displayed on both lists is completely consistent in semantics and values.

[0037] In one possible implementation, step S30 is followed by step S40: obtaining the final status value and corresponding processing conclusion data determined in the current audit record, wherein the final status value is either successful or unsuccessful; locating the original complaint record in the main complaint process according to the associated complaint code pre-stored in the audit record; writing the final status value and the processing conclusion data back to the audit response field of the original complaint record; and advancing the business processing status of the main complaint process to the audit completed node.

[0038] In this step, the final status value and corresponding processing conclusion data determined in the current audit record are obtained. The final status value is either "appeal successful" or "appeal failed," and the processing conclusion data includes processing opinions, processing basis, and evidence images. Based on the associated complaint codes pre-stored in the audit record, the corresponding original complaint record in the main complaint process is located. If the final status value is "appeal successful," the processing approval conclusion, processing opinions, processing basis, and evidence images are written back to the audit response field of the original complaint record, and the business processing status of the main complaint process is advanced to the audit completed node. If the final status value is "appeal failed," the processing disapproval conclusion, processing opinions, processing basis, and evidence images are written back to the audit response field of the original complaint record, and the business processing status of the main complaint process is advanced to the audit completed node. If the final status value is "to be supplemented" and the preset maximum number of rejections has been reached, the processing disapproval conclusion and rejection reason are written back to the audit response field of the original complaint record, and the business processing status of the main complaint process is advanced to the audit completed node.

[0039] The closed-loop write-back method for complaint auditing in this embodiment is as follows: The main complaint process supports transfer to "Life Services Auditing." During transfer, the complaint suggestion code, order information, supplier information, etc., are included and written into the auditing side's dedicated complaint list. Auditors can filter by complaint suggestion code, SKU, order number, etc., in the "Life Services Auditing Complaint List" to view details. The details page displays complaint information, order information, supplier information, and processing records. Auditors fill in the audit results, processing opinions, and processing basis, and can upload images. The system supports a "rollback" operation: After the auditor fills in the rollback instructions, the status is rolled back to the previous stage of the main complaint process, along with the reason for the rollback. The main process reassigns the processing upon receiving the rollback. After the audit is completed, the processing result (pass / fail, basis) is written back to the "Audit Reply" field of the main complaint process, achieving a closed loop.

[0040] In one possible implementation, the associated complaint codes pre-stored in the audit records are established as follows: When the main complaint process is created, a complaint suggestion code is generated according to a first numbering rule, serving as the unique business identifier for the complaint form throughout the entire process; when the audit side creates a new audit record, a unique audit record identifier is independently generated according to a second numbering rule, serving as the unique identifier for the audit side's processing record, wherein the first numbering rule and the second numbering rule are independent numbering rules; when the main complaint process performs the transfer to the audit, the complaint suggestion code is written into the associated complaint code field of the audit record database row, establishing a one-to-one binding relationship between the complaint form and the audit record; when the write-back operation is performed after the audit is completed, the original complaint record corresponding to the main complaint process is located through the complaint suggestion code stored in the associated complaint code field, and the processing conclusion data is written back to the original complaint record; when the rollback operation is performed, the rollback reason is synchronized to the main complaint process through the complaint suggestion code stored in the associated complaint code field, triggering the main process to reassign processing.

[0041] Specifically, the generation and association mechanism of the unified business code in this application is as follows: The complaint suggestion code is generated according to the system's established rules when the main complaint process is created, serving as the unique business identifier for the complaint form throughout the entire process. The inspection record ID is independently generated by the system according to the numbering rules of the inspection module when the inspector creates an inspection record, serving as the unique identifier for the inspection-side processing record. The inspection records generated from complaint transfers share the same set of inspection record ID generation rules as ordinary self-inspection records, ensuring that all inspection records are managed uniformly under the same numbering system. When a complaint is transferred to "Life Services Inspection," the system writes the complaint suggestion code into the association field of the inspection record, establishing a one-to-one binding relationship between the complaint form and the inspection record. Inspectors can perform precise searches by complaint suggestion code in the "Life Services Inspection Complaint List," and can also view the corresponding complaint suggestion code on the inspection details page. After the inspection is completed, the system locates the corresponding main complaint process record through this association field and writes the inspection results, handling opinions, and handling basis back to the "Inspection Response" field of the main complaint process. During a rollback operation, the system also uses this associated field to synchronize the rollback reason and rollback status to the main complaint process, triggering the main process to reassign processing.

[0042] Next, referring to the accompanying drawings, a multi-terminal collaborative data processing system based on dual-state collaboration proposed in the embodiments of this application is described, which is used to implement the multi-terminal collaborative data processing method based on dual-state collaboration as described in any of the above schemes.

[0043] Figure 2 This is a structural diagram of a multi-terminal collaborative data processing system based on dual-state collaboration, according to an embodiment of this application.

[0044] like Figure 2As shown, the multi-terminal collaborative data processing system based on dual-state collaboration includes: a model building module 100, a dynamic form generation module 200, and a cross-terminal data synchronization processing module 300.

[0045] Specifically, the model building module 100 is used to obtain two classification rule sets that have been determined in the business, and to build a dual-state collaborative data model based on the two classification rule sets; The dynamic form generation module 200 is used to determine the user's type identifier and a preset type template mapping table, and to generate a dynamic input form corresponding to the type identifier by matching the type template mapping table according to the type identifier. The cross-end data synchronization processing module 300 is used to respond to the operation instructions of the dynamic input form based on the dual-state collaborative data model, execute cross-end state collaborative flow and data same-source binding, and control the audit end and the supplier end to maintain consistent display based on the same data source.

[0046] Figure 3 A structural diagram of a terminal provided in an embodiment of this application. The terminal may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0047] When the processor 502 executes the program, it implements the multi-terminal collaborative data processing method based on dual-state collaboration provided in the above embodiments.

[0048] Furthermore, the terminal also includes: Communication interface 503 is used for communication between memory 501 and processor 502.

[0049] The memory 501 is used to store computer programs that can run on the processor 502.

[0050] Memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0051] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EIS) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0052] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0053] Processor 502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0054] This embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described multi-terminal collaborative data processing method based on dual-state collaboration.

[0055] One embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the features described in this application. Figure 1 The corresponding embodiments provide a multi-terminal collaborative data processing method based on dual-state collaboration.

[0056] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0057] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0058] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0059] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable storage medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable storage medium could be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0060] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0061] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0062] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0063] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

[0064] It should be understood that the application of this application is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

[0065] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A multi-terminal collaborative data processing method based on dual-state collaboration, characterized in that, The multi-terminal collaborative data processing method based on dual-state collaboration includes: Obtain two sets of classification rules that have been determined in the business context, and construct a dual-state collaborative data model based on the two sets of classification rules; Determine the user's type identifier and a preset type template mapping table, and match the type identifier with the type template mapping table to generate a dynamic input form corresponding to the type identifier; Based on the dual-state collaborative data model, in response to the operation instructions of the dynamic input form, cross-terminal state collaborative flow and data source binding are executed to control the audit end and the supplier end to maintain consistent display based on the same data source.

2. The multi-terminal collaborative data processing method based on dual-state collaboration according to claim 1, characterized in that, The two sets of classification rules include a set of classification rules for inspection conclusions and a set of classification rules for rectification procedures; The construction of the dual-state collaborative data model based on the two classification rule sets specifically includes: A first state enumeration set is defined according to the inspection conclusion classification rule set, and a second state enumeration set is defined according to the rectification process classification rule set. The first state enumeration set includes pending inspection, inspection violation, and inspection compliance, and the second state enumeration set includes pending push, pending appeal, pending review, pending supplementation, appeal failure, and appeal success. The first state enumeration set and the second state enumeration set are stored in the first physical field and the second physical field of the same database table, respectively, and the first physical field and the second physical field are bound to the same audit record unique identifier to form a dual-field physical isolation storage structure. Set cross-dimensional state transition constraints on the dual-field physically isolated storage structure, and set a directed chain transition path within the second physical field; A dual-state collaborative data model is constructed based on the first physical field, the second physical field, the cross-dimensional state transition constraint, and the directed chain transition path.

3. The multi-terminal collaborative data processing method based on dual-state collaboration according to claim 1, characterized in that, The determination of the user's type identifier and the preset type template mapping table specifically includes: A pre-defined type template mapping table is provided, wherein the type template mapping table stores the correspondence between the combination of primary scenes and secondary types and the form template metadata; Receive the type identifier determined by the user through the cascading selection component, which is the first-level scene and the second-level type.

4. The multi-terminal collaborative data processing method based on dual-state collaboration according to claim 3, characterized in that, The step of matching the type identifier with the type template mapping table to generate a dynamic input form corresponding to the type identifier specifically includes: The type template mapping table is queried according to the type identifier to obtain the form template metadata corresponding to the type identifier, wherein the form template metadata includes field set definitions and evidence upload rules; Based on the field set in the form template metadata, a dynamic rendering field block is defined to generate a dynamic input form that matches the type identifier.

5. The multi-terminal collaborative data processing method based on dual-state collaboration according to claim 4, characterized in that, Based on the dual-state collaborative data model, in response to the operation instructions of the dynamically entered form, cross-terminal state collaborative flow and data source binding are executed to ensure that the audit end and the supplier end maintain consistent display based on the same data source. Specifically, this includes: In response to the supplier push operation instruction triggered by the inspector on the dynamic entry form, according to the cross-dimensional state transition constraints in the dual-state collaborative data model, the first state field value and the second state field value of the current inspection record are obtained. It is verified whether the first state field value is an inspection violation and whether the second state field value is pending push. If the verification passes, the second state field value is changed from pending push to pending appeal along the internal chain transfer path. The push time is generated and the response deadline is calculated. The unique identifier of the inspection record, product information, violation content, push time and response deadline are synchronously written into the supplier-side pending list database table to establish a cross-end data binding relationship. In response to the supplier's submission reply operation instruction triggered on the dynamic entry form, the value of the second status field is verified as pending appeal; if the verification passes, the supplier's reply content is written into the corresponding field of the current audit record, and the value of the second status field is changed from pending appeal to pending review along the internal chain transfer path; In response to the review operation instruction triggered by the inspector on the dynamic entry form, the value of the second status field is checked to be pending review. If the check passes, the value of the second status field is changed to appeal successful, pending supplementation, or appeal failed along the internal chain transfer path according to the type of the review operation instruction. The handling opinion, handling basis, and evidence pictures filled in by the inspector are written into the corresponding field of the current inspection record. Data is read from the same database table on both the audit end and the supplier end based on the unique identifier of the audit record, ensuring that the data displayed on the audit end and the supplier end is consistent in real time.

6. The multi-terminal collaborative data processing method based on dual-state collaboration according to claim 1, characterized in that, The execution of cross-platform state collaborative flow and data source binding also includes: Obtain the final status value and corresponding processing conclusion data that have been determined in the current audit record, wherein the final status value is either appeal successful or appeal failed; Based on the associated complaint codes pre-stored in the inspection records, locate the corresponding original complaint record in the main complaint process; The final status value and the processing conclusion data are written back to the investigation response field of the original complaint record, and the business processing status of the main complaint process is advanced to the investigation completed node.

7. The multi-terminal collaborative data processing method based on dual-state collaboration according to claim 6, characterized in that, The multi-terminal collaborative data processing method based on dual-state collaboration also includes: When the main complaint process is created, a complaint suggestion code is generated according to the first numbering rule, which serves as the unique business identifier for the complaint form throughout the entire process; When the auditing side creates a new audit record, it independently generates a unique identifier for the audit record according to the second numbering rule, which serves as the unique identifier for the auditing side to process the record. The first numbering rule and the second numbering rule are independent numbering rules. When the main complaint process is transferred to the investigation department, the complaint suggestion code is written into the associated complaint code field of the investigation record database row to establish a one-to-one binding relationship between the complaint form and the investigation record. When performing the write-back operation after the audit is completed, the original complaint record in the main complaint process is located by the complaint suggestion code stored in the associated complaint code field, and the processing conclusion data is written back to the original complaint record. When performing a rollback operation, the reason for rollback is synchronized to the main complaint process through the complaint suggestion code stored in the associated complaint code field, triggering the main process to reassign processing.

8. A multi-terminal collaborative data processing system based on dual-state collaboration, characterized in that, The dual-state collaborative multi-terminal collaborative data processing system is used to implement the dual-state collaborative multi-terminal collaborative data processing method according to any one of claims 1-7, wherein the dual-state collaborative multi-terminal collaborative data processing system comprises: The model building module is used to obtain two sets of classification rules that have been determined in the business, and to build a dual-state collaborative data model based on the two sets of classification rules. The dynamic form generation module is used to determine the user's type identifier and a preset type template mapping table, and to generate a dynamic input form corresponding to the type identifier by matching the type template mapping table according to the type identifier. The cross-end data synchronization processing module is used to respond to the operation instructions of the dynamic input form based on the dual-state collaborative data model, execute cross-end state collaborative flow and data source binding, and control the audit end and the supplier end to maintain consistent display based on the same data source.

9. A terminal, characterized in that, The terminal includes: a memory, a processor, and a multi-terminal collaborative data processing program based on dual-state collaboration stored in the memory and executable on the processor. When the multi-terminal collaborative data processing program based on dual-state collaboration is executed by the processor, it implements the steps of the multi-terminal collaborative data processing method based on dual-state collaboration as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a multi-terminal collaborative data processing program based on dual-state collaboration, which, when executed by a processor, implements the steps of the multi-terminal collaborative data processing method based on dual-state collaboration as described in any one of claims 1-7.

Images