Multi-version based protocol library inventory price benchmark generation and audit invocation system

Abstract

The multi-version-based protocol library inventory price benchmark generation and audit calling system of the application comprises a version fingerprint generation module, an engineering type partition module, a candidate price ordered chain generation module, a strategy decision snapshot module, a refresh batch number management module and a verification switching module, each source version set generates a dedicated source version set fingerprint, then all source data are partitioned, candidate price analysis and sorting are performed in each partition, a candidate price ordered chain is generated, the selected price is determined from the candidate price ordered chain according to the price taking strategy set by the user, a strategy decision snapshot is generated, a complete effective snapshot data set carrying a refresh batch number is generated by binding multi-source data, batch verification is performed on the complete effective snapshot data set, and after the verification passes, the corresponding refresh batch number is switched to the current active batch of the system, which is uniformly called by the audit component, can guarantee that multiple audit components read the price benchmark caliber uniformly, and realize the traceability of the whole process of price selection.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a system for generating, auditing, and calling inventory price benchmarks based on multiple versions of protocols. Background Technology

[0002] In the cost auditing of power engineering projects, the bidding data of contracted inventory materials is continuously uploaded to the database in multiple batches, resulting in multiple source versions. The same material can generate multiple records with different bidding prices under different bidding versions. In the existing business auditing scenario, different auditing business components need to reference the contracted inventory bidding prices as a basis for price auditing. Existing technologies typically have the following problems: First, the auditing components directly access the original bidding source data table, reading, grouping, and sorting the entire historical version data in real time during each audit to obtain the representative price of the material. When the number of contracted inventory versions and the amount of detailed data are large, it will cause a decrease in the performance of the auditing interface. Second, different auditing components implement their own pricing logic. For the same material, the representative prices calculated by different components are prone to inconsistencies in their calculation methods. Third, storing only the final selected representative price cannot fully retain the price selection process, the candidate price set, and the source version information on which it is based. When there is a dispute over the price review result, it is difficult to trace the formation process of the price benchmark, and the audit evidence is insufficient. Fourth, when a new winning bid version is added, the source data is modified, or the business pricing configuration is changed, the cache is prone to mixing old and new data, making it difficult to achieve smooth updates of the price benchmark. If the price cache currently in use is directly overwritten and modified, incomplete intermediate state data may be read during the audit call process. Fifth, the business requirements for price review of different types of projects, such as substation projects, cable line projects, and distribution network projects, are different. The existing solution is difficult to isolate the price benchmark for different types of projects and cannot configure independent pricing rules for different types of projects and material categories. Summary of the Invention

[0003] In view of this, the present invention proposes a multi-version protocol inventory price benchmark generation and auditing system, which can ensure that multiple auditing components read the same price benchmark, while achieving full-process traceability of price selection, and taking into account both system performance and audit traceability capabilities.

[0004] The technical solution of this invention is implemented as follows: A multi-version protocol inventory price benchmark generation and verification system is in place, including: The source version fingerprint generation module is used to generate a source version set fingerprint for each source version in the source version set. The project type partitioning module is used to partition all source data according to project type, material category, configuration type, and material merging key; The candidate price ordered chain generation module is used to complete the parsing and sorting of candidate prices in each partition and generate an ordered chain of candidate prices. The strategy decision snapshot module is used to read the pricing strategy configuration set by the user and generate a strategy decision snapshot based on the ordered chain of candidate prices. The refresh batch number management module is used to bind the source version set fingerprint, the candidate price ordered chain, and the strategy decision snapshot to generate a complete effective snapshot dataset carrying the refresh batch number; The verification and switching module is used to perform batch verification on the complete effective snapshot dataset, and after the verification is passed, it switches the corresponding refresh batch number to the currently active batch of the system for consistent use by the audit component; The project type partitioning module, the candidate price ordered chain generation module, and the strategy decision snapshot module are sequentially connected in data. The refresh batch number management module is connected in data to the source version fingerprint generation module, the candidate price ordered chain generation module, the strategy decision snapshot module, and the verification switching module, respectively.

