An enterprise bidding whole-cycle data visualization supervision method

Abstract

The application relates to the technical field of bidding supervision, and discloses an enterprise bidding whole-cycle data visualized supervision method, which comprises the following steps: a supervision server generates a whole-cycle node skeleton, and generates a unified event primary key according to a project identifier, a bid section identifier, a bid object identifier and a node identifier; an electronic bid file is received and normalized to generate a normalized file hash and a digital bid file evidence chain record; a seal anchor texture area image of a bid entity package is received and geometrically corrected to generate an image fingerprint and a bid entity package evidence chain record; a paper and electricity evidence chain consistency coefficient is generated based on a digital file content jump variable, a package texture jump variable and a normalized time offset, and a whole-cycle evidence chain supervision visualized image is outputted, which is used for node state positioning and evidence checking.

Description

Technical Field

[0001] This invention relates to the field of bidding supervision technology, and more specifically, to a method for data visualization supervision of the entire bidding process for enterprises. Background Technology

[0002] In a company's hybrid paper-and-electronic bidding platform, the electronic bidding system, document receiving interface, barcode scanning terminal, image storage service, database, and monitoring display terminal typically belong to different services. After electronic bid documents enter the platform, they undergo processes such as uploading, decryption, review and retrieval, and archiving; physical bid packages are recorded during on-site reception, temporary storage, pre-opening verification, and archiving scanning. These two types of records are generated by different devices and from different time sources, and subsequently enter the document library, image library, business library, and display terminal, respectively.

[0003] In common implementations, the electronic bid document side primarily stores file hashes, reception times, storage addresses, and business node statuses; the bid entity packet side primarily stores QR code reading results, seal images, image fingerprints, collection times, and verification statuses. Due to inconsistent binding methods between projects, bid sections, bidding objects, and nodes, maintenance or supervisory personnel often need to switch between the electronic bidding system, on-site data collection system, archive database, and report pages when verifying multi-node materials for the same bidding object. This type of verification relies on manual screening and form comparison, which can easily lead to unstable node correspondences, delayed detection of missing records, and lengthy anomaly localization processes.

[0004] Existing visualization pages are mostly used to display process progress, number of pending tasks, or individual risk warnings, but they are insufficient in expressing the linkage between changes in the content of electronic tender documents, changes in the texture of the tender entity's envelope, and differences in the intervals between the nodes of the two types of evidence chains. Even if the platform has saved file hashes, image fingerprints, and trusted timestamps, without a unified event primary key that runs through all nodes in the entire cycle and a unified output process for regulatory images, it is still difficult for the relevant data to form a verifiable node mapping relationship in the same regulatory screen. Summary of the Invention

[0005] This invention provides a data visualization and supervision method for the entire bidding process of enterprises, which solves the technical problems mentioned in the background.

[0006] To achieve the above-mentioned objectives, the present invention provides the following technical solution.

[0007] A data visualization and supervision method for the entire bidding process of enterprises, used to process electronic bid documents and bid entity packets, is executed by a supervision server and includes:

[0008] Generate a full-cycle node skeleton and generate a unified event primary key based on the project identifier, bid section identifier, bidding object identifier, and node identifier;

[0009] Upon receiving electronic bid documents, perform normalization processing to generate a normalized file hash representing the content of the electronic bid documents. Write the normalized file hash, trusted digital time, unified event primary key, and record status into the digital bid document evidence chain to form a digital bid document evidence chain record.

[0010] Receive the seal anchor texture area image of the bidding entity packet, perform geometric correction on the seal anchor texture area image based on fixed geometric anchor points, generate an image fingerprint representing the state of the bidding entity packet, and write the image fingerprint, trusted physical time, unified event primary key and record state into the physical packet evidence chain to form a physical packet evidence chain record.

[0011] Adjacent nodes that simultaneously possess both digital bid document evidence chain records and physical packet evidence chain records are selected to form a set of valid node segments. Digital file content jump variables, physical packet texture jump variables, and cross-chain time differences are generated. Based on the cross-chain time differences of other bid objects within the same project and the same node segment, a normalized time offset is generated. Based on the digital file content jump variables, physical packet texture jump variables, and normalized time offset, a paper-electronic evidence chain consistency coefficient is generated.

[0012] A full-cycle evidence chain regulatory visualization image is generated based on the full-cycle node skeleton, bidding object identification, node completion status, and consistency coefficient of paper and electronic evidence chains.

[0013] Compared with the prior art, the technical effects of the present invention are as follows:

[0014] This invention unifies electronic bid documents, bid entity packet collection results, and regulatory visualization output under a single unified event key. This allows for the querying of file hashes, image fingerprints, trusted times, and node completion status for the same bid object across nodes such as bid receipt, bid opening, bid evaluation, bid awarding, and archiving using a unified index. Through the coordinated processing of effective node segment sets, normalized time offsets, and consistency coefficients of paper and electronic evidence chains, the regulatory server can transform changes in file content, packet texture, and cross-chain time differences into visual arcs and node positions. This reduces the need for manual cross-system verification, improves the efficiency of evidence location, node missing identification, and archiving verification, and outputs regulatory images without displaying quotations, amounts, personal identification information, or unanonymized contact information, facilitating traceability management of the enterprise's bidding process. Attached Figure Description

[0015] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0016] Figure 1 This is a system architecture and processing mechanism diagram of a data visualization and supervision method for the entire bidding process of an enterprise, as proposed in this invention. Detailed Implementation

[0017] The following description is provided in conjunction with the accompanying drawings. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the invention; those skilled in the art can make equivalent substitutions or combinations for the specific implementations.

[0018] Example 1:

[0019] This implementation method is used to process electronic bid documents and bid entity packages, and is particularly suitable for enterprise bidding supervision scenarios involving both paper and electronic documents. In this scenario, the same bidder typically submits both electronic bid documents and bid entity packages simultaneously. The electronic bid documents enter the supervision process through the electronic document receiving interface 110, while the bid entity packages generate on-site data through the package acquisition terminal 120. Because the electronic bid documents and bid entity packages have different sources, different record granularities, and different time sources, if only the two types of records are saved separately, subsequent audits may encounter problems such as unclear correspondence between the same bidder across multiple business nodes, low evidence verification efficiency, and long anomaly location paths. This implementation method uses the supervision server 100 to perform unified data binding, evidence chain construction, calculation of consistency coefficients for paper and electronic evidence chains, and generation of full-cycle evidence chain supervision visualization images, enabling electronic bid documents, bid entity packages, and visualization elements to be traced under the same index relationship.

