A data alignment procurement optimization method, system, medium, and product

Abstract

The application discloses a data alignment procurement optimization method, system, medium and product, and relates to the technical field of data processing.In the method, by obtaining procurement data of a first business system and response data of a second business system, a to-be-aligned record is created in an alignment check table.The system performs consistency check on the response data and the to-be-aligned record, and updates the alignment state after passing.The push permission instruction is generated according to the initial alignment identifier set associated with the procurement business document, and the data packet is sent to the second business system for mapping.The return alignment identifier set in the business result data packet returned by the second business system is received and parsed, and by comparing the consistency of the return alignment identifier set and the initial alignment identifier set, it is determined whether to generate a business result document or to mark the procurement business document as an exception and start a verification process.Implementation of the technical solution provided by the application can improve the efficiency of procurement business data processing.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a data alignment procurement optimization method, system, medium, and product. Background Technology

[0002] As enterprises deepen their digital transformation, the scale and complexity of cross-system business collaboration are constantly increasing. As a key infrastructure connecting internal and external supply chains, the accuracy of data alignment in procurement systems is crucial for the scientific management of procurement processes. Data alignment refers to ensuring that procurement data exchanged between different business systems remains consistent in terms of coding rules, attribute definitions, and other aspects.

[0003] Currently, data alignment in procurement operations primarily relies on establishing standard interfaces between systems, mapping and transmitting information from different systems through data conversion. This interface-based alignment method can meet the basic transmission needs of procurement data and has been widely used in enterprise procurement operations.

[0004] However, with the increasing diversity of procurement scenarios, data interaction between systems is becoming more frequent. In practical applications, alignment methods based on interface conversion struggle to accurately track the transmission status of each piece of business data, and manual intervention is often required to handle anomalies during data conversion. Especially when data transmission anomalies occur, the lack of an effective status tracking mechanism necessitates significant manpower for verification and processing, thereby reducing the efficiency of procurement data processing. Summary of the Invention

[0005] This application provides a data alignment procurement optimization method, system, medium, and product that can improve the efficiency of procurement business data processing.

[0006] The first aspect of this application provides a data alignment procurement optimization method, comprising: Obtain procurement data from the first business system and response data from the second business system. The first business system is the procurement request initiator, and the second business system is the external collaborative response provider. In response to the procurement data, create a record to be aligned in the alignment verification table, which includes a cross-system alignment identifier; The response data and the record to be aligned are encoded and their attributes are checked for consistency. When the consistency check passes, the cross-system alignment identifier of the record to be aligned is updated to the aligned state. After the cross-system alignment identifier is updated, the initial alignment identifier set associated with the purchase business documents of the first business system is obtained, and a push permission instruction is generated based on the initial alignment identifier set. In response to the push permission instruction, the purchase business document and the initial alignment identifier set are encapsulated into a data packet and sent to the second business system to map and generate business document records; Receive the business result data packet generated by the second business system based on the business document record, and parse it to obtain the set of return alignment identifiers in the business result data packet; The return alignment identifier set is compared with the initial alignment identifier set. If the comparison result is consistent, a business result document is generated. If the comparison result is inconsistent, the purchase business document is marked as abnormal and a preset verification business process is initiated.

[0007] By adopting the above technical solution, and by acquiring procurement data from the first business system and response data from the second business system, and creating a record to be aligned containing cross-system alignment identifiers in the alignment verification table, the entire procurement data transmission process can be tracked. When the encoding and attributes of the response data and the record to be aligned pass the consistency verification, the alignment identifier is updated to an aligned state, thereby ensuring the accuracy of data mapping between different systems. Furthermore, a push permission instruction is generated based on the initial alignment identifier set associated with the procurement business document, and the procurement business document and the initial alignment identifier set are sent as a data packet to the second business system, enabling the second business system to accurately map and generate business document records. By comparing the consistency between the alignment identifier set returned by the second business system and the initial alignment identifier set, anomalies in the data transmission process can be detected in a timely manner, and a preset verification business process can be automatically triggered, thereby significantly reducing the workload of manual verification. This solution establishes a complete data alignment mechanism, which not only achieves accurate transmission of procurement data but also enables rapid location and handling of anomalies, improving the efficiency of procurement business data processing.

[0008] Optionally, the first coded identifier in the record to be aligned and the second coded identifier in the response data are extracted; the second coded identifier is matched with the first coded identifier; when the string matching degree between the second coded identifier and the first coded identifier is greater than the matching degree threshold, the target attribute fields of the response data and the procurement data are extracted, and the first hash value of the response data and the second hash value of the procurement data are calculated based on the target attribute fields; when the first hash value and the second hash value are the same, the consistency verification is determined to be passed; the status field of the cross-system alignment identifier in the alignment verification table is updated to the aligned status; the cross-system alignment identifier is written into the data extension fields of the first business system and the second business system respectively to establish a cross-system data mapping relationship.

[0009] Optionally, the bill of materials in the procurement document is read, and the cross-system alignment identifiers corresponding to each material item in the bill of materials are extracted; the extracted cross-system alignment identifiers corresponding to each material item are combined into an initial alignment identifier set; the alignment status of each cross-system alignment identifier in the initial alignment identifier set is queried one by one in the alignment verification table; based on the alignment status, the alignment integrity ratio is calculated, and the alignment integrity ratio is the ratio of the number of cross-system alignment identifiers in the initial alignment identifier set whose alignment status is aligned to the total number of cross-system alignment identifiers in the initial alignment identifier set; when the alignment integrity ratio is greater than or equal to a preset threshold, the push permission instruction is generated.

[0010] Optionally, based on the interface protocol of the second business system, the procurement business document is converted into a standard exchange format file according to the interface protocol, and the initial alignment identifier set is embedded in the metadata header of the standard exchange format file; the standard exchange format file is encrypted using a preset encryption algorithm to generate an encrypted transmission data packet; the encrypted transmission data packet is sent to the receiving interface of the second business system through a secure transmission channel; the second business system is triggered to decrypt the encrypted transmission data packet, and the corresponding material mapping relationship is searched in the database of the second business system according to the initial alignment identifier set in the metadata header; based on the material mapping relationship and the business content in the standard exchange format file, an instantiation is performed in the second business system to generate a business document record corresponding to the procurement business document.

[0011] Optionally, multiple fragmented data packets transmitted back from the second business system are collected through a preset asynchronous message queue; data is reassembled based on the sequence number of each fragmented data packet to obtain the original bitstream of the business result data packet; digital signature digests are extracted from the original bitstream, and the digital signature digests are verified using a preset public key; after verification, the original bitstream is deserialized to obtain a business result object; the row item list in the business result object is traversed using a reflection mechanism to extract the alignment identifier field value marked as an immutable attribute; the extracted alignment identifier field values ​​are sorted according to a preset sorting rule to generate a return identifier sequence, and the checksum of the return identifier sequence is calculated; the return identifier sequence and the checksum are used as the return alignment identifier set.

[0012] Optionally, the class metadata handle of the business result object is obtained, and the class metadata handle is used to scan all member variable declarations of the business result object; a target member variable with a preset immutable attribute mark is identified in the member variable declaration, and a field reflection instance corresponding to the target member variable is constructed; the access control flag of the field reflection instance is removed, and an accessible field channel is established; through the accessible field channel, each row item object in the row item list is mapped one by one, the attribute data corresponding to each row item object in the memory stack is read, and the attribute data is used as the alignment identifier field value.

[0013] Optionally, the initial alignment identifier set and the return alignment identifier set are converted into binary bitmaps, and flag bits are set in the corresponding bitmaps of the binary bitmaps based on the hash values ​​of each cross-system alignment identifier; a bitwise XOR operation is performed on the binary bitmaps, and a match is determined when all bits of the operation result are zero; the actual delivery quantity in the business result data packet is extracted, and the actual delivery quantity is compared with the planned purchase quantity in the purchase business document to generate a business result document; if there are non-zero bits in the bitwise XOR operation result, a mismatch is determined, the bit indices of the non-zero bits are traversed, and a reverse mapping is performed to obtain the difference alignment identifier; the corresponding material code is queried in the alignment verification table according to the difference alignment identifier, a difference material list is generated, and it is stored in association with the document number of the purchase business document; the status field of the purchase business document is updated to an abnormal status, and a preset verification business process containing the difference material list and the document number is inserted into a preset abnormal processing queue.

