File data checking method and system, medium and electronic equipment

Abstract

The invention provides a file data checking method and system, a medium and electronic equipment. A table data dynamic expansion array and a paragraph data dynamic expansion array are extracted by obtaining a standard analysis file; and calling a rule base comprising charge checking calculation, a qualification name base, exclusive clause detection based on a longest common substring algorithm, a text repetition degree judgment rule, a sequential logic rule, a project grade division rule and other rules to perform comparison verification on the structured data to generate an exception report comprising a file source and exception information. According to the method and the device, automatic file checking is realized, traditional technical obstacles are overcome, and the file checking accuracy is improved.

Description

Technical Field

[0001] This application belongs to the field of data technology and relates to a document compliance check, and in particular to a document data verification method, system, medium and electronic device. Background Technology

[0002] A significant technical bottleneck exists in the current review process of procurement documents or contracts for water conservancy and hydropower survey and design services: review systems often treat documents simply as linear text streams, lacking the ability to deeply analyze document structure. This approach prevents the system from effectively identifying and extracting the row and column topological relationships of tables in the document, making it difficult to automate complex verification tasks based on table data (such as cost verification) and time-series-based verification tasks (such as performance table time window verification).

[0003] Traditional manual review methods, when faced with a large volume of procurement documents, often require reviewers to expend considerable effort on tedious details, yet still struggle to uncover some hidden but crucial issues. Particularly concerning timeline, manual review easily overlooks illogical time-series conflicts, such as awarding the contract before the review process, or signing the contract before issuing the notification of award—clearly illogical errors. These conflicts not only violate the fundamental logic of the procurement process but may also affect the legal validity of the procurement. Summary of the Invention

[0004] The purpose of this application is to provide a document data verification method, system, medium, and electronic device to improve the efficiency and accuracy of document review.

[0005] Firstly, this application provides a document data verification method, which includes: obtaining a standard parsing file; extracting data from the standard parsing file to obtain structured data, the structured data including a dynamically expanding array of table data and a dynamically expanding array of paragraph data; calling a rule base to compare and verify the structured data to obtain anomaly results; and generating and outputting an anomaly report based on the anomaly results, the anomaly report including the document source and anomaly information.

[0006] In one implementation of the first aspect, the process of extracting data from the standard parsing file to obtain structured data includes: extracting table data from table objects in the standard parsing file to obtain a dynamically expanding array of table data; and extracting paragraph data from document paragraph objects in the standard parsing file to obtain a dynamically expanding array of paragraph data.

[0007] In one implementation of the first aspect, the process of calling the rule base to compare and verify the structured data to obtain abnormal results includes: traversing the dynamically expanded array of the table data to locate the table containing keywords in the table header; and performing cost verification on the table containing keywords to obtain the cost table verification result.

[0008] In one implementation of the first aspect, the keywords include unit price, quantity of work, frequency, and total price; a verification judgment is made on whether the total price is equal to the product of the unit price, the quantity of work, and the frequency to obtain the abnormal result.

[0009] In one implementation of the first aspect, the process of calling a rule base to compare and verify the structured data to obtain abnormal results further includes: dynamically expanding an array based on the paragraph data to obtain a first text and a second text; comparing the lengths of a first string in the first text and a second string in the second text to obtain a short string and a long string; using a longest common substring dynamic programming algorithm based on the first string and the second string to obtain the longest common substring between the first string and the second string; using the longest common substring dynamic rule algorithm to construct a two-dimensional array to record the substring matching length, determining the length and end position of the longest common substring to extract the longest common substring; obtaining a similarity percentage based on the longest common substring and the long string; obtaining the repetition degree between the first text and the second text based on the similarity percentage; and obtaining the abnormal result based on the repetition degree.

[0010] In one implementation of the first aspect, the process of generating and outputting an exception report based on the exception result includes: storing the file source in the exception result into a dynamically expanding file array; storing the exception information in the exception result into a dynamically expanding content array; and outputting a DOCX table and a visualization form based on the dynamically expanding file array and the dynamically expanding content array.

[0011] In one implementation of the first aspect, the method further includes: numbering the imported standard parsing files in chronological order.

[0012] Secondly, this application provides a file data verification system comprising: a file acquisition module for acquiring a standard parsed file; a data extraction module for extracting data from the standard parsed file to obtain structured data, the structured data including a dynamically expanding array of table data and a dynamically expanding array of paragraph data; an anomaly result acquisition module for calling a rule base to compare and verify the structured data to obtain anomaly results; and an anomaly report output module for generating and outputting an anomaly report based on the anomaly results, the anomaly report including the file source and anomaly information.