[0005] Preferably, it also includes a source version set identification module, which is data-connected to the source version fingerprint generation module, and its execution steps are as follows: Read the business configuration version table and filter the protocol inventory source version records that simultaneously meet the requirements of configuration type matching, upload status being completed, and version activation status being valid. The filtered results are sorted in descending order of creation time, and a version mapping table containing version identifiers and version names is generated. The version mapping table is then integrated into a source version set.

[0006] Preferably, the execution steps of the source version fingerprint generation module are as follows: Receive the source version set output by the source version set identification module, concatenate all version identifiers into a string in ascending order, and concatenate the corresponding version name in the same order; By appending the last update timestamp of each source version and a summary of the total number of data records in each source version, the original fingerprint string is obtained; Use MD5 or SHA The 256 hash algorithm performs a hash operation on the original fingerprint string to generate a set of source version fingerprints.

[0007] Preferably, it also includes a material merging key standardization module, which is connected to the source version set identification module and the project type partitioning module respectively. Its execution steps are as follows: Read the source data from the source version set, filter out empty prices and data with severely missing key fields of materials, and clean the price string to remove thousands separator commas, Chinese commas, and spaces; Extract the material name, material description, material code, technical identifier, and version identifier for each source data entry, and standardize the technical identifier. The version identifier and the standardized technical identifier are combined to generate a material merging key, which is then sent to the project type partition module.

[0008] Preferably, the execution steps of the project type partitioning module are as follows: Read the project type field, material category field, and configuration type field from the project information, material attribute information, and source version configuration information of the currently reviewed project, and determine the project type, material category, and configuration type to which it belongs; The project type, material category, configuration type, and material merge key are concatenated in a fixed order to generate a composite partition key. If the project type, material category, or configuration type is not configured, an empty string is used for concatenation. Partition all source data according to the composite partition key to obtain a set of all candidate price records corresponding to each composite partition key.

[0009] Preferably, the execution steps of the candidate price ordered chain generation module are as follows: Remove thousands separators, Chinese commas, and spaces from the price strings of all candidate records corresponding to the same material merge key in the same partition, and then convert them into high-precision numerical values. Candidate records are sorted in descending order of high-precision numerical values. If prices are equal, the record IDs of the source data are sorted in descending order as the second sorting criterion. After sorting, an ordered chain of candidate prices is generated. The ordered chain of candidate prices records the source version identifier, version name, supplier, package number, tax-inclusive price, sorting position, and anomaly flag for each candidate record.

[0010] Preferably, the execution steps of the strategy decision snapshot module are as follows: Read the corresponding pricing strategy configuration based on the current partition's project type and material category; For each candidate price ordered chain in the partition, the selected price of the material is obtained from the candidate price ordered chain according to the pricing strategy; Generate a snapshot of the strategy decision that includes the pricing strategy, the total length of the ordered chain of candidate prices, the candidate sorting direction, and the sorting position of the selected candidate.

[0011] Preferably, the execution steps of the batch number refresh management module are as follows: Receive the source version set fingerprint, the candidate price ordered chain, and the strategy decision snapshot, and generate a globally unique refresh batch number. Bind the refresh batch number with the source version set fingerprint, the candidate price ordered chain, and the strategy decision snapshot to generate a complete effective snapshot dataset. When events such as uploading the source version of the protocol inventory, modifying or deleting the source record, or changing the protocol inventory pricing method configuration occur, a cache refresh is triggered, generating a complete and effective snapshot dataset corresponding to the newly refreshed batch number.

[0012] Preferably, the execution steps of the verification switching module are as follows: Based on the complete effective snapshot dataset, perform source version set quantity verification, material merge key group quantity verification, snapshot row count verification, and abnormal price record verification; Upon successful verification, the complete effective snapshot dataset will be written in batches to the current effective data cache table of the material agreement inventory bidding status, and the refresh batch number corresponding to the current complete effective snapshot dataset will be switched to the system's currently active batch. If the verification fails, the complete effective snapshot dataset for this instance will be discarded, and the previous activation batch of the system will be retained to continue providing services.

