Contract data multi-system bidirectional synchronization and field mapping method and equipment

Abstract

The invention relates to the technical field of database system integration, and provides a contract data multi-system bidirectional synchronization and field mapping method and device.The contract data multi-system bidirectional synchronization and field mapping method comprises the steps that fields of different systems are named and standardized by building and loading a static field mapping table, and contract main table data in a source system and extended data model information of the contract main table data are obtained according to query conditions; performing field name conversion and value formatting on the acquired data according to a static field mapping table, and performing recursive processing and change tracking on a contract signing party sub-table and a money return plan sub-table associated with a contract; identifying field-level and sub-table-level change information by comparing historical versions of the contract data, and generating a structured change record; and assembling and synchronizing the converted main table data, the processed sub-table data and the change record according to a data structure of the target system. According to the method, the integrated development and long-term maintenance cost of the system can be remarkably reduced, and accurate synchronization of a complex nested data structure is completely supported.

Description

Technical Field

[0001] This invention relates to the field of database system integration technology, and in particular to a method and device for bidirectional synchronization and field mapping of contract data across multiple systems. Background Technology

[0002] In enterprise IT infrastructure development, especially in the operation and management of large corporations, contract data typically needs to be transferred and shared between multiple heterogeneous business systems. For example, contract approval processes are completed in an office automation (OA) system, financial data is processed in an enterprise resource planning (ERP) system, while the entire lifecycle management of contracts is handled by a dedicated contract management system. These systems are often independently built and technologically heterogeneous, resulting in significant differences in the models, structures, and field naming of contract data.

[0003] Currently, existing technologies for achieving data synchronization between such systems have the following shortcomings and drawbacks:

[0004] 1. Significant differences in data models and cumbersome mapping maintenance: Different systems use completely different field names and formats for the same contract attribute, resulting in extensive hard-coded mapping conversions for each integration. When business fields change or are added, code and configuration must be modified frequently, leading to high development and maintenance costs.

[0005] 2. Complex data structure, making complete synchronization difficult: Contract data contains multiple nested sub-tables and list structures, including contracting parties, payment plans, and performance terms. Traditional synchronization methods struggle to effectively handle such master-slave relationships, easily leading to data loss in sub-tables or incorrect associations.

[0006] 3. Frequently changing business requirements and insufficient support for dynamic fields: Enterprise contract templates are often adjusted according to business needs, with dynamic fields frequently added or removed. Traditional synchronous solutions based on fixed data structures cannot automatically adapt to these changes and have poor scalability.

[0007] 4. Difficulty in tracking changes and lack of effective audit clues: Contracts are often modified multiple times during their lifecycle. Existing technologies mostly only synchronize the current data status and lack the ability to record and synchronize historical changes at the field level, making it difficult to meet compliance audit and business traceability requirements.

[0008] 5. Weak data consistency guarantee: Incorrect field mapping, synchronization timing issues, or insufficient exception handling often lead to inconsistencies in contract data between different systems, affecting business accuracy and decision reliability.

[0009] Chinese patent CN116226145A discloses a data interaction method. This method improves the accuracy of field mapping through a static hierarchical mapping model. It is suitable for form data synchronization scenarios with relatively fixed data structures, mainly unidirectional appending, and simple business logic. However, when facing the specific scenario of bidirectional synchronization of contract data across multiple systems, it has significant shortcomings in terms of dynamic adaptability, change tracking, complex sub-table processing, bidirectional synchronization, and business semantic integration.

[0010] Therefore, how to provide a low-cost and highly reliable method to achieve intelligent bidirectional synchronization and field mapping of contract data between heterogeneous systems has become an urgent technical problem to be solved. Summary of the Invention

[0011] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a method and device for multi-system bidirectional synchronization and field mapping of contract data.

[0012] According to a first aspect of the present invention, a method for bidirectional synchronization and field mapping of contract data across multiple systems is provided, the method comprising:

[0013] Step S1: Standardize field naming for different systems by building and loading a static field mapping table, and obtain the contract master table data and its extended data model information from the source system according to the query conditions;

[0014] Step S2: Based on the static field mapping table, perform field name conversion and value formatting on the obtained data, and recursively process and track changes in the contract-related contracting party sub-table and payment plan sub-table;

[0015] Step S3: By comparing historical versions of contract data, identify field-level and sub-table-level change information and generate structured change records;

[0016] Step S4: Assemble and synchronize the transformed main table data, processed sub-table data, and change records according to the data structure of the target system.

[0017] Optionally, in the contract data multi-system bidirectional synchronization and field mapping method of the present invention, step S1 includes:

[0018] Construct a static field mapping table to store the correspondence between source system field names and target system field names. This static field mapping table uses a key-value pair data structure for storage and is loaded into memory during system initialization.

[0019] Based on preset query conditions, the basic information of the contract master table is obtained from the source system database. By calling the application programming interface provided by the source system, the extended data model object associated with the contract is obtained.

[0020] Parse the extended data model object and extract all dynamic form fields defined therein and their corresponding key-value pairs.

[0021] Optionally, in the multi-system bidirectional synchronization and field mapping method for contract data of the present invention, step S2, performing field name conversion and value formatting on the acquired data according to the static field mapping table, includes:

[0022] Iterate through the set of fields in the main table obtained from the source system and the set of dynamic fields in the extended data model;

[0023] Query the static field mapping table to obtain the target system field name corresponding to each field. If the corresponding target system field name is not found, retain the original field name.

[0024] Date type fields are uniformly converted to standard date and time formats, numeric type fields are precision controlled and formatted, and enumeration type fields are converted to corresponding enumeration description text.

[0025] Optionally, in the multi-system bidirectional synchronization and field mapping method for contract data of the present invention, step S2 involves recursively processing and tracking changes to the contract-related contracting party sub-table in the following manner:

[0026] Based on the contract primary key, retrieve the list of contracting party records from the source system database, iterate through the list of contracting party records, and extract the basic information from each record.

[0027] Based on the role of each signatory in the contract, a corresponding type identifier is set for each signatory;

[0028] Legal and authorized identification information can be obtained by querying the contracting party information table or the internal entity information table;

[0029] The contracting party data is encapsulated into structured objects and formed into a list, while recording the addition, modification, and deletion status of contracting party entries.

[0030] Optionally, in the multi-system bidirectional synchronization and field mapping method for contract data of the present invention, step S2 involves recursively processing and tracking changes to the contract-related payment plan sub-table in the following manner:

[0031] Locate and retrieve the collection plan data list from the parsed extended data model, traverse each entry in the collection plan data list, and extract the collection plan performance element field;

[0032] Perform a transformation on the extracted field names based on a static field mapping table, and standardize the data types of the extracted field values;

[0033] Each completed payment collection plan entry is encapsulated as an independent data object and organized into a structured list of payment collection plan data.

[0034] By comparing the differences in the repayment plan data between the source system and the target system, the add, modify, and delete operations that need to be synchronized can be identified.

[0035] Optionally, in the multi-system bidirectional synchronization and field mapping method for contract data of the present invention, step S3 identifies field-level and sub-table-level change information in the following manner:

[0036] Using the contract number as the query condition, retrieve all historical change records for the contract from the change log table of the source system and sort them in reverse chronological order.

[0037] Retrieve the complete contract data after the most recent change and compare it field by field with the data snapshot saved before the change;

[0038] Based on the predefined tracking field configuration, the values ​​of each field before and after the change are compared, and the field identifier, field name, old value, new value and change time are recorded.

[0039] For the contracting party sub-table and the payment plan sub-table, new entries, deleted entries, and content modification entries are identified by comparing a set of unique identifiers.

[0040] Integrate field-level change records and sub-table change records into a complete structured change history data package.

[0041] Optionally, the contract data multi-system bidirectional synchronization and field mapping method of the present invention further includes processing contract attachment data in the following manner: when acquiring contract data, synchronously querying all attachment information associated with the contract, setting a type identifier for each attachment according to the attachment business type, extracting basic information of each attachment, and integrating the attachment data with type identifier and basic information into the final data transmission object.

[0042] Optionally, in the multi-system bidirectional synchronization and field mapping method for contract data of the present invention, in step S4, the converted master table data, the processed sub-table data, and the change records are assembled according to the data structure of the target system in the following manner:

[0043] Create a standardized data transfer object that conforms to the target system interface specification, and map the transformed and formatted main table field data to the top-level property of the standardized data transfer object;

[0044] Assign the processed list of contracting parties and the list of payment plans to the corresponding sub-table attributes in the standardized data transmission object;

[0045] The generated change history data packet is assigned to a dedicated attribute in the standardized data transmission object used to carry change information, and a data type compatibility check is performed.

[0046] Optionally, in the contract data multi-system bidirectional synchronization and field mapping method of the present invention, in step S4, the converted master table data, the processed sub-table data, and the change records are synchronized according to the data structure of the target system in the following manner:

[0047] The assembled standardized data transmission object is pushed via HTTP request or message queue through the standard data interface provided by the target system.

[0048] After receiving the data, the target system determines whether to perform an add or update operation based on the contract number, verifies and persists the received data, and returns the synchronization result.