[0013] Thirdly, this application provides an electronic device, the electronic device comprising: a memory storing a computer program thereon; and a processor communicatively connected to the memory for executing the computer program to implement the above-described file data verification method.

[0014] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by an electronic device, implements the above-described file data verification method.

[0015] As described above, the beneficial effects of the document data verification method, system, medium, and electronic device described in this application are as follows:

[0016] By extracting data from standard parsed files, structured data containing dynamically expanding arrays of table data and paragraph data is obtained. By calling the rule base to compare and verify the structured data, abnormal results are obtained, thereby obtaining the file source and specific abnormal information of the abnormal results. This realizes automated file checking and improves the accuracy and efficiency of verification. Attached Figure Description

[0017] Figure 1A This diagram illustrates an application scenario of the document data verification method described in this application.

[0018] Figure 1B This diagram illustrates the structure of the interaction process between the client and the cloud server in these implementation methods.

[0019] Figure 2 The diagram shows a process schematic of the document data verification method described in the embodiments of this application.

[0020] Figure 3 The diagram shows a verification process for a single cost calculation table as described in an embodiment of this application.

[0021] Figure 4 The diagram shows the verification process of multiple cost calculation tables described in the embodiments of this application.

[0022] Figure 5 The diagram shown is a schematic representation of the process for obtaining abnormal results as described in an embodiment of this application.

[0023] Figure 6 The diagram shown is a flowchart illustrating the document data verification method described in this application embodiment.

[0024] Figure 7 The diagram shown is a structural schematic of the document data verification system described in this application embodiment.

[0025] Figure 8The diagram shown is a structural schematic of the electronic device described in an embodiment of this application.

[0026] Component designation explanation

[0027] 1. Document Data Verification Device

[0028] 11 Storage devices

[0029] 12 Local Processors

[0030] 13 Display Terminals

[0031] 2. Client-Cloud Server Interaction System

[0032] 20 terminals

[0033] 21 Cloud Servers

[0034] 100 Document Data Verification System

[0035] 101 File Acquisition Module

[0036] 102 Data Extraction Module

[0037] 103 Abnormal Result Acquisition Module

[0038] 104 Anomaly Report Output Module

[0039] 200 electronic devices

[0040] 201 Memory

[0041] 202 processor

[0042] 203 Monitor

[0043] Steps S11 to S14

[0044] Steps S21 to S27 Detailed Implementation

[0045] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0046] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0047] A significant technical bottleneck exists in the current review process of procurement documents or contracts for water conservancy and hydropower survey and design services: review systems often treat documents simply as linear text streams, lacking the ability to deeply analyze document structure. This approach prevents the system from effectively identifying and extracting the row and column topological relationships of tables in the document, making it difficult to automate complex verification tasks based on table data (such as cost verification) and time-series-based verification tasks (such as performance table time window verification).

[0048] Traditional manual review methods, when faced with a large volume of procurement documents, often require reviewers to expend considerable effort on tedious details, yet still struggle to uncover some hidden but crucial issues. Particularly concerning timeline, manual review easily overlooks illogical time-series conflicts, such as awarding the contract before the review process, or signing the contract before issuing the notification of award—clearly illogical errors. These conflicts not only violate the fundamental logic of the procurement process but may also affect the legal validity of the procurement.

[0049] Manual review also has significant limitations in cost calculation. Cost calculations in procurement documents typically involve multiple tables and complex mathematical formulas, including various rates, coefficients, and adjustment factors. During manual review, reviewers find it difficult to fully verify all calculation steps, easily overlooking errors or omissions in the calculation process, leading to inaccurate final cost calculations. Such calculation errors may cause contractual disputes or even economic losses during project execution.

[0050] Furthermore, due to a lack of in-depth understanding of document structure, existing review systems are unable to effectively identify cross-references within documents, and cannot verify the consistency and completeness between different parts of the document. This blind spot in review may result in contradictory content or missing information in procurement documents, creating potential problems for subsequent project implementation.

[0051] At least in response to the above-mentioned problems, the following embodiments of this application provide a method for verifying document data.

[0052] Figure 1A This diagram illustrates an application scenario of the document data verification method described in this application. The document data verification device 1 can be used to implement the document data verification method provided in the embodiments of this application, but the application scenarios of the document data verification method provided in the embodiments of this application are not limited to this. Figure 1A The document data verification device 1 shown is as follows. Figure 1A As shown, the file data verification device 1 includes a storage device 11, a local processor 12, and a display terminal 13. The file data verification method provided in this embodiment can be applied to the local processor 12. The storage device 11 stores standard parsed files, rule base data, and intermediate data during the verification process. The local processor 12 executes the core computational tasks of the file data verification method, such as data extraction and rule base verification. In a local processing scenario, the storage device 11 stores the standard parsed file to be verified, the local processor 12 retrieves the file from the storage device 11 and performs data extraction and rule base verification steps, and displays the processed verification results to the user through the display terminal 13.

