ERP heterogeneous data synchronization method and system for bonded business

Abstract

The application belongs to the technical field of enterprise data synchronization, and discloses an ERP heterogeneous data synchronization method and system for bonded business, which internally has a unified metadata model of bonded business, including standard field definition, business logic rules and compliance verification approaches of core business domains such as procurement and warehousing, production material taking, finished product warehousing, inventory checking, bonded account book, etc., automatically scans the table structure and field semantics of the enterprise ERP mirror database, automatically aligns the heterogeneous fields and the standard fields of the unified metadata model of bonded business based on semantic similarity matching, generates initial field mapping rules and data collection SQL scripts, and supports management personnel to adjust and confirm as needed; when the system structure of the enterprise end changes, all configuration parameters are centrally encrypted and stored on the supervision side, and the data collection client does not save any database configuration information locally, and sensitive configurations such as database connection credentials and collection scripts are uniformly encrypted and stored on the supervision side.

Description

Technical Field

[0001] This invention belongs to the field of enterprise data synchronization technology, specifically a method and system for heterogeneous data synchronization in ERP systems for bonded business. Background Technology

[0002] Traditional bonded supervision models rely on enterprises to manually compile and declare their procurement, production, and inventory records offline, with customs verifying each record individually. This approach suffers from issues such as data lag, low verification efficiency, and weak risk identification capabilities. Currently, bonded business data integration primarily employs two solutions: customized interface development and deployment of general ETL tools. Customized interface development involves developing separate data integration interfaces for individual enterprise ERP systems, while general ETL tools synchronize heterogeneous data through data extraction, transformation, and loading processes. However, the following technical challenges still exist in bonded supervision scenarios. Processing trade enterprises use a variety of ERP and WMS systems with significant differences in architecture. The database types include various mainstream relational databases and domestic databases. The business table structures and field definitions of each enterprise are not uniform. The implementation cycle is long. When the enterprise system changes, the data collection program needs to be modified simultaneously. The integration and maintenance costs are high, making it difficult to support the access of a large number of enterprises.

[0003] Existing data collection schemes mostly use account passwords as the sole authentication method, lacking device-level identity binding, which poses a risk of unauthorized terminals accessing the monitoring network. Sensitive information such as database connection credentials and enterprise operating data are mostly stored in plaintext or transmitted with single-level encryption. Long-term reuse of fixed keys can easily lead to leakage risks, posing security risks in both data transmission and storage.

[0004] Existing data synchronization methods mostly adopt a fixed-cycle full-data collection mode, which cannot distinguish the priority differences between routine supervision and temporary special inspections. At the same time, it is impossible to set differentiated collection strategies based on the enterprise's bonded compliance risk level, resulting in unreasonable allocation of regulatory resources. Furthermore, there is a general lack of refined incremental collection mechanisms, and repeated transmission of full data consumes a large amount of network bandwidth and storage resources, leading to low synchronization efficiency.

[0005] Most existing systems only store the final reported business data, without fully recording the status and operation logs from terminal activation, data collection and execution, data transmission to parsing and storage. Furthermore, the log data lacks anti-tampering protection mechanisms. When data errors or omissions occur, it is impossible to accurately locate the problematic link and the responsible party, resulting in insufficient reliability of the traceability results. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for synchronizing heterogeneous data in ERP systems for bonded business, so as to solve one or more of the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a method for synchronizing heterogeneous data in an ERP system for bonded business, comprising the following specific steps: Furthermore, the regulatory side completes the filing of basic enterprise information and bonded business permissions, uses the enterprise's unified social credit code as the unique identifier, generates a unique and non-reusable activation code, divides the corresponding data collection permission scope, and the regulatory side generates an independent SM2 asymmetric key pair for the enterprise. The public key pair is open for query and access by the corresponding filed enterprise, and the private key is securely stored by the regulatory side. Enterprises deploy data collection clients on their local intranet. The data collection client automatically collects the hardware fingerprint information of the local machine. After the enterprise operator enters the activation code, the data collection client requests the corresponding enterprise's SM2 public key from the regulatory side, concatenates the activation code, the enterprise's unified social credit code, and the hardware fingerprint information into authentication plaintext, encrypts it using the SM2 public key, and sends it to the regulatory side's activation interface. After receiving the request, the regulatory side uses the corresponding private key to decrypt it, and sequentially verifies the validity of the activation code and the enterprise to which it belongs, the enterprise's filing qualifications, and verifies that the hardware fingerprint is not bound to other enterprises and that the enterprise is not bound to other devices. After the verification is passed, the system establishes a permanent binding relationship between the activation code, the hardware fingerprint and the enterprise's four types of bonded business data collection permission scope, updates the activation status to effective, and returns the authentication credentials bound to the device to the data collection client. The data collection client encrypts and stores the authentication credentials in a local encrypted file.

[0008] Furthermore, the regulatory side has a built-in unified metadata model for bonded business. This unified metadata model includes standard field definitions, business logic rules, and compliance verification criteria for core business domains such as procurement warehousing, production material requisition, finished product warehousing, inventory counting, and bonded ledgers. In the management system deployed on the regulatory side, managers enter the connection parameters of the target enterprise's ERP mirror database. These connection parameters include the database type, JDBC connection address, access port, authorized username and password, and the selection of the corresponding bonded business type and ledger version for the enterprise. The regulatory side, based on the unified metadata model of bonded business, scans the table structure and field semantics of the target ERP database, and automatically aligns heterogeneous fields with standard fields of the unified metadata model of bonded business through semantic similarity matching, generating initial field mapping rules and data collection SQL scripts. The management personnel adjust and confirm the automatically generated rules. The system automatically encrypts sensitive information, including database connection credentials and collection SQL scripts, using the SM4 national cryptographic symmetric encryption algorithm and stores it in the configuration database on the regulatory side. It associates and binds business rules, including bonded data format verification, unit consumption logic verification, and ledger consistency verification, with the corresponding collection tasks to form collection task templates. After configuration, all parameters are stored on the regulatory side, and the data collection client does not save any database configuration information locally.

[0009] Furthermore, the regulatory side executes data collection and scheduling based on the needs of bonded supervision scenarios and enterprise risk ratings. The system has a built-in enterprise bonded compliance risk profile, which dynamically updates the enterprise's bonded compliance risk level based on historical declaration data, abnormal records, and audit results, and sets corresponding data collection strategies: high-risk enterprises are subject to high-frequency incremental data collection, covering all fields of the core business table; medium-risk enterprises are subject to a hybrid data collection combining medium-frequency incremental data collection and periodic full data collection; and low-risk enterprises are subject to low-frequency full data collection. The data collection tasks are divided into three categories: scheduled data collection, triggered data collection, and immediate data collection. The scheduled data collection tasks are configured with a basic execution cycle by the administrator. The system dynamically adjusts the actual execution frequency and data time range based on the enterprise's bonded compliance risk level. The triggered data collection is automatically triggered by regulatory business events. Triggering scenarios include ledger reversal warnings, risk clue pushes, and abnormal data alarms. These events have a higher priority than scheduled data collection. The immediate data collection tasks are manually created by the regulatory personnel and set as the highest execution priority. After the task is created, the system generates a unique one-time session key for this task. The task identifier, data time range, corresponding data source configuration, collection script, associated verification rules, and one-time session key are encapsulated into a task data packet. The data collection client actively initiates a polling request to the regulatory side at a preset period. The request message carries the encrypted authentication credentials. After the regulatory side completes the identity verification and business permission verification, it sorts the data according to the priority of immediate collection, triggered collection, and timed collection. Tasks of the same type are sorted in ascending order of creation time. The data packet of the highest priority task is encrypted and sent to the data collection client.