[0020] like Figure 1 As shown, the electronic document receiving interface 110 and the packet acquisition terminal 120 are respectively connected to the supervision server 100. The supervision server 100 includes a unified event primary key generation module 130, an evidence chain database 140, a consistency processing module 150, and a visualization image generation module 160. The electronic document receiving interface 110 is used to receive electronic bid documents, trusted digital time, and node identifiers; the packet acquisition terminal 120 is used to receive the QR code tag reading results, seal anchor texture area images, and trusted physical time of the bid entity packet; the unified event primary key generation module 130 is used to generate a unified event primary key based on the project identifier, bid section identifier, bid object identifier, and node identifier; the evidence chain database 140 is used to store digital bid document evidence chain records, physical packet evidence chain records, node completion status, and image archiving records; the consistency processing module 150 is used to generate the consistency coefficient of the paper and electronic evidence chain; and the visualization image generation module 160 is used to generate a full-cycle evidence chain supervision visualization image.

[0021] The full-cycle node skeleton in this embodiment covers at least the bid receiving node, bid opening node, bid evaluation node, bid awarding node, and archiving node. Each node is used to carry the digital bid document evidence chain record, physical packet evidence chain record, and node completion status formed by the same bidder in the corresponding business stage. By organizing the records of different nodes onto the full-cycle node skeleton, the monitoring server 100 can identify adjacent nodes in subsequent calculations and determine which adjacent nodes can enter the set of valid node segments. The full-cycle node skeleton is not limited to a certain database table or interface style; it is used to provide a stable node order and computable node segment relationships.

[0022] Example 2:

[0023] When the monitoring server 100 executes, it first generates a full-cycle node skeleton. This skeleton represents the sequence of nodes in the enterprise's bidding monitoring process and can include bid acceptance, bid opening, bid evaluation, bid awarding, and archiving nodes. Each node corresponds to a node identifier, which distinguishes the evidence records formed by the same bidder in different business stages. The full-cycle node skeleton can be generated by the unified event primary key generation module 130 reading the project identifier, bid section identifier, bidder identifier, and node identifier, or by the monitoring server 100 based on a fixed node sequence of bid acceptance, bid opening, bid evaluation, bid awarding, and archiving nodes. Regardless of the conventional software implementation method used, the full-cycle node skeleton supports subsequent unified event primary key generation, the formation of a set of valid node segments, and the generation of a visualized image of the full-cycle evidence chain monitoring.

[0024] The unified event primary key is generated from the project identifier, bid section identifier, bid object identifier, and node identifier. The project identifier is used to distinguish bidding projects from different enterprises; the bid section identifier is used to distinguish different bid sections under the same project; the bid object identifier is used to distinguish different bid objects participating in the same project or the same bid section; and the node identifier is used to distinguish bid receiving nodes, bid opening nodes, bid evaluation nodes, bid awarding nodes, and archiving nodes. The unified event primary key generation module 130 generates the unified event primary key in a fixed order of project identifier, bid section identifier, bid object identifier, and node identifier, so that electronic bid documents, normalized file hashes, trusted digital timestamps, seal anchor texture area images, image fingerprints, trusted physical timestamps, node completion status, and visual elements under the same node for the same bid object can be bound to the same index.

[0025] In one implementation, the unified event primary key generation module 130 receives the project identifier, bid section identifier, bidding object identifier, and node identifier. It first verifies whether each identifier is empty and whether its format conforms to preset rules, then concatenates them in a fixed order to form a unified event primary key. For inputs with empty fields or incorrect formats, the monitoring server 100 can refuse to write and record the error status.

[0026] When generating the unified event primary key, the project identifier, bid section identifier, bid object identifier, and node identifier are all represented by non-empty strings, and the fields must not contain delimiters used to separate fields. The unified event primary key generation module 130 writes the fields in a fixed order of project identifier, bid section identifier, bid object identifier, and node identifier, and writes fixed delimiters between adjacent fields. If any field is empty, the field order does not conform to the fixed order, or the field contains a delimiter, the monitoring server 100 sets the corresponding record status to missing or pending review.

[0027] After the unified event primary key is generated, it is written to the evidence chain database 140. The evidence chain database 140 can store digital bid document evidence chain records, physical packet evidence chain records, node completion status, and image archiving records based on the unified event primary key. In subsequent queries, as long as the supervisory personnel or supervisory procedures obtain any unified event primary key, they can locate the digital bid document evidence chain record, physical packet evidence chain record, node completion status, and visualization elements corresponding to that unified event primary key.

[0028] Example 3:

[0029] Electronic document receiving interface 110 receives electronic bid documents. Electronic bid documents may include the bid text, technical response attachments, authorization documents, forms, drawings, or compressed files. Electronic document receiving interface 110 also receives trusted digital time and node identifiers. The trusted digital time is used to represent the time record when the electronic bid document enters the regulatory process under the corresponding business node. The node identifier, together with the project identifier, bid section identifier, and bid object identifier, is used to generate a unified event primary key. Electronic document receiving interface 110 sends the electronic bid document, trusted digital time, and node identifier to the regulatory server 100.

[0030] After receiving the electronic bid documents, the monitoring server 100 performs normalization processing. Normalization eliminates the impact of non-content factors related to file metadata, storage format differences, and system cache information on the normalized file hash, enabling electronic bid documents from different business nodes to be compared according to the same rules. For PDF files, normalization can retain the binary content of the main text, embedded attachments, and signature objects; for DOCX files, normalization can retain the main text, table content, embedded objects related to the substantive content of the electronic bid document, and attachment content, while removing non-content factors related to operating system temporary caches; for compressed files, normalization can standardize file path separators and file sorting, and exclude temporary files automatically generated by the operating system.