[0053] in, Figure 1A The local processor 12 can be a single local processor, a cluster of multiple local processors, or a cloud computing center, etc., and is not specifically limited here. Although Figure 1A Only one storage device 11, one local processor 12, and one display terminal 13 are shown, but it should be understood that... Figure 1A The examples in this paper are only for understanding this solution. The specific number of local processors 12 and display terminals 13 should be flexibly determined based on the actual situation.

[0054] In some other implementations, the file data verification device 1 may not include a display terminal 13, but only a local processor 12 with display functionality and a storage device 11. The file data verification method provided in this application embodiment can be applied to the local processor 12. The local processor 12 with display functionality may include tablet computers, laptops, handheld computers, mobile phones, personal computers, and voice interaction devices, or it may be a monitoring device, etc., which is not limited here.

[0055] In some other implementations, the file data verification method described in this application can be applied to the interaction process between the client and the cloud server. Figure 1B This diagram illustrates the structural process of client-cloud server interaction in these implementations. (Example:) Figure 1B As shown, the client-cloud server interaction system 2 includes a terminal 20 and a cloud server 21. The terminal 20 and the cloud server 21 can communicate with each other, and the communication method is not limited to wired or wireless.

[0056] The terminal 20 can be mobile or fixed. For example, it can be a wireless terminal or a wired terminal. A wireless terminal can refer to a device with wireless transceiver capabilities and can be deployed indoors or outdoors. The terminal 20 can be a mobile phone, tablet computer, laptop computer, etc., and is not limited thereto. The cloud server 21 can include one or more servers, or one or more processing nodes, or one or more virtual machines running on the server. The cloud server 21 can also be referred to as a server cluster, management platform, data processing center, etc., and is not limited thereto in this embodiment.

[0057] The technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0058] Figure 2 This is a schematic diagram illustrating the process of a document data verification method in one embodiment of this application. For example... Figure 2 As shown, the file data verification method includes the following steps S11 to S14.

[0059] Step S11: Obtain the standard parsing file. The standard parsing file is based on the Office Open XML format and is used for verification documents such as project application documents and negotiation procurement documents in the procurement process of water conservancy and hydropower survey and design services.

[0060] Step S12 involves extracting data from the standard parsing file to obtain structured data. The structured data includes a dynamically expanding array of table data and a dynamically expanding array of paragraph data. A variable number of data items are stored in the dynamically expanding array, with the array length defined based on the data volume. In one embodiment of this application, the process of extracting data from the standard parsing file to obtain structured data includes: extracting table data from table objects in the standard parsing file to obtain the dynamically expanding array of table data; and extracting paragraph data from document paragraph objects in the standard parsing file to obtain the dynamically expanding array of paragraph data.

[0061] For example, the process of extracting table data from a table object in a standard parsing file to obtain a dynamically expanding array of table data includes: inputting a table object from a docx document, converting the table object into the total number of rows and paragraph text for each row, extracting the number of columns and column text for each row, where the paragraph text is composed into a long string in the format "{total number of columns in the current row\text of column 1 in the current row\text of column 2 in the current row\...\text of column N in the current row}", and storing it in the dynamically expanding array of table data. The dynamically expanding array of table data is a two-dimensional dynamically expanding array, with the array form "LstrTableData[i][j]", where "i" is the file number and "j" is the data number, used to store the total number of rows and the text of each column in the standard parsing file, preserving the row and column topology of the table. Using a two-dimensional dynamically expanding array of table data can preserve the row and column topology of the table, supporting subsequent logical verification.

[0062] The process of extracting paragraph data from document paragraph objects in a standard parsing file to obtain a dynamically expanding paragraph data array includes: inputting a document paragraph object, extracting the paragraph text, font size, font, horizontal alignment information, and bold attribute from the document paragraph object, and storing them in the dynamically expanding paragraph data array. The dynamically expanding paragraph data array is a two-dimensional dynamically expanding array with the format "LstrParaData[i][k]", where "i" is the file sequence number and "k" is the paragraph number, used to store the paragraph text in the standard parsing file. Using this two-dimensional dynamically expanding paragraph data array, if the text data repetition exceeds a threshold, it is considered a violation. This dynamically expanding paragraph data array enables accurate identification of discriminatory clauses (e.g., "local businesses only"), providing a data foundation for title recognition and clause matching.

[0063] Specifically, the paragraph text, font, font size, and horizontal alignment information in the document are stored in a dynamically expanding array of two-dimensional string paragraph data. The bold text, font, font size, file number, and paragraph number in the document paragraphs are stored in a dynamically expanding array of one-dimensional string paragraph data. The underlined text, font, font size, file number, and paragraph number in the document paragraphs are also stored in a dynamically expanding array of one-dimensional string paragraph data.