[0010] Furthermore, after receiving the task data packet, the data acquisition client decrypts and obtains the database connection information, the SQL script for data collection, the data time range, and the business verification rules. The data acquisition client automatically matches and loads the corresponding JDBC driver according to the database type and establishes a temporary connection with the enterprise's intranet ERP mirror database.

[0011] The data collection client queries local historical collection records to obtain the timestamp of the last successful collection and the business primary key range, determines the collection mode, and replaces the time condition in the collection SQL with an incremental time interval when there are valid historical records. Based on the business primary key dimension, it captures the newly added and changed business data within the time range. When there are no historical collection records, it performs the first full data collection. During the data collection process, the data acquisition client performs pre-cleaning and verification of the data according to the built-in data format rules and bonded business rules, removing dirty data with missing fields or abnormal formats, and simultaneously completing basic business logic verification. The verification content includes material code compliance and quantity unit consistency. Abnormal data that does not conform to bonded business specifications is intercepted and abnormal details are recorded. The result set is segmented according to the business table. When the size of a single segment file exceeds the threshold, the data acquisition client automatically splits the segment into volumes. During the collection process, the collection progress is persistently recorded according to the segment dimension. After an abnormal interruption, the local progress can be read and the collection can continue from the interrupted position. After the collection is completed, the data acquisition client reports the collection status, number of data entries, time range, and abnormal statistics to the regulatory side, which updates the task execution status.

[0012] Furthermore, the data acquisition client performs double-layer encryption on the fragmented data files generated by the acquisition. It uses a one-time session key issued by the task to compress the original data file and perform symmetric encryption using the AES-256 algorithm. It uses the SM2 public key of the corresponding enterprise to perform asymmetric encryption on the one-time session key. The one-time session key, along with the session key ciphertext, task identifier, and inner ciphertext data, is encapsulated into the final file to be transmitted. The one-time session key is only valid for the current task and automatically expires after the task is completed. The data acquisition client uses a multi-part form protocol to upload encrypted files in multiple parts to the monitoring side. After each part is uploaded, the monitoring side performs a cryptographic SM3 national cryptographic hash integrity check on it. If the upload fails due to network fluctuations, service interruptions, or other reasons during transmission, the data acquisition client automatically records the sequence number and offset of the successfully uploaded part. When a retransmission is triggered next time, the data acquisition client skips the completed parts and only transmits the remaining parts that failed. After the file is successfully uploaded, the data acquisition client reports the transmission completion status to the monitoring side.

[0013] Furthermore, after receiving the encrypted data file, the regulatory side uses the corresponding enterprise's SM2 private key to complete the outer asymmetric decryption, and decrypts the inner compressed package through the one-time session key associated with the task to restore the original collected data; The system performs mapping processing based on the unified metadata model of bonded business. According to the preset field mapping rules, it converts the field names and data formats of heterogeneous ERP systems of different enterprises into the standard format defined by the unified metadata model of bonded business. It processes data items including date format, numerical precision, and material code. After format cleaning, the system performs bonded business logic verification. The verification content includes the consistency of unit consumption accounting, bonded material inventory balance verification, and the correlation of ledger data. It removes abnormal data that does not conform to the business logic and records abnormal details and risk tags. The system will write the verified data into the customs intranet business database in batches to form the original ledger of enterprise bonded supervision, that is, the original business data set after verification and entry into the database, and simultaneously update the execution status of the collection task and data statistics information, and synchronously update abnormal data to the enterprise bonded compliance risk profile.

[0014] Furthermore, the system logs the technical operations and business nodes of data synchronization. The technical logs include operation records of technical aspects such as data acquisition client activation and deactivation, task creation and distribution, data acquisition execution status, split transmission progress, data parsing results, and data entry execution status. The business logs include operation records of core business nodes such as bonded ledger matching, business rule verification, risk tag generation, ledger updates, and permission changes. The system generates a unique hash value for each log entry. Technical logs and business logs in the same data batch are aggregated through a Merkle tree to generate the batch log Merkle root. The final root hash of the current batch is generated by concatenating the Merkle root of this batch log with the final root hash of the previous batch, forming a batch-level chain-like evidence storage structure. Supervisory personnel can use the management system deployed on the supervisory side to retrieve the entire chain of logs by enterprise entity, time range, operation type, task number, business node, and other dimensions. They can trace back from the final bonded ledger data to the original ERP fields and identify the entire chain of collection, transmission, conversion, and verification, thus locating abnormal links and responsible entities. The system generates an electronic ledger for enterprise bonded business supervision based on the data entered into the database. This is the formal supervision ledger after aggregation and processing, which summarizes the enterprise's bonded business data, including procurement, production, and inventory.

[0015] This invention also provides an ERP heterogeneous data synchronization system for bonded business, used to implement the above method, including the following modules: The activation authentication module is deployed on the regulatory side to complete the filing of basic enterprise information and bonded business permissions, generate a unique and non-reusable activation code and a dedicated SM2 key pair for the enterprise, receive encrypted authentication requests submitted by the data collection client, and sequentially verify the validity of the activation code, the enterprise's filing qualifications and the binding relationship with the hardware fingerprint. After the verification is passed, a permanent binding relationship is established between the activation code, the hardware fingerprint and the enterprise's bonded business permission scope, and the encrypted and stored basic identity credentials are issued to the data collection client. The data acquisition and configuration module has a built-in unified metadata model for bonded business. It supports managers to enter connection parameters for the enterprise ERP mirror database, automatically scans the database table structure and completes the semantic alignment of heterogeneous fields with standard fields of the unified metadata model for bonded business, generates field mapping rules and data acquisition SQL scripts, binds bonded business verification rules to form data acquisition task templates, and stores all configuration parameters in encrypted form on the regulatory side. The task scheduling module sets differentiated collection strategies based on the enterprise's bonded compliance risk profile, generates three types of collection tasks with different priorities: timed, triggered, and immediate collection. It generates a one-time session key for each batch of collection tasks and encapsulates the corresponding task data packet. After receiving polling requests from the data collection client and completing identity and permission verification, it sends the corresponding task data packet in priority order. The data acquisition module, deployed on the data acquisition client, decrypts the task data package and obtains the task parameters, establishes a temporary connection with the enterprise ERP mirror database, queries historical records to determine the acquisition mode, captures business data within the corresponding range, performs pre-cleaning and verification and result fragmentation, and then reports the acquisition status. The encrypted transmission module, deployed on the data acquisition client, performs double-layer encryption on the fragmented data, transmits it using a multi-volume upload method, and supports encrypted integrity verification and breakpoint resume. The parsing module completes layered decryption, data mapping, and business logic verification, and writes compliant data in batches into the customs intranet business database and updates the associated status. The audit and evidence storage module records technical and business logs, constructs a batch-level chain-like evidence storage structure, supports retrieval and full-chain traceability, and generates an electronic ledger for bonded business supervision.

