A business process document integrity checking method and system based on multi-dimensional context configuration

Abstract

The application discloses a kind of based on multi-dimensional context configuration's business process document integrity checking method and system, belong to enterprise business process management system technical field.The method includes: constructing the four-dimensional orthogonal document requirement configuration model of process × state × authentication system × audit stage, administrator is configured required document list and must pass / optional attribute for each business link by background interface;Before any business link advances to next state, all business modules uniformly call the same document integrity checking service as only checking entrance;The service runtime obtains the real-time context (process type, current state, associated authentication system list, audit stage list) of current business object, executes three-dimensional context filtering to pre-configured document requirement, dynamically determines the document set that current link should have uploaded;Associated uploaded document record, whether corresponding file exists is checked item by item for must pass document, if missing, then block process advance and give explicit prompt.The application replaces hard-coded checking rule by four-dimensional orthogonal configuration, realizes the configurable management and zero code extension of document integrity checking rule;Through unified checking gateway, the risk of checking logic dispersion, omission is eliminated;Combined with tree-like volume structure, three-layer RBAC permission and the automatic bridging of document to volume, form from document upload, integrity checking to volume archiving Full-process closed loop, greatly reduce manual operation cost and error rate.

Description

I. Technical Field

[0001] This invention belongs to the technical field of enterprise business process management systems, specifically relating to a method and system for automating the verification of the integrity of business process documents through a unified verification gateway, based on a four-dimensional orthogonal configuration of process × status × certification system × audit stage in an ISO certification audit management information system. II. Background Technology

[0002] In highly regulated industries such as certification auditing, certification bodies require companies or auditors to upload specific documents and / or templates at every stage of the entire business process after accepting a company's application, from contract submission, contract review, contract approval, audit plan commissioning, audit plan submission, audit plan approval, to dossier return, technical review, and certification decision. For example, the contract review stage may require uploading a "Contract Review Form" and an "Application Acceptance Confirmation," while the audit plan approval stage may require uploading an "Audit Plan" and an "Audit Strategy." The required document content varies significantly depending on the certification system (ISO 9001 / 14001 / 45001, etc.) and the audit stage (Initial Stage 1, Initial Stage 2, Surveillance Audit 1 / 2 / 3, etc.).

[0003] Existing document integrity verification schemes typically employ hard-coding: document checking logic is directly written into the status progression code of each business process. For example: If (status == TO_REVIEW) { if (!hasDocument("contract_review_form"))throw Exception("Please upload the contract review form"); if (!hasDocument("application_confirm"))throw Exception("Please upload the application acceptance confirmation");} This hard-coded validation logic is scattered across the Service methods of various business modules, with each module independently managing its own list of "which documents are needed".

[0004] When certification rules change (for example, when ISO releases a new standard requiring an additional "Data Protection Impact Assessment Form" during contract review), traditional solutions require finding the corresponding source code files, modifying the verification logic, and going through a series of processes including testing, approval, and deployment before going live. This process typically takes several days or even weeks, resulting in extremely slow response times. Moreover, different certification bodies apply different rules, and when the same system serves multiple organizations, hard-coding is almost impossible to manage the diverse documentation requirements.

[0005] In a typical certification audit management system, there are nine different stages requiring document integrity verification: contract submission, contract review, contract approval, project delegation, project submission, project approval, dossier submission, technical review approval, and certification decision approval. In traditional solutions, the verification logic for these nine stages is scattered across at least six different business module codes. Due to the lack of a unified verification entry point and management view, when adding a new business stage, developers may forget to add the corresponding document verification, causing the business process to incorrectly advance to the next stage with incomplete documentation, creating compliance risks.

[0006] Traditional solutions only support differentiating document requirements by the single dimension of "process type + status" (e.g., "contract process + document A required for review status"), and cannot support more dimensions such as "system × review stage". However, in actual business, the same document: For the Q system, it may be "mandatory" to upload, while for the E system, it may be "optional". For the initial second stage, it may be "must be uploaded", while for the monitoring and review, it may be "not required". Different branches may have different requirements.

[0007] To achieve the above multi-dimensional condition combinations, traditional solutions require writing a large number of nested if-else branches, resulting in code complexity that increases exponentially with the dimension.