[0064] Furthermore, the table data search module is used to search for tables from the dynamically expanding array of table data whose headers match the given file number, start number, end number, whether the number of columns is given, and 8 short texts for 12 parameters. The paragraph search module is used to search for paragraphs from the current file number that contain parallel short texts with superimposed "*", font, font size, and bold text.

[0065] Furthermore, the document processing module includes a project application document processing module and a negotiation procurement document processing module. The project application document processing module numbers the paragraphs or tables in the imported files according to their order (each table is considered as one paragraph). It identifies the first and second level headings and their corresponding paragraph numbers based on the maximum number of characters, font size, font, and bold. The text content, font size, font, bold, and underline information of the headings are stored in the corresponding dynamically expanding string arrays. The module compares the headings at each level with the selected rule base for deduplication, and identifies the headings with the highest repetition rate that exceeds the preset similarity threshold as similar headings. It also checks the continuity of the numbering in the paragraphs and tables, and whether the project name and the name of the purchaser are consistent.

[0066] The negotiation and procurement document processing module verifies, based on selected rules, whether the project level matches the application time, project funding source (self-funded or market-contracted), and project amount. It converts specific dates to integers to check if the project initiation time, procurement document review time, bid award time, and contract signing time in the schedule are sequentially later than the previous one, verifying whether the time schedule logic conforms to the selected time schedule logic table. It checks whether the total price matches the project amount, and identifies the most duplicated items exceeding a preset similarity threshold to check whether the qualification conditions for ship access meet risk management requirements. It checks whether the financial situation of the past two or three years requires continuous losses to enhance risk resistance by including the terms "not continuous" and "loss". It also checks whether the performance and financial situation time ranges are accurate by including specific dates and "up to the bid deadline". The negotiation procurement document processing module also includes checking whether the text section titles and cited chapter names in the main text match the table of contents using text equality checks; checking whether the purchaser's name, project name, procurement scope, procurement method, supplier solicitation method, qualification requirements, review method, and project application documents are consistent using text equality checks; and comparing the procurement announcement, bidder instructions, security agreement, confidentiality agreement, integrity agreement, compliance commitment, quotation letter, power of attorney and legal representative's identity certificate, deviation table, template for commitment letter to pay migrant workers' wages on time and in full, commitment letter to not have any specific related persons, bidder's basic information table, qualification and certification certificates, financial status table, staffing table, resume table of key personnel, and main equipment table using text equality checks.

[0067] Step S13 involves calling the rule base to compare and verify the structured data to obtain anomaly results. The rule base includes various pre-stored rules, such as fee calculation rules, qualification name databases, exclusivity clause determination rules, text duplication determination rules, temporal logic rules, and project level classification rules. The rule base is used to perform core verifications, such as fee calculation and exclusivity clause detection, on the structured data extracted from the standard parsing file.

[0068] In one embodiment of this application, the process of calling the rule base to compare and verify the structured data to obtain abnormal results includes: performing cost verification on the cost table in the structured data, specifically including: traversing the dynamically expanded array of the table data to locate the table containing keywords in the table header; performing cost verification on the table containing keywords to obtain the cost table verification result.

[0069] In one embodiment of this application, the keywords include unit price, quantity of work, frequency, and total price; the total price is checked to determine whether it is equal to the product of the unit price, the quantity of work, and the frequency, so as to obtain the abnormal result.

[0070] For example, the system iterates through dynamically expanding arrays of table data, identifies and locates tables whose headers contain "unit price," "workload or quantity or number (including similar synonyms)," and "total price or subtotal." For each row, it checks if the columns corresponding to the unit price and quantity are not empty. It then verifies row by row the formula "total price = unit price × workload × frequency item (if there is no frequency item, the default frequency is 1)" to determine if it holds true, and whether the sum of the total prices matches the total price. When multiple levels of cost tables need to be verified, the cost tables are first located, and the table with the highest total price is used as the summary table. The system then verifies whether the total price in the summary table matches the sum of the total prices in the other cost tables. By performing cost verification on tables containing keywords, logical errors in cost calculations can be automatically detected, replacing manual calculations and greatly improving accounting efficiency.

[0071] Figure 3 This is a schematic diagram illustrating the verification process of a single cost calculation table in one embodiment of this application. For example... Figure 3 As shown, the verification process for a single cost estimate sheet includes the following steps.

[0072] S100, perform keyword identification on the header of the dynamically expanded array LstrTableData[0][i] of the document i=1 to determine whether it contains the agreed unit price item, workload item and total price item.