[0013] Preferably, it also includes a batch invocation module, which is data-connected to the verification switching module, and its execution steps are as follows: Receive unified interface call requests initiated by multiple review components, wherein the call requests carry project type, table type and optional refresh batch number; Based on the call request, find the corresponding complete effective snapshot dataset, and locate the corresponding effective snapshot record from the complete effective snapshot dataset; Return the effective snapshot record to the initiating review component, including representative price, source version, number of candidates, pricing strategy, source version set fingerprint, ordered chain snapshot of candidate prices, and refresh batch number.

[0014] Compared with the prior art, the beneficial effects of the present invention are: The present invention relates to a multi-version protocol inventory price benchmark generation and auditing system. A source version fingerprint generation module generates a set of source version fingerprints, uniquely identifying the source version combination upon which the generated price benchmark depends. Then, a project type partitioning module constructs a composite partitioning key to partition the source data, achieving price benchmark isolation for different business scenarios such as substation projects, cable line projects, and distribution network projects. It supports differentiated pricing strategies adapted according to project type and material category. A candidate price ordered chain generation module constructs a candidate price ordered chain to completely retain all candidate records. A strategy decision snapshot module selects the selected price for the material based on the pricing strategy and generates a strategy decision snapshot, solidifying the price selection logic, candidate insufficiency fallback rules, and anomaly flags, and refreshing the batch. The batch management module assigns a unique refresh batch number, binding and packaging business prices, source version set fingerprints, candidate chain snapshots, strategy decision snapshots, and source evidence information into a complete effective snapshot dataset. The verification and switching module can switch the activation batch after completing batch verification, avoiding reading incomplete data during business calls. At the same time, it retains historical batch snapshots, enabling historical price benchmarks to be traceable. The batch calling module allows multiple external audit components to uniformly read effective snapshot records, eliminating pricing discrepancies caused by independent calculations by each audit component. This effectively reduces computational overhead during auditing, improves interface response performance, and fully retains price benchmarks to generate full-chain evidence, facilitating price dispute verification and audit report auditing. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of the multi-version protocol inventory price benchmark generation and verification system of the present invention; In the diagram, 1. Source version fingerprint generation module; 2. Project type partitioning module; 3. Candidate price ordered chain generation module; 4. Strategy decision snapshot module; 5. Refresh batch number management module; 6. Verification switching module; 7. Source version set identification module; 8. Material merging key standardization module; 9. Batch calling module. Detailed Implementation

[0017] To better understand the technical content of this invention, a specific embodiment is provided below, and the invention will be further described in conjunction with the accompanying drawings.

[0018] See Figure 1The present invention provides a multi-version protocol inventory price benchmark generation and auditing system, including a source version fingerprint generation module 1, an engineering type partitioning module 2, a candidate price ordered chain generation module 3, a strategy decision snapshot module 4, a refresh batch number management module 5, a verification switching module 6, a source version set identification module 7, a material merging key standardization module 8, and a batch calling module 9. The execution steps of the source version set identification module 7 are as follows: Read the business configuration version table and filter the protocol inventory source version records that simultaneously meet the requirements of configuration type matching, upload status being completed, and version activation status being valid. The filtered results are sorted in descending order of creation time, and a version mapping table containing version identifiers and version names is generated. The version mapping table is then integrated into a source version set.

[0019] The system queries the business configuration version table for protocol library source version records that meet all of the following conditions: the type field equals the preset configuration type identifier (e.g., Shanxi Power Grid_2025 First Project), the upload status field equals YES indicating that the upload has been completed, and the version is enabled. Then, the system sorts the records in descending order of creation time and retrieves the latest records. The query results return a version mapping table, which contains a key and a value, where the key is the version identifier and the value is the version name. This version mapping table is the valid set of source versions, and all subsequent source data queries are limited to the version identifier range of this set.

[0020] Source version fingerprint generation module 1 is used to generate a source version set fingerprint for each source version in the source version set. Its execution steps are as follows: Receive the source version set output by the source version set identification module 7, concatenate all version identifiers into a string in ascending order, and concatenate the corresponding version names in the same order; By appending the last update timestamp of each source version and a summary of the total number of data records in each source version, the original fingerprint string is obtained; Use MD5 or SHA The 256 hash algorithm performs a hash operation on the original fingerprint string to generate a set of source version fingerprints.