[0014] In a second aspect, embodiments of this application provide a data alignment procurement optimization system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the data alignment procurement optimization system to perform the method described in the first aspect and any possible implementation thereof.

[0015] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a data alignment procurement optimization system, cause the data alignment procurement optimization system to perform the method described in the first aspect and any possible implementation thereof.

[0016] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a data alignment procurement optimization system, cause the data alignment procurement optimization system to perform the method described in the first aspect and any possible implementation thereof.

[0017] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: By adopting the above technical solution, and by acquiring procurement data from the first business system and response data from the second business system, and creating a record to be aligned containing cross-system alignment identifiers in the alignment verification table, the entire procurement data transmission process can be tracked. When the encoding and attributes of the response data and the record to be aligned pass the consistency verification, the alignment identifier is updated to an aligned state, thereby ensuring the accuracy of data mapping between different systems. Furthermore, a push permission instruction is generated based on the initial alignment identifier set associated with the procurement business document, and the procurement business document and the initial alignment identifier set are sent as a data packet to the second business system, enabling the second business system to accurately map and generate business document records. By comparing the consistency between the alignment identifier set returned by the second business system and the initial alignment identifier set, anomalies in the data transmission process can be detected in a timely manner, and a preset verification business process can be automatically triggered, thereby significantly reducing the workload of manual verification. This solution establishes a complete data alignment mechanism, which not only achieves accurate transmission of procurement data but also enables rapid location and handling of anomalies, improving the efficiency of procurement business data processing. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a data alignment and procurement optimization method disclosed in an embodiment of this application; Figure 2 This is another flowchart illustrating a data alignment and procurement optimization method disclosed in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a system provided in an embodiment of this application.

[0019] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0021] In the description of the embodiments in this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Specifically, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a concrete manner.

[0022] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0023] This application provides a data alignment and procurement optimization method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a data alignment procurement optimization method provided in an embodiment of this application. The method is applied to a system, which refers to a hardware and software integrated platform capable of executing a data alignment procurement optimization program. The system can execute a data alignment procurement optimization program, and the method includes steps 101 to 107, as follows: Step 101: Obtain the procurement data from the first business system and the response data from the second business system. The first business system is the procurement request initiator, and the second business system is the external collaborative response provider.

[0024] The first business system is an internal information system used by the enterprise to initiate procurement requests, formulate procurement plans, and manage procurement processes. It includes basic data such as purchase requisitions, purchase orders, and material codes. Procurement data refers to structured data generated during the procurement process, specifically including fields such as purchase order number, material code, quantity purchased, amount purchased, and delivery date. The second business system is a collaborative system used by suppliers or external partners to receive and respond to procurement requests. It is responsible for processing order confirmations, shipment notifications, and delivery feedback. Response data refers to the confirmation information returned by the second business system in response to procurement requests, including data items such as response order number, material code, confirmed quantity, and estimated delivery date.

[0025] Specifically, business data from both ends is acquired in real time through data interfaces between the systems. For procurement data from the first business system, a direct database connection is used, executing SQL queries to filter newly added or updated procurement document records within a specific time period and extracting necessary business fields. Simultaneously, a Web Service interface is used to call the data service provided by the second business system to obtain the corresponding response information. In practice, a database connection pool is first established, query conditions (such as timestamps, document status, etc.) are defined, and a select statement is executed to retrieve procurement data. Then, the getResponseData interface of the external system is called, passing in query parameters (such as the procurement order number), and receiving the returned response data. The acquired data is transmitted and parsed in JSON or XML format, and the parsed field values ​​are saved in memory objects to prepare for subsequent data alignment processing. During the data acquisition process, exception handling and retry mechanisms are required to ensure data integrity. For example, reconnection is performed when a database connection fails, retry is executed when an interface call times out, and basic format validation is performed on the acquired data. This ensures that complete and valid business data is obtained for subsequent processing.

[0026] Step 102: In response to the procurement data, create a record to be aligned in the alignment check table containing a cross-system alignment identifier.

[0027] The alignment verification table is a database table used to store and manage cross-system data mapping relationships. It includes fields such as alignment identifier, data status, and creation time. The cross-system alignment identifier is a string used to uniquely identify the data correspondence between two systems. It is generated using a combination of UUID or timestamp and random number to ensure global uniqueness. A record to be aligned is a data item in the alignment verification table, recording the business information that requires cross-system data alignment, including the alignment identifier, source system data, target system data, and alignment status.

[0028] Specifically, upon receiving the procurement data, a 32-bit cross-system alignment identifier is generated using UUID to ensure its uniqueness. Then, an insert statement is constructed for the alignment check table, inserting a new record into the `alignment_check_table`. This record includes fields such as `alignment_id` (alignment identifier), `source_system_code` (source system code), `source_business_id` (source system business ID), `material_code` (material code), `quantity` (quantity), `price` (unit price), `alignment_status` (alignment status, initially set to "pending alignment"), `create_time` (creation time), and `update_time` (update time). After the insert operation, a new record awaiting alignment is generated in the alignment check table. Simultaneously, the alignment identifier is returned to the caller for subsequent data processing and status tracking. During record creation, transaction control ensures data consistency; if insertion fails, a rollback operation is performed. For batch procurement data, batch processing is used to improve insertion efficiency, processing 1000 records per batch, and pre-compiled SQL statements enhance execution performance. After creation, the record awaiting alignment enters its initial state, awaiting subsequent data alignment processing. The entire process enabled the automatic conversion and identification generation of procurement data into records to be aligned, laying the foundation for subsequent cross-system data alignment.

[0029] Step 103: Perform consistency verification of the encoding and attributes between the response data and the record to be aligned. When the consistency verification passes, update the cross-system alignment flag of the record to be aligned to the aligned state.

[0030] Encoding refers to the unique identification code used in the system to identify business objects such as materials and documents, including both internal and external encoding. Attributes are specific data items describing the characteristics of a business object, such as material specifications, model, and unit price. Consistency verification is the process of comparing the encoding and attribute values ​​in the response data with those in the record to be aligned to determine if they match. An aligned state indicates that a correct mapping relationship has been established between the data in the two systems.

[0031] Specifically, the process begins by extracting a first encoding identifier from the record to be aligned and a second encoding identifier from the response data. A string matching algorithm is then used to calculate the similarity between the two encodings. The similarity calculation employs an edit distance algorithm, comparing the two encoded strings character by character to calculate the minimum number of operations required to convert one string to the other, including insertion, deletion, and replacement. The calculated edit distance is divided by the length of the longer string to obtain a normalized similarity value. When the similarity value exceeds a preset matching threshold (e.g., 0.9), target attribute fields are further extracted for comparison. These target attribute fields contain key business data such as quantity, price, and specifications. The extracted attribute field values ​​are standardized by removing spaces, unifying case, and formatting values. Then, hash algorithms such as SHA-256 are used to calculate the hash values ​​of the response data and the procurement data, respectively. The two hash values ​​are compared; if they are identical, the consistency check passes. An update operation is then initiated in the alignment check table, changing the status field of the corresponding record from "to be aligned" to "aligned." Simultaneously, extended fields are added to the data tables of the first and second business systems, containing cross-system alignment identifiers to establish a data mapping relationship between the two systems. After the update is complete, the data is aligned and enters the aligned state. The entire process achieves automated alignment and state update of cross-system data, and data consistency verification can be completed without manual intervention.

[0032] In one possible implementation, the response data and the record to be aligned are encoded and their attributes are checked for consistency. When the consistency check passes, the cross-system alignment identifier of the record to be aligned is updated to an aligned state. Specifically, this includes steps 1031-1033, which are as follows: Step 1031: Extract the first encoding identifier from the record to be aligned and the second encoding identifier from the response data.

[0033] The first coded identifier in the record to be aligned is a unique identifier for business objects such as material codes and document numbers in the first business system, represented by a string with a fixed format and length. The second coded identifier in the response data is the corresponding business object identifier in the second business system, and has a mapping relationship with the first coded identifier. These two coded identifiers follow the coding rules of their respective systems. For example, material code "M2024001" in the first system may correspond to "MAT20240001" in the second system.