[0016] The beneficial effects of this invention are as follows: 1. This invention incorporates a unified metadata model for bonded business, including standard field definitions, business logic rules, and compliance verification criteria for core business domains such as procurement warehousing, production material requisition, finished product warehousing, inventory counting, and bonded ledgers. It automatically scans the table structure and field semantics of the enterprise ERP mirror database, and automatically aligns heterogeneous fields with the standard fields of the unified metadata model for bonded business based on semantic similarity matching. It generates initial field mapping rules and data collection SQL scripts, which can be adjusted and confirmed by management personnel as needed. When the enterprise-side system structure changes, only the configuration needs to be adjusted on the regulatory side to complete the adaptation. All configuration parameters are centrally encrypted and stored on the regulatory side, and the data collection client does not save any database configuration information locally.

[0017] 2. In this invention, sensitive configurations such as database connection credentials and collection scripts are uniformly encrypted and stored on the monitoring side. No sensitive configuration information is stored locally on the client side. The transmission process adopts a one-time session key combined with a two-layer encryption architecture. First, the compressed data is symmetrically encrypted using the AES-256 algorithm, and then asymmetric secondary encapsulation is completed using the SM2 public key. The session key is only valid for a single batch of tasks and automatically expires after the task ends, and neither party retains it. The multi-volume upload process supports encrypted state integrity verification and breakpoint resume. The data is in a state of encryption protection throughout the entire process, while ensuring the confidentiality and integrity of the data transmission process.

[0018] 3. This invention supports three priority task scheduling types: scheduled, triggered, and immediate collection. It can respond to regulatory scenarios such as ledger reconciliation warnings, risk clue pushes, and abnormal data alarms. It has a built-in incremental collection mechanism that captures new and changed business data based on historical collection records, reducing the amount of invalid data transmission and saving network bandwidth and storage resources. Technical and business logs are aggregated through Merkle trees to build a batch-level chain-like evidence storage structure. It can trace back from the final ledger to the original ERP fields and the entire chain of collection, transmission, conversion, and verification, locate abnormal nodes, and retain complete full-chain operation records. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the heterogeneous data synchronization process for bonded business ERP in this invention. Figure 2 This is a flowchart illustrating the task scheduling and execution process of the present invention. Detailed Implementation

[0020] The following, with reference to the attached diagram, uses a bonded processing enterprise for electronic components that holds electronic ledgers as an example to fully explain the implementation process of this solution. The enterprise deploys the Kingdee ERP system on its intranet. Production database data is synchronized to the mirror database in real time via binlog, with a data delay of ≤5 seconds between the mirror database and the production database. The mirror database uses MySQL 8.0, and the data acquisition client only accesses the mirror database and does not touch the production business database.

[0021] like Figures 1 to 2 As shown, this embodiment of the invention provides a method for synchronizing heterogeneous data in an ERP system for bonded business, including the following specific steps: In this embodiment of the invention, the regulatory side completes the filing of the basic information and electronic ledger bonded business permissions of the electronic component processing enterprise, and generates a unique and non-reusable activation code with the enterprise's unified social credit code as the unique identifier, and divides the enterprise's data collection permissions for four categories of bonded business: procurement warehousing, production material requisition, finished product warehousing, and inventory counting. The regulatory side generates a dedicated SM2 asymmetric key pair for the enterprise. The private key is encrypted and stored in the secure area of ​​the regulatory side, while the public key is accessible to the enterprise for querying and access, and is used for encrypting authentication information on the client side. The company deployed a data acquisition client on the server where the local intranet ERP mirror database is located. The data acquisition client sequentially reads four types of hardware identification information: the MAC address of the physical network card integrated on the motherboard, the CPU serial number, the system disk hard drive serial number, and the motherboard serial number. During the reading process, empty values ​​and invalid placeholder characters are filtered out, and the data is concatenated in a preset fixed order. A uniform delimiter is inserted at the concatenation point to form a complete hardware information string. For multi-NIC scenarios, the MAC address of the integrated physical NIC on the motherboard is selected; for multi-hard drive scenarios, the serial number of the system disk is selected. An SM3 one-way hash operation is performed on the hardware information string to generate a fixed-length hardware fingerprint string, which is written to a dedicated configuration file in the local encrypted storage directory and associated with the local collection log directory. After the enterprise's operations and maintenance personnel enter the activation code, the data collection client requests the enterprise's SM2 public key from the regulatory side, concatenates the activation code, the enterprise's unified social credit code, and the hardware fingerprint information into authentication plaintext, encrypts it using the SM2 public key, and sends it to the regulatory side's activation interface. The data acquisition client deployed by the enterprise sequentially reads four types of hardware identification information from the server's motherboard: MAC address of the integrated physical network card, CPU serial number, system disk serial number, and motherboard serial number. During the reading process, empty values ​​and invalid placeholder characters are filtered out, and the information is concatenated in a preset fixed order, with uniform delimiters inserted at the concatenation points to form a complete hardware information string. Perform a one-way hash operation on the concatenated hardware information string to generate a fixed-length hardware fingerprint string. Write the generated hardware fingerprint string into a dedicated configuration file in the local encrypted storage directory and establish an association mapping with the local collection log directory.

[0022] After receiving the request, the regulatory side uses the SM2 private key corresponding to the enterprise to decrypt it, and then verifies the validity of the activation code and its affiliation with the enterprise, the enterprise's electronic ledger filing qualification, and verifies that the hardware fingerprint is not bound to other enterprises and that the enterprise is not bound to other collection devices. After successful verification, the system permanently binds the activation code and hardware fingerprint to the enterprise's four types of bonded business data collection permissions, and updates the activation status to "effective." When hardware devices are changed, the enterprise must submit an application, which must be manually reviewed and approved by regulatory personnel before the original fingerprint can be unbound and the new device can be rebound. The system then returns the authentication credentials bound to the device to the data collection client, which encrypts and stores the authentication credentials in a local encrypted file. If verification fails, the system returns the corresponding error message and refuses terminal access.

[0023] The enterprise's data acquisition client extracts the hardware fingerprint string of the local machine, uses the PBKDF2-HMAC-SM3 algorithm to derive a locally stored special key, takes the hardware fingerprint as the input, adds a 16-byte random salt value, sets no less than 10,000 iterations, and derives a 128-bit SM4 symmetric key to perform symmetric encryption on the entire authentication credential, generating credential ciphertext. Salt values ​​and credential ciphertexts are stored separately; a dedicated credential storage file is generated in a designated protected directory on the local machine, and the file name is derived from the hash value of the hardware fingerprint; the encrypted credential ciphertext, credential version number, unified social credit code of the bound enterprise, and activation timestamp are written to the storage file in a fixed structure, and the file system access permissions are set to be readable only by the current operating system user; after the storage operation is completed, the plaintext authentication credential data and derived key data cached in memory are actively cleared.