[0031] The standardization process employs a deterministic workflow. The monitoring server 100 first identifies the file type of the electronic tender document, then invokes the corresponding rules according to the version of the standardization rules. For PDF files, the monitoring server 100 reads the main text in page order, and reads the binary content of embedded attachments and signature objects in the stable reference order of objects within the file, excluding non-content factors such as creation time, modification time, generating software name, temporary cache identifiers, and random object numbers. For DOCX files, the monitoring server 100 reads the main text content in paragraph order, reads the table content in the order of tables appearing in the document, and reads the embedded objects and attachments content related to the substantive content of the electronic tender document in the stable order of embedded objects and attachments in the document relationship file, excluding author, revision identifier, editing time, temporary cache relationships, and temporary files automatically generated by the operating system. For compressed files, the monitoring server 100 first unifies the file path separator to forward slashes, then reads the file content in lexicographical order of the file path, excluding temporary files automatically generated by the operating system.

[0032] The normalization output is a normalized byte sequence. This sequence is formed by concatenating multiple content entries in a fixed order, based on the electronic bid document type identifier, the normalization rule version, the number of content entries, and the number of bytes. Each content entry includes its type, path or sequence number, length, and bytes. The main text content uses UTF-8 encoding, while binary content retains its original bytes. The normalization rule version is permanently stored on the monitoring server within the same project. Electronic bid documents from different business nodes must use the same normalization rule version to generate the normalized file hash. The normalized file hash is calculated based on the normalized byte sequence, ensuring that the same electronic bid document yields a reproducible normalized file hash across different nodes.

[0033] After normalization, the monitoring server 100 generates a normalized file hash representing the content of the electronic bid document. The normalized file hash represents the substantive content state of the electronic bid document after removing non-content factors. When the normalized file hashes of adjacent nodes are consistent, it indicates that the corresponding electronic bid document has not undergone content changes between those adjacent nodes; when the normalized file hashes of adjacent nodes are inconsistent, it indicates that the corresponding electronic bid document has undergone content changes between those adjacent nodes. The normalized file hash is written into the digital bid document evidence chain, enabling subsequent digital file content jump variables to be calculated.

[0034]

[0035] in, Indicates the serial number of the bidding object is The node number is Electronic bid documents; This indicates the content obtained after standardizing the electronic bid document; This refers to a cryptographic hash algorithm; This represents the hash of the normalized document calculated from the normalized electronic tender document.

[0036] The monitoring server 100 writes the normalized file hash, trusted digital time, unified event primary key, and record status into the digital bid document evidence chain, forming a digital bid document evidence chain record. The record status indicates whether the digital bid document evidence chain record is valid; common statuses include valid, missing, or pending review. If the electronic bid document is missing, normalization processing fails, the normalized file hash is missing, or the trusted digital time is missing, the monitoring server 100 can set the corresponding record status to missing or pending review. Digital bid document evidence chain records in the missing or pending review state do not enter the set of valid node segments until they are supplemented or reviewed as valid.

[0037] The record status of the digital bid document evidence chain is generated according to fixed rules. The record status is valid when the electronic bid document exists, the normalization processing rule version exists, normalization processing is complete, the normalized file hash exists, the trusted digital time exists, and the unified event primary key exists. The record status is missing when the electronic bid document is missing, the normalized file hash is missing, the trusted digital time is missing, or the unified event primary key is missing. The record status is pending review when the electronic bid document exists but normalization processing failed, the electronic bid document type cannot be identified, the normalization processing rule version is inconsistent, or manual verification of the substantive content of the electronic bid document is required. The pending review status can only be converted to valid after manual review and regeneration of the normalized file hash.

[0038] Example 4:

[0039] The packet acquisition terminal 120 receives the QR code tag reading result, seal anchor texture area image, and trusted physical time from the bidding entity's packet. The QR code tag reading result is used to identify the bidding object, enabling the QR code tag reading result, seal anchor texture area image, and trusted physical time of the bidding entity's packet to be bound to the electronic bid document and trusted digital time under the same unified event primary key. The trusted physical time represents the time record of the bidding entity's packet during the on-site acquisition process. The seal anchor texture area image reflects the physical state of the seal area of ​​the bidding entity's packet.

[0040] Before receiving the image of the anchored texture area of ​​the seal, the packet acquisition terminal 120 can first read the QR code label reading result of the bidding entity packet. If the QR code label reading result can identify the bidding object, the monitoring server 100 generates a unified event primary key based on the bidding object identifier, project identifier, bid section identifier, and node identifier. If the QR code label reading fails, the bidding object identifier can be entered through conventional manual review, and the record status is set to pending review. Records in the pending review status are not included in the automatic calculation of the consistency coefficient of the paper and electronic evidence chain until manual review is completed and written into a valid record.

[0041] The seal anchor texture area image is acquired using fixed geometric anchor points. These fixed geometric anchor points can be derived from at least one of the following: the four corners of the QR code, the location marker of the acquisition station, the packet boundary marker, or the location marker of the seal area. These fixed geometric anchor points ensure that the seal anchor texture area images acquired by different business nodes are in a comparable geometric state. If the acquisition angle, size, or position of the seal anchor texture area images differs significantly between different nodes, even if the bidding entity packet remains unchanged, it may lead to increased differences in the image fingerprint. Therefore, the monitoring server 100 performs geometric correction on the seal anchor texture area image based on the fixed geometric anchor points before generating the image fingerprint.

[0042] Geometric correction employs deterministic output rules. After identifying fixed geometric anchor points in the seal anchor texture area image, the packet acquisition terminal 120 sends the coordinates of these fixed geometric anchor points to the monitoring server 100. When there are at least three fixed geometric anchor points, the monitoring server 100 uses a conventional affine transformation to correct the seal anchor texture area image to the target coordinate system; when there are at least four fixed geometric anchor points, the monitoring server 100 can use a conventional perspective transformation to correct the seal anchor texture area image to the target coordinate system. The target coordinate system uses the upper left corner of the corrected image as the origin, the horizontal direction as the first coordinate direction, and the vertical direction as the second coordinate direction. The output image size is fixed and saved within the same project. If there are insufficient fixed geometric anchor points, the coordinates of fixed geometric anchor points are missing, or the corrected image cannot cover the seal anchor texture area image, the monitoring server 100 sets the record status of the corresponding physical packet evidence chain record to missing or pending review.