[0034] Specifically, during the extraction of records to be aligned, the records with the status field value of "to be aligned" in the alignment verification table are first read, and the specific data row is located based on the primary key or business key of the record. The value of the source_code field is read from the data row, which stores the encoding identifier of the first business system. During the extraction of response data, the received response data structure is parsed, and fields such as code or identifier representing encoding are located, and the field value is read as the second encoding identifier. During the extraction process, encoding format standardization needs to be handled, including operations such as removing leading and trailing spaces, unifying capitalization, and removing special characters. Standardization is done through string processing functions, such as trim() to remove spaces, toUpperCase() to convert to uppercase, and replaceAll() to replace special characters. For encodings containing prefixes or suffixes, the core encoding part needs to be extracted according to predefined rules. After extraction, the two encoding identifiers are saved to memory variables for subsequent matching and comparison. The entire extraction process ensures the acquisition of accurate encoding identifiers, laying the foundation for subsequent consistency verification.

[0035] Step 1032: Perform string matching between the second encoding identifier and the first encoding identifier; when the string matching degree between the second encoding identifier and the first encoding identifier is greater than the matching degree threshold, extract the target attribute fields of the response data and the procurement data, and calculate the first hash value of the response data and the second hash value of the procurement data based on the target attribute fields; when the first hash value and the second hash value are the same, the consistency check is confirmed to be passed.

[0036] Match score is a numerical value representing the similarity between two strings, ranging from 0 to 1. The match score threshold is the standard value for determining whether a string match passes, typically set to 0.8 or 0.9. The target attribute field refers to the business attributes that need to be compared for consistency, including key data items such as quantity, specifications, and price. The hash value is a fixed-length string calculated using a hash algorithm, used to quickly determine whether the data content is consistent.

[0037] Specifically, the first stage is string matching, using the edit distance algorithm to calculate the similarity between two codes. The edit distance calculation process is as follows: create an (m+1)×(n+1) matrix (where m and n are the lengths of the two strings, respectively), where each element of the matrix represents the minimum number of operations required to transform from the first i characters of the first string to the first j characters of the second string. The matrix is ​​filled using dynamic programming, and the bottom right element of the final matrix represents the edit distance. Dividing the edit distance by the length of the longer string yields the normalized matching score. The second stage is attribute extraction and hash calculation, executed when the matching score is greater than a preset threshold (e.g., 0.9). First, target attribute fields are extracted from the response data and procurement data, and each field is standardized (uniform numerical precision, removal of spaces, sorting, etc.). Then, the processed attribute values ​​are concatenated into strings in a fixed order, and the SHA-256 algorithm is used to calculate the hash values ​​of the two strings respectively. The SHA-256 algorithm divides the input data into 512-bit blocks, performs 64 rounds of compression function operations on each block, and finally generates a 256-bit hash value. The third stage is hash value comparison, which directly compares whether the strings of two hash values ​​are completely identical. When the hash values ​​are the same, it indicates that the business data in the two systems are completely consistent, and the consistency check passes. The entire process ensures the accuracy of data alignment through two verifications: string matching and hash value comparison.

[0038] Step 1033: Update the status field of the cross-system alignment identifier in the alignment verification table to the aligned status; write the cross-system alignment identifier into the data extension fields of the first business system and the second business system respectively to establish a cross-system data mapping relationship.

[0039] The alignment check table's status field records the data alignment processing status, including multiple status values ​​such as pending alignment, aligned, and exception. Data extension fields are reserved in the business system's data tables for storing additional business information, typically in JSON or string format. Cross-system data mapping relationships are established between different systems through alignment identifiers, ensuring that business data can correspond and be traced. An aligned status indicates that the business data has completed inter-system matching and association.

[0040] Specifically, the alignment check table is first updated by using an UPDATE statement to change the status field of the record corresponding to the specified alignment identifier from "pending alignment" to "aligned," while simultaneously updating the record's update time field to the current system time. Row-level locking ensures data consistency during the status update. Then, in the first business system's data table, the corresponding business record is located, and the alignment identifier is written to a predefined extended field. This extended field is stored in JSON format and contains information such as the alignment identifier, alignment time, and alignment source. The same operation is performed on the second business system, writing the same alignment identifier information to the extended field of its corresponding business record. Transaction control ensures that the update operations in both systems are completed synchronously; if the write operation fails in either system, the entire process is rolled back. After the write operation is complete, data association queries between the two systems can be achieved using the alignment identifier. For example, querying the response record in the second system based on a business document from the first system, or reverse querying the procurement source in the first system. This mapping relationship supports subsequent business collaboration and data traceability. The entire process achieves synchronized data status updates and inter-system data association, providing a data foundation for cross-system business processing.

[0041] Step 104: After the cross-system alignment identifier is updated, obtain the initial alignment identifier set associated with the purchase business documents of the first business system, and generate a push permission instruction based on the initial alignment identifier set.

[0042] Purchase transaction documents are business vouchers generated during the procurement process, including types such as purchase orders and purchase requisitions, recording the specific content and execution status of procurement activities. The initial alignment identifier set is a combination of multiple alignment identifiers associated with the purchase transaction document; these alignment identifiers correspond to different material items or business items within the document. The push authorization command is a data transmission authorization command issued by the system based on the alignment status, used to control the cross-system transfer of business data. The bill of materials is a list of specific material items contained in the purchase transaction document, recording information such as material code, quantity, and specifications.

[0043] Specifically, after updating the cross-system alignment identifiers of the records to be aligned, the material list data of the purchase order is first read. Each material item in the list is traversed, and the corresponding cross-system alignment identifier is retrieved from the alignment verification table. The query process matches based on the material code or other business keys, returning the alignment identifiers corresponding to records with a "aligned" value in the status field of the alignment verification table. All retrieved alignment identifiers are added to a set, forming an initial alignment identifier set. The alignment identifiers in the set are deduplicated to ensure each identifier appears only once. Then, the ratio of the number of identifiers with an alignment status of "aligned" to the total number of identifiers is calculated to obtain the alignment integrity ratio. The alignment integrity calculation formula is: number of aligned identifiers / total number of identifiers. When the alignment integrity ratio reaches or exceeds a preset threshold (e.g., 0.95), it indicates that the data associated with the business document has sufficient alignment. At this time, a push permission instruction containing information such as the push timestamp, business document identifier, and alignment identifier set is generated. The generated permission instruction uses a standard instruction format, including fields such as instruction type, instruction parameters, and validity period, for subsequent data push control. The entire process implements intelligent push control based on data alignment, ensuring the integrity and accuracy of cross-system data transmission.

[0044] In one possible implementation, the initial alignment identifier set associated with the purchase business documents of the first business system is obtained, and a push authorization instruction is generated based on the initial alignment identifier set, specifically including steps 1041-1043, as follows: Step 1041: Read the bill of materials from the purchase order and extract the cross-system alignment identifiers for each material item in the bill of materials.

[0045] A bill of materials (BOM) is a data structure in a purchasing document that records the details of purchased materials. It contains multiple material items, each with attributes such as material code, name, specifications, quantity, and unit price. A material item is a single material record in the BOM, describing the specific purchasing requirements. A cross-system alignment identifier is a unique identifier recorded in an alignment check table, used to associate corresponding material data in different systems. A purchasing document is a business voucher generated during the purchasing process, recording complete purchasing information.

[0046] Specifically, the process begins by retrieving the associated bill of materials (BOM) data from the database using the primary key or document number of the purchase order. The query employs a JOIN operation, linking the purchase order master table and the material details table to extract detailed information for all material items. For each material item, its basic information, such as material code, quantity, and specifications, is read. Then, based on the material item's material code, the corresponding cross-system alignment identifier in the alignment verification table is retrieved. Query conditions include records with matching material codes and a "aligned" status. For the retrieved alignment identifiers, their validity is verified, including checking if the identifier format conforms to specifications and if it is within its validity period. The verified alignment identifiers are then associated with their corresponding material items, forming a mapping table from material items to alignment identifiers. For material items for which no corresponding identifier is found in the alignment verification table, their material codes are recorded for subsequent processing. The entire extraction process uses batch processing, processing a batch of material items at a time to improve data processing efficiency. Finally, a complete dataset containing material item information and corresponding alignment identifiers is obtained. This dataset will be used for subsequent alignment completeness calculations and push permission determination.

[0047] Step 1042: Form an initial alignment identifier set by combining the cross-system alignment identifiers corresponding to each extracted material item; query the alignment status of each cross-system alignment identifier in the initial alignment identifier set one by one in the alignment verification table.