[0008] In certification audit management, there are two related but traditionally independent systems: a document management system (for uploading and verifying documents at each stage) and a dossier archiving system (for managing the final archived dossier files). In practice, after the plan is approved, auditors need to manually re-upload the documents that have already been uploaded at each stage into the dossier archiving system. This not only causes repetitive work but is also prone to errors due to human intervention, leading to inconsistencies between the dossier and the original documents.

[0009] In summary, there is an urgent need for a business process document integrity verification method and system that can decouple document requirements from code, support multi-dimensional orthogonal configuration, perform verification through a unified entry point, and automatically bridge the document system and the dossier system. III. Summary of the Invention

[0010] The present invention aims to provide a method and system for verifying the integrity of business process documents, in order to solve the technical problems in the prior art, such as the difficulty in maintaining hard-coded verification rules, the easy omission of scattered verification logic, the lack of support for multi-dimensional condition combinations, and the separation between document system and dossier system.

[0011] This invention provides a method for verifying the integrity of business process documents based on multi-dimensional context configuration, comprising the following steps: Step S1 (Configure 4D Document Requirements): In the system management backend, document requirement entries are pre-configured for each business process step. Each configuration entry (corresponding to a row in the database table config_document) contains the following key fields: The unique document requirement definition is formed by any combination of four orthogonal dimensions—process × status, certification system, review stage, and mandatory / unmandatory. Configuration is independent of code; administrators can add, delete, and modify configurations via a web interface.

[0012] Step S2 (Unified Verification Entry Point - Single Choke Point): Before any process is initiated, all business modules in the system uniformly call one of two methods from the same document integrity verification service (CommonDocumentService): checkPlanDocument(planId): Applicable to the review plan process and its subsequent stages (plan delegation, plan submission, plan approval, dossier submission, technical review, certification decision). checkContractDocument(contractId): Applicable to the contract process and its subsequent stages (contract submission, contract review, contract approval). These two methods constitute the system's "Single Choke Point": any code path that needs to verify document integrity must, and can only, pass through one of these two entry points. This ensures that: (1) There will be no situation where a certain step is missed in the verification - as long as the process is progressing, it will pass through this entry point; (2) Modifications to the validation logic only need to be made in these two methods or the underlying methods they call, without having to traverse all business modules; (3) When adding a new business process, you only need to add a call to the above method in the process advancement code of that process.

[0013] Step S3 (Runtime Context Acquisition): When the validation method is invoked, the system retrieves the following from the database based on the passed process type identifier (Project or Plan) and business object identifier (contractId or planId): (1) The real-time status code of the current business object (e.g., pending review = 20, pending approval = 45, etc.); (2) A list of authentication systems associated with the business object (obtained from the ContractSystem table or the PlanPhase table). (3) The list of audit stages associated with this business object (obtained from ContractSystem.auditActivity or PlanPhase.auditPhase).

[0014] This real-time data constitutes the runtime context. Key design point: The source tables for obtaining the above data in the contract process and the review plan process are different (contracts are obtained through ContractSystem, and plans are obtained through PlanPhase), but the filtering logic after acquisition is exactly the same, realizing the reuse of the core verification logic.

[0015] Step S4 (3D Context Filtering): All document requirement items pre-configured in step S1 are subjected to three-dimensional cascading filtering based on the runtime context obtained in step S3: Filter 1 (Process Subcategories Filter): Matches the `process` field of the configuration entry with the target substring (current process type + current status code + "#") in the runtime context. The encoding format of the `process` field is process identifier + status code + "#", such as "Project20#" representing "Contract Process + Status 20 (Pending Review)". Only entries whose `process` field contains the target substring or whose `process` field is empty pass this filter.

[0016] The ingenuity of this design lies in replacing the traditional binary judgment of "process type == X AND status == Y" with string inclusion operation, so that a configuration entry can specify multiple process-status combinations (such as "Project20#, Project30#") through the process field, and express complex process conditions with a single field.

[0017] Filter 2 (Authentication System Filter): Entries passing Filter 1 are compared to the authentication system list of the current business object based on their csUuid field. Matching conditions are: the csUuid field is empty (indicating no system restriction), or the system set specified in the csUuid field is completely contained within the current object's authentication system list. Using complete inclusion rather than partial matching semantics ensures that when the configuration requires [Q,E], only business objects containing both Q and E need this document, avoiding mismatches of a single Q system.