[0073] S101, determine whether the dynamically expanded array LstrTableData[0][i] of table data contains frequency items.

[0074] S102, when a frequency item is included, remember the column order of the frequency item, j = i + 1, otherwise the frequency is 1 by default, j = i + 1, where j: data block index (0 = total number of rows, 1 ~ n = row data).

[0075] S103, if j < LstrTableData[0][i - 1] + i + 1 holds, then the unit price item, workload item, and total price item are not empty, and verify that the total price = unit price × workload × frequency. If the verification result does not match, add an exception and correct the total price. At this time, j = j + 1.

[0076] S104, if j < LstrTableData[0][i - 1] + i + 1 does not hold, then determine whether the total price is equal to the sum of the total prices. If not, add an exception and correct the total price.

[0077] It should be noted that the above labels S100 to S104 are only used to label different steps, rather than to limit the execution order between these steps.

[0078] Figure 4 Shown is a schematic diagram of the verification process of multiple cost calculation tables in an embodiment of the present application. As Figure 4 shown, the verification process of multiple cost calculation tables includes the following steps.

[0079] S200, determine whether there is still a cost calculation table in the dynamic expansion array of table data.

[0080] S201, if not, then verify the current cost calculation table.

[0081] S202, if so, then find the one with the largest total price in each cost table as the summary total price table, and accumulate the total prices of the remaining cost calculation tables.

[0082] S203, verify whether the summary total price is equal to the sum of the other total prices.

[0083] S204, if so, then add an exception and correct the summary total price.

[0084] It should be noted that the above labels S200 to S204 are only used to label different steps, rather than to limit the execution order between these steps.

[0085] In some embodiments, a pumped storage power station survey and design quotation document is input. This quotation document is in docx format. The process of verifying the cost of this quotation document is as follows: A cost table is obtained by extracting tables from the quotation document. The cost table is parsed to obtain the number of rows in the calculation table and stored in the format "Serial Number\Cost Item\Quantity\Unit Price\Total Price\Remarks". Logical verification is performed on the cost table, identifying the table headers containing keywords such as "unit price", "total price" (including but not limited to total price, total amount, or subtotal), and "workload" (including but not limited to quantity). Cost verification is performed based on these keywords. For example, if the unit price is 1000 yuan, the quantity is 5, the total price is 9000 yuan, and the frequency is 1 when empty, the verification shows that the expected value of 5000 yuan does not match the actual value of 9000 yuan, thus an error occurs. The total price in row 7 should be 5000 yuan.

[0086] In some embodiments, when verifying the performance table, adjustments can be made based on the expense table as needed. For example, horizontal header matching can be used when verifying the expense table, while vertical three-row feature matching can be used when verifying the performance table. Alternatively, if the table has no fixed features, all tables can be traversed to check whether the column names contain "contract signing time" and the number of rows is greater than 5, and the compliance of the time window can be verified.

[0087] In some embodiments, when the table header has no fixed characteristics, the process for identifying and verifying performance tables is as follows: Traverse all tables and calculate tables whose column names contain "Contract Signing Time". If the number of rows is greater than 5 and contains a "Project Name" column, it is determined to be a performance table. Extract the time column values ​​from the table and verify whether the time column values ​​are within the qualification condition time window (e.g., January 1, 2020 - December 31, 2024).

[0088] Figure 5 This is a schematic diagram illustrating the process of obtaining abnormal results in one embodiment of this application. For example... Figure 5 As shown, the process of calling the rule base to compare and verify the structured data to obtain abnormal results also includes identifying and detecting exclusive clauses in the structured data, specifically including the following steps S21 to S27.

[0089] Step S21: Dynamically expand the array based on the paragraph data to obtain the first text and the second text.

[0090] Step S22: Compare the lengths of the first string in the first text and the second string in the second text to obtain the short string and the long string.

[0091] Step S23: Based on the first string and the second string, use the longest common substring dynamic programming algorithm to obtain the longest common substring between the first string and the second string.

[0092] Step S24: The longest common substring dynamic rule algorithm is used to construct a two-dimensional array to record the substring matching length, determine the length and end position of the longest common substring, and extract the longest common substring.

[0093] Step S2S25: Obtain the similarity percentage based on the longest common substring and the long string.

[0094] Step S26: Obtain the degree of repetition between the first text and the second text based on the similarity percentage.

[0095] Step S27: Obtain the abnormal results based on the repeatability.