[0024] In this embodiment of the invention, the regulatory side has a built-in unified metadata model for bonded business. This model includes standard field definitions, business logic rules, and compliance verification criteria for the core business domains of procurement warehousing, production material requisition, finished product warehousing, inventory counting, and bonded ledgers. Regulatory personnel enter the connection parameters of the enterprise's MySQL 8.0 mirror database into the management system, including the database type, JDBC connection address, access port, authorized username and password, and select the corresponding electronic component processing bonded business type and electronic ledger version for the enterprise. Based on the unified metadata model for bonded business, the regulatory side scans the table structure and field semantics of the enterprise's ERP mirror database, including purchase receipts, production material requisitions, finished goods receipts, and inventory counts. Semantic similarity matching is used to automatically align heterogeneous fields with standard fields. A three-level matching process is then executed to generate field mapping rules: the first level is automatic semantic similarity matching; if the matching coverage is less than 60%, a second level of bonded field dictionary rule matching is triggered. If a match still cannot be found, a configuration list is generated and pushed to management personnel for manual configuration. Finally, initial field mapping rules and data collection SQL scripts are generated. The regulatory side pre-generates a dedicated master key for the configuration library. The master key is split into multiple segments and stored in an independent secure storage area. When called, it is reassembled as needed. The system extracts the database connection address, access port, authorized username, login password, and complete SQL script of the enterprise, and concatenates the corresponding type identifier prefix according to the field type. The SM4 national standard symmetric encryption algorithm and the configuration library master key are used to perform symmetric encryption on each field to generate corresponding independent ciphertext fields. All ciphertext fields are associated with the enterprise's unified social credit code, configuration version number, generation timestamp, and operator identifier and written into the corresponding data table in the configuration library. All plaintext content is not written to any persistent storage medium.

[0025] Semantic similarity matching uses the field names, business definitions, and business domain labels of standard fields such as material code, document number, and quantity received in the unified metadata model of bonded business to form the baseline feature set, and uses the field names, field comments, and data types of fields such as mat_no, bill_id, and in_num obtained from the enterprise's ERP database to form the feature set to be matched. The two feature sets are processed by word segmentation, stop word removal, and word vector encoding respectively. The cosine similarity between each feature set to be matched and all baseline features is calculated. The cosine similarity preset threshold is set to 0.75. Matching pairs with similarity values ​​≥ 0.75 are automatically included in the initial mapping rules. Matching pairs with a similarity between 0.5 and 0.75 are added to the manual confirmation list; fields with a similarity < 0.5 are judged as unable to be automatically matched, and are pushed to administrators for manual configuration; the word vector model is finely trained based on the customs bonded business corpus.

[0026] The system automatically encrypts sensitive information such as the enterprise's database connection credentials and collection SQL scripts using the SM4 national cryptographic symmetric encryption algorithm before storing them in the regulatory-side configuration database. The configuration database master key is split into multiple segments using the Shamir(k,n) threshold secret sharing scheme, held by multiple administrators in separate segments. When called, the segments are assembled and restored as needed. The plaintext of the master key is not persistently stored. Business rules such as bonded data format verification, electronic component unit consumption logic verification, and electronic ledger consistency verification are associated and bound with the corresponding collection tasks to form the enterprise's collection task template. After configuration, all parameters are stored on the regulatory side, and the enterprise's data collection client does not save any database configuration information locally.

[0027] In this embodiment of the invention, the regulatory side performs data collection and scheduling based on bonded supervision needs and enterprise risk rating. The system has a built-in bonded compliance risk profile of the enterprise. Based on the enterprise's historical declaration data, abnormal records, and audit results, it is determined to be at a medium risk level. The corresponding data collection strategy is set: a hybrid data collection mode combining daily incremental data collection and monthly full data collection is executed, covering all fields of the core business table. The enterprise's bonded compliance risk profile is set up with four assessment dimensions: consistency of declaration data, deviation rate of account book reconciliation, proportion of abnormal data, and number of audit issues. The weights of the four dimensions are as follows: consistency of declaration data 25%, deviation rate of account book reconciliation 30%, proportion of abnormal data 25%, and number of audit issues 20%. Actual business data for the corresponding dimension is extracted by calendar month. The abnormal data proportion ≤0.1% will receive full marks for the corresponding dimension. For every 0.1% increase, 5 points will be deducted, until all points are deducted. The remaining dimensions are scored according to the same proportional rules, and the final weighted sum is used to obtain the comprehensive risk score. Based on the preset score range in which the comprehensive risk score is located, the corresponding bonded compliance risk level of the enterprise is determined, and the profile storage data is updated simultaneously.

[0028] Formula for calculating the comprehensive risk score of bonded compliance: ; ; This represents the comprehensive risk score for bonded compliance of an enterprise, used to determine the enterprise's bonded compliance risk level. The higher the score, the higher the compliance risk. The score represents the consistency dimension of the declared data, which is scored according to a proportional rule based on the degree of matching between the enterprise's declared data and the actual collected data. This represents the weighting coefficient for the consistency dimension of the declared data; The score represents the deviation rate of the accounting reconciliation dimension, which is scored according to a proportional rule based on the degree of deviation of the enterprise's accounting reconciliation data. This represents the weighting coefficient for the accounting book reconciliation deviation rate dimension; This represents the score for the dimension of abnormal data percentage. The scoring rule is that if the abnormal data percentage is ≤0.1%, the corresponding dimension receives the full score. For every 0.1% increase, 5 points are deducted, until all points are deducted. The weighting coefficients represent the proportion of outlier data. The score represents the number of audit issues, calculated proportionally based on the number of issues discovered in the company's historical audits. This represents the weighting coefficient for the quantity dimension of audit issues.

[0029] The data collection tasks for this enterprise are divided into three categories: scheduled collection, triggered collection, and immediate collection. Scheduled collection tasks are configured with a basic daily cycle, and the system adjusts the execution time to midnight every day based on the risk level, collecting all business data from the previous day. Triggered collection is automatically triggered by regulatory business events such as electronic ledger reconciliation warnings, risk clue pushes, and abnormal data alarms, and has a higher priority than scheduled collection. Immediate collection tasks are manually created by regulatory personnel and have the highest execution priority. After the task is created, the system generates a unique 256-bit true random one-time session key for this task through the supervisory side cryptographic machine; after the task is executed and archived, the session key is immediately cleared from memory and cache without any persistent storage, realizing one key per task, and encapsulating the task identifier, data time range, corresponding data source configuration, collection script, associated verification rules, and one-time session key into a task data package; The company's data collection client proactively initiates a polling request to the regulatory side every 5 minutes, with the request message carrying encrypted authentication credentials. After the regulatory side completes identity verification and business permission verification, it sorts the data collection according to the priority of immediate collection, triggered collection, and scheduled collection. Tasks of the same type are sorted in ascending order of creation time. The data packet of the highest priority task is encrypted and sent to the data collection client.

[0030] The enterprise's data collection client reads the locally encrypted authentication credentials, generates the current system timestamp and random request sequence number, and concatenates the authentication credentials, timestamp, and request sequence number into plaintext to be encrypted; it uses the enterprise's SM2 public key disclosed by the regulatory side to perform asymmetric encryption on the plaintext to be encrypted to generate credential ciphertext, and assembles the credential ciphertext, hardware fingerprint string, and request sequence number into a task query request message according to a preset message structure, and sends it to the regulatory side's task distribution interface; After receiving the request message, the regulatory side parses and extracts the information of each field, and uses the enterprise's SM2 private key to decrypt the ciphertext to obtain the plaintext content. First, it verifies whether the difference between the timestamp in the plaintext and the current time on the server is within a 300-second valid time window. Then, it verifies that the request sequence number has not appeared within the 300-second cache window. Duplicate sequence numbers are directly rejected, forming a dual anti-replay mechanism of time window + sequence number deduplication. Next, it verifies the validity of the authentication credential and the enterprise affiliation. Then, it compares the hardware fingerprint with the bound device fingerprint information. Finally, it verifies the data collection permission scope of the four types of bonded business corresponding to the device.