[0043] Within the same project, the cropping range, output image size, and target coordinate system of the seal anchoring texture area image remain unchanged. The monitoring server 100 extracts the effective area from the corrected seal anchoring texture area image according to a fixed cropping range, and then inputs this effective area into the image fingerprint generation process. This fixed cropping range ensures that the seal anchoring texture area images collected at the bid receiving node, bid opening node, bid evaluation node, bid awarding node, and archiving node are compared within the same spatial range, avoiding irreproducible image fingerprints due to differences in acquisition angle, rotation, scaling, or displacement.

[0044] When the monitoring server 100 generates an image fingerprint, it performs grayscale conversion, size normalization, perceptual hashing, and binarization on the geometrically corrected seal anchor texture area image to obtain an image fingerprint used for comparing the physical state of bidding entity packets across business nodes. Grayscale conversion reduces the impact of color differences on the image fingerprint; size normalization ensures that images from different nodes are processed at the same scale; perceptual hashing extracts features that characterize the overall texture state of the seal anchor texture area image; and binarization converts the perceptual hashing result into an image fingerprint that can be compared using Hamming distance.

[0045] Image fingerprint generation employs a fixed perceptual hashing processing rule. The monitoring server 100 first converts the geometrically corrected seal anchoring texture area image into a grayscale image. Then, it scales the grayscale image to a fixed target size within the same project and performs a discrete cosine transform on the scaled grayscale image, selecting the discrete cosine transform coefficients from a fixed low-frequency region as candidate coefficients. The monitoring server 100 calculates the median of the candidate coefficients and compares each candidate coefficient to this median. A candidate coefficient greater than or equal to the median is recorded as 1, and a candidate coefficient less than the median is recorded as 0. These candidate coefficients are arranged in a fixed order from top to bottom and left to right to form the image fingerprint. The number of perceptual hash bits is equal to the number of bits in the image fingerprint and remains constant within the same project.

[0046] When grayscale conversion fails, size normalization fails, discrete cosine transform cannot be completed, the number of candidate coefficients is insufficient, or binarization processing cannot obtain an image fingerprint with a fixed perceptual hash bit length, the monitoring server 100 sets the record status of the corresponding physical packet evidence chain record to missing or pending review. By fixing the target size, fixing the low-frequency region, fixing the source of the binarization threshold, and fixing the positional arrangement rule, the seal anchor texture area images of different business nodes can generate image fingerprints according to the same perceptual hash processing rule.

[0047]

[0048] in, Indicates the serial number of the bidding object is The node number is The image of the seal anchoring texture area; This indicates perceptual hashing; This represents the image fingerprint obtained by perceptual hashing the image of the seal anchor texture region. The image fingerprint is used to represent the physical state of the bidding entity packet of the same bidding object under different business nodes.

[0049] The monitoring server 100 writes the image fingerprint, trusted physical time, unified event primary key, and record status into the physical packet evidence chain, forming a physical packet evidence chain record. If the image of the seal anchor texture area is missing, the image fingerprint generation fails, the trusted physical time is missing, or the QR code label reading result fails verification, the monitoring server 100 can set the record status of the corresponding physical packet evidence chain record to missing or pending verification. Physical packet evidence chain records in the missing or pending verification state are not included in the set of valid node segments.

[0050] The recording status of the physical packet evidence chain is generated according to fixed rules. When the QR code tag reading result can identify the bidding object, confirm the existence of the seal anchor texture area image, confirm the existence of fixed geometric anchor points, confirm geometric correction, confirm the existence of the image fingerprint, confirm the existence of a trusted physical time, and confirm the existence of a unified event primary key, the recording status is valid. When the seal anchor texture area image, image fingerprint, trusted physical time, or unified event primary key is missing, the recording status is missing. When the QR code tag reading result cannot identify the bidding object, there are insufficient fixed geometric anchor points, geometric correction fails, image fingerprint generation fails, or manual confirmation of the correspondence between the bidding entity packets is required, the recording status is pending review. Only after manual review and regeneration of the image fingerprint can the pending review status be converted to valid.

[0051] Example 5:

[0052] The consistency processing module 150 reads the digital bid document evidence chain record and the physical packet evidence chain record from the evidence chain database 140, and selects adjacent nodes that simultaneously possess both digital bid document evidence chain records and physical packet evidence chain records to form a set of valid node segments. This set of valid node segments is used to limit which adjacent nodes participate in the calculation of the consistency coefficient of the paper-electronic evidence chain. For bid object serial number... The set of valid node segments for the bidding objects can be represented as .

[0053] When forming a set of valid node segments, the consistency processing module 150 determines whether adjacent nodes simultaneously contain both a valid digital bid document evidence chain record and a valid physical packet evidence chain record. If any record is missing or pending review, the consistency processing module 150 excludes the corresponding adjacent node from the set of valid node segments and outputs the node completion status. The node completion status can be used to display whether there is a valid record under the corresponding unified event primary key, and is presented as a node location in the full-cycle evidence chain supervision visualization image.

[0054] The set of valid node segments only accepts adjacent node segments with valid record status. For any adjacent node segment, if both the preceding and following nodes have digital bid document evidence chain records, and both the preceding and following nodes have physical packet evidence chain records, and all four record statuses are valid, then the adjacent node segment enters the set of valid node segments; if any record status is missing or pending review, then the adjacent node segment does not enter the set of valid node segments. The node completion status is generated based on the record status under the corresponding unified event primary key. When all record statuses are valid, the node completion status is complete; when any record status is missing, the node completion status is missing; when any record status is pending review, the node completion status is pending review.