[0021] All version identifiers in the version mapping table are sorted in ascending order and concatenated into a string (e.g., "1,2,3,5"). Simultaneously, the version names are concatenated in the same order (e.g., "First Batch, Second Batch, Third Batch, Fifth Batch"). Finally, a summary of the last update timestamp and total number of data records for each source version is appended. The concatenated string is then hashed using either MD5 or SHA-256 algorithms to generate a fixed-length source version set fingerprint. This fingerprint uniquely identifies the source version set upon which the current price benchmark is based. When any source version changes, the fingerprint value changes accordingly, triggering a cache refresh.

[0022] The execution steps of the material merging key standardization module 8 are as follows: Read the source data from the source version set, filter out empty prices and data with severely missing key fields of materials, and clean the price string to remove thousands separator commas, Chinese commas, and spaces; Extract the material name, material description, material code, technical identifier, and version identifier for each source data entry, and standardize the technical identifier. The version identifier and the standardized technical identifier are combined to generate a material merging key, which is then sent to the project type partition module 2.

[0023] Before generating the material merge key, all protocol inventory source data in the source version set is read, and data with empty prices, empty names, or severe missing key fields is filtered out. For the price field, the system removes thousands separator commas, Chinese commas, and spaces, and converts it to a high-precision value for sorting. Then, for each source data, its version identifier field and technical identifier field are extracted. The technical identifier is standardized using a standardization method, including trimming to remove leading and trailing spaces, replacing null values ​​with empty strings, unifying full-width and half-width characters, and unifying capitalization. Then, the material merge key construction method is called, which concatenates the version identifier and the standardized technical identifier with double vertical lines as separators to generate the material merge key string. If the version identifier is null, it is replaced with an empty string to ensure stable material merge key generation.

[0024] Project type partitioning module 2 is used to partition all source data according to project type, material category, configuration type, and material merging key. Its execution steps are as follows: Read the project type field, material category field, and configuration type field from the project information, material attribute information, and source version configuration information of the currently reviewed project, and determine the project type, material category, and configuration type to which it belongs; The project type, material category, configuration type, and material merge key are concatenated in a fixed order to generate a composite partition key. If the project type, material category, or configuration type is not configured, an empty string is used for concatenation. Partition all source data according to the composite partition key to obtain a set of all candidate price records corresponding to each composite partition key.

[0025] The system reads the project type field from the project information of the currently reviewed project to determine the project type, such as substation project, cable line project, distribution network project, etc. Then, it reads the configuration type field from the protocol inventory source version configuration to determine the configuration source type of the current version. Next, it reads the material category field from the material attribute information to determine the category to which the material belongs. Finally, the system concatenates the project type, material category, configuration type, and material merge key in a fixed order to form a composite partition key string, in the format {project type}||{material category}||{configuration type}||{material merge key}. The system groups all source data records according to this composite partition key to obtain a set of multiple candidate price records corresponding to each partition. In the current implementation, if the project type, material category, or configuration type is not configured, an empty string is used in the concatenation to ensure the stability of the generated composite partition key.

[0026] If all candidate prices under a certain material merge key are empty, the system will not generate a cache line and will record the exception. If the candidate price record set has only one record but the strategy is the second highest price, the system will select the only candidate and record the candidate count as 1 to avoid the representative price being empty.

[0027] Candidate Price Ordered Chain Generation Module 3 is used to parse and sort candidate prices within each partition and generate an ordered chain of candidate prices. Its execution steps are as follows: Remove thousands separators, Chinese commas, and spaces from the price strings of all candidate records corresponding to the same material merge key in the same partition, and then convert them into high-precision numerical values. Candidate records are sorted in descending order of high-precision numerical values. If prices are equal, the record IDs of the source data are sorted in descending order as the second sorting criterion. After sorting, an ordered chain of candidate prices is generated. The ordered chain of candidate prices records the source version identifier, version name, supplier, package number, tax-inclusive price, sorting position, and anomaly flag for each candidate record.