[0049] The source system updates the synchronization status based on the synchronization results and records the synchronization log.

[0050] According to a second aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect of the present invention.

[0051] The method and apparatus for multi-system bidirectional synchronization and field mapping of contract data of the present invention have the following beneficial technical effects:

[0052] 1. Significantly reduces system integration development and long-term maintenance costs.

[0053] When the data model of the source or target system changes (such as adding, renaming or deleting fields), only the mapping table configuration needs to be updated, without modifying the program source code. This greatly reduces the need to modify the code of the synchronization program itself, shortens the development cycle, and significantly reduces the long-term maintenance complexity and cost caused by system iteration and upgrades.

[0054] 2. Fully supports accurate synchronization of complex nested data structures.

[0055] This ensures that the original hierarchical structure and business relationships of the data are fully preserved during the synchronization process, effectively avoiding common problems in traditional synchronization methods such as loss of sub-table data, flattened structure, or disordered relationships, thereby guaranteeing the semantic integrity of business data.

[0056] 3. Flexibly adapt to dynamic business changes and expand fields

[0057] When businesses adjust contract templates or add or remove custom fields according to their business needs, the synchronization program does not need to write or modify processing code for each specific extended field. It can adaptively handle new field structures and quickly respond to dynamic changes in business requirements.

[0058] 4. Enable refined change history tracking and data traceability

[0059] It can accurately record every data change of a contract throughout its lifecycle, capturing information such as the specific field identifiers that have changed, the values ​​before and after the change, the time of the change, and the operator. It can also track the addition, modification, and deletion of entries, meeting the stringent requirements of internal auditing and compliance management, and providing reliable and detailed data traceability for business analysis, risk monitoring, and dispute resolution.

[0060] 5. Ensure high data consistency across multiple systems.

[0061] It reduces the risk of data errors and omissions caused by manual intervention, mapping mistakes, or program defects, and can maintain the long-term consistency of the status of core contract data and related data across multiple heterogeneous systems such as OA, ERP, and contract management systems.

[0062] 6. Improve system integration efficiency and collaborative work capabilities

[0063] Automatic data synchronization simplifies the development of inter-system interfaces, significantly improves the overall efficiency of system integration, and promotes collaborative work among different business departments based on consistent and real-time contract data. Attached Figure Description

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

[0065] Figure 1 This is a flowchart illustrating the method for bidirectional synchronization and field mapping of contract data across multiple systems according to an exemplary embodiment 1 of the present invention.

[0066] Figure 2 This is a flowchart illustrating the field mapping conversion process of the multi-system bidirectional synchronization and field mapping method for contract data according to Exemplary Embodiment 1 of the present invention.

[0067] Figure 3 This is a flowchart illustrating the sub-table data processing method for the multi-system bidirectional synchronization and field mapping of contract data according to Exemplary Embodiment 1 of the present invention.

[0068] Figure 4 This is a flowchart illustrating the change data tracking process of the multi-system bidirectional synchronization and field mapping method for contract data according to Exemplary Embodiment 1 of the present invention.

[0069] Figure 5 This is a technical principle illustration of the multi-system bidirectional synchronization and field mapping method for contract data according to exemplary embodiment 3 of the present invention;

[0070] Figure 6 This is a schematic diagram of the structure of the device provided by the present invention. Detailed Implementation

[0071] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0072] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0073] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0074] Example 1

[0075] Exemplary embodiment 1 of the present invention provides a method for bidirectional synchronization and field mapping of contract data across multiple systems. Figure 1 This is a flowchart illustrating the method for bidirectional synchronization and field mapping of contract data across multiple systems according to an exemplary embodiment 1 of the present invention. Figure 1 As shown, the method of this embodiment is implemented in the following manner:

[0076] Step S1: Standardize field naming for different systems by building and loading a static field mapping table, and obtain the contract master table data and its extended data model information from the source system according to the query conditions.

[0077] In this embodiment, a static field mapping table is pre-built and loaded to define the correspondence between field names between the source system and the target system; based on the query conditions, the basic data of the main table of the target contract is obtained from the source system, and its associated extended data model is parsed to extract complete source data including dynamic form fields.

[0078] Specifically, a static field mapping table is constructed to store the correspondence between field names in the source system and field names in the target system. This static field mapping table uses a key-value pair data structure for storage, with the field names in the source system as keys and the field names in the target system as values. It is loaded into memory during system initialization to achieve efficient querying. Based on preset query conditions, the basic information of the contract master table is retrieved from the source system database. By calling the application programming interface provided by the source system, the extended data model object associated with the contract is obtained. The extended data model object is parsed to extract all the dynamic form fields defined therein and their corresponding key-value pairs.