[0096] For example, a first text, a first string, a second text, and a second string are obtained from a dynamically expanded array of paragraph data. The lengths of the first and second strings are compared using a dynamic programming algorithm for the longest common substring, with the longer string designated as the long string and the shorter string as the short string. The longest common substring is calculated using dynamic programming, and its length and end position are recorded to extract it. The longest common substring of the short and long strings is calculated, and the similarity percentage is obtained by calculating the percentage of the longest common substring's length relative to the length of the longer string. A threshold is applied to this similarity percentage to determine the degree of repetition between the first and second texts; higher similarity indicates greater text similarity. By identifying and detecting exclusive clauses in the structured data, duplicate and potentially conflicting clauses in contracts or documents can be detected. When the similarity exceeds a certain threshold, these clauses can be marked for further review to ensure document consistency and compliance.

[0097] The Exclusivity Clause module searches the current document for clauses with the highest repetition rate (length of the longest common substring / maximum length of the current text and the rule text) that exceed a preset similarity threshold. It then checks for exclusive clauses that restrict eligibility to specific administrative regions, regional awards, patents, trademarks, brands, countries of origin, suppliers, differentiated qualification reviews, different evaluation standards, or unreasonable qualification bundling. The Unreasonable Bonus Items module searches the current document for clauses with the highest repetition rate that exceed a preset similarity threshold. It checks for clauses that set specific patents, brands, manufacturers, imported products, state-owned enterprises, or unreasonable local performance, industry performance, or cooperation experience with a specific entity as bonus items. The Contract Management module compares the titles of all clauses in the current negotiated procurement document with the clauses that have the highest repetition rate and exceed a preset similarity threshold against the corresponding clauses in the selected contract template. The Review Method Management module compares the titles of all levels in the current negotiated procurement document with the titles that have the highest repetition rate and exceed a preset similarity threshold against the selected review method template. The performance management module includes a horizontal performance management module and a vertical performance management module. The horizontal performance management module searches all tables in the current file, including those with preset horizontal performance headers, and checks whether the contract signing time for non-empty performance items in those tables falls within the time range set by the qualification criteria. The vertical performance management module checks whether the contract signing time for non-empty performance items in those tables falls within the time range set by the qualification criteria.

[0098] Furthermore, when determining the threshold for the similarity percentage, the threshold can be dynamically adjusted according to actual needs. For example, a strict threshold of 75% can be set for exclusive clauses, while a more lenient threshold of 65% can be set for contract templates.

[0099] In some embodiments, the process of identifying and detecting exclusive clauses in structured data employs a hybrid model that integrates multiple strategies, including:

[0100] 1. Rule-based keyword matching: First, a predefined exclusive keyword library (such as "only", "prohibited", "a certain brand", etc.) is used for quick filtering to initially screen out highly suspicious clauses.

[0101] 2. Syntactic structure-based analysis: Dependency syntactic analysis or component analysis is performed on the initially screened clauses to identify the restrictive subject (such as "enterprise"), restrictive conditions (such as "local"), and restrictive behaviors (such as "participate in bidding" and "participate in quotation") in the clauses, and to determine whether their structure is consistent with the common patterns of exclusive clauses.

[0102] 3. Semantic-based deep matching: For clauses that have passed the first two layers of screening, the aforementioned deep learning semantic model is used to perform accurate similarity calculation.

[0103] The final decision is based on the combined results of the three-layer analysis above, and a final conclusion is reached through a weighted average or voting mechanism, which greatly improves the accuracy and recall of identification and reduces the false positive and false negative rates.