[0028] The candidate price record set may come from multiple versions or from the same supplier or package number. The system will sort the candidate price record set to form an ordered chain of candidate prices. During sorting, the price parsing method is first called to remove thousands separators, Chinese commas, and spaces from the price string of each record and convert it into a high-precision value. Then, the records are sorted in descending order of the high-precision value (prices from high to low). When multiple records have the same price value, the source data record ID is used as the second sorting condition and the records are sorted in descending order of ID. The list formed after sorting is the ordered chain of candidate prices, where the first record is the highest price, the second highest price, the middle record is the median price, and subsequent records are arranged in order.

[0029] The strategy decision snapshot module 4 is used to read the user-set pricing strategy configuration and generate a strategy decision snapshot based on the ordered chain of candidate prices. Its execution steps are as follows: Read the corresponding pricing strategy configuration based on the current partition's project type and material category; For each candidate price ordered chain in the partition, the selected price of the material is obtained from the candidate price ordered chain according to the pricing strategy; Generate a snapshot of the strategy decision that includes the pricing strategy, the total length of the ordered chain of candidate prices, the candidate sorting direction, and the sorting position of the selected candidate.

[0030] The strategy decision snapshot records the strategy code, the length of the ordered chain of candidate prices, the candidate sorting direction, the position of the selected candidate, the fallback rules when there are not enough candidates, and whether a manual confirmation flag is triggered. The highest price, the second highest price, and the median price only participate in the decision snapshot as strategy codes and are not claimed as separate business rules.

[0031] In addition to the highest price, second-highest price, and median price, pricing strategies can be extended to the lowest price, weighted average price, average price after removing extreme values, and price based on supplier level priority. The weighting dimension can be the number of winning bids, execution ratio, agreement amount, or supplier level, and these can be further written into the pricing strategy field. The system can also configure different pricing strategies according to different project types and material categories. For example, substation projects can use the second-highest price to avoid extreme highest prices affecting the price review; cable line projects can use the median price for the cable body and the highest price or the most recent valid price for cable fireproofing materials; distribution network projects can use the median price according to the distribution network agreement inventory winning bid details; the median price is used for materials with large price fluctuations, the second-highest price is used for key equipment, and the highest price is used for scarce materials. When reading pricing strategies, the system no longer only reads the global configuration, but queries by project type and material category. If no dedicated pricing strategy is configured, it will fall back to the global default strategy.

[0032] The pricing strategy is an important configuration that affects the audit benchmark. The system can restrict it to only administrators or cost management personnel. After each strategy modification, the system records the operator, the value before modification, the value after modification, and the refresh result. If the refresh fails, the strategy modification can be rolled back or the old cache can be kept valid.

[0033] The system can also generate price distribution summaries for candidate prices under the same material consolidation key, such as the highest price, lowest price, average price, median price, and selected price. This summary may not necessarily be used in the review calculation, but it can serve as supplementary information for reviewers to understand the reasonableness of the representative price. If the difference between the highest and lowest prices exceeds a threshold, the system can mark it as a price-dispersed material, prompting manual attention.

[0034] The refresh batch number management module 5 is used to bind the source version set fingerprint, the candidate price ordered chain, and the strategy decision snapshot, and generate a complete effective snapshot dataset carrying the refresh batch number. Its execution steps are as follows: Receive the source version set fingerprint, the candidate price ordered chain, and the strategy decision snapshot, and generate a globally unique refresh batch number. Bind the refresh batch number with the source version set fingerprint, the candidate price ordered chain, and the strategy decision snapshot to generate a complete effective snapshot dataset. When events such as uploading the source version of the protocol inventory, modifying or deleting the source record, or changing the protocol inventory pricing method configuration occur, a cache refresh is triggered, generating a complete and effective snapshot dataset corresponding to the newly refreshed batch number.

[0035] The system copies the selected source row as the currently effective snapshot row, and simultaneously writes the refresh batch number, source version set fingerprint, candidate price ordered chain snapshot, strategy decision snapshot, number of candidate rows, source version, source version identifier list, material merging key and pricing strategy. During copying, fields such as material name, description, unit, price, tax-inclusive price, supplier, and package number are retained for easy front-end display and audit traceability.