[0079] In practical applications, the method of this embodiment parses the extended data model object as follows: It calls the source system interface to obtain the extended data model object embedded within the contract object; it uses the methods provided by this model object to obtain a mapping set containing all dynamic form fields; it iterates through this mapping set, and for each field entry, it parses it according to its declared type: for text types, it directly reads the string value; for date types, it formats it into a standard string; for numeric types, it performs precision processing and formatting; for enumeration types, it converts the stored value into an enumeration description; for complex structures where the field type is a nested object or a list, it initiates a recursive parsing process, that is, it recursively calls this parsing process for nested objects, and iterates through each element of a list and recursively parses it, to ensure complete extraction of dynamic field data at all levels.

[0080] Step S2: Based on the static field mapping table, perform field name conversion and value formatting on the obtained data, and recursively process and track changes to the contracting party sub-table and the payment plan sub-table associated with the contract.

[0081] In this embodiment, a static field mapping table is used to uniformly convert the field names in the main table and extended data model, and to standardize and format the field values. At the same time, the contract-related contracting party sub-table and payment plan sub-table data are recursively processed to extract their contents and track changes to the sub-table entries.

[0082] Figure 2 This is a flowchart illustrating the field mapping transformation process of the multi-system bidirectional synchronization and field mapping method for contract data according to Exemplary Embodiment 1 of the present invention. Figure 2As shown, as an optional example, in this embodiment, the acquired data is converted in terms of field name and formatted in terms of value according to the static field mapping table as follows: traverse the set of fields in the main table obtained from the source system and the set of dynamic fields in the extended data model; query the static field mapping table to obtain the target system field name corresponding to each field; if the corresponding target system field name is not found, the original field name is retained; date type fields are uniformly converted to standard date and time format, numeric type fields are precision controlled and formatted, and enumeration type fields are converted to the corresponding enumeration description text.

[0083] Figure 3 This is a flowchart illustrating the sub-table data processing method for the multi-system bidirectional synchronization and field mapping of contract data according to Exemplary Embodiment 1 of the present invention. Figure 4 This is a flowchart illustrating the change data tracking process of the multi-system bidirectional synchronization and field mapping method for contract data according to Exemplary Embodiment 1 of the present invention. Figure 3 and Figure 4 As shown, in this embodiment, the contracting party sub-table associated with the contract is recursively processed and its changes are tracked in the following manner:

[0084] Based on the contract primary key, a list of contracting party records is retrieved from the source system database. This list is then iterated through to extract basic information from each record, including the entity name, contact information, bank account, and taxpayer identification number. Based on the contracting party's role in the contract, a corresponding type identifier is assigned to each party, with at least four categories: Party A, Party B, Party C, Party D, and Party E. Legal and authorized identification information, such as the legal representative and organization code, is obtained by querying the contracting party information table or internal entity information table. The contracting party data is then encapsulated into structured objects and listed, while simultaneously recording the addition, modification, and deletion status of contracting party entries.

[0085] In this embodiment, the contract-related payment plan sub-table is recursively processed and its changes are tracked in the following manner:

[0086] The system locates and retrieves the collection plan data list from the parsed extended data model. It iterates through each entry in the collection plan data list, extracting core fields such as collection node, collection conditions, payment period days, collection ratio, and collection amount. The extracted field names are then transformed using a static field mapping table, and the extracted field values ​​are standardized for data type. Each processed collection plan entry is encapsulated as an independent data object and organized into a structured collection plan data list. By comparing the differences between the collection plan data in the source and target systems, the system identifies the add, modify, and delete operations that need to be synchronized.

[0087] Step S3: By comparing historical versions of contract data, identify field-level and sub-table-level change information and generate structured change records.

[0088] In this embodiment, field-level and sub-table-level change information is identified in the following manner:

[0089] Using the contract number as the query condition, retrieve all historical change records for the contract from the change log table of the source system and sort them in reverse chronological order by change time; obtain the complete contract data after the most recent change and compare it field by field with the data snapshot saved before the change; based on the predefined tracking field configuration, compare the values ​​of each field before and after the change, and record the changed field identifier, field name, old value, new value, and change time; for the contracting party sub-table and the payment plan sub-table, identify added, deleted, and modified entries by comparing unique identifier sets; integrate the field-level change records and sub-table change records into a complete structured change history data package.

[0090] It should be noted that the method in this embodiment also includes processing contract attachment data in the following manner: when acquiring contract data, simultaneously query all attachment information associated with the contract, set a type identifier for each attachment according to the attachment business type, extract the basic information of each attachment, and integrate the attachment data with type identifier and basic information into the final data transmission object.