[0018] Filter 3 (Audit Phase Filter): Entries that pass Filter 2 are compared to the audit phase list of the current business object based on their `auditPhase` field. Matching conditions are: the `auditPhase` field is empty, or the current object's audit phase list is completely contained within the set of phases specified by the `auditPhase` field. This uses the semantics of the current phase being contained within the configuration phase (rather than the configuration being contained within the current phase), adapting to the reality that configuration typically defines "which phases this document applies to," while runtime may only have "one or a few phases currently."

[0019] Step S5 (Associated Uploaded Files): For the remaining document requirement items after three-dimensional filtering, the uploaded document table (document table) is queried using docId as the association key. After grouping by docId, the list of uploaded files corresponding to each document requirement item is mounted to the item, forming the ConfigDocumentWithFileListDto data structure—that is, the pairing of configuration document requirements with the list of uploaded files.

[0020] Step S6 (Required Verification): Iterate through the pairing list output in step S5. For entries with `required=1` (mandatory), check if their associated `fileList` is empty. If a mandatory document has not yet been uploaded, immediately throw a business exception (BizException) with a clear warning message to halt the process. For example: The error message includes the business object number and the name of the missing document, enabling business personnel to quickly locate and upload the missing document.

[0021] Step S7 (Documents → Automatic Volume Bridging) (Optional Extension): When the review plan is approved, the system automatically triggers the document-to-volume bridging process, which includes the following sub-steps: S7.1 Query Phase: Query the document table to obtain a list of all uploaded document records under the audit plan (planId); S7.2 Filtering Phase: Traverse the document record list, and for each document record, query the config_document configuration table using its docId as the key, and filter out document records in which the archiveConfigId field is not empty; at the same time, according to the certification system (csUuidList) and audit phase (auditPhaseList) associated with the audit plan, query the corresponding dossier configuration list in the config_archive configuration table; S7.3 Bridging Phase: For each document record that meets the bridging criteria selected in S7.2, perform the following data mapping write operation: Extract the fields name (filename), url (storage address), urlPdf (PDF preview address), and size (file size) from the document record; Retrieve the target volume configuration identifier from the archiveConfigId field of the config_document record; Get the folderId (folder node identifier) ​​corresponding to the volume configuration from the config_archive configuration. Generate a new snowflake ID (using the snowflake algorithm) as the archiveId; Create a new Archive record using the mapped fields and insert it into the database; S7.4 Completion Stage: After bridging is completed, auditors can directly see the file records automatically converted from documents in the file management interface without having to upload them repeatedly; the conversion process is automatically triggered when the plan is approved without manual intervention.

[0022] Step S8 (Volume Tree Structure and RBAC Permissions) (Optional Extension): The files are organized in a multi-level folder tree structure: The ConfigArchiveFolder table defines folder nodes, and the parentFolderId field expresses the hierarchical relationship; The ConfigArchive table defines the leaf nodes for volume configuration, which are mounted to folders using the folderId field. Each Archive node contains three layers of RBAC permissions: permissionLeader (group leader permissions), permissionMember (group member permissions), and permissionOuter (permissions for people outside the group). The value of each permission layer is 0 = invisible, 1 = read-only, and 2 = writable.

[0023] At runtime, the myPermission value for each dossier node is dynamically calculated based on the actual role of the currently logged-in user in the audit plan (matched from the audit group member list), so that the same dossier tree presents differentiated permissions for different users.

[0024] Step S9 (Multiple Validation of Dossier Submission) (Optional Extension): A five-factor check chain is executed when the case file is submitted: Authorized Person Identity Verification: Only authorized persons (entrustPersonnelId) who are reviewing the plan can submit it; The dossier must be returned for verification: recursively traverse the dossier tree and check if the node with required=1 has an uploaded file; Signature integrity verification: The signed field of all domicile signature records is "Yes"; Document integrity verification: Invoke the document verification service in step S2; Once all approvals are granted, the review plan status will be updated and subsequent events (such as the cost calculation event) will be released.

[0025] The business process document integrity verification method and system based on multi-dimensional context configuration provided by this invention have the following advantages compared with the prior art: (1) Zero-code extension achieved through four-dimensional orthogonal configuration: Document requirements are completely decoupled from the code, and administrators can independently configure any combination of the four dimensions of process × status, certification system, audit stage, and whether it is mandatory through the backend web interface. When certification rules change and document requirements need to be added or adjusted, only the configuration table needs to be modified, without modifying the code or retesting and deploying. Adding a new certification system or audit stage only requires adding enumeration values ​​to the corresponding dimensions and referencing them in the configuration.