[0048] The initial alignment identifier set is a data set consisting of multiple cross-system alignment identifiers, each identifier corresponding to an inter-system mapping relationship for a material item. Alignment status is a data status identifier recorded in the alignment verification table, containing multiple status values ​​such as "pending alignment," "aligned," and "abnormal." The alignment verification table is a data table storing cross-system data mapping relationships, containing fields such as alignment identifier, status, and timestamp. The cross-system alignment identifier is a string used to uniquely identify the cross-system data correspondence.

[0049] Specifically, firstly, the cross-system alignment identifiers corresponding to the material items extracted in the previous step are added to the initial alignment identifier set. The set construction process uses a Set data structure to automatically remove duplicate alignment identifiers. The identifiers in the set are sorted to ensure consistent processing order. Then, each alignment identifier in the initial alignment identifier set is traversed, and its current status is queried in the alignment verification table. The query operation is performed in batches, querying the status of multiple identifiers at a time to reduce the number of database accesses. The query statements are indexed according to the alignment identifier fields to improve query efficiency. For the query results of each identifier, its status field value, last update time, and other information are read. The queried status information is associated with the corresponding alignment identifier to form a complete data structure containing identifiers and statuses. For identifiers whose status cannot be found, they are marked as unknown and logged. After the query is completed, the number of each status identifier is counted, including the number of aligned, the number to be aligned, and the number of abnormal identifiers. These statistics will be used for subsequent alignment integrity calculations. The entire process realizes the construction of the alignment identifier set and the batch query of status information, providing a data foundation for subsequent push permission judgment.

[0050] Step 1043: Based on the alignment status, calculate the alignment integrity ratio. The alignment integrity ratio is the ratio of the number of cross-system alignment identifiers in the initial alignment identifier set whose alignment status is aligned to the total number of cross-system alignment identifiers in the initial alignment identifier set. When the alignment integrity ratio is greater than or equal to a preset threshold, generate a push permission instruction.

[0051] The alignment integrity ratio is a numerical metric that measures the degree of data alignment, ranging from 0 to 1, representing the proportion of data that has been aligned to the total data. The push authorization command is a system command used to authorize data transmission, containing information such as authorization time, validity period, and authorization scope. The preset threshold is a standard value used to determine whether data meets the conditions for push, typically set between 0.9 and 1. The aligned status is a value in the alignment verification table indicating that the data has completed inter-system mapping.

[0052] Specifically, firstly, the status of the identifiers in the initial alignment identifier set is statistically analyzed, and a counter is established to record the number of identifiers in different states. Each identifier in the set is traversed, and its corresponding alignment status is read. When the status is "aligned", the aligned counter is incremented by 1. After traversal, the number of aligned identifiers N1 and the total number of identifiers N2 are obtained. The formula for calculating the alignment integrity ratio is: R = N1 / N2. For example, if there are 100 material items, and 95 of them are aligned, then the alignment integrity ratio R = 95 / 100 = 0.95. The calculated ratio R is compared with a preset threshold T (e.g., 0.95). When R is greater than or equal to T, it indicates that the data alignment meets the push requirements, and a push permission instruction is generated. The process of generating the push permission instruction includes: creating an instruction identifier (using a timestamp plus a random number), setting the instruction type (e.g., "DATA_PUSH"), specifying the authorization scope (including the business document number and the alignment identifier set), setting the validity period (e.g., valid for 24 hours after generation), and adding a digital signature (using the system private key to sign the instruction content), etc. The generated push authorization command is encapsulated in a standard data format, facilitating parsing and execution by subsequent processing programs. The entire process implements intelligent push control based on data alignment integrity, ensuring that only data that meets the alignment requirements can be transmitted across systems.

[0053] Step 105: In response to the push permission instruction, encapsulate the purchase business document and the initial alignment identifier set into a data packet and send it to the second business system to map and generate business document records.

[0054] Data packets are data carriers used for inter-system transmission, encapsulating business data and metadata in a standard format. Business document records are data entities in the second business system corresponding to procurement business documents, containing relevant business attributes and processing status. Interface protocols are technical standards that specify the rules for data exchange between systems, defining data formats, transmission methods, security requirements, and other related content.

[0055] Specifically, firstly, according to the interface protocol specifications of the second business system, the procurement business documents are converted into standard exchange format files. The conversion process includes: extracting basic document information (such as document number, creation time, and business type), processing detailed line data (such as material information, quantity, and amount), and adding business attributes (such as procurement organization and supplier). The converted data is then structured and organized according to XML or JSON format. An initial alignment identifier set is embedded in the metadata header of the exchange file to support data mapping in the second system. The standard exchange format file is encrypted using the AES-256 encryption algorithm and a shared key between the systems to generate encrypted transmission data packets. These encrypted data packets are sent to the receiving interface of the second business system via secure transmission protocols such as HTTPS. The transmission process employs a breakpoint resumption mechanism, transmitting large data packets in chunks, each 1MB in size. After receiving the data packets, the second business system first performs decryption verification, then parses the alignment identifier set in the metadata header. Based on the alignment identifiers, the corresponding material mapping relationship is searched in the system database. Based on the found mapping relationship and the business content in the exchange file, data instantiation is performed in the second business system to generate the corresponding business document record. The generated records contain business attributes corresponding to the first system and establish a two-way data association. The entire process achieves secure transmission of procurement data and automatic mapping between systems, ensuring accurate transmission and consistency of business data.

[0056] In one possible implementation, in response to a push authorization command, the purchase business document and the initial alignment identifier set are encapsulated into a data packet and sent to the second business system to map and generate a business document record, specifically including steps 1051-1053, as follows: Step 1051: Based on the interface protocol of the second business system, convert the purchase business documents into standard exchange format files according to the interface protocol, and embed the initial alignment identifier set into the metadata header of the standard exchange format file.

[0057] An interface protocol is a technical specification that defines data exchange between systems, including data format definitions, field mapping rules, and communication methods. A standard exchange format file is a standardized file used for data transmission between systems, employing common formats such as XML or JSON. The metadata header is a specific area in the exchange file that stores file attributes and control information. The initial alignment identifier set is a set of unique identifiers used to associate data between two systems. A procurement business document is a business voucher containing procurement information, possessing a fixed data structure and business rules.

[0058] Specifically, the process begins by reading the interface protocol configuration to obtain data mapping rules, including field correspondences, data type conversion rules, and required field requirements. Data content is then extracted from the procurement documents, including basic document information (document number, date, type), procurement organization information (organization code, name), supplier information (supplier code, name), and detailed line information (material code, quantity, amount). The extracted data undergoes format conversion, transforming database fields into a standard exchange format. This conversion process includes: data type conversion (e.g., unifying date format to ISO8601 standard), field naming conversion (renaming fields according to interface specifications), and numerical precision handling (processing values ​​to the specified decimal places). Next, a standard exchange format file is created, organizing the data structure using XML format. A metadata node is created in the XML file header to store metadata information. Within the metadata node, an alignmentIdentifiers node is created, writing the initial set of alignment identifiers to this node. Alignment identifiers are organized in a standard format, with each identifier containing attributes such as identifier value, associated material code, and generation time. Within the body node of the XML file, the transformed business data is organized hierarchically, including nodes such as header (document header information) and items (detail line information). The generated XML file undergoes format validation to ensure it conforms to the data format requirements defined by the XML Schema. Finally, the checksum of the file is calculated, and the checksum value is written to the metadata header for transmission integrity verification. This entire process achieves standardized transformation and file encapsulation of business data, ensuring that the data conforms to interface protocol requirements and contains necessary alignment information.

[0059] Step 1052: Encrypt the standard exchange format file using a preset encryption algorithm to generate an encrypted transmission data packet; send the encrypted transmission data packet to the receiving interface of the second business system through a secure transmission channel.

[0060] Encrypted data packets are encrypted binary data streams containing encrypted data and parameters. Secure transmission channels are encrypted communication links based on the SSL / TLS protocol, ensuring the security of data transmission. The receiving interface is the data receiving service endpoint provided by the second business system, defining the rules and processing logic for data reception. Standard exchange format files are standardized business data files, using XML or JSON format.