[0031] The regulatory side extracts the authentication credentials corresponding to the data collection client from the device binding relationship, generates a symmetric encryption key based on the authentication credentials using the PBKDF2-HMAC-SM3 derived algorithm, and uses the key to perform symmetric encryption processing on the entire task data packet; After receiving the encrypted task data packet, the enterprise's data acquisition client reads the locally encrypted authentication credentials, generates a decryption key using the same derived algorithm, performs a decryption operation on the data packet, and verifies the integrity of the task identifier in the data packet after decryption.

[0032] In this embodiment of the invention, after receiving the task data packet, the enterprise's data acquisition client decrypts and obtains the database connection information, the collection SQL script, the data time range, and the business verification rules; the client automatically matches and loads the corresponding JDBC driver according to the MySQL 8.0 database type, and establishes a temporary connection with the enterprise's intranet ERP mirror database.

[0033] The enterprise's data acquisition client extracts the database type identifier, connection address, access port, authorized username, and password parameters from the decrypted task data packet. Based on the database type identifier, it matches the corresponding MySQL JDBC driver class from the local driver library and completes the loading and initialization of the driver class. It assembles the connection URL according to the standard JDBC connection format, passes in the username and password parameters, calls the driver connection interface to establish a database session connection, and synchronously sets three timeout parameters: connection timeout of 30 seconds, query execution timeout of 300 seconds, and data read timeout of 180 seconds. After the connection is established, a connectivity verification statement is executed. Once the connection is confirmed to be valid, subsequent data collection operations are performed. After all data collection tasks are completed, the data result set, SQL script object and database connection session are closed in sequence. All database connection parameters, driver instances and query result data cached in memory are cleared. All cached files related to this connection in the local temporary directory are deleted. No database connection credentials are stored locally.

[0034] The data collection client queries local historical collection records to obtain the collection timestamp of 23:59:59 of the previous day and the maximum business primary key range of each business table to determine the collection mode. If there are valid historical records, the time condition in the collection SQL is replaced with the incremental time range of the current day, and the newly added and changed business data within the time range is captured based on the business primary key dimension. If there are no historical collection records, the first full data collection is performed. The data collection client reads the last successful data collection record from the corresponding business tables such as procurement receipt and production material requisition from the local history file, and extracts the data collection end timestamp, the maximum business primary key value, the corresponding data collection task number, and the record verification code field. Three checks are performed sequentially: the check code of the historical record is consistent with the check value of the record generated and stored after the last successful collection; the enterprise identifier corresponding to the record matches the currently bound enterprise; and the business table to which the record belongs is consistent with the current collection table. If all three checks pass, the historical record is deemed valid, and the corresponding timestamp and primary key range parameters are extracted for incremental collection condition assembly. If any check fails, the historical record is deemed invalid and is treated as having no valid historical records.

[0035] The data collection client prioritizes using the update_time field built into the business table as the basis for determining data changes; when the target table has no valid time field, it automatically switches to the auto-incrementing business primary key dimension to determine the increment; for business tables that do not support either method, it automatically downgrades to the periodic full collection mode, extracts the end timestamp of the last successful collection from the local historical collection records, and replaces the time query condition of the collection SQL script with the incremental range from the last end timestamp to the deadline of this task. After executing the query, all business records within the time interval are retrieved. The data status is determined based on the business primary key and the update timestamp. Records with a primary key greater than the historical maximum primary key are marked as newly added, and the remaining records are marked as changed. The maximum primary key value and the latest collection end timestamp of each business table stored locally are updated synchronously.

[0036] During the data collection process, the data collection client performs pre-cleaning and verification of the data according to the built-in data format rules and bonded business rules, removing dirty data with missing fields or abnormal formats, and simultaneously completing basic business logic verification. The verification content includes the compliance of the 10-digit customs material code, verifying that the code follows the segmented format and character type rules of the first 4 digits of the tariff code column, the middle 4 digits of the enterprise internal serial number, and the last 2 digits of the material category code; the consistency of the quantity unit, verifying that the unit belongs to the scope of the customs statutory unit of measurement directory and matches the corresponding material category, intercepting abnormal data that does not comply with the bonded business specifications and recording the abnormal details; The result set is segmented according to the business table. When the size of a single segment file exceeds the 10MB threshold, the data acquisition client automatically splits the segment into volumes. During the acquisition process, the acquisition progress is persistently recorded according to the segment dimension. After an abnormal interruption, the local progress can be read and the acquisition can continue from the interrupted position. After the acquisition is completed, the data acquisition client reports the acquisition status, number of data entries, time range and abnormal statistics to the regulatory side, and the regulatory side updates the task execution status.

[0037] The data collection client iterates through the business result set collected line by line, performing item-by-item verification in the order of format verification first and business rule verification second. The format verification step checks in turn whether the required fields of each row of data have empty values ​​or empty strings, whether the field data type matches the preset field type rules, whether the length of string field content exceeds the limit, whether the value of numeric field is within the preset legal value range, and whether the format of date field conforms to the standard date format requirements. The business rule verification process verifies whether the material code field format conforms to the 10-digit customs bonded business unified coding rule, whether the quantity unit field value belongs to the preset compliant unit set, and whether the business document number field conforms to the coding rule of the corresponding document type in the electronic ledger. During the verification process, each abnormal data is marked with the corresponding abnormal type code and abnormal field name, and the abnormal details are written to the local abnormal record file.

[0038] This data acquisition client generates initial fragment files based on the single collection result set of a single business table. Each business table corresponds to an independent fragment file, and the fragment files are named by a combination of the business table name and batch number. A preset 10MB size threshold is set for each fragment file. Fragments whose file size exceeds the threshold are split into volumes. During splitting, the fragment files are cut in order of fixed 5MB byte length, and each split file is assigned a continuously increasing volume number. A volume index file is generated, which records the total number of volumes, the byte offset of each volume, the file size of each volume, and the correspondence between the volume number and the fragment file. The index file and the corresponding volume file are stored in the same local directory.

[0039] In this embodiment of the invention, the enterprise's data acquisition client performs double-layer encryption on the fragmented data files generated from the acquisition; using the one-time session key issued by the task, the original data file is ZIP lossless compressed to obtain a compressed data packet, and then symmetric encryption is performed using the AES-256 algorithm; the enterprise's SM2 public key is used to perform asymmetric encryption on the one-time session key, and the one-time session key is encapsulated together with the session key ciphertext, task identifier, and inner ciphertext data into the final file to be transmitted; the one-time session key is only valid for the current task and automatically expires after the task is completed, and is not retained for a long time by either the client or the monitoring side; The data acquisition client first performs ZIP lossless compression on the original fragmented data file to generate a compressed data packet. Then, it uses the one-time session key issued in this task to perform AES-256 symmetric encryption on the compressed data packet to obtain the inner ciphertext data packet. Finally, it uses the enterprise's SM2 public key to perform asymmetric encryption on the one-time session key to generate the session key ciphertext. The session key ciphertext, task identifier field, and inner ciphertext data packet are concatenated in a preset byte order. A fixed-length file header identifier and a total file length field are added at the beginning of the file to encapsulate it into a single complete ciphertext file to be transmitted. If the fragment has been split into multiple volumes, each volume file is independently encapsulated according to the above process, and the corresponding volume number and total number of volumes are marked in the header of each volume file.