[0091] Step S4: Assemble and synchronize the transformed main table data, processed sub-table data, and change records according to the data structure of the target system.

[0092] In this embodiment, the converted main table data, the processed sub-table data, and the change records are assembled according to the data structure of the target system in the following manner:

[0093] Create a standardized data transmission object that conforms to the target system interface specification, and map the transformed and formatted main table field data to the top-level attribute of the standardized data transmission object; assign the processed list of contracting party data and the list of payment plan data to the corresponding sub-table attributes in the standardized data transmission object; assign the generated change history data package to the dedicated attribute in the standardized data transmission object used to carry change information, and perform a data type compatibility check.

[0094] In this embodiment, the converted main table data, the processed sub-table data, and change records are synchronized according to the data structure of the target system in the following manner:

[0095] The standardized data transmission object, assembled through the standard data interface provided by the target system, is pushed via HTTP request or message queue. After receiving the data, the target system determines whether to perform an add or update operation based on the contract number, verifies and persists the received data, and returns the synchronization result. The source system updates the synchronization status based on the synchronization result and records the synchronization log.

[0096] Example 2

[0097] Exemplary embodiment 2 of the present invention provides a method for bidirectional synchronization and field mapping of contract data across multiple systems. The method of this embodiment is implemented in the following manner:

[0098] I. Construction of Static Field Mapping Table

[0099] When the system starts, a static field mapping table is loaded. This table defines the correspondence between source system field names and target system field names, and includes the following types of field mappings:

[0100] Date fields: such as contract start date, end date, signing date, etc.;

[0101] Amount fields: such as contract amount, amount including tax, amount excluding tax, etc.;

[0102] Status fields: such as whether a warranty deposit is involved, whether a performance bond is involved, etc.

[0103] Text fields: such as contract performance location, acceptance terms, warranty terms, etc.;

[0104] Fields related to payment collection: such as payment collection node, payment collection conditions, payment period days, payment collection ratio, etc.

[0105] II. Analysis of the Extended Data Model

[0106] The contract object contains extended data model information. By calling the retrieve method of the extended data model, the key-value pair data of the dynamic form fields can be obtained. The parsing process includes: obtaining the extended data model object, calling the model data retrieval method to obtain the field mapping, traversing the field mapping, and processing it according to the field type. For nested object types, the internal fields are parsed recursively; for list types, the list elements are traversed and processed one by one.

[0107] III. Processing of Contractor Data

[0108] The contracting party data is stored in a relational table and retrieved through relational queries. The processing flow includes: querying the contracting party list based on the contract primary key; traversing the contracting party records and extracting basic information; setting type identifiers based on the contracting party type (Party A, Party B, Party C, Party D, Party E); querying the contracting party details to obtain information such as the taxpayer identification number; querying internal entity information to obtain information such as the legal representative; and assembling the contracting party data object.

[0109] IV. Handling of the Collection Plan

[0110] The payment collection plan data is stored in a list field of the extended data model. The processing flow includes: retrieving the payment collection plan list from the extended data model; traversing the payment collection plan records and extracting the values ​​of each field; performing field name conversion; processing the formatting of numeric types such as amount and percentage; and assembling the payment collection plan data object list.

[0111] V. Tracking of Change Records

[0112] In this embodiment, the change record tracking process includes: querying historical change records of the contract and sorting them in reverse chronological order; obtaining the form data of the latest change; obtaining the change field configuration list; traversing the change fields and comparing the values ​​before and after the change; converting enumeration type fields to enumeration values; recording the changed field information, processing changes to the detail table (addition, modification, deletion), and assembling the change record data structure.

[0113] VI. Processing of Attachment Data

[0114] In this embodiment, the attachment data is classified and processed according to the business type in the following manner:

[0115] Contract text attachments: Type identifier 1

[0116] Contract scan: Type identifier is 2

[0117] Document attachments with official seal: Type identifier 3

[0118] Protocol text file: Type identifier is 4

[0119] Internal company decision-making documents: Type identifier 5

[0120] Other related files: type identifier is 6

[0121] Example 3

[0122] Exemplary embodiment 3 of the present invention provides a method for bidirectional synchronization and field mapping of contract data across multiple systems. Figure 5 This is an example diagram illustrating the technical principle of the multi-system bidirectional synchronization and field mapping method for contract data according to Exemplary Embodiment 3 of the present invention, as shown below. Figure 5As shown, this embodiment takes a real-world application scenario as an example, involving synchronizing contract data from the OA system to the contract management system and realizing two-way change tracking, further explaining the method of two-way synchronization and field mapping of contract data across multiple systems.