[0026] (2) Unified verification gateway eliminates the risk of omissions: Through the Single Choke Point design pattern, the document integrity verification of all 9 business processes goes through the same method entry point of the same service. Audit and compliance personnel can be confident that as long as the process proceeds, it will inevitably go through document integrity verification. When adding a new business process, only the unified entry point method needs to be called, and no verification will be missed.

[0027] (3) Runtime context precise filtering: The three-dimensional cascading filtering (process subcategories → authentication system → audit stage) is dynamically executed at runtime based on the current business object status, ensuring that each step only checks the truly applicable document requirements. It is implemented using the functional filter chain of the Stream API, with clear filtering logic and negligible performance overhead (a single call can filter at most a few dozen configuration records).

[0028] (4) Automatic document-to-dosage file bridging eliminates redundant work: By utilizing the foreign key bridging relationship between ConfigDocument.archiveConfigId and ConfigArchive.archiveConfigId, uploaded documents are automatically converted into dosage file records when the plan is approved. Auditors do not need to upload repeatedly in the dosage file system, reducing operating costs and eliminating the risk of inconsistency caused by manual copying.

[0029] (5) Tree structure + RBAC for fine-grained access control: Dossiers are organized in a multi-level folder tree, with each node having three levels of independent role permissions. The front end obtains the complete tree + permissions + uploaded files + signature status at once. Different users see different operable permission views on the same interface, which ensures both the integrity of information visibility and the compliance of operations.

[0030] (6) Multiple verification chains ensure compliance of submission: identity verification, mandatory return verification, signature verification and document verification before submission constitute a multi-layered defense system. If any layer fails, the submission cannot be completed, which fundamentally avoids the compliance risk of incomplete files entering the subsequent review process. IV. Description of the attached drawings

[0031] Figure 1 A schematic diagram of configuring a matrix for a four-dimensional context.

[0032] Figure 2 This is a diagram of a unified verification gateway architecture.

[0033] Figure 3 Flowchart for runtime context filtering.

[0034] Figure 4 This is a diagram illustrating the dot file tree structure and RBAC permissions.

[0035] Figure 5 Automatic bridging sequence diagram for documents → volumes.

[0036] Figure 6 Flowchart for submitting multiple verifications for case files. V. Detailed Implementation Methods

[0037] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the accompanying drawings and specific embodiments.

[0038] This example demonstrates how to expand document requirements through pure configuration operations when authentication rules change.

[0039] Scenario: The certification body receives a notification that the new version of the ISO 9001 standard requires that, before the contract is approved, an additional "Data Protection Impact Assessment Form" must be uploaded for the initial second phase (0102) Q system.

[0040] Traditional approach (hard-coded): Locate the CommonContractService.approval() method and add code checks before calling checkContractDocument() – this requires modifying the source code, writing unit tests, submitting code for review, and waiting for the release window.

[0041] Invention solution (configuration driver): The administrator logs into the system backend and enters the "Document Configuration" management interface.

[0042] Click "Add" and fill in the following fields: docId: A unique ID automatically generated by the system (e.g., DOC_DPIA_001) docName: "Data Protection Impact Assessment Form" Required: 1 (must be uploaded) process: Project30# (Contract process, status 30 = pending approval) csUuid: Q system UUID Audit Phase: 0102 (Initial Phase Two) docType: Word, PDF, Image (Restrictions on allowed file formats) docLimit: 1 (Limit to 1 document upload) Click Save.

[0043] Done. The above operations require no code modification, no service restart, and no redeployment. The next time any contract enters the "approval" stage, CommonDocumentService.getDocumentWithFileList() will automatically match the newly added configuration using a three-dimensional filter, and checkContractDocument() will check if the document has been uploaded; if not, the approval process will be blocked.

[0044] This example demonstrates the workflow of the unified verification gateway in the contract review process.

[0045] Scenario: A company's contract (contract ID CON-2024-001) is currently in the "Pending Review" status (status code = 20), associated with the certification system [Q, E], and in the review stage [0101, 0102]. The contract reviewer clicks "Submit" after passing the review.