[0061] Specifically, the standard exchange format file is first pre-processed with encryption to generate a 16-byte random initialization vector (IV). The AES-256 encryption algorithm is used, employing CBC mode for data encryption. The encryption process involves the following steps: dividing the file content into 16-byte blocks, padding the last block with less than 16 bytes with PKCS7; performing AES encryption on each data block using a preset key and IV; and combining the encrypted data blocks and IVs to form an encrypted data stream. An HMAC-SHA256 message authentication code is calculated for the encrypted data stream and appended to the end of the data packet. The structure of the encrypted transmission data packet is constructed, including: a header (version number, encryption algorithm identifier, IV value), encrypted data, and authentication code. When the data packet size exceeds the transmission limit, data fragmentation is performed, with each fragment being 1MB in size, and a sequence number and checksum are generated for each fragment. A secure connection is established with the second business system, using the TLS 1.3 protocol for encrypted communication. Two-way authentication is performed during connection establishment, verifying the digital certificates of both parties. Encrypted data packets are sent through the established secure channel, employing a breakpoint resumption mechanism to support resuming transmission after interruption. For fragmented data, each fragment is sent sequentially according to its sequence number, and an end flag is transmitted after transmission is complete. Upon receiving the data, the receiver returns an acknowledgment message containing the reception status and verification result. The sender uses the acknowledgment message to determine if the transmission was successful; if a transmission error is detected, retransmission is performed. This entire process achieves secure encryption and reliable transmission of data, protecting the confidentiality and integrity of business data during transmission.

[0062] Step 1053: Trigger the second business system to decrypt the encrypted transmission data packet, and search for the corresponding material mapping relationship in the database of the second business system according to the initial alignment identifier set in the metadata header; based on the material mapping relationship and the business content in the standard exchange format file, instantiate in the second business system to generate a business document record corresponding to the procurement business document.

[0063] The metadata header is the area in the data packet that stores control information. The initial alignment identifier set is a combination of identifiers used to associate data between two systems. The material mapping relationship is a material code lookup table stored in the second business system, recording the correspondence between material codes in different systems. The business document record is a business voucher generated in the second system, containing complete business attributes and processing status.

[0064] Specifically, the process begins by receiving encrypted data packets and reading the header information to obtain encryption parameters, including the encryption algorithm identifier and IV value. AES-256 decryption is then performed using the system key and IV. The decryption process includes: verifying the HMAC-SHA256 authentication code of the data packet; performing AES decryption in 16-byte blocks; removing PKCS7 padding; and obtaining the original standard exchange format file. The metadata header of the exchange file is parsed to extract the initial alignment identifier set. Each identifier in the alignment identifier set is traversed, and a database query statement is constructed to find the corresponding mapping record in the material mapping table. The query conditions include the alignment identifier value and mapping status, returning information such as the material code and material attributes of this system. The query results are organized into a mapping dictionary to establish a conversion relationship from the source system code to the target system code. The business content in the exchange file is read, including basic document information and detailed line information. The class definition of the target business object is determined based on the document type, and a business object instance is created. Using reflection, the attribute definitions of the business object are traversed, mapping the source system data to the target attributes. For material-related fields, encoding conversion is performed using the mapping dictionary. System fields such as the processing status and creation time of the business object are set. The data access layer's save method is invoked to persist business objects to the database, generating business document records. Source system association information, including the source system number and original document number, is added to the generated records to establish a two-way traceability relationship. The entire process achieves secure decryption of encrypted data and automatic conversion of business data, ensuring accurate data mapping and business collaboration between systems.

[0065] Step 106: Receive the business result data packet generated by the second business system based on the business document record, and parse it to obtain the set of return alignment identifiers in the business result data packet.

[0066] Fragmented data packets are small chunks of data split from large data packets, facilitating transmission and processing. Asynchronous message queues are middleware systems used for asynchronous data transmission, supporting reliable message delivery and sequential processing.

[0067] Specifically, the system first receives result data sent by the second business system through a pre-defined asynchronous message queue. The message queue employs a persistence mechanism to ensure no data loss. The receiving process involves the following steps: listening to a specified message topic and obtaining the message content; decompressing the received message; verifying the message's digital signature to ensure data integrity; and converting the message content into a business result object. When the data volume is large, the second system will divide the result data into multiple fragments for transmission. For fragmented data, the following processing is performed: sorting according to fragment sequence number; verifying the checksum of each fragment; and reassembling the fragmented data according to sequence number to obtain a complete data stream. The reassembled data stream is parsed to extract business result information, including: processing status code, processing time, and processing result. A set of alignment identifiers is retrieved from the result data, containing all alignment identifiers used in the second system's processing. The identifier set is normalized, including: removing duplicate identifiers; sorting by identifier value; and calculating the checksum of the identifier set. The processed set of alignment identifiers is saved in memory for subsequent comparison and verification. The entire process ensured the reliable reception of business result data and the extraction of identification information, providing a foundation for subsequent data consistency verification.

[0068] Step 107: Compare the returned alignment identifier set with the initial alignment identifier set. If the comparison result is consistent, generate a business result document. If the comparison result is inconsistent, mark the purchase business document as abnormal and initiate the preset verification business process.

[0069] The returned alignment identifier set is the combination of alignment identifiers used during the processing returned by the second business system. The initial alignment identifier set is the combination of alignment identifiers initially sent to the second system. The business result document is a business voucher generated based on the processing result, recording the actual execution status. An abnormal status is a marker indicating a problem in data processing. The preset verification business process is the standard operating procedure for handling abnormal situations, including steps such as anomaly identification, cause analysis, and handling measures.

[0070] Specifically, the two alignment identifier sets are first converted into binary bitmap format for rapid comparison. The conversion process includes: calculating a hash value for each identifier in each set; creating a fixed-size bitmap array; and setting the corresponding bits in the bitmap based on the hash value. The bitmap conversion uses the following algorithm: calculating a 32-bit hash value for the identifier using MurmurHash3; obtaining the position index by taking the modulo of the hash value with the bitmap size; and setting a flag bit at the corresponding position in the bitmap. A bitwise XOR operation is performed on the two bitmaps to obtain the difference bitmap. All bits in the difference bitmap are checked; if all are 0, it indicates that the two sets are completely identical. When the comparison is successful, the following operations are performed: extracting the actual delivery quantity from the business result data packet; comparing the actual delivery quantity with the planned purchase quantity in the purchase business document; and generating a business result document containing difference analysis data based on the comparison results. When an inconsistency is detected, the following steps are performed: traverse the non-zero bits in the difference bitmap; reverse the lookup for the corresponding alignment identifier based on the position index; add the material codes corresponding to these identifiers to the difference material list; record the specific difference item in the difference material list, including the material code and the reason for the difference; update the status of the purchase order to "abnormal"; generate an exception handling task containing the difference material list; and submit the exception handling task to the pre-defined verification workflow. This entire process enables rapid verification of data consistency and automated handling of anomalies, ensuring the accuracy and integrity of business data.

[0071] In one possible implementation, the returned alignment identifier set is compared with the initial alignment identifier set. If the comparison result is consistent, a business result document is generated. If the comparison result is inconsistent, the purchase business document is marked as abnormal and a preset verification business process is initiated, specifically including steps 1071-1074, as follows: Step 1071: Convert the initial alignment identifier set and the return alignment identifier set into a binary bitmap, and set the flag bit in the corresponding bitmap of the binary bitmap based on the hash value of each cross-system alignment identifier.

[0072] A binary bitmap is a data structure that uses binary bits to represent a set of data, with each bit representing a state. A cross-system alignment identifier is a unique identifier used to associate data from different systems. A hash value is a fixed-length numerical value converted from the alignment identifier using a hash algorithm. A flag bit is a binary bit in the bitmap that represents a specific state; a value of 1 indicates presence, and a value of 0 indicates absence.

[0073] Specifically, the bitmap size is first determined, using a prime number as the bitmap length (e.g., 2048 bits) to avoid hash collisions. A transformation is performed on each alignment identifier set: the MurmurHash3 algorithm is used to calculate the 64-bit hash value of the identifier; the hash value is modulo the bitmap length to obtain the position index; the binary bit at the corresponding position is set to 1. The specific implementation steps are: create a fixed-length bit array, initializing all bits to 0; traverse the initial alignment identifier set, performing a hash calculation on each identifier; the calculated hash value is right-shifted by 32 bits using bitwise operations to obtain the high 32-bit value; the high 32-bit value is modulo the bitmap length to obtain the position mapped to the bitmap; the binary bit at that position is set to 1. The same operation is performed on the returned alignment identifier set to generate a second bitmap. Both bitmaps use the same hash algorithm and bitmap length to ensure consistent position mapping. After the transformation, two equal-length binary bitmaps are obtained, with 1 in each bitmap indicating the presence of an alignment identifier at the corresponding position. The entire process transforms set alignment into bitmap operations, improving alignment efficiency.