[0036] When source data changes or pricing strategies change and trigger cache refresh, the specific steps are as follows: The system triggers a refresh operation when the following four events occur: First, when a user uploads a new Excel file of the agreement inventory bidding status table through the upload interface, the system automatically calls the effective service to refresh after parsing and storing it in the database; Second, when a user modifies an existing source data record through the update method interface by business object, the effective service is automatically called to refresh after the modification is completed; Third, when a user deletes a source data record through the interface, the effective service is automatically called to refresh after the deletion is completed; Fourth, when an administrator modifies the "agreement inventory pricing method" configuration value in the business configuration table, the system detects the configuration change and triggers the effective service to refresh. To avoid the audit component reading an empty table during the refresh process, the system can adopt a double buffering scheme. During the refresh, new cache batch number data is generated first, and after generation, the current batch identifier is switched, while the old batch is delayed in deletion. In this way, even if the refresh takes a long time, the audit component can still read the previous batch of stable data. At the same time, the audit project can record the cache batch number used, thereby accurately tracing the effective price version at the time of the audit.

[0037] The refresh method is executed within a transaction: First, all records in the current cache table are cleared. Then, a complete and effective snapshot of the data is regenerated and inserted in batches. Additionally, the system provides a lazy refresh mechanism: when the audit component queries the currently effective data, if it detects that the cache table has 0 records but the source table contains valid data, a refresh is automatically triggered to ensure users see usable results. A complete snapshot is first generated in a temporary batch, and row count, partition, and anomaly checks are performed. Then, the refresh batch number is switched to the currently active batch. If a query finds no active batch but valid source data exists, a lazy refresh can be executed. Lazy refresh still follows the process of batch generation followed by switching. This mechanism is used to handle scenarios after initial deployment, accidental cache deletion, or data migration, ensuring users see usable results when clicking on the currently effective data page.

[0038] Verification and switching module 6 is used to perform batch verification on the complete effective snapshot dataset, and after successful verification, it switches the corresponding refresh batch number to the currently active batch in the system for consistent use by the audit component. Its execution steps are as follows: Based on the complete effective snapshot dataset, perform source version set quantity verification, material merge key group quantity verification, snapshot row count verification, and abnormal price record verification; Upon successful verification, the complete effective snapshot dataset will be written in batches to the current effective data cache table of the material agreement inventory bidding status, and the refresh batch number corresponding to the current complete effective snapshot dataset will be switched to the system's currently active batch. If the verification fails, the complete effective snapshot dataset for this instance will be discarded, and the previous activation batch of the system will be retained to continue providing services.

[0039] Verification and switching module 6 performs multi-level verification on the complete and effective snapshot dataset. Only after the verification passes can the refresh batch number be atomically switched to the currently active batch. The execution steps of batch call module 9 are as follows: Receive unified interface call requests initiated by multiple review components, wherein the call requests carry project type, table type and optional refresh batch number; Based on the call request, find the corresponding complete effective snapshot dataset, and locate the corresponding effective snapshot record from the complete effective snapshot dataset; Return the effective snapshot record to the initiating review component, including representative price, source version, number of candidates, pricing strategy, source version set fingerprint, ordered chain snapshot of candidate prices, and refresh batch number.

[0040] The audit component calls the "Query Valid List" or "Query Valid Price" methods to read the currently active snapshot instead of directly reading the source table. The call request includes the project type, table type, and an optional refresh batch number. Including the project type allows the server to locate the corresponding cache partition and return representative price data matching that project type. Including the table type allows the server to further filter applicable price caches based on the current audit page type (e.g., summary of equipment supplied by Party A, price difference of main materials supplied by Party A, price difference of main materials supplied by Party B). Including the optional refresh batch number allows the audit component to specify the price benchmark for a particular batch for accurate tracing of historical audit reports. If no batch number is included, the server parses the currently active batch.

[0041] Once the audit component completes price verification using the currently active cache, the audit report can reference the source version, number of candidate entries, and pricing strategy from the cache table. The report not only specifies whether the prices match, but also explains how the price benchmark was formed by merging several valid source versions, what pricing strategy was used, and the final selected supplier or package number. This report linkage can transform the strategy-based pricing process into auditable evidence. If a user subsequently questions a price benchmark, the system can return to the currently active cache line to check the source without having to re-traverse all historical versions of the protocol inventory.