[0046] step: The CommonContractService.review() method is called. Before the state progression logic is executed, line 966 first calls commonDocumentService.checkContractDocument("CON-2024-001").

[0047] checkContractDocument calls getDocumentWithFileList("Project", "CON-2024-001").

[0048] The internal execution of getDocumentWithFileList is as follows: Query the database for all ConfigDocument configuration records where the "process" field contains "Project" (assuming a total of 15 records). Call `contractService.getByContractId()` to get the contract status (20), and `projectCSService.listByContractList()` to get the certification system [Q,E] and audit stage [0101,0102]. 3D Filtering: Filter 1 (Process Subcategory): Keep entries where the process contains "Project20#" → 8 entries remaining. Filter 2 (Authentication System): Retain entries where csUuid is empty or the csUuid set [Q,E] is completely contained within [Q,E] → 5 entries remaining. Filter 3 (Audit Stage): Retain entries where auditPhase is empty or [0101,0102] is completely contained within the auditPhase configuration set → 4 entries remaining. Query the `document` table to retrieve all uploaded documents with `refId="CON-2024-001"` and `process="Project"`, and group them by `docId`. Assemble the ConfigDocumentWithFileListDto list: Of the 4 configuration requirements, 3 already have uploaded files, and 1 requires a missing document. The `checkContractDocument` command iterates through the configuration file pairing list and finds a missing item, then throws a `BizException`. The contract reviewer received a clear error message, located the missing document, uploaded it, and resubmitted it. After successful verification, the contract status changed from "Pending Review" to "Review Passed".

[0049] This example demonstrates the entire process of automatic bridging of documents to dossiers after the review plan is approved.

[0050] Scenario: Audit plan PLAN-2024-005 has been approved. A total of 5 documents were uploaded during the "Plan Submission" and "Plan Approval" stages. Among them, the "Audit Plan" and "Audit Scheme" documents have the archiveConfigId field set in the ConfigDocument configuration (associated with dossier configurations ARCH_001 and ARCH_002 respectively).

[0051] step: CommonPlanService.approval() executes, and checkPlanDocument() passes the verification.

[0052] The approval result is set to "Passed", and the plan status is updated to PLAN_APPROVAL_PASS.

[0053] Triggering document → dossier bridging process: Query all document records in the document table where process="Plan" and refId="PLAN-2024-005" → 5 records were found. Query the config_document table for configuration records whose docId is in the docId set of the above 5 documents and whose archiveConfigId is not empty → 2 records are obtained: "Audit Plan" (→ARCH_001) and "Audit Scheme" (→ARCH_002). Construct a mapping using ArchiveConfigId as the key: {ARCH_001: [Audit Plan], ARCH_002: [Audit Scheme]} Query the `config_archive` table, filter by the certification system and audit stage of this plan → confirm that both ARCH_001 and ARCH_002 are within the range. For each matching ConfigArchive: Create Archive entity records: Set archiveConfigId, planId, archiveId (Snowflake ID), name (copied from Document.name), url (copied from Document.url), size (copied from Document.size), and urlPdf (copied from Document.urlPdf). Insert archive table After bridging is completed, auditors can directly see the "Audit Plan" and "Audit Solution" files in the file management interface without having to upload them again.

[0054] This example demonstrates the assembly process of the dossier tree structure and the dynamic calculation of role permissions.

[0055] Volume directory structure (config_archive_folder table): folderId=ROOT, parentFolderId=null, name="Document Root Directory" folderId=F01, parentFolderId=ROOT, name="01 Audit Plan and Scheme" folderId=F02, parentFolderId=ROOT, name="02 Audit Records" folderId=F03, parentFolderId=ROOT, name="03 Non-conformity Report" Volume configuration (config_archive table, mounted under the corresponding folder): Call getArchiveTree(planId): Query all Folder nodes → Convert to ArchiveTree nodes Dynamically filter ConfigArchive based on the planned certification system and audit phase. Convert the filtered ConfigArchive into ArchiveTree leaf nodes and mount them under the corresponding folderId. Query the uploaded Archive records under this planId, group them by archiveConfigId, and mount them to the corresponding nodes. Call TreeUtil.makeTree() to assemble a flat list into a tree structure. For each node, call myPermission() to calculate the current user's permissions: Find the current user using planDto.getTeamList() and determine their role. Select the values ​​of permissionLeader / permissionMember / permissionOuter based on the role. Front-end effect: For team leader users: all nodes are visible, the audit plan and audit scheme are writable (permission=2), and the sign-in sheet and non-compliance report are writable.