[0055] For adjacent nodes in the set of valid node segments, the consistency processing module 150 generates a digital file content jump variable. This digital file content jump variable indicates whether the normalized file hashes of adjacent nodes are consistent. When the normalized file hashes of adjacent nodes are consistent, the digital file content jump variable takes a value of 0; when the normalized file hashes of adjacent nodes are inconsistent, the digital file content jump variable takes a value of 1. The purpose of the digital file content jump variable is to convert changes in the content of the electronic bid document into a calculable discrete variable, enabling the consistency coefficient of the paper-electronic evidence chain to comprehensively reflect the state of the electronic bid document content.

[0056]

[0057] in, Indicates the serial number of the bidding object. The node segment number is The content of the digital file jumps to variables; This indicates that the bidding object is in the node segment number. The normalized file hash corresponding to the previous node; This indicates that the bidding object is in the node segment number. The normalized file hash corresponding to the next node. The consistency processing module 150 generates a digital file content jump variable only when the corresponding adjacent node segment has entered the set of valid node segments; if any normalized file hash is missing, the corresponding adjacent node segment will not enter the set of valid node segments, and no digital file content jump variable will be generated.

[0058] For adjacent nodes in the set of valid node segments, the consistency processing module 150 generates a physical packet texture hop variable. The physical packet texture hop variable represents the degree of difference in image fingerprints between adjacent nodes. When the image fingerprint is a binary feature, the difference between image fingerprints of different nodes can be calculated using Hamming distance, then divided by the perceptual hash bit length to obtain a physical packet texture hop variable with a value ranging from 0 to 1. The larger the physical packet texture hop variable, the greater the difference in the seal anchor texture region image of the bidding entity packet between adjacent nodes.

[0059]

[0060] in, Indicates the serial number of the bidding object. The node segment number is Physical packet texture jump variable; This indicates that the bidding object is in the node segment number. The image fingerprint corresponding to the previous node; This indicates that the bidding object is in the node segment number. The image fingerprint corresponding to the next node; This indicates the calculation of Hamming distance; This indicates the number of bits in the perceptual hash. The perceptual hash number is the number of bits in the image fingerprint, used to normalize the Hamming distance to a comparable degree of difference.

[0061] For adjacent nodes in the set of valid node segments, the consistency processing module 150 also generates a cross-chain time difference. The cross-chain time difference represents the absolute value of the difference between the node interval time of the physical packet evidence chain and the node interval time of the digital bid document evidence chain. If the flow rhythm of the physical packet evidence chain and the digital bid document evidence chain is consistent between adjacent nodes, the cross-chain time difference is small; if there is a significant rhythm difference between the physical packet evidence chain and the digital bid document evidence chain between adjacent nodes, the cross-chain time difference increases. The cross-chain time difference is not the time of a single node, but rather the difference in node intervals between the two evidence chains within the same adjacent node segment.

[0062] Trusted digital time and trusted physical time are converted to the same time base and the same time unit before entering the cross-chain time difference calculation. The supervisory server 100 converts trusted digital time and trusted physical time into timestamps in the same time zone and saves them in seconds or milliseconds as fixed time units; only one fixed time unit can be used in the same project. If trusted digital time or trusted physical time cannot complete the time base conversion, the supervisory server 100 sets the status of the corresponding record to pending review, so that the adjacent node segment is not included in the set of valid node segments.

[0063]

[0064] in, Indicates the serial number of the bidding object is The node segment number is The cross-chain time difference; and These represent the trusted physical time of the bidding object at adjacent nodes; and These represent the credible digital time of the bidding object at adjacent nodes. The cross-chain time difference expresses the magnitude of the difference in the time interval between nodes in the two evidence chains through its absolute value.

[0065] After generating the cross-chain time difference, the consistency processing module 150 reads the cross-chain time differences of other bidding objects within the same project and the same node segment (excluding the current bidding object) to form a time difference set. Based on the median and median absolute deviation of the time difference set, the module normalizes the cross-chain time differences to generate a normalized time offset. Using the median and median absolute deviation of the time difference set reduces the impact of individual outliers within the same node segment on the normalization process, making the normalized time offset more stably reflect the time offset of the current bidding object relative to other bidding objects within the same project and the same node segment.

[0066]

[0067] in, Indicates the serial number of the bidding object is The node segment number is Normalized time offset; This indicates the cross-chain time difference of the corresponding node segment of the bidding object; This represents the set of time differences formed by the cross-chain time differences of other bidding objects within the same project and the same node segment, excluding the current bidding object. Represents the median of the set of time differences; Represents the median absolute deviation of the time difference set; The zero-minimum constant represents the minimum time unit. The zero-minimum constant and the cross-chain time difference use the same time unit; its value is the smallest positive time quantity corresponding to the recording resolution of the trusted digital time and trusted physical time. When the trusted digital time and trusted physical time are stored in seconds, the zero-minimum constant is expressed in seconds; when the trusted digital time and trusted physical time are stored in milliseconds, the zero-minimum constant is expressed in milliseconds. Therefore, the median, median absolute deviation, and zero-minimum constant in the denominator are all time quantities, and the normalized time offset is dimensionless.

[0068] If the number of other bidders in the same project or the same node segment is insufficient, resulting in the time difference set being insufficient to support stable calculation of the median and median absolute deviation, the regulatory server 100 can set the record status of the corresponding node segment to pending review and will not automatically generate the consistency coefficient of the paper and electronic evidence chain.

[0069] The time difference set includes at least one cross-chain time difference from another bidding object besides the current bidding object. When the time difference set is empty, the monitoring server 100 sets the record status of the corresponding node segment to pending review; when the time difference set is not empty, the consistency processing module 150 sorts the cross-chain time differences in the time difference set from smallest to largest to generate the median, and sorts the absolute differences between each cross-chain time difference and the median from smallest to largest to generate the median absolute deviation.

[0070] Example 6:

[0071] The consistency coefficient of the paper-electronic evidence chain is jointly determined by the digital file content jump variable, the physical packet texture jump variable, and the normalized time offset. The consistency coefficient is used to comprehensively characterize changes in the content of electronic bid documents between adjacent nodes, changes in the physical state of the bid entity packet, and differences in node intervals between the digital bid document evidence chain and the physical packet evidence chain. It also enhances the characterization of evidence anomaly risks when at least one of the above changes or differences increases.