[0123] I. System Initialization and Mapping Configuration

[0124] During system startup or service initialization, a static field mapping table is loaded first. This mapping table is stored in memory using a hash table data structure, and can be defined in JSON format, with an example of key-value pairs as follows:

[0125] json

[0126] {

[0127] "fd_cct_startTime_value": "contractStartDate",

[0128] "cttAmount": "contractAmount",

[0129] "fd_is_guarantee": "hasGuaranteeDeposit",

[0130] "fd_payment_node": "paymentNode"

[0131] }

[0132] This mapping table covers field types such as date, amount, status, text, and payment receipt. Additionally, the system includes a pre-configured list of fields for contract change tracking, clearly defining the fields that need to be monitored.

[0133] II. Source System Data Acquisition and Analysis

[0134] When a synchronous task is triggered (such as a scheduled task or a manual trigger), the system retrieves the basic contract data that meets the conditions from the main contract table in the OA system database, including the contract number, contract name, and signing date, based on the input query conditions.

[0135] For each contract, the system further calls the extended data model interface provided by the OA system to obtain the dynamic form data associated with that contract. For example, a procurement contract may contain dynamic extended fields such as "Special Delivery Terms" and "Technical Standard Annex". The system parses this extended data model to obtain a mapping set containing all field names and field values. For nested structures (such as "Receiving Address" being a sub-object containing province, city, and detailed address) or list structures (such as "Acceptance Standard List"), the system uses a recursive algorithm for depth-first traversal to ensure the extraction of complete hierarchical data.

[0136] III. Field Conversion and Sub-table Data Processing

[0137] Main table and extended field conversion: The system iterates through each field (including main table fields and extended fields) obtained from the OA system. For the field name fd_cct_startTime_value, after querying the static mapping table, it is converted into the field name contractStartDate recognized by the target contract management system. For the field value, if it is a date type (such as 1640995200000), it is formatted as the standard date string "2022-01-01"; if it is an enumeration type (such as a status field value of "1"), it is converted into the corresponding semantic description "approved".

[0138] Contractor Sub-Table Processing: Based on the contract number, the system queries the contractor association table in the OA system to obtain a list of contractors for that contract. It iterates through this list, extracting information such as "Entity Name" and "Contact Number" for each contractor. Based on the contractor's role in the contract (e.g., "Buyer" or "Seller"), it maps them to standardized type identifiers (e.g., "Party A" or "Party B"). Subsequently, the system further queries the "Counterparty Information Database" or "Internal Organizational Structure Database" to obtain supplementary legal and authorized identification information such as "Legal Representative" and "Unified Social Credit Code" for each contractor. Finally, each contractor is encapsulated as a structured data object, and all contractor objects form a list.

[0139] Processing the Payment Repayment Plan Sub-table: The system locates the "Payment Repayment Plan" list field from the extended data model. It iterates through this list, extracting the core performance elements of each plan entry, including specific information such as "First Payment," "30 days after acceptance of goods," "30," "0.5," and "500000." The system maps and transforms these field names and formats the values ​​(e.g., the amount is formatted as 500000.00). Simultaneously, by comparing the extracted payment repayment plans with existing plans in the target system, the system accurately identifies entries that need to be added, modified, or deleted, and marks the corresponding operation type (INSERT, UPDATE, DELETE) in the data object.

[0140] IV. Change History Tracking and Recording: The system queries the operation log table of the contract in the OA system, retrieving all historical change records in reverse chronological order. By comparing the latest version of the data with the data snapshot saved during the last synchronization, a field-by-field difference analysis is performed. For example, if the "Contract Amount" field changes from 1,000,000 to 1,200,000, the system records the field's identifier, the value before the change, the value after the change, and the change time. For the payment plan sub-table, the system compares the unique ID list and records any newly added payment plan as "new" for that sub-table data. All these change details are integrated to generate a structured change record data package, including a change summary and details.

[0141] V. Data Assembly and Synchronization Push: The system creates a JSON data object conforming to the contract management system API specification. The converted main table fields (e.g., `contractStartDate: "2022-01-01"`) are placed at the top level. The processed list of signatories and payment plans are filled into the `signatories` and `paymentPlans` fields, respectively. The change record data package is filled into the `changeHistory` field. In addition, the system queries and appends a list of uploaded contract attachments, indicating the type of each attachment (e.g., "Contract Text").

[0142] After assembly, the system pushes the JSON data object to the "Contract Data Synchronization Interface" provided by the contract management system via an HTTP POST request. Upon receiving the data, the contract management system determines the data based on the contract number: if the number does not exist, it performs an add operation; if it exists, it performs an update operation, and persists the changes to the sub-table data (such as adding a payment plan) to the database within the transaction. After synchronization is complete, the contract management system returns a success response, and the source system updates the synchronization status and timestamp of the contract.