[0074] Step 1072: Perform a bitwise XOR operation on the binary bitmap. When all bits of the result are zero, the comparison is confirmed to be consistent. Extract the actual delivery quantity from the business result data packet and compare the actual delivery quantity with the planned purchase quantity in the purchase business document to generate a business result document.

[0075] Bitwise XOR is a binary bitwise operation; the result is 1 if corresponding bits are different, and 0 if they are the same. Actual delivery quantity refers to the quantity of materials actually processed by the second business system. Planned purchase quantity refers to the quantity of materials originally planned in the purchase order. Business result documents are business vouchers that record comparison results and discrepancy analysis.

[0076] Specifically, firstly, a bitwise XOR operation is performed on the two binary bitmaps. The operation process is as follows: corresponding bits of the two bitmaps are XORed; if the corresponding bits are the same, the result bit is 0; if the corresponding bits are different, the result bit is 1. All bits of the XOR result are checked to see if they are all 0. When all bits are 0, it indicates that the two sets are completely matched, and the following operations are performed: extract the actual delivery quantity data from the business result data package; read the actual delivery quantity value for each material item; read the corresponding planned purchase quantity from the purchase business document; perform quantity comparison, calculate the difference between the actual delivery quantity and the planned quantity; generate a business result document containing the following: basic document information (document number, date, status), material details (material code, planned quantity, actual quantity, difference quantity), summary information (total planned quantity, total actual quantity, total difference quantity), and processing result (completion status, reason for difference). The entire process achieves rapid verification of data consistency and automatic generation of result documents.

[0077] Step 1073: When there are non-zero bits in the result of the bitwise XOR operation, it is determined that the comparison is inconsistent. Traverse the bit index of the non-zero bits and perform reverse mapping to obtain the difference alignment identifier. According to the difference alignment identifier, query the corresponding material code in the alignment verification table, generate the difference material list, and store it in association with the document number of the purchase business document.

[0078] A bit index is the position number of a binary bit in a bitmap. A difference alignment identifier is the original alignment identifier restored from the bit index through reverse mapping. A difference bill of materials is a collection of data recording inconsistent material items. An alignment check table is a data table that stores the mapping relationship between alignment identifiers and material codes.

[0079] Specifically, first, the XOR result bitmap is scanned, recording the position indices of all bits with a value of 1. For each non-zero position index, a reverse mapping is performed: multiply the position index by the bitmap length; perform the inverse operation of the hash function on the mapping result; and search for the corresponding identifier value in the original alignment identifier set using the result of the inverse operation. After finding the difference alignment identifier, a database query statement is constructed to query the material information corresponding to the identifier in the alignment verification table. The material information returned by the query includes attributes such as material code, material name, and specifications. The query results are organized into a difference material list, with the list structure including fields such as difference identifier, basic material information, difference type (missing / redundant), and discovery time. An association record is created between the difference material list and the purchasing business document, containing information such as list number, document number, association time, and association status. The association record is persisted to the database, establishing a bidirectional association relationship between the difference list and the business document.

[0080] Step 1074: Update the status field of the purchase business document to an abnormal status, and insert a preset verification business process containing the discrepancy material list and document number into the preset abnormal handling queue.

[0081] An abnormal status indicates a problem in the processing of a procurement document. The preset exception handling queue is a message queue used to store pending exception tasks. The preset verification process defines a standardized exception handling procedure. The document number is a unique identifier for a procurement document.

[0082] Specifically, the process begins by updating the status of the purchase order by performing a database update operation: changing the value of the status field to "abnormal"; recording the status update time and reason; and saving the status change history. Next, an exception handling task is created, including: task type (data alignment exception), task priority (set according to the degree of difference), task parameters (difference material list, document number), and processing requirements (processing time limit, processing steps). The created task is then sent to a pre-defined exception handling queue. The sending process includes: serializing the task object; setting message attributes (priority, timeout); performing the message sending operation; and waiting for confirmation. Upon receiving the task, the message queue triggers a pre-defined verification process: creating a process instance; setting process variables; starting process execution; and recording the process status. This entire process automatically marks exceptions and automatically initiates processing flows, ensuring timely handling of exceptions.

[0083] In the above embodiments, basic cross-system data synchronization functionality is achieved through the collection and alignment of business data. To further improve the automation level of data processing and reduce the impact of system heterogeneity on business collaboration, this application also provides a business result data parsing method. This method constructs a unified data parsing framework by analyzing the structural characteristics, serialization format, and security verification mechanism of data packets, and uses reflection mechanisms for attribute extraction, enabling the system to handle data return requirements in complex business scenarios more efficiently. The following section combines... Figure 2 Another data alignment procurement optimization method in the embodiments of this application is described below: Please see Figure 2 This is a flowchart illustrating a data alignment procurement optimization method in an embodiment of this application.

[0084] Step 201: Collect multiple fragmented data packets returned by the second business system through a preset asynchronous message queue; reassemble the data based on the sequence number of each fragmented data packet to obtain the original bit stream of the business result data packet.

[0085] Asynchronous message queues are distributed message passing middleware used for reliable message transmission between systems, supporting asynchronous message processing and persistent storage. Fragmented data packets are small data units divided from large data packets; each fragment contains a sequence number and data content. The sequence number is an integer value that identifies the fragment order and is used for order control during data reassembly. The original bitstream is the reassembled complete binary data stream, containing complete business result information. The business result data packet is the complete data set returned by the second business system after processing.

[0086] Specifically, first, configure the connection parameters for the asynchronous message queue to establish a connection with the message queue server. Set message reception parameters: specify the message topic (e.g., "business.result"); configure the consumer group ID; set the message batch retrieval size (e.g., 100 messages); set the message timeout (e.g., 30 seconds). Start the message listener and perform message reception in a loop: retrieve message batches from the queue; parse the message content and extract fragmented data packets; verify the integrity checksum of the fragmented data packets; save the verified fragments to a memory buffer. Organize the received fragmented data and create a fragment manager: use a TreeMap data structure to store fragments, with the key being the sequence number; set the fragment timeout (e.g., 60 seconds); record the number of received fragments. When a fragment is received, perform the following processing: extract the fragment's sequence number; store the fragment data in the corresponding position in the TreeMap; update the received fragment count; check the fragment reception integrity. The integrity check is based on the following conditions: the end-of-line flag fragment is received; the number of received fragments equals the total number of fragments; all sequence numbers are consecutive and without missing numbers. Once complete reception is confirmed, fragment reassembly is performed: the TreeMap is traversed in sequence number order; the data portions of each fragment are sequentially concatenated; additional information at the fragment headers and trailers is removed; and a complete original bitstream is generated. After reassembly, resources are cleaned up: fragment buffers are released; message listeners are closed; and queue connections are disconnected. This entire process enables reliable reception and automatic reassembly of large data packets, ensuring the integrity of business data.

[0087] Step 202: Extract the digital signature digest from the original bitstream, verify the digital signature digest using a preset public key, and deserialize the original bitstream after successful verification to obtain the business result object.

[0088] A digital signature digest is a fixed-length string generated by encrypting data content using a private key, used to verify the integrity and authenticity of the data. A pre-defined public key is paired with the signing private key and used to verify the validity of the digital signature. The raw bitstream is a complete binary data stream containing business data and control information. The business result object is the business data entity obtained after deserialization, containing the specific content of the processing result. Deserialization is the process of converting binary data into an object structure in memory.

[0089] Specifically, the process begins by extracting digital signature information from the original bitstream: the first 256 bytes are read as signature data; the remaining portion is used as business data content; and the SHA-256 hash value of the business data content is calculated. Digital signature verification is then performed: a pre-defined RSA public key is loaded; the signature data is decrypted using the public key to obtain the original digest; the decrypted digest is compared with the calculated hash value; if the two values ​​are identical, the signature verification is successful. After successful verification, deserialization is performed on the business data content: the data type identifier is read to determine the target object type; an object instance is created, and the attribute container is initialized; the data stream is parsed according to a predefined serialization protocol; and the parsed data is filled into the object attributes. Specific deserialization steps include: parsing the object header information (class name, version number); reading the number of attributes; iteratively parsing each attribute (attribute name, type, value); handling nested objects and collection types; and setting reference relationships between objects. After deserialization, object validity verification is performed: the completeness of required attributes is checked; the validity of attribute values ​​is verified; and the consistency of the object state is confirmed. Finally, a complete business result object is obtained, which includes: processing status information, business data content, processing timestamp, and association identifier. The entire process implements secure data verification and object restoration, ensuring the authenticity and integrity of the business data.