[0040] The data acquisition client uses a multi-part form protocol to upload encrypted files in multiple parts to the supervisory side. After each part is uploaded, the supervisory side performs a cryptographic SM3 national cryptographic hash integrity check on it, extracts the SM3 digest value reported by the client from the header of the file, recalculates the SM3 digest value based on the received full text of the file and compares it bit by bit. If the comparison is consistent, the file upload is marked as valid. When an upload fails due to network fluctuations, service interruptions, or other reasons during transmission, the data acquisition client automatically records the sequence number and offset of the successfully uploaded volume. When a retransmission is triggered next time, the data acquisition client skips the completed volumes and only transmits the remaining volumes that failed to upload. After the file is successfully uploaded, the data acquisition client reports the transmission completion status to the regulatory side.

[0041] The data acquisition client writes the confirmed successfully uploaded volume sequence number, the corresponding volume SM3 digest value, the transmitted byte offset, and the volume file size into the local transmission status record file. The record file name is bound to the unique identifier of this task. Before triggering the retransmission operation, the data acquisition client reads the local transmission status record file and sends a volume status verification request to the supervisory side. The request message carries the task identifier and the list of uploaded volume sequence numbers. After receiving the request, the regulatory side retrieves the corresponding task's volume upload ledger, verifies the integrity status of each volume by serial number, and returns a list of confirmed and valid completed volumes. The data acquisition client uses the confirmation list returned by the regulatory side as the standard, filters out the completed volumes, and transmits the remaining incomplete volumes in ascending order of volume serial number.

[0042] Before uploading the data in multiple volumes, the data acquisition client calculates the SM3 digest value for each encrypted file to be uploaded, writes the digest value into the extended field of the corresponding file header, and submits it to the supervisory side along with the file. After receiving a single file, the supervisory side extracts the SM3 digest value reported by the client from the file header, and recalculates the SM3 digest value based on the received full text of the file. The two sets of digest values ​​are then compared bit by bit. If the comparison results match, the upload of the sub-volume is marked as valid; if the comparison results do not match, the upload of the sub-volume is marked as failed, and a retransmission instruction is returned to the data acquisition client.

[0043] In this embodiment of the invention, after receiving the encrypted data file of the enterprise, the regulatory side uses the enterprise's SM2 private key to complete the outer asymmetric decryption, and decrypts the inner compressed package through the one-time session key associated with the task to restore the original collected data; The system performs mapping processing based on the unified metadata model of bonded business. According to the field mapping rules of the enterprise, it converts the heterogeneous field names and data formats of its Kingdee ERP into standard formats, retains four decimal places for numerical values, and converts material codes into 10-digit customs codes. After format cleaning, the system performs bonded business logic verification, including consistency of electronic component unit consumption accounting, bonded material inventory balance verification, and correlation of electronic ledger data. Abnormal data that does not conform to business logic is removed, abnormal details and corresponding risk tags are recorded, and abnormal alarms are generated and pushed to enterprise liaisons and regulatory personnel simultaneously. After verification, enterprises can initiate supplementary data collection tasks to correct data, and regulatory personnel can review and mark it as confirmed as violation or data error. Different marks correspond to different risk profile update weights. The system loads the field mapping rule table corresponding to the enterprise. The mapping rule table contains five pieces of information: source data table name, source field name, target standard field name, conversion rule type, and conversion parameters. The system iterates through the original collected data line by line, matching the material code standard field and conversion rule with the source table name of the purchase receipt and the source field name of mat_no. For the successfully matched fields, the corresponding processing is performed according to the conversion rule: date fields are uniformly converted, numeric fields are uniformly converted in precision and unit, and coded fields are converted using dictionary mapping. Unnecessary fields that do not match the rules are discarded and not included in the standard dataset; required standard fields that are missing after matching are judged as abnormal data, and the corresponding abnormal details and field missing identifiers are recorded and not included in the standard dataset; after all fields are processed, the transformed data rows are assembled according to the standard table structure defined by the unified metadata model for bonded business and written to the temporary standard dataset.

[0044] The system extracts the enterprise's currently valid bonded material unit consumption standard data, previous period bonded material inventory balance data, and valid electronic ledger basic information from the enterprise filing database as the benchmark dataset for this verification. Three verification actions are performed sequentially: First, extract the material consumption value from the current warehousing and material requisition data, and set a reasonable deviation threshold of ±2% based on the registered unit consumption × (1 + registered process loss rate). If the deviation exceeds the threshold, it is judged as an abnormal unit consumption. Second, calculate the current theoretical inventory based on the previous period's inventory balance data combined with the current period's warehousing, material requisition, and scrap loss data. If the deviation from the collected inventory data exceeds ±3%, it is judged as an abnormal inventory balance. Third, verify that the ledger number of all business documents is completely consistent with the registered valid ledger number, and that the document date is within the ledger's validity period. Record the primary key of the data that fails the verification, the corresponding verification item, and the deviation value for each item.

[0045] Formula for calculating the theoretical inventory of bonded materials for this period: ; This represents the theoretical inventory quantity of bonded materials within the current verification period, serving as the benchmark value for inventory balance verification. This indicates the actual inventory balance of bonded materials confirmed by the enterprise after the end of the previous verification period; This indicates the total quantity of bonded materials newly added to the enterprise's inventory and warehousing processes during the current verification period; This indicates the total quantity of bonded materials issued by the enterprise during the current verification period, including those used in production processes such as material requisition. This represents the sum of the amount of bonded material scrap and process loss generated during the enterprise's production process within the current verification period.

[0046] The system will write the verified data into the customs intranet business database in batches to form the original ledger of the enterprise's electronic components bonded supervision, and simultaneously update the execution status of the collection task and data statistics information, and synchronously update the enterprise's bonded compliance risk profile with abnormal data.

[0047] The system statistically analyzes the total number and percentage of abnormal data in all data collected in this batch. It categorizes the abnormal data into four types: format abnormalities, unit consumption accounting abnormalities, inventory balance abnormalities, and ledger association abnormalities, and extracts the specific number and percentage of each type of abnormality. The statistical data is written into each assessment dimension of the enterprise's bonded compliance risk profile, and the rolling cumulative values ​​for the past 30 days and the past 90 days for the corresponding dimensions are updated. The abnormal details of this batch are simultaneously stored in the profile history database. After the dimension data is updated, the bonded compliance risk level recalculation process for the enterprise is triggered. The latest cumulative values ​​of the four assessment dimensions are read, and the comprehensive risk score is calculated according to the preset weights and scoring rules. The risk level identifier and score data corresponding to the enterprise are updated.

[0048] In this embodiment of the invention, the system logs the technical operations and business nodes of the enterprise's data synchronization; the technical logs include operation records of technical aspects such as data acquisition client activation, task creation and distribution, data acquisition execution status, volume transmission progress, data parsing results, and data entry execution status; the business logs include operation records of core business nodes such as electronic ledger matching, business rule verification, risk tag generation, ledger updates, and permission changes. The system generates a unique hash value for each log entry in the batch. Technical logs and business logs in the same data batch are aggregated through a Merkle tree to generate the batch log Merkle root. The final root hash of the current batch is calculated by concatenating the Merkle root of this batch log with the final root hash of the previous batch of the enterprise, forming the batch-level chain-like evidence storage structure of the enterprise. The system sorts all technical and business logs within the same data batch of the enterprise in ascending order by log generation timestamp. For each log entry, the SM3 algorithm is used to calculate its hash value, and the result is used as a leaf node in a Merkle tree. Each bonded warehouse receipt is bound to a corresponding collection batch number, with a one-to-one correspondence between the batch number and the batch storage root hash, supporting full-chain reverse traceability. Leaf nodes are paired sequentially, and the hash values ​​of each pair of leaf nodes are concatenated to calculate the parent node hash. If the total number of nodes is odd, the last node is directly copied upwards as the parent node. This pairing and calculation process is repeated layer by layer upwards until a unique batch log Merkle root is generated. If the database retrieves the company's historical batch records and it is the first batch to be collected, the Merkle root of the current batch log is directly used as the final root hash of the current batch and written into the database. If it is not the first batch to be collected, the final root hash value of the previous batch of the company is extracted, and the Merkle root of the current batch log is concatenated with the final root hash of the previous batch to calculate the hash value, which generates the final root hash of the current batch and is written into the corresponding batch record in the database.