[0072]

[0073] in, Indicates the serial number of the bidding object is Consistency coefficient of the paper and electronic evidence chain; Indicates the serial number of the bidding object is The set of valid node segments; This indicates the number of node segments in the set of valid node segments; Indicates the node segment number; Indicates the normalized time offset; Indicates the physical packet texture jump variable; Indicates a jump variable in the content of a digital file; This represents an exponential function. The consistency coefficient of the paper and electronic evidence chains ranges from 0 to 1. According to the definition in this scheme, the larger the consistency coefficient of the paper and electronic evidence chains, the lower the degree of matching between the content changes and circulation rhythm of the two evidence chains, and the higher the risk of evidence anomalies.

[0074] In this formula, the normalized time offset is used to express the difference in temporal rhythm between two chains of evidence at adjacent nodes, the physical packet texture jump variable is used to express changes in the physical state of the bid entity packet, and the digital file content jump variable is used to express changes in the content of the electronic bid document. These three variables are multiplied and fed into an exponential function, amplifying the temporal rhythm differences when changes occur in the electronic bid document content or the physical state of the bid entity packet.

[0075] After generating the consistency coefficient for the paper-electronic evidence chain, the consistency processing module 150 writes the consistency coefficient into the evidence chain database 140. The evidence chain database 140 can associate and save the consistency coefficient of the paper-electronic evidence chain with the bidding object identifier, the set of valid node segments, and the record status. The record status is used to identify whether the consistency coefficient of the paper-electronic evidence chain has been normally generated based on the set of valid node segments, or whether it was not generated due to missing records, pending review, an empty set of valid node segments, or insufficient samples in the time difference set.

[0076] Example 7:

[0077] The visualization image generation module 160 generates a full-cycle evidence chain regulatory visualization image based on the full-cycle node skeleton, bidding object identifier, node completion status, and consistency coefficient of the paper and electronic evidence chain. The full-cycle evidence chain regulatory visualization image forms a basic coordinate system with the full-cycle node skeleton as one coordinate direction and the bidding object identifier as another. In the basic coordinate system, node positions represent node completion status, and arcs crossing nodes represent the consistency coefficient of the paper and electronic evidence chain.

[0078] In one implementation, the full-cycle node skeleton serves as the horizontal coordinate direction, and the bid object identifier serves as the vertical coordinate direction. Each bid object corresponds to a node position at each node. If both the digital bid document evidence chain record and the physical packet evidence chain record under the unified event primary key are valid, the node position can be displayed as complete; if any record is missing, the node position can be displayed as missing; if any record is in a pending review state, the node position can be displayed as pending review. The node position does not need to display the bid object's real identity information; it can use the bid object identifier or an anonymized bid object identifier.

[0079] The basic coordinate system adopts a fixed arrangement rule. The visualization image generation module 160 arranges the horizontal coordinates according to the node order in the full-cycle node skeleton, and arranges the vertical coordinates according to the lexicographical order of the bid object identifiers or the fixed order of the bid object identifiers stored in the evidence chain database 140; a fixed sorting rule is used within the same project. The position of each node is determined by both the node number and the bid object identifier number. Different node display styles are used for the completion status, missing status, and pending review status, and the node display styles are fixedly stored within the same project.

[0080]

[0081] in, Indicates the serial number of the bidding object is The node segment number is The linewidth of the cross-node arc; Indicates the minimum line width of the arc spanning the node; Indicates the maximum line width of the arc spanning the nodes; This represents the consistency coefficient of the paper and electronic evidence chain. and Display parameters that are consistently saved within the same project, and Greater than The inputs to this formula are dimensionless display parameters or line widths, and the output is used to display cross-node arcs in a full-cycle evidence chain regulatory visualization image.

[0082]

[0083] in, Indicates the serial number of the bidding object is The node segment number is The transparency of the cross-node arc; Indicates the minimum transparency of the arc spanning the node; Indicates the maximum transparency of the arc across nodes; This represents the consistency coefficient of the paper and electronic evidence chain. and Display parameters that are consistently saved within the same project, and Greater than As the consistency coefficient of the paper-based evidence chain increases, the line width and transparency of the cross-node arcs also increase simultaneously.

[0084] Cross-node arcs are used to represent the consistency coefficient of the paper-electronic evidence chain. For adjacent nodes that enter the set of valid node segments, the visualization image generation module 160 generates cross-node arcs between the corresponding node points and maps the consistency coefficient of the paper-electronic evidence chain to the line width and transparency of the cross-node arcs. The larger the consistency coefficient of the paper-electronic evidence chain, the thicker the cross-node arcs can be and the higher the transparency can be, so that regulatory personnel can quickly locate bidding objects and node segments with high risk of evidence anomalies.

[0085] When generating a full-cycle evidence chain regulatory visualization image, the visualization image generation module 160 excludes quotations, amounts, personal identification information, and un-anonymized contact information according to the display field filtering rules. These display field filtering rules are used to prevent the full-cycle evidence chain regulatory visualization image from disclosing sensitive information that does not need to be displayed. The full-cycle evidence chain regulatory visualization image mainly expresses the completion status of nodes, the consistency coefficient of the paper and electronic evidence chain, and the traceability relationship related to the unified event primary key, and does not use quotations, amounts, personal identification information, or un-anonymized contact information as image content.

[0086] The field filtering rules employ a combination of field whitelists and field blacklists. The field whitelist includes the full-cycle node skeleton, bidding object identifier, node completion status, consistency coefficient of the paper and electronic evidence chain, unified event primary key, image file hash, and image archive records. The field blacklist includes price quotes, amounts, individual identity information, and un-anonymized contact information. When the visualization image generation module 160 generates a full-cycle evidence chain regulatory visualization image, it only reads fields from the field whitelist. If a field to be displayed matches a field in the field blacklist, that field is directly excluded. If a field to be displayed belongs to neither the field whitelist nor the field blacklist, that field is excluded, and the filtering result is recorded. Through this rule, the full-cycle evidence chain regulatory visualization image does not display price quotes, amounts, individual identity information, or un-anonymized contact information.