[0090] Step 203: Use reflection to traverse the list of row items in the business result object and extract the alignment identifier field value marked as an immutable attribute.

[0091] Reflection is a runtime mechanism for dynamically acquiring and manipulating classes, objects, methods, and properties. A row item list is a collection structure within a business result object that stores detailed data. Immutable properties are fields marked with specific annotations whose values ​​cannot be changed during business processing. Alignment identifier fields are unique identifier fields used to associate data from different systems. Field values ​​are the actual data content stored in object properties.

[0092] Specifically, first, obtain the Class object of the business result object and access the class definition via reflection API. Scan the class's field definitions: obtain all declared fields (Field objects); read the annotation information on the fields; identify immutable attributes marked with @Immutable. Obtain the row item list fields and read the list content via field accessor: set the field's accessibility (setAccessible(true)); call the field's get method to obtain the list object; convert the return value to a List type. Traverse each element object in the row item list: obtain the element's Class object; scan the element class's field definitions; filter alignment marker fields annotated with @Alignment. Perform value extraction for each alignment marker field: obtain the field's current value; verify the validity of the field value; check if the field also has the @Immutable annotation. Add the extracted field values ​​to the result collection: create a HashSet to store the extracted values; perform normalization processing on each value; verify the uniqueness of the value; add it to the result collection. The specific implementation includes the following steps: using Java reflection APIs (such as getDeclaredFields, getAnnotation, etc.); handling field access permissions; handling null values ​​and exceptions; and ensuring the consistency of the extracted value types. The entire process achieves automatic traversal of object properties and extraction of specific values, ensuring the complete acquisition of business data.

[0093] In one possible implementation, a reflection mechanism is used to traverse the list of row items in the business result object and extract the alignment identifier field value marked as an immutable attribute. Specifically, steps 2031-2033 are as follows: Step 2031: Obtain the class metadata handle of the business result object, and use the class metadata handle to scan all member variable declarations of the business result object.

[0094] A class metadata handle is a reference object pointing to class definition information, including the class's structure, methods, fields, etc. A business result object is a Java object instance containing the processed result data. Member variable declarations are field information defined in the class, including field name, type, modifiers, etc. Modifiers are keywords that define field characteristics, such as public, private, static, etc. Annotations are metadata markers added to fields to describe their special attributes.

[0095] Specifically, the process begins by retrieving class metadata via the reflection API: calling the object's `getClass()` method to obtain a `Class` object; and then converting the `Class` object into a metadata handle. The metadata handle retrieval process includes: checking if the object is null; obtaining the object's runtime type; and creating a metadata accessor for the type. The metadata handle is then used to scan the class structure: obtaining the list of declared fields (`getDeclaredFields()`); obtaining the list of inherited fields (`getFields()`); and merging and deduplicating the field collection. Information extraction is performed on each field: reading the field name (`getName()`); obtaining the field type (`getType()`); obtaining the field modifiers (`getModifiers()`); and reading the annotation collection on the field (`getAnnotations()`). The field information is then organized into structured data: creating a field description object; setting the field's basic attributes; recording the field's annotation information; and establishing dependencies between fields. Generic type fields are processed: obtaining generic type information (`getGenericType()`); parsing generic parameter types; and recording complete type information. Array type fields are processed: determining if a field is an array (`isArray()`); obtaining the array element type; and recording array dimension information. Create field accessors: set field accessibility; cache field access methods; optimize access performance. The entire process achieves a complete scan of the class structure and extraction of field information, providing a data foundation for subsequent field processing.

[0096] Step 2032: Identify the target member variable that has a preset immutable attribute marker in the member variable declaration, and construct the field reflection instance corresponding to the target member variable.

[0097] Member variable declarations are information about fields defined in a class, including the field's name, type, and modifiers. Preset immutable attribute markers are annotations (such as @Immutable) used to indicate that a field's property cannot be modified. The target member variable is the field marked with the immutable attribute. A field reflection instance is a reflection API object used to access and manipulate fields. The reflection API is a runtime programming interface provided by Java for manipulating classes and objects.

[0098] Specifically, the process begins by iterating through all member variable declarations and performing annotation checks on each field: retrieving all annotations on the field (getAnnotations()); filtering out annotations marked @Immutable; and verifying the validity and completeness of the annotations. The process of identifying target member variables includes: checking the field's modifiers (Modifier.isPrivate, Modifier.isFinal, etc.); verifying the field's type compatibility; and confirming the field's scope and accessibility. For each target member variable, the following operations are performed: creating a Field object instance; setting the field's access permissions (setAccessible(true)); and caching the field's type information. The steps for constructing a field reflection instance are: creating a FieldAccess object; setting the field's getter methods; configuring the access control context; and initializing the field value cache. Specific implementations include: using the Field class of the reflection API; handling field access exceptions; and optimizing reflection call performance. Field indexing is established: creating a mapping from field names to reflection instances; constructing type tokens for field types; and recording the field's location information. Special field types are handled: for primitive type fields, creating corresponding wrapper types; for collection type fields, retrieving the collection's generic information; and for custom type fields, loading the type's metadata. The entire process enables the identification of immutable fields and the creation of accessors, providing support for subsequent field value extraction.

[0099] Step 2033: Remove the access control flag of the field reflection instance and establish an accessible field channel; through the accessible field channel, map each row item object in the row item list one by one, read the corresponding attribute data of each row item object in the memory stack, and use the attribute data as the alignment identifier field value.

[0100] A field reflection instance is an instance of the Field class provided by the Java Reflection API, used to access the fields of an object. Access control flags are binary flags that control field access permissions. Accessible field channels are access mechanisms that bypass access controls to directly read field values. A list of row items is a collection storing detailed business data. A row item object is a single data item instance in the list. The memory heap is a memory area that stores the data of object instances. Attribute data is the actual value of the object's fields.

[0101] Specifically, the process begins by removing access control restrictions: calling the `setAccessible(true)` method to modify the access flags; modifying the field's `modifiers` value via the reflection API; and clearing the `final` modifier restriction. The steps to establish a field access channel are: creating a direct memory accessor (`DirectFieldAccessor`); configuring the accessor's caching strategy; and initializing the accessor's performance optimization options. Next, the list of row items is traversed: obtaining the list's iterator; checking the validity of list elements; and establishing a batch access caching mechanism. Each row item object is then processed: obtaining the object's memory address; locating the object's field offset; and reading the field's raw data. The specific data reading process involves: accessing memory using the `Unsafe` class; reading data of a specified length according to the field type; and performing data type conversion. The implementation details of data reading include: directly reading values ​​from primitive type fields; resolving reference addresses for reference type fields; and reading array elements from array type fields. Data validation and conversion are performed: checking the validity of the read values; performing necessary type conversions; and handling null values. Finally, the read data is used as an alignment identifier field value: creating an identifier value object; setting the value's properties; and recording the value's source information. This entire process achieves direct access to object fields and value extraction, ensuring efficient and accurate data reading. The specific implementation includes: using the Field class of the Java reflection API; using the sun.misc.Unsafe class for memory operations; using caching to optimize access performance; and handling concurrent access scenarios.

[0102] Step 204: Generate a return identifier sequence from the extracted alignment identifier field values ​​according to the preset sorting rules, calculate the checksum of the return identifier sequence, and use the return identifier sequence and checksum as the return alignment identifier set.

[0103] The alignment identifier field value is identifier data extracted from the business result object. The preset sorting rule is a fixed algorithm rule for sorting the identifiers. The returned identifier sequence is an ordered set of sorted identifier values. The checksum is a fixed-length verification value calculated from the data content. The returned alignment identifier set is a complete data structure containing the identifier sequence and the checksum.