[0104] Furthermore, the environmental safety compliance module scans the current document to check for any missing mandatory environmental safety statements from the preset rule base. The preset rule base module automatically imports external rules (including project classification tables published over the years, exclusive clause libraries, environmental safety mandatory clause error libraries, progress logic tables, cost table thesaurus, project application document templates, procurement announcement templates, bidder instructions templates, review method templates, contract templates, safety agreement templates, confidentiality agreement templates, integrity agreement templates, compliance commitment letter templates, quotation letter templates, power of attorney and legal representative identity certificate templates, deviation table templates, commitment letter for timely and full payment of migrant workers' wages templates, commitment letter templates for no specific related parties, bidder basic information table templates, qualification and certification templates, financial status table templates, performance templates, staffing table templates, key personnel resume table templates, and key equipment allocation table templates) to create several rules. The rule base selection module then selects the applicable rules based on the user's choices.

[0105] Step S14: Generate and output an anomaly report based on the anomaly result. The anomaly report includes the file source and anomaly information.

[0106] In one embodiment of this application, the process of generating and outputting an anomaly report based on the anomaly result includes: storing the file source in the anomaly result into a dynamically expanding file array; storing the anomaly information in the anomaly result into a dynamically expanding content array; and outputting a DOCX table and a visualization form based on the dynamically expanding file array and the dynamically expanding content array.

[0107] For example, the document source includes project application or procurement documents. Anomaly information includes anomaly content, anomaly coordinates (e.g., paragraph k in document i), suggested solutions, and anomaly level (hint, warning, and error). The anomaly report can be output in DOCX tables and visual forms. The DOCX table is an automatically generated Word document format report containing all detected anomalies, with each entry including the document source, anomaly content, and anomaly coordinate location hints for user viewing and correction within a document environment. The visual form is a graphical interface window that displays anomaly information using a table display component (e.g., a DataGridView control). These two output formats allow users to flexibly view the anomaly report and prompt them to modify anomalies that failed compliance checks.

[0108] The following section will provide a detailed description of the document data verification method provided in this application through a specific example. It should be noted that the content of this example is only used to explain and illustrate the document data verification method provided in this application, and is not intended to limit the scope of protection of this application in any way. In specific applications, appropriate steps can be added or deleted based on this example according to actual needs. Figure 6 This is a flowchart illustrating the file data verification method used in this example. Figure 6 As shown, the file data verification method in this example includes the following steps.

[0109] S300 automatically imports the rule base from the default directory and sets the rule base document parsing layer and the interpersonal interaction rule base establishment layer.

[0110] S301, import the project application document (DOCX) and the negotiated procurement document (DOCX).

[0111] S302, extract the table data from the project application document to obtain the dynamically expanded array LstrTableData[0][j], and extract the paragraph data from the negotiation procurement document to obtain the dynamically expanded array LstrParaData[1][j].

[0112] S303 extracts the first and second level headings from the dynamic array of table data, compares the headings with the rules, extracts keywords between headings, and compares the keywords with the rules.

[0113] S304 performs project-level matching verification on dynamically expanded arrays of table data, reviews progress plans according to time sequence logic and rule base, checks eligibility conditions, detects exclusive clauses, and checks review methods.

[0114] S305 extracts the first and second level headings from the dynamically expanded array of paragraph data and compares the headings with the rules.

[0115] S306 performs a matching check on the chapter names, text references, and table of contents of the dynamically expanded array of paragraph data.

[0116] S307 extracts keywords from the headings of the dynamically expanded array of paragraph data, checks the consistency of keywords, compares the keywords with the rules, and compares the table with the rules.

[0117] S308 cross-validates the project application documents with the negotiated procurement documents.

[0118] S309, check the authorization scheme and add any abnormal results to the dynamically resizing array Lstrconclusion.

[0119] S310 outputs the exception results to the form and docx.

[0120] It should be noted that the labels S300 to S310 are only used to indicate different steps, and not to restrict the execution order of these steps.

[0121] In summary, the document data verification method of this application automates the inspection of project application documents and negotiation procurement documents in the procurement process of water conservancy and hydropower survey and design services to determine whether the documents comply with relevant laws, regulations, and industry standards, thereby improving the compliance and efficiency of the procurement process. The method utilizes dynamic verification based on "total price = unit price × workload × frequency," overcoming the technical obstacle of traditional OCR's inability to parse table topological relationships, and intelligently splits merged cells, avoiding errors from manual calculations. The method also uses the longest common substring algorithm for exclusive clause detection, improving the accuracy and matching precision of semantic variant recognition (preferring local companies over rejecting out-of-province suppliers).

[0122] The scope of protection of the document data verification method described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0123] This application also provides a document data verification system, which can implement the document data verification method described in this application. However, the implementation device of the document data verification method described in this application includes, but is not limited to, the structure of the document data verification system listed in this embodiment. All structural modifications and substitutions of the prior art made based on the principles of this application are included within the protection scope of this application.

[0124] Figure 7 The diagram shown is a structural schematic of a document data verification system according to an embodiment of this application. Figure 7 As shown, the file data verification system 100 includes: a file acquisition module 101, a data extraction module 102, an anomaly result acquisition module 103, and an anomaly report output module 104. The file acquisition module 101 is used to acquire standard parsed files, such as... Figure 1A The file acquisition module 101 can read the standard parsed file from the storage device 11 via the local processor 12 to achieve local file acquisition. The data extraction module 102 is used to extract data from the standard parsed file to obtain structured data, which includes dynamically expanding arrays of table data and paragraph data. The anomaly result acquisition module 103 is used to call a rule base to compare and verify the structured data to obtain anomaly results. The anomaly report output module 104 is used to generate and output an anomaly report based on the anomaly results, which includes the file source and anomaly information.

[0125] It should be noted that, Figure 7 The modules in the document data verification system 100 shown are related to... Figure 2 The steps in the document data verification method correspond one by one, and will not be elaborated here.