[0087] After generating a full-cycle evidence chain regulatory visualization image, the visualization image generation module 160 can save the image as an SVG image file or a PNG image file. The regulatory server 100 simultaneously associates and saves the image file hash and image archive record with the unified event primary key. The image file hash is used to characterize the content of the archived image file, and the image archive record is used to record the storage location and archiving time of the full-cycle evidence chain regulatory visualization image. This process enables regulatory personnel to locate not only the digital tender document evidence chain record and the physical packet evidence chain record when querying the unified event primary key, but also the visualization element and image archive record corresponding to that unified event primary key.

[0088] The image file hash is calculated based on the complete file bytes of the saved SVG or PNG image file. After saving the full-cycle evidence chain monitoring visualization image, the monitoring server 100 reads the complete file bytes of the SVG or PNG image file and calculates the image file hash. If saving the SVG or PNG image file fails, or if image file hash generation fails, the monitoring server 100 sets the record status of the image archive to missing or pending review. The image archive record at least stores the unified event primary key, the storage address of the full-cycle evidence chain monitoring visualization image, the image file hash, and the record status.

[0089] As an optional implementation, the electronic document receiving interface 110 successfully receives electronic bid documents and trusted digital timestamps at the bid receiving node, bid opening node, bid evaluation node, bid award node, and archiving node; the packet acquisition terminal 120 successfully reads the QR code label reading results, acquires the seal anchor texture area image, and records the trusted physical time at the same nodes. The digital bid document evidence chain record and the physical packet evidence chain record generated by the monitoring server 100 are both in a valid state. At this time, the set of valid node segments includes adjacent node segments such as bid receiving node to bid opening node, bid opening node to bid evaluation node, bid evaluation node to bid award node, and bid award node to archiving node. If the content of the electronic bid document of the same bid object has not changed, the normalized file hash of adjacent nodes is consistent, and the digital file content jump variable is 0. If the seal anchor texture area image of the bid entity packet remains stable, the image fingerprint difference between adjacent nodes is small, and the physical packet texture jump variable is low. If the flow rhythm of the digital bid document evidence chain and the physical packet evidence chain between adjacent nodes is similar to that of other bid objects in the same node segment of the same project, the normalized time offset is low. At this point, the consistency coefficient of the paper and electronic evidence chains is low, indicating a high degree of matching between the content changes and the flow rhythm of the two evidence chains. The visualization image generation module 160 displays each node as completed in the full-cycle evidence chain supervision visualization image, and displays the cross-node arcs as a display effect of a low consistency coefficient in the paper and electronic evidence chains. Supervisory personnel can confirm through the image that the digital bid document evidence chain record and physical package evidence chain record of the bidding object are complete on the full-cycle node skeleton.

[0090] As an optional implementation, the electronic document receiving interface 110 receives electronic bid documents from the same bidder at both the bid opening node and the bid evaluation node. The monitoring server 100 performs normalization processing on the electronic bid documents from both nodes and generates normalized file hashes for each. If the normalized file hash of the bid opening node is inconsistent with that of the bid evaluation node, the consistency processing module 150 sets the digital file content jump variable corresponding to the bid opening node to the bid evaluation node to 1. If the image fingerprints generated by the packet acquisition terminal 120 within the adjacent node segment are not significantly different and the physical packet texture jump variable is low, but the digital file content jump variable already indicates that the content of the electronic bid document has changed, the consistency coefficient of the paper-electronic evidence chain will still increase due to the participation of the digital file content jump variable in the calculation. The visualization image generation module 160 maps the consistency coefficient of the paper-electronic evidence chain to the line width and transparency of the cross-node arc, enabling the monitoring personnel to locate the node segment where the content change of the electronic bid document occurs and further query the corresponding digital bid document evidence chain record through the unified event primary key.

[0091] As an optional implementation, the packet acquisition terminal 120 acquires images of the seal anchor texture area of ​​the same bidding object at adjacent nodes. The monitoring server 100 performs geometric correction on the seal anchor texture area image based on fixed geometric anchor points and generates an image fingerprint. If the Hamming distance between the image fingerprints of adjacent nodes is large, the physical packet texture hop variable increases. If the normalized file hash of the electronic bidding document remains consistent between adjacent nodes, the digital file content hop variable is 0, but the physical packet texture hop variable increases, and the consistency coefficient of the paper-electronic evidence chain will still increase. This result indicates that there is an abnormal risk in the physical state of the bidding entity packet. The visualization image generation module 160 enhances the cross-node arc of the corresponding node segment in the full-cycle evidence chain monitoring visualization image. Supervisory personnel can query the seal anchor texture area image and image fingerprint through the unified event primary key and conduct subsequent verification.

[0092] As an optional implementation, both the electronic document receiving interface 110 and the packet acquisition terminal 120 form valid records at adjacent nodes, but the node interval time of the digital bid document evidence chain differs significantly from that of the physical packet evidence chain. For example, the record interval of the electronic bid document between the bid opening node and the bid evaluation node is relatively short, while the credible physical time interval of the bid entity packet within the same node segment is significantly longer. Based on this, the consistency processing module 150 generates a large cross-chain time difference. The consistency processing module 150 further reads the cross-chain time differences of other bid objects within the same project and the same node segment to form a time difference set, and generates a normalized time offset based on the time difference set. If the cross-chain time difference of the current bid object deviates significantly from the time difference set, the normalized time offset increases. Even if the jump variables of the digital document content and the physical packet texture are low, the normalized time offset will still increase the consistency coefficient of the paper and electronic evidence chains, thereby reflecting the abnormal risk in the circulation rhythm of the two evidence chains.