[0104] Specifically, the extracted identifier values ​​are first standardized: whitespace characters are removed; case sensitivity is standardized; and duplicate values ​​are removed. Identifier sorting is then performed, with sorting rules including: ascending order by string length; lexicographical ascending order for strings of the same length; and special characters preceding letters. The specific sorting algorithm is implemented by: creating a custom comparator; implementing the `compare` method to define the sorting logic; and using the sorting methods of the Java Collections Framework. The sorted identifiers are then constructed into a sequence: a `StringBuilder` object is created; the sorting results are iterated; each identifier is appended to the `StringBuilder`; and separators (such as "|") are inserted between identifiers. The checksum of the sequence is calculated using the following steps: the sequence is converted to a byte array; the checksum is calculated using the CRC32 algorithm; specifically, a CRC32 object is created; the byte array content is updated; and the checksum value is obtained. A return alignment identifier collection object is created: a data structure containing the sequence and checksum is defined; the sequence content is set; the checksum value is set; and a creation timestamp is set. The collection object is serialized for subsequent processing: the object is converted to JSON format; serialization options (such as date format, precision, etc.) are set; and the final serialized string is generated. The entire process achieves standardized organization and integrity protection of identification data, ensuring the orderliness and verifiability of the data.

[0105] The following describes a data alignment and procurement optimization system according to an embodiment of the present invention from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 3 This is a schematic diagram of the structure of a data alignment procurement optimization system in an embodiment of this application.

[0106] It should be noted that, Figure 3 The structure of the data alignment procurement optimization system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0107] like Figure 3 As shown, a data alignment procurement optimization system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on a program stored in Read-Only Memory (ROM) 302 or a program loaded from storage portion 308 into Random Access Memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0108] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0109] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0110] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0111] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0112] Specifically, a data alignment procurement optimization system according to this embodiment includes a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements a data alignment procurement optimization method provided in the above embodiment.

[0113] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the data alignment and procurement optimization system described in the above embodiments; or it may exist independently and not assembled into the data alignment and procurement optimization system. The storage medium carries one or more computer programs, which, when executed by a processor of the data alignment and procurement optimization system, cause the data alignment and procurement optimization system to implement the data alignment and procurement optimization method based on IoT data encryption transmission provided in the above embodiments.

Claims

1. A data-aligned procurement optimization method, characterized in that, The method includes: Obtain procurement data from the first business system and response data from the second business system. The first business system is the procurement request initiator, and the second business system is the external collaborative response provider. In response to the procurement data, create a record to be aligned in the alignment verification table, which includes a cross-system alignment identifier; The response data and the record to be aligned are encoded and their attributes are checked for consistency. When the consistency check passes, the cross-system alignment identifier of the record to be aligned is updated to the aligned state. After the cross-system alignment identifier is updated, the initial alignment identifier set associated with the purchase business documents of the first business system is obtained, and a push permission instruction is generated based on the initial alignment identifier set. In response to the push permission instruction, the purchase business document and the initial alignment identifier set are encapsulated into a data packet and sent to the second business system to map and generate business document records; Receive the business result data packet generated by the second business system based on the business document record, and parse it to obtain the set of return alignment identifiers in the business result data packet; The return alignment identifier set is compared with the initial alignment identifier set. If the comparison result is consistent, a business result document is generated. If the comparison result is inconsistent, the purchase business document is marked as abnormal and a preset verification business process is initiated.

2. The data alignment and procurement optimization method according to claim 1, characterized in that, The step of performing consistency verification on the encoding and attributes of the response data and the record to be aligned, and updating the cross-system alignment identifier of the record to be aligned to an aligned state when the consistency verification passes, includes: Extract the first encoded identifier from the record to be aligned and the second encoded identifier from the response data; Perform string matching between the second encoded identifier and the first encoded identifier; When the string matching degree between the second encoding identifier and the first encoding identifier is greater than the matching degree threshold, the target attribute fields of the response data and the procurement data are extracted, and the first hash value of the response data and the second hash value of the procurement data are calculated based on the target attribute fields; When the first hash value and the second hash value are the same, the consistency check is determined to be successful; Update the status field of the cross-system alignment identifier in the alignment verification table to the aligned status; The cross-system alignment identifier is written into the data extension fields of the first business system and the second business system respectively to establish a cross-system data mapping relationship.

3. The method according to claim 1, characterized in that, The step of obtaining the initial alignment identifier set associated with the purchase business documents of the first business system, and generating a push authorization instruction based on the initial alignment identifier set, includes: Read the bill of materials from the procurement document and extract the cross-system alignment identifiers corresponding to each material item in the bill of materials; The cross-system alignment identifiers corresponding to each of the extracted material items are combined into an initial alignment identifier set; The alignment status of each cross-system alignment identifier in the initial alignment identifier set is queried one by one in the alignment verification table; Based on the alignment status, the alignment integrity ratio is calculated. The alignment integrity ratio is the ratio of the number of cross-system alignment identifiers in the initial alignment identifier set whose alignment status is aligned to the total number of cross-system alignment identifiers in the initial alignment identifier set. When the alignment integrity ratio is greater than or equal to a preset threshold, the push permission instruction is generated.

4. The method according to claim 1, characterized in that, In response to the push permission instruction, the process of encapsulating the purchase order and the initial alignment identifier set into a data packet and sending it to the second business system to map and generate a business order record includes: Based on the interface protocol of the second business system, the procurement business document is converted into a standard exchange format file according to the interface protocol, and the initial alignment identifier set is embedded in the metadata header of the standard exchange format file. The standard exchange format file is encrypted using a preset encryption algorithm to generate encrypted transmission data packets; The encrypted data packet is sent to the receiving interface of the second business system through a secure transmission channel; The second business system is triggered to decrypt the encrypted transmission data packet and search for the corresponding material mapping relationship in the database of the second business system according to the initial alignment identifier set in the metadata header; Based on the material mapping relationship and the business content in the standard exchange format file, the system is instantiated in the second business system to generate a business document record corresponding to the procurement business document.

5. The method according to claim 1, characterized in that, The process of parsing and obtaining the set of return alignment identifiers in the service result data packet includes: Multiple fragmented data packets transmitted back from the second business system are collected through a preset asynchronous message queue; Data is reassembled based on the sequence number of each fragmented data packet to obtain the original bit stream of the service result data packet; Extract the digital signature digest from the original bitstream, verify the digital signature digest using a preset public key, and after successful verification, deserialize the original bitstream to obtain a business result object. The list of row items in the business result object is traversed using reflection, and the alignment identifier field value marked as an immutable attribute is extracted. The extracted alignment identifier field values ​​are sorted according to a preset sorting rule to generate a return identifier sequence, and the checksum of the return identifier sequence is calculated. The return identifier sequence and the checksum are used as the return alignment identifier set.

6. The method according to claim 5, characterized in that, The step of using reflection to traverse the list of row items in the business result object and extract the alignment identifier field value marked as an immutable attribute includes: Obtain the class metadata handle of the business result object, and use the class metadata handle to scan all member variable declarations of the business result object; Identify target member variables that have a preset immutable attribute marker in the member variable declaration, and construct a field reflection instance corresponding to the target member variable; Remove the access control flag of the field reflection instance and establish an accessible field channel; Through the accessible field channel, each row item object in the row item list is mapped one by one, the attribute data corresponding to each row item object in the memory stack is read, and the attribute data is used as the alignment identifier field value.

7. The method according to claim 1, characterized in that, The comparison of the returned alignment identifier set with the initial alignment identifier set, generates a business result document when the comparison result is consistent, and marks the procurement business document as abnormal and initiates a preset verification business process when the comparison result is inconsistent, including: The initial alignment identifier set and the return alignment identifier set are converted into a binary bitmap, and a flag bit is set in the corresponding bitmap of the binary bitmap based on the hash value of each cross-system alignment identifier. Perform a bitwise XOR operation on the binary bitmap. When all bits of the operation result are zero, it is determined that the comparison is consistent. Extract the actual delivery quantity from the business result data packet and compare the actual delivery quantity with the planned purchase quantity in the purchase business document to generate a business result document. When the bitwise XOR operation result contains a non-zero bit, it is determined that the comparison is inconsistent. The bit indices of the non-zero bits are traversed and reverse mapping is performed to obtain the difference alignment identifier. Based on the difference alignment identifier, the corresponding material code is queried in the alignment verification table to generate a difference material list, which is then stored in association with the document number of the purchase business document. Update the status field of the procurement document to an abnormal status, and insert a preset verification process containing the discrepancy list of materials and the document number into the preset abnormal processing queue.

8. A data-aligned procurement optimization system, characterized in that, The data alignment procurement optimization system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the data alignment procurement optimization system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is run on the data alignment procurement optimization system, the data alignment procurement optimization system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the data alignment procurement optimization system, the data alignment procurement optimization system performs the method as described in any one of claims 1-7.

Images