[0143] The method of this invention has the following beneficial technical effects in practical applications:

[0144] 1. Significantly reduces system integration development and long-term maintenance costs.

[0145] By introducing a static field mapping table, the correspondence between heterogeneous field names across different business systems is predefined and managed through configuration. During data transformation, the system automatically completes the field name mapping by querying this mapping table, thus avoiding the traditional practice of writing hard-coded transformation logic for each field. When the data model of the source or target system changes (such as adding, renaming, or deleting fields), only the mapping table configuration needs to be updated, without modifying the program source code. This greatly reduces the need to modify the code of the synchronization program itself, shortens the development cycle, and significantly reduces the long-term maintenance complexity and cost caused by system iteration and upgrades.

[0146] 2. Fully supports accurate synchronization of complex nested data structures.

[0147] Addressing the complex, multi-layered structure of contract data—comprising main table information, a list of contracting parties, payment plans, and performance details—this approach utilizes recursive parsing and sub-table processing mechanisms to automatically identify and traverse the hierarchical relationships within the data. It independently and structurally extracts, transforms, and assembles data from each sub-table (e.g., contracting party bank account information, and detailed entries of the payment plan). This ensures that the original hierarchical structure and business relationships are fully preserved during synchronization, effectively avoiding common problems in traditional synchronization methods such as sub-table data loss, structural flattening, or disordered relationships, thus guaranteeing the semantic integrity of the business data.

[0148] 3. Flexibly adapt to dynamic business changes and expand fields

[0149] By extending the data model parsing, dynamic form fields in contract templates can be automatically identified and processed. Whether these extended fields are text, date, numeric, dropdown options, or more complex object and list types, their key-value pairs can be obtained through a unified parsing process. When businesses adjust contract templates or add or remove custom fields according to business needs, the synchronization program does not require writing or modifying processing code for each specific extended field. It can adaptively handle new field structures and quickly respond to dynamic changes in business requirements.

[0150] 4. Enable refined change history tracking and data traceability

[0151] Through an integrated change tracking mechanism, every data change to a contract throughout its lifecycle can be accurately recorded. This mechanism operates at the field level, capturing information such as the specific field identifier that changed, the values ​​before and after the change, the change time, and the person responsible for the change. For sub-tables such as contracting parties and payment plans, it can also track the addition, modification, and deletion of entries. All change information is structured and recorded, forming a complete audit trail. This not only meets the stringent requirements of internal auditing and compliance management but also provides reliable and detailed data traceability for business analysis, risk monitoring, and dispute resolution.

[0152] 5. Ensure high data consistency across multiple systems.

[0153] By standardizing field mapping, completing structural processing, and accurately synchronizing changes, a unified and reliable data conversion and synchronization process has been established. Consistent rules and verifications are used in all stages from data extraction and conversion to loading, reducing the risk of data errors or omissions caused by manual intervention, mapping mistakes, or program defects. This process can maintain long-term consistency of the status of core contract data and related data across multiple heterogeneous systems such as OA, ERP, and contract management systems.

[0154] 6. Improve system integration efficiency and collaborative work capabilities

[0155] By defining standardized data transmission objects and synchronization interfaces, the complex process of integrating data from multiple systems is standardized and templated. Each related system only needs to interact according to the agreed-upon data format to achieve automatic data synchronization, simplifying the development of inter-system interfaces. This significantly improves the overall efficiency of system integration and promotes collaborative work among different business departments based on consistent, real-time contract data.

[0156] like Figure 6 As shown, the present invention also provides a device including a processor 310, a communication interface 320, a memory 330 for storing processor-executable computer programs, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the aforementioned method for multi-system bidirectional synchronization and field mapping of contract data.

[0157] The computer program in memory 330, when implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0158] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected based on actual needs to achieve the purpose of this embodiment. Those skilled in the art can understand and implement this without any creative effort.

[0159] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0160] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for bidirectional synchronization and field mapping of contract data across multiple systems, characterized in that, The method includes: Step S1: Standardize field naming for different systems by building and loading a static field mapping table, and obtain the contract master table data and its extended data model information from the source system according to the query conditions; Step S2: Based on the static field mapping table, perform field name conversion and value formatting on the obtained data, and recursively process and track changes in the contract-related contracting party sub-table and payment plan sub-table; Step S3: By comparing historical versions of contract data, identify field-level and sub-table-level change information and generate structured change records; Step S4: Assemble and synchronize the transformed main table data, processed sub-table data, and change records according to the data structure of the target system.