[0056] For personnel outside the group: the audit plan, audit scheme, and non-compliance report are not visible (permission=0), only the attendance sheet is visible (permission=1).

[0057] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for verifying the integrity of business process documents based on multi-dimensional context configuration, characterized in that, Includes the following steps: Step S1 (Four-Dimensional Document Requirement Configuration): In the system management backend, pre-configure document requirement entries for each business process step. Each document requirement entry contains the following four dimensions of condition fields: (a) Process and Status Field: Stored in the encoding format of "process identifier + status code + separator", used to specify the process type to which the document requirement applies and the specific status under the process; (b) Certification System Field: One or more certification system identifiers connected by separators, used to specify the scope of certification systems to which the document requirement applies; (c) Audit Stage Field: One or more audit stage codes connected by separators, used to specify the scope of audit stages to which the document requirement applies; (d) Required Field: Boolean value, used to indicate whether the document is required to be uploaded or optional; Wherein, when the certification system field or audit stage field is empty, it means that there are no restrictions on the corresponding dimension; Step S2 (Unified Verification Entry Point): In multiple business modules of the business system, whenever a business process needs to advance from the current state to the next state, each business module uniformly calls the same document integrity verification service method as the only verification entry point. This method takes two parameters: process type identifier and business object identifier. Step S3 (Runtime Context Acquisition): After the document integrity verification service is invoked, it retrieves the real-time status of the current business object, as well as the list of authentication systems and the list of audit stages associated with the business object, from the database based on the input process type identifier and business object identifier, thus forming the runtime context. Step S4 (3D Context Filtering): All document requirement entries pre-configured in Step S1 are subjected to 3D filtering based on the runtime context obtained in Step S3: S4.1 Process Subcategorization Filtering: Check whether the process and status fields of each document requirement entry contain a target substring composed of the current process type, current status code, and the delimiter; only entries containing this substring or with an empty field are retained. S4.2 Authentication System Filtering: Check whether the authentication system field of the entries filtered by S4.1 completely contains the authentication system list of the current business object; only entries satisfying the complete inclusion relationship or with an empty field are retained. S4.3 Audit Stage Filtering: Check whether the audit stage field of the entries filtered by S4.2 completely contains the audit stage list of the current business object; only entries satisfying the complete inclusion relationship or with an empty field are retained. Step S5 (Association of Uploaded Files): For the remaining document requirement items after the three-dimensional filtering in Step S4, the uploaded document table is queried using the document identifier as the association key. The list of uploaded files is then mounted onto the corresponding document requirement item to form a configuration-file pairing data structure. Step S6 (Required File Verification): Traverse the configuration-file pairing list output in Step S5. For entries where the "Required" field is "Yes", check if their associated file list is empty. If a required file list is empty, immediately throw a business exception, block the process, and clearly indicate the missing document name in the exception information so that business personnel can locate and supplement the upload.

2. A business process document integrity verification system based on multi-dimensional context configuration, characterized in that, include: The document requirement configuration module is used to pre-configure document requirement items in the backend management interface in a four-dimensional orthogonal manner of process × status × certification system × audit stage. Each item includes process and status fields, certification system fields, audit stage fields, and whether it is required fields. The unified verification gateway module serves as the sole entry point for document integrity verification before all business modules in the system advance their processes. It provides verification methods to the outside world and receives process type identifiers and business object identifiers. The context acquisition module is used to obtain the real-time status of the current business object, the list of associated certification systems, and the list of audit stages based on the process type identifier and the business object identifier, thus forming the runtime context; The context filtering module is used to perform cascading filtering on pre-configured document requirement items across three dimensions: process sub-category filtering, certification system filtering, and audit stage filtering, based on the runtime context, and output the set of document requirements that are truly needed in the current stage. The file association module is used to query the uploaded documents table and mount the list of uploaded files to the filtered document requirement items, using the document identifier as the association key. The mandatory upload verification module is used to traverse the configuration-file pairing list, check whether the mandatory upload item has a corresponding uploaded file, and throw a business exception to block the process and prompt the missing document name when it is missing.