[0049] The formula for calculating the final root hash of batch-level chained evidence storage is as follows: ; ; It represents the final root hash value of the nth data batch, and is a unique tamper-proof identifier for batch-level chained evidence storage; This represents the SM3 cryptographic hash algorithm function, which outputs a one-way hash value of the input content; This represents the byte concatenation operator, which concatenates two hash values ​​sequentially into a complete byte string. This represents the batch log Merkle root generated by aggregating all technical and business logs within the nth data batch using a Merkle tree. This represents the final root hash value of the (n-1)th data batch, which is the evidence root hash of the previous collection batch; This represents the final root hash value of the first collection batch. If there is no preceding batch, it is directly equal to the log Merkle root of this batch. This represents the batch log Merkle root generated by aggregating all logs within the first collection batch using a Merkle tree.

[0050] Supervisory personnel can use the management system to search the company's full-chain logs by dimensions such as company entity, time range, and operation type. They can trace back from a bonded ledger data of an abnormal purchase to the original ERP field to the entire chain of collection, transmission, conversion, and verification, and locate the abnormal link and the responsible party. The system generates an electronic ledger for the company's bonded business supervision based on the data entering the warehouse, summarizing its bonded business data for the entire chain of procurement, production, and inventory.

[0051] After receiving the traceability query conditions from the enterprise, the system first locates the bonded ledger data records that meet the conditions, extracts the data batch number associated with the ledger record and the corresponding collection task number; based on the batch number, it retrieves all business logs and technical logs of the corresponding batch, and sorts all log records in reverse order by operation timestamp; The system sequentially associates task distribution records, data transmission volume records, collection and execution detail records, and field mapping rule version records, matching the original ERP purchase receipt source table name and source field name corresponding to the ledger fields; it assembles the operation subject identifier, operation time, operation content, and corresponding data unique identifier information of each node in the entire chain to form a complete chain traceability dataset.

[0052] This invention also provides an ERP heterogeneous data synchronization system for bonded business, used to implement the above method, including the following modules: The activation authentication module is deployed on the regulatory side to complete the filing of basic information and electronic ledger bonded business permissions for the electronic component processing enterprise, generate a unique and non-reusable activation code and enterprise-specific SM2 key pair, receive encrypted authentication requests submitted by the data collection client, and sequentially verify the validity of the activation code, the enterprise's filing qualifications and the binding relationship of the hardware fingerprint. After the verification is passed, a permanent binding relationship is established between the activation code, the hardware fingerprint and the enterprise's bonded business permission scope, and the encrypted and stored basic identity credentials are issued to the data collection client. The data acquisition and configuration module has a built-in unified metadata model for bonded business. It allows managers to enter the connection parameters of the enterprise's MySQL mirror database, automatically scan the database table structure and complete the semantic alignment of heterogeneous fields with standard fields, generate field mapping rules and data acquisition SQL scripts, bind the verification rules for bonded electronic components to form a data acquisition task template, and encrypt and store all configuration parameters on the regulatory side. The task scheduling module generates three types of collection tasks with different priorities: timed, triggered, and immediate collection, based on the enterprise's bonded compliance risk profile and the corresponding mixed collection strategy. It generates a one-time session key for each batch of collection tasks and encapsulates the corresponding task data packet. After receiving the data collection client's polling request and completing the identity and permission verification, it sends the corresponding task data packet in priority order. The data acquisition module is deployed on the enterprise intranet data acquisition client. After decrypting the task data packet and obtaining the task parameters, it establishes a temporary connection with the enterprise's ERP mirror database, queries historical records to determine the acquisition mode, captures business data within the corresponding range, performs pre-cleaning and verification and result fragmentation, and then reports the acquisition status. The encrypted transmission module, deployed on the data acquisition client, performs double-layer encryption on the enterprise's segmented business data, transmits it using a multi-volume upload method, and supports encrypted integrity verification and breakpoint resume. The parsing and data entry module completes the hierarchical decryption, standardized mapping and electronic ledger business logic verification of the enterprise's data, and writes compliant data in batches into the customs intranet business database and updates the associated status. The audit and evidence storage module records the company's technical and business logs, constructs a batch-level chain-like evidence storage structure, supports multi-dimensional retrieval and full-chain traceability, and generates an electronic ledger for the company's bonded business supervision.

[0053] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0054] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for synchronizing heterogeneous data in ERP systems for bonded business, characterized in that: The specific steps include the following: The regulatory side completes the enterprise qualification registration, builds a unified metadata model for bonded business, configures the connection parameters of the enterprise ERP mirror database, and generates collection rules and task templates after completing the semantic alignment of fields. After receiving the authentication request from the data collection client and completing the identity verification and permission binding, the system sends authentication credentials to the data collection client. The regulatory side sets differentiated collection strategies based on the enterprise's bonded compliance risk level, generates collection tasks with different priorities, generates a one-time session key for a single batch of collection tasks and encapsulates the corresponding task data packet, and sends the data collection client according to priority after verifying the client's identity and permissions. The data acquisition client decrypts the task data packet, establishes a temporary connection with the enterprise ERP mirror database, determines the acquisition mode, captures the corresponding range of business data, and reports the acquisition status after cleaning, verification, and fragmentation. The fragmented data files are encrypted using a double layer before being uploaded in multiple volumes. The regulatory side performs layered decryption of uploaded data, completes data mapping and transformation and bonded business logic verification based on the unified metadata model of bonded business, writes compliant data into the customs intranet business database, generates batch log Merklegen and constructs a batch-level chain-like evidence storage structure to form an electronic ledger for bonded business supervision.

2. The ERP heterogeneous data synchronization method for bonded business according to claim 1, characterized in that, During the enterprise qualification filing process, the regulatory side completes the filing and registration of the enterprise's basic information and bonded business permissions. Using the enterprise's unified social credit code as the unique identifier, a unique and non-reusable activation code is generated to divide the corresponding bonded business data collection permission scope for the enterprise. The regulatory side generates an independent SM2 asymmetric key pair for each registered company. The public key pair is open for querying and access by the corresponding registered company, while the private key is securely stored by the regulatory side.