2. The method for multi-system bidirectional synchronization and field mapping of contract data according to claim 1, characterized in that, Step S1 includes: Construct a static field mapping table to store the correspondence between source system field names and target system field names. This static field mapping table uses a key-value pair data structure for storage and is loaded into memory during system initialization. Based on preset query conditions, the basic information of the contract master table is obtained from the source system database. By calling the application programming interface provided by the source system, the extended data model object associated with the contract is obtained. Parse the extended data model object and extract all dynamic form fields defined therein and their corresponding key-value pairs.

3. The method for multi-system bidirectional synchronization and field mapping of contract data according to claim 1, characterized in that, In step S2, the obtained data is processed according to the static field mapping table, including field name conversion and value formatting, including: Iterate through the set of fields in the main table obtained from the source system and the set of dynamic fields in the extended data model; Query the static field mapping table to obtain the target system field name corresponding to each field. If the corresponding target system field name is not found, retain the original field name. Date type fields are uniformly converted to standard date and time formats, numeric type fields are precision controlled and formatted, and enumeration type fields are converted to corresponding enumeration description text.

4. The method for multi-system bidirectional synchronization and field mapping of contract data according to claim 1, characterized in that, In step S2, the contract-related contracting party sub-table is recursively processed and change tracked in the following manner: Based on the contract primary key, retrieve the list of contracting party records from the source system database, iterate through the list of contracting party records, and extract the basic information from each record. Based on the role of each signatory in the contract, a corresponding type identifier is set for each signatory; Legal and authorized identification information can be obtained by querying the contracting party information table or the internal entity information table; The contracting party data is encapsulated into structured objects and formed into a list, while recording the addition, modification, and deletion status of contracting party entries.

5. The method for multi-system bidirectional synchronization and field mapping of contract data according to claim 1, characterized in that, In step S2, the contract-related payment plan sub-table is recursively processed and change tracked as follows: Locate and retrieve the collection plan data list from the parsed extended data model, traverse each entry in the collection plan data list, and extract the collection plan performance element field; Perform a transformation on the extracted field names based on a static field mapping table, and standardize the data types of the extracted field values; Each completed payment collection plan entry is encapsulated as an independent data object and organized into a structured list of payment collection plan data. By comparing the differences in the repayment plan data between the source system and the target system, the add, modify, and delete operations that need to be synchronized can be identified.

6. The method for multi-system bidirectional synchronization and field mapping of contract data according to claim 1, characterized in that, In step S3, field-level and sub-table-level change information is identified as follows: Using the contract number as the query condition, retrieve all historical change records for the contract from the change log table of the source system and sort them in reverse chronological order. Retrieve the complete contract data after the most recent change and compare it field by field with the data snapshot saved before the change; Based on the predefined tracking field configuration, the values ​​of each field before and after the change are compared, and the field identifier, field name, old value, new value and change time are recorded. For the contracting party sub-table and the payment plan sub-table, new entries, deleted entries, and content modification entries are identified by comparing a set of unique identifiers. Integrate field-level change records and sub-table change records into a complete structured change history data package.

7. The method for multi-system bidirectional synchronization and field mapping of contract data according to claim 1, characterized in that, The method also includes processing contract attachment data in the following manner: when acquiring contract data, simultaneously query all attachment information associated with the contract, set a type identifier for each attachment according to the attachment business type, extract the basic information of each attachment, and integrate the attachment data with type identifier and basic information into the final data transmission object.

8. The method for multi-system bidirectional synchronization and field mapping of contract data according to claim 1, characterized in that, In step S4, the transformed main table data, processed sub-table data, and change records are assembled according to the target system's data structure in the following manner: Create a standardized data transfer object that conforms to the target system interface specification, and map the transformed and formatted main table field data to the top-level property of the standardized data transfer object; Assign the processed list of contracting parties and the list of payment plans to the corresponding sub-table attributes in the standardized data transmission object; The generated change history data packet is assigned to a dedicated attribute in the standardized data transmission object used to carry change information, and a data type compatibility check is performed.

9. The method for multi-system bidirectional synchronization and field mapping of contract data according to claim 1, characterized in that, In step S4, the transformed master table data, processed sub-table data, and change records are synchronized according to the target system's data structure in the following manner: The assembled standardized data transmission object is pushed via HTTP request or message queue through the standard data interface provided by the target system. After receiving the data, the target system determines whether to perform an add or update operation based on the contract number, verifies and persists the received data, and returns the synchronization result. The source system updates the synchronization status based on the synchronization results and records the synchronization log.

10. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method according to any one of claims 1-9.

Images