[0042] The system of this invention can add a refresh log table to record refresh time, number of participating source versions, number of generated cache lines, strategy name, time consumption and failure reason for operation and maintenance auditing. It can also display material name, description, price, tax-inclusive price, pricing method, number of candidate items and source version on the front-end currently effective data page, and support auditors to view the basis for representative price formation.

[0043] To improve the consistency between the complete and effective snapshot data and the source data, the system can set a snapshot generation verification step. After the refresh is completed, the system counts the number of valid source versions, the fingerprint of the source version set, the total number of source data entries, the number of material merge key groups, and the number of snapshot rows. If the number of snapshot rows is greater than the number of groups or less than the number of non-empty groups, the system records an anomaly and prevents switching the current refresh batch number.

[0044] This invention also provides a variety of anomaly handling measures: Exception 1: Price cannot be parsed: The system will treat data with unparseable prices as 0 or remove it, and can record the exception list to avoid exceptions during sorting that could interrupt cache generation.

[0045] Anomaly 2: Illegal pricing strategy configuration: If an unknown value is configured in the business configuration table, the system will use the default second-highest price strategy to ensure that the review process is not interrupted.

[0046] Anomaly 3: No valid version: The system returns an empty cache, does not generate an error price, and displays a message on the front end indicating that there is currently no available protocol inventory data.

[0047] Anomaly 4: The candidate price set contains only one price, but the pricing strategy is the second highest price: The system selects a unique candidate to avoid having no representative price due to insufficient candidates.

[0048] Anomaly 5: Frequent source version updates: Instead of directly overwriting the current activation batch, the system generates a new refresh batch number and completes the data writing and verification in a temporary state. After the verification is passed, the activation batch is switched to avoid the audit component reading data in a semi-generated state.

[0049] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A system for generating, reviewing, and calling multi-version agreement inventory price benchmarks, characterized in that: include: The source version fingerprint generation module is used to generate a source version set fingerprint for each source version in the source version set. The project type partitioning module is used to partition all source data according to project type, material category, configuration type, and material merging key; The candidate price ordered chain generation module is used to complete the parsing and sorting of candidate prices in each partition and generate an ordered chain of candidate prices. The strategy decision snapshot module is used to read the pricing strategy configuration set by the user and generate a strategy decision snapshot based on the ordered chain of candidate prices. The refresh batch number management module is used to bind the source version set fingerprint, the candidate price ordered chain, and the strategy decision snapshot to generate a complete effective snapshot dataset carrying the refresh batch number; The verification and switching module is used to perform batch verification on the complete effective snapshot dataset, and after the verification is passed, it switches the corresponding refresh batch number to the currently active batch of the system for consistent use by the audit component; The project type partitioning module, the candidate price ordered chain generation module, and the strategy decision snapshot module are sequentially connected in data. The refresh batch number management module is connected in data to the source version fingerprint generation module, the candidate price ordered chain generation module, the strategy decision snapshot module, and the verification switching module, respectively.

2. The system for generating and verifying multi-version agreement inventory price benchmarks according to claim 1, characterized in that, It also includes a source version set identification module, which is data-connected to the source version fingerprint generation module, and its execution steps are as follows: Read the business configuration version table and filter the protocol inventory source version records that simultaneously meet the requirements of configuration type matching, upload status being completed, and version activation status being valid. The filtered results are sorted in descending order of creation time, and a version mapping table containing version identifiers and version names is generated. The version mapping table is then integrated into a source version set.

3. The system for generating and verifying multi-version agreement inventory price benchmarks according to claim 2, characterized in that, The execution steps of the source version fingerprint generation module are as follows: Receive the source version set output by the source version set identification module, concatenate all version identifiers into a string in ascending order, and concatenate the corresponding version name in the same order; By appending the last update timestamp of each source version and a summary of the total number of data records in each source version, the original fingerprint string is obtained; Use MD5 or SHA The 256 hash algorithm performs a hash operation on the original fingerprint string to generate a set of source version fingerprints.