3. The ERP heterogeneous data synchronization method for bonded business according to claim 2, characterized in that, After an enterprise deploys the data collection client on its local intranet, the data collection client automatically collects the hardware fingerprint information of the local machine, obtains the input activation code and the enterprise's unified social credit code, and then requests the corresponding enterprise's SM2 public key from the regulatory side with the activation code. The activation code, the enterprise's unified social credit code, and the hardware fingerprint information are concatenated into authentication plaintext, encrypted with the SM2 public key, and then sent to the regulatory side. Upon receiving the request, the regulatory side uses the private key to decrypt and sequentially verifies the validity of the activation code, its affiliation with the registered enterprise, the enterprise's registration qualifications, and confirms that the hardware fingerprint information is not bound to any registered enterprise other than the registered enterprise, and that the registered enterprise is not bound to any data collection terminal other than the data collection client currently applying for access. After successful verification, a permanent binding relationship is established between the activation code, the hardware fingerprint information, and the enterprise's bonded business data collection permission scope. The regulatory side then returns the authentication credential bound to the device to the data collection client, which encrypts and stores the authentication credential locally.

4. The ERP heterogeneous data synchronization method for bonded business according to claim 3, characterized in that, The unified metadata model for bonded business includes standard field definitions, business logic rules, and compliance verification criteria for core business domains such as procurement warehousing, production material requisition, finished product warehousing, inventory counting, and ledger reconciliation. The regulatory side enters the connection parameters of the enterprise ERP mirror database, including database type, connection address, access port, authorized username and password, and selects the corresponding bonded business type and ledger version; the regulatory side scans the table structure and field semantics of the enterprise ERP mirror database based on the unified metadata model of the bonded business, and automatically aligns heterogeneous fields with standard fields in the unified metadata model of the bonded business through semantic similarity matching, generating initial field mapping rules and data collection SQL scripts; The regulatory side encrypts and stores sensitive configuration information in its configuration database, associates and binds bonded business verification rules with data collection tasks to form the task template, and stores all configuration parameters in encrypted form on the regulatory side. The data collection client does not save any database configuration information locally.

5. The ERP heterogeneous data synchronization method for bonded business according to claim 4, characterized in that, The regulatory side has a built-in enterprise bonded compliance risk profile, which is dynamically updated based on historical declaration data, abnormal records, and audit results to determine the enterprise's bonded compliance risk level, and corresponding differentiated data collection strategies are set. High-risk enterprises are subject to high-frequency incremental data collection, medium-risk enterprises are subject to mixed data collection combining medium-frequency incremental data collection and periodic full data collection, and low-risk enterprises are subject to low-frequency full data collection. Data collection tasks are divided into three categories: scheduled data collection, triggered data collection, and immediate data collection. Triggered data collection is automatically triggered by regulatory business events, including ledger reconciliation warnings, risk clue pushes, and abnormal data alarms. It has a higher priority than scheduled data collection. Immediate data collection is manually created by regulatory personnel and has the highest priority. After the data collection task is created, the monitoring side generates a unique one-time session key for this task, encapsulates the task parameters and the one-time session key into the task data packet, and the data collection client initiates a polling request carrying the encrypted authentication credentials. After identity verification and business permission verification, the monitoring side issues the task data packet in priority order.

6. The ERP heterogeneous data synchronization method for bonded business according to claim 5, characterized in that, After receiving the task data packet, the data acquisition client decrypts it to obtain database connection information, data time range and business verification rules, and establishes a temporary connection with the enterprise ERP mirror database. The data acquisition client queries local historical acquisition records. If there are valid historical records, incremental acquisition is performed to capture newly added and changed business data within the time range. If there are no historical acquisition records, the first full data acquisition is performed. During the data collection process, pre-processing and verification are performed according to built-in data format rules and field-level basic business rules. The pre-processing verification is clearly defined as field-level basic verification, which is different from the backend full-link business logic verification. Dirty data with missing fields or abnormal formats is removed, basic business logic verification is completed, abnormal data is intercepted and recorded in detail, and the result set is split into pieces according to the business table. When the size of a single piece file exceeds a preset threshold, the data collection client automatically splits the single piece file into volumes. After the collection is completed, the collection status and abnormal statistics information are reported.

7. The ERP heterogeneous data synchronization method for bonded business according to claim 6, characterized in that, The data acquisition client performs double-layer encryption on the fragmented data files generated by the acquisition: it compresses the original fragmented data files using the one-time session key issued by the acquisition task and performs symmetric encryption, and then uses the SM2 public key of the corresponding enterprise to perform asymmetric encryption on the one-time session key, and encapsulates it to generate a file to be transmitted. The one-time session key is only valid for the current acquisition task. After the task is completed, the monitoring side and the data acquisition client destroy the one-time session key simultaneously and it is not reused. The data acquisition client uploads the encrypted file in multiple volumes to the monitoring side. After each volume is uploaded, the monitoring side performs a ciphertext integrity check. If the upload fails, the data acquisition client automatically records the uploaded volume information. When re-transmitting, it skips the completed volumes. After successful upload, it reports the transmission completion status.

8. The ERP heterogeneous data synchronization method for bonded business according to claim 7, characterized in that, After receiving the encrypted data file, the regulatory side uses the corresponding enterprise's SM2 private key to complete the outer asymmetric decryption, and decrypts the inner compressed package using the one-time session key to restore the original collected data. The regulatory side performs mapping processing based on the unified metadata model of bonded business, converting the field names and data formats of heterogeneous ERP systems into the standard format defined by the unified metadata model of bonded business. After completing the data standardization and format cleaning, the bonded business logic is checked, the abnormal data is removed, and details and risk labels are recorded. Data that passes verification is written in batches to the customs intranet business database to form the enterprise's original bonded supervision ledger, and the task execution status is updated synchronously. Abnormal data is also updated synchronously to the enterprise's bonded compliance risk profile.

9. The ERP heterogeneous data synchronization method for bonded business according to claim 8, characterized in that, The regulatory side logs the technical operations and business node operations of data synchronization separately, and generates a unique hash value for each log. A single collection task is a data batch. All logs in the same data batch are aggregated through a Merkle tree to generate the batch log Merkle root. The final root hash of the current batch is generated by concatenating the Merkle root of the current batch log with the final root hash of the previous batch, thus forming the batch-level chain-like evidence storage structure. The regulatory side supports multi-dimensional log retrieval and full-link data traceability, and generates the bonded business supervision electronic ledger based on the compliant business data that has been entered into the database.

10. An ERP heterogeneous data synchronization system for bonded business, used to implement the method described in any one of claims 1-9, characterized in that, Includes the following modules: The activation and authentication module is used to complete the enterprise qualification filing, generate an activation code and a dedicated SM2 key pair for the enterprise, verify the authentication request of the data collection client, and issue authentication credentials. The data acquisition and configuration module has a built-in unified metadata model for bonded business, which supports database table structure scanning, field semantic alignment, data acquisition rule generation and task template configuration, and encrypts and stores all configuration parameters. The task scheduling module is used to set differentiated collection strategies based on the enterprise's bonded compliance risk level, generate multi-priority collection tasks, encapsulate task data packets, and distribute them according to priority. The data acquisition module is used to decrypt task data packets, establish database connections, determine the acquisition mode and capture business data, complete pre-cleaning and verification and result fragmentation, and report the acquisition status. The encrypted transmission module is used to perform double-layer encryption on fragmented data, transmits data in a multi-volume manner, and supports ciphertext integrity verification and breakpoint resume; The parsing and data entry module is used to complete data layering and decryption, standardized mapping and transformation, and bonded business logic verification, write compliant data into the customs intranet business database and update the associated status; The audit and evidence storage module is used to record the technical and business logs of the entire process, build a batch-level chain-like evidence storage structure, support full-link traceability, and generate an electronic ledger for bonded business supervision.

Images