[0093] As an optional implementation, a certain adjacent node may lack a digital bid document evidence chain record, or a physical packet evidence chain record, or either record may be in a pending review status. For example, the packet acquisition terminal 120 may fail to read the QR code label reading result at a certain node, resulting in the bid object identification requiring manual review; or the electronic document receiving interface 110 may fail to perform normalization processing after receiving the electronic bid document, resulting in a missing normalized document hash. In this case, the consistency processing module 150 does not include the corresponding adjacent node in the set of valid node segments, but instead outputs the node completion status. The visualization image generation module 160 displays the missing status or pending review status through node locations in the full-cycle evidence chain supervision visualization image. Since this node segment is not included in the automatic calculation of the paper-electronic evidence chain consistency coefficient, supervisors can first address the record integrity issue, and then decide whether to recalculate the paper-electronic evidence chain consistency coefficient based on the review results.

[0094] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for full-cycle data visualization and supervision of enterprise bidding, used to process electronic bid documents and bid entity packages, characterized in that, Executed by the monitoring server, including: Generate a full-cycle node skeleton and generate a unified event primary key based on the project identifier, bid section identifier, bidding object identifier, and node identifier; Upon receiving electronic bid documents, perform normalization processing to generate a normalized file hash representing the content of the electronic bid documents. Write the normalized file hash, trusted digital time, unified event primary key, and record status into the digital bid document evidence chain to form a digital bid document evidence chain record. Receive the seal anchor texture area image of the bidding entity packet, perform geometric correction on the seal anchor texture area image based on fixed geometric anchor points, generate an image fingerprint representing the state of the bidding entity packet, and write the image fingerprint, trusted physical time, unified event primary key and record state into the physical packet evidence chain to form a physical packet evidence chain record. Adjacent nodes that simultaneously possess both digital bid document evidence chain records and physical packet evidence chain records are selected to form a set of valid node segments. Digital file content jump variables, physical packet texture jump variables, and cross-chain time differences are generated. Based on the cross-chain time differences of other bid objects within the same project and the same node segment, a normalized time offset is generated. Based on the digital file content jump variables, physical packet texture jump variables, and normalized time offset, a paper-electronic evidence chain consistency coefficient is generated. A full-cycle evidence chain regulatory visualization image is generated based on the full-cycle node skeleton, bidding object identification, node completion status, and consistency coefficient of paper and electronic evidence chains.

2. The enterprise bidding full-cycle data visualization supervision method according to claim 1, characterized in that, Generating the unified event primary key includes: The unified event primary key is generated in a fixed order of project identifier, bid section identifier, bidding object identifier, and node identifier, and is used for query binding between digital bid document evidence chain, physical packet evidence chain, node completion status, and full-cycle evidence chain supervision visualization image.

3. The enterprise bidding full-cycle data visualization supervision method according to claim 1, characterized in that, The normalization process includes: The main text, tables, embedded objects and attachments related to the substantive content of the electronic tender documents are retained. Non-content factors related to file metadata, storage format differences and system cache information are removed, and the version of the normalization processing rules is recorded so that the normalized file hashes of different business nodes are generated according to the same rules.

4. The enterprise bidding full-cycle data visualization supervision method according to claim 1, characterized in that, The digital bid document evidence chain record includes a normalized processing rule version, normalized file hash, trusted digital time, and record status corresponding to the same unified event primary key. The physical packet evidence chain record includes an image fingerprint, trusted physical time, and record status corresponding to the same unified event primary key. The record status is used to determine whether the digital bid document evidence chain record and the physical packet evidence chain record have entered the set of valid node segments.

5. The enterprise bidding full-cycle data visualization supervision method according to claim 1, characterized in that, Before receiving the seal anchoring texture area image, the system also receives the QR code tag reading result of the bidding entity package, determines the bidding object identifier based on the QR code tag reading result, and receives the seal anchoring texture area image obtained by using at least one of the four corners of the QR code, the acquisition station positioning mark, the package boundary mark, or the seal area positioning mark as fixed geometric anchor points.

6. The enterprise bidding full-cycle data visualization supervision method according to claim 1, characterized in that, Generating the image fingerprint includes: The geometrically corrected image of the anchor texture region of the seal is subjected to grayscale conversion, size normalization, perceptual hashing, and binarization to obtain an image fingerprint for comparing the physical state of the bidding entity packet across business nodes.

7. The enterprise bidding full-cycle data visualization supervision method according to claim 1, characterized in that, Forming the set of valid node segments includes: Determine whether adjacent nodes simultaneously contain a valid digital bid document evidence chain record and a valid physical packet evidence chain record; If any record is missing or pending review, the corresponding adjacent node will be excluded from the set of valid node segments, and the node completion status will be output.

8. The enterprise bidding full-cycle data visualization supervision method according to claim 1, characterized in that, Generating the normalized time offset includes: The cross-chain time differences of other bidding objects within the same project and the same node segment, excluding the current bidding object, are read to form a time difference set. The cross-chain time differences are then normalized based on the median and median absolute deviation of the time difference set.

9. The method for full-cycle data visualization supervision of enterprise bidding as described in claim 1, characterized in that, The consistency coefficient of the paper-electronic evidence chain is jointly determined by the digital file content jump variable, the physical packet texture jump variable, and the normalized time offset. It is used to comprehensively characterize the changes in the electronic bid document content, the changes in the physical state of the bid entity packet, and the differences in the node intervals between the digital bid document evidence chain and the physical packet evidence chain between adjacent nodes. When at least one of the changes in the electronic bid document content, the changes in the physical state of the bid entity packet, and the differences in the node intervals between the digital bid document evidence chain and the physical packet evidence chain increases, the characterization of evidence anomaly risk is improved.

10. The enterprise bidding full-cycle data visualization supervision method according to claim 1, characterized in that, Generating the full-cycle evidence chain regulatory visualization image includes: A basic coordinate system is formed with the full-cycle node skeleton as one coordinate direction and the bidding object identifier as another coordinate direction. In the basic coordinate system, the node position represents the node completion status, and the cross-node arc represents the consistency coefficient of the paper and electronic evidence chain. The full-cycle evidence chain supervision visualization image is generated according to the display field filtering rules, and the full-cycle evidence chain supervision visualization image is saved as an SVG image file or a PNG image file. At the same time, the image file hash and image archive record are associated and saved with the unified event primary key. The display field filtering rules are used to exclude quotations, amounts, personal identification information, and contact information that has not been anonymized.

Images