3. The method according to claim 1 or the system according to claim 2, characterized in that, The unified call to the same document integrity verification service in step S2 covers at least nine business steps: contract submission, contract review, contract approval, audit plan delegation, audit plan submission, audit plan approval, file submission, technical review approval, and certification decision approval. All steps perform verification by calling the checkPlanDocument or checkContractDocument methods of the document integrity verification service, rather than implementing independent verification logic in each module.

4. The method according to claim 1 or the system according to claim 2, characterized in that, After step S6 is executed, if the verification passes, the business module continues to execute the status advancement logic. After the status advancement logic is completed, if the current business object is an audit plan and the status advancement result is approval passed, the document-to-file bridging process is automatically triggered, which includes the following sub-steps: S7.1 Query stage - query all document records uploaded under the audit plan from the document table; S7.2 Filtering stage - query the config_document configuration table with the document's docId as the key, filter out documents with a non-empty archiveConfigId field, and query the matching file configuration list in the config_archive configuration table according to the audit plan's authentication system and audit stage; S7.3 Bridging stage - for each document record that meets the bridging conditions, extract the file name, storage address, and file size fields from the document record, obtain the target file configuration identifier from the archiveConfigId of config_document, generate a new Snowflake ID as the archiveId, and create a new Archive record to write to the database; S7.4 Completion Phase – After bridging is completed, auditors can directly see the file records automatically converted from documents in the file management interface without having to upload them again.

5. The method according to claim 1 or the system according to claim 2, characterized in that, The method also includes dossier structure management, specifically: organizing dossiers into a multi-level folder tree structure, wherein the hierarchical relationship of folder nodes is expressed through the parent folder identifier field; each dossier configuration entry is mounted under a certain folder node, forming a dossier configuration tree; during runtime, dossier configuration entries are dynamically filtered according to the certification system and audit stage of the current audit plan, and matching dossier configuration entries are mounted to the corresponding folder nodes, finally assembling into a complete tree structure containing folder nodes and dossier configuration nodes, and returning it to the front end for display at once.

6. The method or system according to claim 5, characterized in that, Each dossier configuration entry also contains three independent role permission fields: group leader permission field, group member permission field, and outsider permission field; each permission field can be set to one of invisible, read-only, or write; at runtime, based on the user's actual role (group leader, group member, or outsider) in the audit plan, the user's actual operation permissions for each dossier node are dynamically calculated, so as to present differentiated permission views for different users in the same dossier tree.

7. The method or system according to claim 5, characterized in that, The volume file configuration entries also include: a field indicating whether a return is mandatory, a file type restriction field, and a file quantity restriction field; the volume file structure management also includes multiple validations during volume file submission. First step: The dossier must be returned for verification. The dossier tree is recursively traversed. For the dossier configuration node where the field to be returned is "yes", the record of the uploaded dossier is checked. If it does not exist, the submission is blocked. The second step: verification of the integrity of case file signatures, checking whether all case file signature records under this review plan have been signed; The third step: document integrity verification, which calls the document integrity verification service described in step S2 to check whether the document for the audit plan has been completely uploaded; Only after all three verifications pass can the case file be submitted to the next stage of the process.

8. The method according to claim 1 or the system according to claim 2, characterized in that, The document requirement items in step S1 also include: a file type restriction field and a file quantity restriction field, which are used to impose front-end constraints on file format and upload quantity when uploading documents; the document requirement items also include an associated volume configuration identifier field, which is used to associate document requirements with volume configuration, supporting automatic bridging of documents to volumes as described in step S4.

9. The method according to claim 1 or the system according to claim 2, characterized in that, The three-dimensional context filtering in step S4 is implemented through streaming filtering: first, all pre-configured document requirement items are converted into a data stream, and then three functional filtering conditions—process sub-category filtering, certification system filtering, and audit stage filtering—are applied in sequence. Items that do not meet each filtering condition are excluded from the data stream, and the items that are finally retained are the set of document requirements that are truly needed in the current stage.

10. The method according to claim 1 or the system according to claim 2, characterized in that, In step S3, when the process type is a contract process, the authentication system list and audit stage list of the current business object are obtained from the contract system association table; when the process type is an audit plan process, the authentication system list and audit stage list of the current business object are obtained from the plan stage table. The two process types use the same filtering logic, only differing in the source of context data, thus achieving unified verification logic for contract processes and audit plan processes.

Images