4. The system for generating and verifying multi-version agreement inventory price benchmarks according to claim 2, characterized in that, It also includes a material merging key standardization module, which is connected to the source version set identification module and the project type partitioning module respectively. Its execution steps are as follows: Read the source data from the source version set, filter out empty prices and data with severely missing key fields of materials, and clean the price string to remove thousands separator commas, Chinese commas, and spaces; Extract the material name, material description, material code, technical identifier, and version identifier for each source data entry, and standardize the technical identifier. The version identifier and the standardized technical identifier are combined to generate a material merging key, which is then sent to the project type partition module.

5. The system for generating and verifying multi-version agreement inventory price benchmarks according to claim 1, characterized in that, The execution steps of the project type partitioning module are as follows: Read the project type field, material category field, and configuration type field from the project information, material attribute information, and source version configuration information of the currently reviewed project, and determine the project type, material category, and configuration type to which it belongs; The project type, material category, configuration type, and material merge key are concatenated in a fixed order to generate a composite partition key. If the project type, material category, or configuration type is not configured, an empty string is used for concatenation. Partition all source data according to the composite partition key to obtain a set of all candidate price records corresponding to each composite partition key.

6. The system for generating and verifying multi-version agreement inventory price benchmarks according to claim 1, characterized in that, The execution steps of the candidate price ordered chain generation module are as follows: Remove thousands separators, Chinese commas, and spaces from the price strings of all candidate records corresponding to the same material merge key in the same partition, and then convert them into high-precision numerical values. Candidate records are sorted in descending order of high-precision numerical values. If prices are equal, the record IDs of the source data are sorted in descending order as the second sorting criterion. After sorting, an ordered chain of candidate prices is generated. The ordered chain of candidate prices records the source version identifier, version name, supplier, package number, tax-inclusive price, sorting position, and anomaly flag for each candidate record.

7. The system for generating and verifying multi-version agreement inventory price benchmarks according to claim 1, characterized in that, The execution steps of the strategy decision snapshot module are as follows: Read the corresponding pricing strategy configuration based on the current partition's project type and material category; For each candidate price ordered chain in the partition, the selected price of the material is obtained from the candidate price ordered chain according to the pricing strategy; Generate a snapshot of the strategy decision that includes the pricing strategy, the total length of the ordered chain of candidate prices, the candidate sorting direction, and the sorting position of the selected candidate.

8. The system for generating and verifying multi-version agreement inventory price benchmarks according to claim 1, characterized in that, The execution steps of the batch number refresh management module are as follows: Receive the source version set fingerprint, the candidate price ordered chain, and the strategy decision snapshot, and generate a globally unique refresh batch number. Bind the refresh batch number with the source version set fingerprint, the candidate price ordered chain, and the strategy decision snapshot to generate a complete effective snapshot dataset. When events such as uploading the source version of the protocol inventory, modifying or deleting the source record, or changing the protocol inventory pricing method configuration occur, a cache refresh is triggered, generating a complete and effective snapshot dataset corresponding to the newly refreshed batch number.

9. The system for generating and verifying multi-version agreement inventory price benchmarks according to claim 1, characterized in that, The execution steps of the verification switching module are as follows: Based on the complete effective snapshot dataset, perform source version set quantity verification, material merge key group quantity verification, snapshot row count verification, and abnormal price record verification; Upon successful verification, the complete effective snapshot dataset will be written in batches to the current effective data cache table of the material agreement inventory bidding status, and the refresh batch number corresponding to the current complete effective snapshot dataset will be switched to the system's currently active batch. If the verification fails, the complete effective snapshot dataset for this instance will be discarded, and the previous activation batch of the system will be retained to continue providing services.

10. The system for generating and verifying multi-version agreement inventory price benchmarks according to claim 1, characterized in that, It also includes a batch invocation module, which is data-connected to the verification switching module, and its execution steps are as follows: Receive unified interface call requests initiated by multiple review components, wherein the call requests carry project type, table type and optional refresh batch number; Based on the call request, find the corresponding complete effective snapshot dataset, and locate the corresponding effective snapshot record from the complete effective snapshot dataset; Return the effective snapshot record to the initiating review component, including representative price, source version, number of candidates, pricing strategy, source version set fingerprint, ordered chain snapshot of candidate prices, and refresh batch number.

Images