[0126] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0127] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0128] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0129] This application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the file data verification method provided in this application. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state hard disk, magnetic tape, floppy disk, optical disk, and any combination thereof. The above storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0130] This application embodiment may also provide an electronic device. Figure 8 The diagram shown is a structural schematic of an electronic device 200 according to an embodiment of this application. Figure 8 As shown, in this embodiment, the electronic device 200 includes a memory 201 and a processor 202.

[0131] The memory 201 is used to store computer programs. In some possible implementations, the memory 201 may include various media capable of storing program code, such as ROM, RAM, magnetic disk, USB flash drive, memory card, or optical disk.

[0132] In this embodiment, memory 201 may include a computer system readable medium in the form of volatile memory, such as RAM and / or cache memory. Electronic device 200 may further include other removable / non-removable, volatile / non-volatile computer system storage media. Memory 201 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0133] The processor 202 is connected to the memory 201 and is used to execute the computer program stored in the memory 201 so that the electronic device 200 performs a file data verification method.

[0134] For example, processor 202 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc. In other embodiments, processor 202 may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0135] In some implementations, the electronic device 200 provided in this application embodiment may further include a display 203. The display 203 is communicatively connected to the memory 201 and the processor 202, and is used to display the relevant graphical user interface (GUI) of the file data verification method.

[0136] In this embodiment, the display 203 may include a display screen (display panel). In some implementations, the display panel may be configured using a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like. Furthermore, the display 203 may also be a touch panel (touchscreen, touch screen), which may include a display screen and a touch-sensitive surface. When the touch-sensitive surface detects a touch operation on or near it, it transmits the information to the processor 22 to determine the type of touch event. Subsequently, the processor 202 provides corresponding visual output on the display device based on the type of touch event.

[0137] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0138] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method of verifying file data, characterized by, The file data checking method comprises the following steps: acquiring a standard parsed file; extracting data from the standard parsed file to obtain structured data, the structured data comprising a table data dynamic expansion array and a paragraph data dynamic expansion array; calling a rule library to compare and check the structured data to obtain an abnormal result; generating and outputting an abnormal report according to the abnormal result, the abnormal report comprising a file source and abnormal information.

2. The file data verification method of claim 1, wherein, The process of extracting data from the standard parsed file to obtain structured data comprises the following steps: extracting table data from a table object in the standard parsed file to obtain the table data dynamic expansion array; extracting paragraph data from a document paragraph object in the standard parsed file to obtain the paragraph data dynamic expansion array.

3. The method of claim 1, wherein The process of calling a rule library to compare and check the structured data to obtain an abnormal result comprises the following steps: traversing the table data dynamic expansion array to locate a table containing a keyword in a table header; checking the table containing the keyword to obtain a cost table verification result.

4. The method of claim 3, wherein The keyword comprises unit price, engineering quantity, frequency and total price; checking whether the total price is equal to the product of the unit price, the engineering quantity and the frequency to obtain the abnormal result.

5. The method of claim 1, wherein The process of calling a rule library to compare and check the structured data to obtain an abnormal result further comprises the following steps: obtaining a first text and a second text based on the paragraph data dynamic expansion array; comparing the length of a first string in the first text and a second string in the second text to obtain a short string and a long string; obtaining the longest common substring between the first string and the second string based on the first string and the second string by using a longest common substring dynamic programming algorithm; determining the length and ending position of the longest common substring by constructing a two-dimensional array to record the matching length of the substring, to extract the longest common substring by using the longest common substring dynamic programming algorithm; obtaining a similarity percentage according to the longest common substring and the long string; obtaining the degree of repetition of the first text and the second text according to the similarity percentage; obtaining the abnormal result based on the degree of repetition.

6. The method of claim 1, wherein The process of generating and outputting an abnormal report according to the abnormal result comprises the following steps: storing the file source in the abnormal result to a file dynamic expansion array; storing the abnormal information in the abnormal result to a content dynamic expansion array; outputting a DOCX table and a visual window form based on the file dynamic expansion array and the content dynamic expansion array.

7. The method of claim 1, wherein The method further comprises numbering a plurality of imported standard parsed files in a chronological order.

8. A file data verification system, characterized by, The file data checking system comprises: a file acquisition module for acquiring a standard parsed file; a data extraction module for extracting data from the standard parsed file to obtain structured data, the structured data comprising a table data dynamic expansion array and a paragraph data dynamic expansion array; an abnormal result acquisition module for calling a rule library to compare and check the structured data to obtain an abnormal result; An abnormality report output module is configured to generate and output an abnormality report according to the abnormality result, wherein the abnormality report comprises a file source and abnormality information.

9. An electronic device, comprising: The electronic device comprises: A memory having a computer program stored thereon; A processor in communication with the memory, configured to execute the computer program to implement the file data checking method according to any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the electronic device to implement the file data checking method according to any one of claims 1 to 7.

Images