Batch change method and system based on teamcenter

Abstract

The application relates to the technical field of batch change and discloses a batch change method and system based on Teamcenter. The method comprises the following steps: inputting a parent material code, a parent material name, a child material code and a child material name input by a user into a Teamcenter database to perform parallel query, obtaining a candidate BOM data set and splitting the candidate BOM data set into a changeable subset and a locked subset, mounting the changeable subset to a target relationship node, performing accurate matching existence verification on a material code to be operated, performing conflict comparison verification on the material code to be operated and a change operation record table, writing an operation type, a parent material code, a parent material version, a parent material name, a material code and a material name into the change operation record table after the two verifications are passed, and completing batch change. The application realizes strong association of change execution records and ECR version objects, and ensures that each batch change operation can be traced back to specific execution actions and execution objects.

Description

Technical Field

[0001] This invention relates to the field of batch change technology, and in particular to a batch change method and system based on Teamcenter. Background Technology

[0002] In the field of enterprise product lifecycle management, engineering change management is a core business process for controlling changes to product design, bill of materials, and process specifications. Teamcenter, as a mainstream PLM platform, is responsible for the unified management of product data, and its change management module is responsible for coordinating the entire process from change request to change execution.

[0003] However, in batch change scenarios involving multiple parent materials and multiple child materials, the existing Teamcenter system lacks a structured batch data processing mechanism. When performing batch changes, it is necessary to manually navigate to the target BOM item by item. It is not possible to simultaneously search and locate the change objects in batches using multi-dimensional conditions such as parent material code, parent material name, child material code, and child material name, resulting in low operational efficiency. Summary of the Invention

[0004] The main objective of this invention is to provide a batch change method and system based on Teamcenter. This invention defines four array attributes on the ECR version object: parent material code, parent material name, child material code, and child material name. This enables four-way parallel querying and deduplication of BOM data in the Teamcenter database. By combining multi-dimensional conditions, it can locate the target BOM for changes across product structures in one batch, replacing the inefficient operation mode of manual navigation one by one in the prior art. This achieves a strong association between change execution records and ECR version objects, ensuring that each batch change operation can be traced back to the specific execution action and execution object.

[0005] To achieve the above objectives, this invention provides a batch change method based on Teamcenter, comprising the following steps:

[0006] Input the parent material code, parent material name, child material code, and child material name into the Teamcenter database and perform a parallel query to obtain a candidate BOM data set;

[0007] The candidate BOM data set is split into a changeable subset and a locked subset, and the changeable subset is attached to the target relationship node, while the locked subset is attached to the associated changeable data relationship node.

[0008] Based on the target relationship node, an exact match existence check is performed on the material code to be operated, and a conflict comparison check is performed on the material code to be operated and the change operation record table. After both checks pass, the operation type, parent material code, parent material version, parent material name, material code, and material name are written into the change operation record table line by line to complete the batch change.

[0009] Optionally, in a first implementation of the first aspect of the present invention, the parent material code, parent material name, child material code, and child material name input by the user are entered into the Teamcenter database for parallel querying to obtain a candidate BOM data set, including:

[0010] Based on the parent material code values ​​stored in the parent material code array attribute, queries are performed on the parent material code and parent material name of the BOM data record in the Teamcenter database to obtain the first query result and the second query result.

[0011] Based on the sub-material code values ​​stored in the sub-material code array attribute, queries are performed on the sub-material codes and sub-material names of the BOM data records in the Teamcenter database to obtain the third and fourth query results.

[0012] The first query result, the second query result, the third query result, and the fourth query result are merged and deduplicated to obtain a candidate BOM data set.

[0013] Optionally, in a second implementation of the first aspect of the present invention, the first query result, the second query result, the third query result, and the fourth query result are merged and deduplication is performed to obtain a candidate BOM data set, including:

[0014] All BOM data records from the first query result, the second query result, the third query result, and the fourth query result are merged into a comprehensive BOM data set;

[0015] The unique identifier of each BOM data record in the Teamcenter database is used as the key to perform deduplication, resulting in a candidate BOM data set.

[0016] Optionally, in a third implementation of the first aspect of the present invention, the candidate BOM data set is split into a mutable subset and a locked subset, and the mutable subset is attached to the target relation node, and the locked subset is attached to the associated modified data relation node, including:

[0017] For each BOM data record in the candidate BOM data set, retrieve the association relationships between each BOM data record in the Teamcenter database and the ECR object, as well as with the ECN object;

[0018] BOM data records that are not associated with any ECR or ECN object are classified into the changeable subset, and BOM data records that are associated with at least one ECR or ECN object are classified into the locked subset.

[0019] Read the stored value of the change action attribute on the ECR version object, mount the changeable subset to the target relationship node according to the stored value, and mount the locked subset to the associated change data relationship node.

[0020] Optionally, in the fourth implementation of the first aspect of the present invention, for each BOM data record in the candidate BOM data set, the association relationships between each BOM data record in the Teamcenter database and the ECR object and the ECN object are retrieved one by one, including:

[0021] Perform a search on each BOM data record in the candidate BOM data set in the ECR object association table and ECN object association table of the Teamcenter database respectively, and obtain the ECR association search results and ECN association search results for each BOM data record;

[0022] When both the ECR and ECN related search results are empty, the association relationship of the corresponding BOM data record is marked as unrelated; when there is at least one record in either the ECR or ECN related search results, the association relationship of the corresponding BOM data record is marked as related.

[0023] Optionally, in the fifth implementation of the first aspect of the present invention, reading the stored value of the change action attribute on the ECR version object, mounting the mutable subset to the target relationship node according to the stored value, and mounting the locked subset to the associated change data relationship node include:

[0024] Read the stored value of the change action attribute on the ECR version object, and determine the target relationship node according to the matching relationship between the stored value and the actual value of the change action;

[0025] All BOM data records in the modifiable subset are attached to the target relationship node, and all BOM data records in the locked subset are attached to the associated modified data relationship node.

[0026] Optionally, in the sixth implementation of the first aspect of the present invention, based on the target relationship node, an exact match existence check is performed on the material code to be operated, and a conflict comparison check is performed on the material code to be operated and the change operation record table. After both checks pass, the operation type, parent material code, parent material version, parent material name, material code, and material name are written line by line into the change operation record table to complete the batch change, including:

[0027] The first-level BOM row data of each BOM data record under the target relationship node is traversed, an exact match existence check is performed on the material code to be operated, and a conflict comparison check is performed on the material code to be operated and the change operation record table.

[0028] After both verifications pass, the number of rows to be written is determined according to the target relationship node, and the operation type, parent material code, parent material version, parent material name, material code, and material name are written to the change operation record table line by line to complete the batch change.

[0029] Optionally, in the seventh implementation of the first aspect of the present invention, the first-level BOM row data of each BOM data record under the target relationship node is traversed, an exact match existence check is performed on the material code to be operated, and a conflict comparison check is performed between the material code to be operated and the change operation record table, including:

[0030] The first-level BOM row data of each BOM data record under the target relationship node is traversed, and an exact match search is performed one by one with the material code to be operated as the matching key value. When the first level of all BOM data records under the target relationship node finds BOM row data that matches the material code to be operated, the existence check is confirmed to be successful.

[0031] Read all existing codes stored in the material code attribute column of the change operation record table. Using the material code to be operated as the comparison key, perform string exact matching comparison on all existing codes one by one. When there is no existing code that matches the material code to be operated, the conflict comparison verification is determined to be successful.

[0032] Optionally, in the eighth implementation of the first aspect of the present invention, after both checks pass, the number of rows to be written is determined according to the target relationship node, and the operation type, parent material code, parent material version, parent material name, material code, and material name are written line by line into the change operation record table to complete the batch change, including:

[0033] After both checks pass, the number of BOM data objects attached to the target relationship node and the number of materials to be operated on are counted, and the number of write lines is determined by the product of the number of BOM data objects and the number of materials to be operated on.

[0034] Based on the number of rows written, and in the order of combination between each BOM data record under the target relationship node and each material to be operated, the operation type, parent material code, parent material version, parent material name, material code, and material name are written line by line into the change operation record table to complete the batch change.

[0035] This invention also provides a batch change system based on Teamcenter, comprising:

[0036] The parallel query module is used to input the parent material code, parent material name, child material code, and child material name into the Teamcenter database and perform parallel queries to obtain a set of candidate BOM data.

[0037] The subset splitting module is used to split the candidate BOM data set into a mutable subset and a locked subset, and to attach the mutable subset to the target relationship node and the locked subset to the associated changed data relationship node;

[0038] The batch change module is used to perform an exact match existence check on the material code to be operated based on the target relationship node, and to perform a conflict comparison check on the material code to be operated and the change operation record table. After both checks pass, the operation type, parent material code, parent material version, parent material name, material code, and material name are written into the change operation record table line by line to complete the batch change.

[0039] In summary, this invention achieves four-way parallel querying and deduplication of BOM data in the Teamcenter database by defining four array attributes—parent material code, parent material name, child material code, and child material name—on the ECR version object. It uses multi-dimensional condition combinations to locate cross-product structure change target BOMs in a single batch, replacing the inefficient manual navigation of existing technologies. After constructing the candidate BOM data set, the system automatically splits the candidate set into mutable and locked subsets by retrieving the association status of each BOM data record with the ECR and ECN objects. This isolates BOM data already occupied by other change processes at the data level, fundamentally eliminating the risk of concurrent change conflicts. Furthermore, the system reads the stored values ​​of change action attributes and accurately mounts the mutable subsets to six target relationship nodes—delete, replace, add, replace get, replace delete, and change attribute—accurately classifying and storing change intentions according to six-branch conditional logic. Before executing the write operation, the system sequentially performs an exact match existence check on the first level of the target BOM for the material code to be operated, and a conflict comparison check on the material code attribute column of the change operation record table. These two verification mechanisms jointly ensure the accuracy and uniqueness of the change data. After the verification passes, the system determines the number of rows to be written based on the product of the number of BOM data objects and the number of materials to be operated. The operation type, parent material code, parent material version, parent material name, material code, and material name are then structured and written row by row into the change operation record table. This achieves a strong association between the change execution record and the ECR version object, ensuring that each batch change operation can be traced back to the specific execution action and execution object. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the steps of a batch change method based on Teamcenter in one embodiment of the present invention;

[0041] Figure 2 This is a schematic diagram of the BOM batch change query and change operation interface in an embodiment of the present invention;

[0042] Figure 3 This is a schematic diagram of the operation interface for a scenario where batch changes are rejected and then resubmitted, as described in an embodiment of the present invention.

[0043] Figure 4 This is a schematic diagram illustrating the changes to the ECR and ECN object structures and their derivation relationships during the mass production stage in this embodiment of the invention.

[0044] Figure 5 This is a schematic diagram of the scenario structure for creating an ECR (Electronic Change Response) to unify the change requirements of multiple departments during the mass production stage in an embodiment of the present invention.

[0045] Figure 6This is a block diagram of the batch change system based on Teamcenter in an embodiment of the present invention.

[0046] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0048] Reference Figure 1 This embodiment provides a batch change method based on Teamcenter, including the following steps:

[0049] S1: Input the parent material code, parent material name, child material code, and child material name entered by the user into the Teamcenter database and perform a parallel query to obtain a candidate BOM data set;

[0050] S2, split the candidate BOM data set into a mutable subset and a locked subset, and attach the mutable subset to the target relationship node, and attach the locked subset to the associated mutable data relationship node;

[0051] S3. Based on the target relationship node, perform an exact match existence check on the material code to be operated and perform a conflict comparison check between the material code to be operated and the change operation record table. After both checks pass, write the operation type, parent material code, parent material version, parent material name, material code, and material name into the change operation record table line by line to complete the batch change.

[0052] In one example, the user-inputted parent material code, parent material name, child material code, and child material name are entered into the Teamcenter database to perform a parallel query, resulting in a candidate BOM data set, including:

[0053] Based on the parent material code values ​​stored in the parent material code array attribute, queries are performed on the parent material code and parent material name of the BOM data record in the Teamcenter database to obtain the first query result and the second query result.

[0054] Based on the sub-material code values ​​stored in the sub-material code array attribute, queries are performed on the sub-material codes and sub-material names of the BOM data records in the Teamcenter database to obtain the third and fourth query results.

[0055] The results of the first, second, third, and fourth queries are merged and deduplicated to obtain a candidate BOM data set.

[0056] In this example, the system reads the parent material code array attribute lf2_FID (a set of entries used to store multiple parent material codes entered by the user to limit the search scope of the parent level; typically, it takes multiple rows of code values ​​pasted from Excel) and the child material code array attribute lf2_ZID (a set of entries used to store multiple child material codes entered by the user to limit the search scope of the child level; typically, it takes multiple rows of code values) from the ECR version object. After reading the above array attributes, each parent material code value stored in the parent material code array attribute lf2_FID is retrieved sequentially to construct a matching query condition for the parent material code field of the BOM data record in the Teamcenter database, and then sent to the database. The database sends a query request and obtains the first query result R1 (the first query result R1, in units of "records", is used to store the set of BOM data records that precisely match the parent material code field with each code in the array attribute lf2_FID, typically a set of several BOM object identifiers). At the same time, based on the parent material code values ​​in the same parent material code array attribute lf2_FID, matching query conditions for the parent material name field in the BOM data records are constructed synchronously, and name field retrieval is performed to obtain the second query result R2 (the second query result R2, in units of "records", is used to store the set of BOM data records that match the names corresponding to each code in the array attribute lf2_FID, typically a set of several BOM object identifiers). The above two queries are initiated in parallel within the same transaction cycle to improve retrieval efficiency. The above processing logic is repeated for each sub-material code value in the array attribute lf2_ZID. For the sub-material code field of the BOM data record, an exact match condition is constructed and a search is performed to obtain the third query result R3 (the third query result R3, in units of "records", is used to store the set of BOM data records whose sub-material code field exactly matches each code in the array attribute lf2_ZID; typically, it is a set of several BOM object identifiers). For the sub-material name field of the BOM data record, a name match condition is constructed and a search is performed to obtain the fourth query result R4 (the fourth query result R4, in units of "records", is used to store the set of BOM data records whose sub-material name field matches the name corresponding to each code in the array attribute lf2_ZID; typically, it is a set of several BOM object identifiers). At the database level, four independent query result sets R1, R2, R3, and R4 are formed.After completing the four-way queries, R1, R2, R3, and R4 are merged to construct a unified temporary set S0 (temporary set S0, in units of "items", used to hold the union data set of the four-way query results, typically the combination result of R1∪R2∪R3∪R4). During the merging process, the unique identifier UID of the BOM data record (unique identifier UID, in units of "strings", used to distinguish different BOM object instances, typically the Teamcenter object UID encoding) is used as the deduplication key to perform deduplication on the temporary set S0. The deduplication result is formally represented as S=Unique(R1∪R2∪R3∪R4), where S (candidate BOM data set S, unit is "records", used as the basic data set for change action determination and relationship mounting, typically a set of BOM objects without duplicate UIDs) and Unique represents the unique operation based on UID, ensuring that even if the same BOM data record is retrieved repeatedly in multi-way queries, it is only retained once in set S, avoiding the risk of duplicate mounting or duplicate table writing due to duplicate objects in the change process.

[0057] Figure 2This is a schematic diagram of the operation interface for the BOM batch change function in the Teamcenter-based batch change method of this invention. The top of the interface is the "Query Conditions" area, which has five input boxes for query conditions: Parent Level Number (current input value is "46901*", wildcard fuzzy search is supported), Parent Level Name, Child Level Number, Child Level Name, and Old Material Number. Users can initiate a BOM data query to the Teamcenter database by filling in the above conditions. The middle of the interface is the "Change Operation" area, which has a "Add Operation" button and a change type drop-down box (currently "Replace"), as well as input fields for change parameters such as data before modification (current input value is "45304-000067"), data after modification (current input value is "45304-000068"), usage, attribute name, and attribute value. The left and right columns correspond to the material attribute information before and after replacement, respectively. The lower part of the interface is the "Data Display" area, presenting the query results in a table format. The table header includes columns for parent material code, parent material name, parent version number, child material code, child material name, child version number, search number, usage, base quantity, and loss. Currently, five BOM data records are displayed, with the first two records checked (parent material codes are 46901-000062 and 46901-000063 respectively, child material codes are both 45304-000068, and child material names are both safety capacitors). "OK" and "Cancel" buttons are located in the lower right corner of the interface. The operation scenario is explained as follows: After selecting an ECR object and filtering the data range to be changed according to the change type maintained in the interface, the user clicks the "OK" button. The system automatically creates a new view for the data to be modified through the development function. TBOMVIEW is named and distinguished according to the ECR number.

[0058] Figure 3 This is a schematic diagram of the operation interface in the Teamcenter-based batch change method of this invention, illustrating scenario one (material replacement modification) where the batch change process is rejected and then resubmitted. The overall layout of the interface is shown in the diagram. Figure 2Consistent with previous operations, the parent level number in the top query criteria area retains the input value "46901*" from the previous operation, and the other query criteria fields maintain their previous state. The operation scenario description highlights two key points: First, when ECR reopens the batch change function, the system automatically displays the interface from the previous operation, restoring all query criteria and change operation parameters from the last submission, eliminating the need for user re-entry. Second, when resubmitting, the user only needs to modify the "Modified Data" field, deleting the old material code and entering the new one. In the change operation area in the middle of the interface, the "Pre-Modification Data" field retains its original value "45304-000067," while the "Post-Modification Data" field has been modified by the user to the new value "45304-000069." This field is highlighted with an orange background, clearly indicating the current change position. In the data display area, the first two BOM data records (parent material codes 46901-000062 and 46901-000063) are still checked, while the remaining three records are not checked, and the data content is consistent with... Figure 2 To maintain consistency. In this embodiment, Figure 3 The system demonstrates an interactive design that allows users to resubmit after making only minor modifications to the changed parameters, automatically restoring the previous interface state in the case of a rejected and resubmitted submission.

[0059] In one example, the results of the first, second, third, and fourth queries are merged and deduplicated to obtain a candidate BOM data set, including:

[0060] All BOM data records from the first, second, third, and fourth query results are merged into a comprehensive BOM data set;

[0061] The unique identifier of each BOM data record in the Teamcenter database is used as the key to perform deduplication, resulting in a candidate BOM data set.

[0062] In this example, a comprehensive BOM data set S0 is constructed in memory. The merging process appends all BOM data records from R1, R2, R3, and R4 to set S0 sequentially, ensuring that all BOM objects satisfying any query condition are included in the unified processing scope. Since the same BOM data record may satisfy multiple query paths simultaneously, such as matching both parent and child material code conditions, duplicate instances may appear in the comprehensive BOM data set S0. A key-value mapping structure is constructed using the unique identifier (UID) of each BOM data record in the Teamcenter database as the key. When traversing the comprehensive BOM data set S0, the UID of each BOM data record is written into the key-value index structure. Before writing, it is checked whether the UID already exists in the index structure. If it does not exist, the BOM data record is retained in the new set S; if it already exists, the current duplicate record is discarded, thus achieving deduplication processing using the UID as the key. The deduplication process is formally represented as S = Unique(S0, UID), where Unique represents a unique filtering operation based on the unique identifier UID. This process ensures that any two records in the candidate BOM data set S have different UIDs. It has a UID i ≠UID j This yields a candidate BOM data set.

[0063] In one example, the candidate BOM data set is split into a mutable subset and a locked subset. The mutable subset is attached to the target relationship node, and the locked subset is attached to the associated mutable data relationship node, including:

[0064] For each BOM data record in the candidate BOM data set, retrieve the association relationships between each BOM data record in the Teamcenter database and the ECR object, as well as with the ECN object;

[0065] BOM data records that are not associated with any ECR or ECN object are classified into the changeable subset, and BOM data records that are associated with at least one ECR or ECN object are classified into the locked subset.

[0066] Read the stored value of the change action attribute on the ECR version object, mount the changeable subset to the target relationship node according to the stored value, and mount the locked subset to the associated change data relationship node.

[0067] In this example, the association status of each BOM data record in set S is retrieved one by one. Specifically, the unique identifier (UID) of the BOM data record in the Teamcenter database is used as the query key to check whether the UID has an object association relationship with any ECR object, and simultaneously check whether it has an object association relationship with any ECN object. Both ECR objects (ECR objects, unit: "business object instance", used to represent change requests) and ECN objects (ECN objects, unit: "business object instance", used to represent change notifications) are associated through Teamcenter's relationship type. The system uses associative storage, so during retrieval, it reads the in-degree and out-degree information of the BOM data records in the relation table to determine whether there are relation records pointing to ECR or ECN objects. The association determination function I3(b) can be formally defined (the association determination function I3(b), in "dimensionless" unit, is used to indicate whether BOM data record b has established an association relationship with ECR or ECN, and its typical value is 0 or 1). When I3(b)=0, it means that the BOM data record has not established an association relationship with any ECR or ECN object, and when I3(b)=1, it means that the BOM data record has an association relationship with at least one ECR or ECN object. During the process of traversing the candidate BOM data set S, the set S is split into two mutually exclusive subsets A and B according to the value of I3(b). The changeable subset A (the changeable subset A is in units of "items" and is used to carry the set of BOM objects with I3(b)=0, typically a subset of unlocked BOM objects) contains all BOM data records that satisfy I3(b)=0. The locked subset B (the locked subset B is in units of "items" and is used to carry the set of BOM objects with I3(b)=1, typically a subset of BOM objects that have been occupied by other change processes) contains all BOM data records that satisfy I3(b)=1. This completes the separation of operable data and non-operable data at the system level.Read the change action attribute lf2_ChangeAction from the current ECR version object (the change action attribute lf2_ChangeAction, in "enumerated real values", used to identify the action type branch to which this batch change belongs, typically real values ​​1, 2, 3, 4, 5, or 6), and determine the target relation node R based on the stored real values ​​of this attribute (target relation node R, in "relation type identifier", used to carry the specific relation type attached to this changeable subset A, typically real value 1 corresponds to LF2_REL_SC, real value 2 corresponds to LF2_REL_TH, real value 3 corresponds to LF2_REL_XZ, real value 4 corresponds to LF2_REL_TDHQ, real value 5 corresponds to LF2_REL_TDSC, real value 6 corresponds to LF2_REL_...). After confirming the target relation node R, each BOM data record in the mutable subset A is linked to the ECR version object through the Teamcenter object relation creation interface, establishing a relationship R between the ECR version object and the BOM data record. This ensures that all BOM objects with I3(b)=0 are attached to the target relation node R. Simultaneously, each BOM data record in the locked subset B is linked through the relation type LF2_REL_UnableChange (associated with the changed data relation node LF2_REL_UnableChange, the unit is "relationship type identifier", the purpose is to isolate BOM objects that have been occupied by other change processes), ensuring that all BOM objects with I3(b)=1 are uniformly attached to the associated changed data relation node, forming two logically isolated object set structures at the ECR version object level.

[0068] Figure 4This diagram illustrates the data structure and derivation relationship between ECR (Change Request) and ECN (Change Notification) objects in the mass production phase change management of this invention. The leftmost part of the diagram is labeled "Mass Production Phase Change Requirement" and lists two implemented component numbers: 46604-0000101 / 01 and 46604-0000201 / 01, as the source of this change requirement. The main area of ​​the diagram shows two parallel ECR-ECN derivation chains: the first one at the top, where the ECR object (number 46604-0000101 / 01) has "Components Before Change" relationship nodes (including part 46604-0000101 / 01) and "Components Affected by Change" relationship nodes (including 1HD12-S-CN-WH001 / 01 assembly and 1HD12-S-CN-WH002 / 01 assembly). After the ECR object is "implemented", an ECN object is derived. The ECN object also has three types of relationship nodes: "Components Before Change" (including 46604-0000101 / 01, upgraded to version V01), "Components Affected by Change" (including 1HD12-S-CN-WH001 / 01 assembly), and "Components After Change". The second group below, the ECR object (number 46604-0000201 / 01), carries "Components Before Change" (including 46604-0000201 / 01) and "Components Affected by Change" (including assembly 1HD12-S-CN-WH003 / 01). Similarly, after being "implemented," a corresponding ECN object is derived. The ECN object carries relationship nodes for "Components Before Change" (including 46604-0000201 / 01), "Components Affected by Change" (including assembly 1HD12-S-CN-WH003 / 01), and "Components After Change." In this embodiment, Figure 4 It clearly presents the standard correspondence structure in the mass production stage: one change requirement corresponds to one ECR, and one ECR derives one ECN. It also shows the data mounting mode of three types of relationship nodes on the ECR and ECN objects: pre-change components, change-affected components, and post-change components.

[0069] Figure 5This diagram illustrates the complete scenario structure for creating ECR objects after multiple departmental change requests are evaluated and integrated by a unified management department (dedicated personnel) during the mass production phase change management of this invention. The leftmost side of the diagram shows the source side of each department's change request, listing three component numbers to be changed: 46604-0000101 / 01, 46604-0000201 / 01, and 46604-0000301 / 01, with the instruction "After passing the review and screening, the department personnel create the ECR on the TC" marked. The top of the diagram displays the product BOM structure tree, with five top-level assembly nodes (assemblies 1HD12-S-CN-WH001 / 01 to WH005 / 01). Each assembly has multiple layers of sub-parts attached (such as 46604-0001001 / 01, the parent node of 46604-0001001 / 01, D46604-0000101 / 01, etc.), forming a complex multi-layered BOM relationship network, serving as background data for the scope of change impact. A note box in the center of the diagram indicates the instruction: "TC internally provides advance notification to analyze the current situation; complete relevant information before creating an ECR file application." The main area of ​​the diagram shows the integrated structure of three ECR objects created after assessment by specialists: the first ECR (46604-0000101 / 01) has three types of relationship nodes attached: "Components before the change" (including 46604-0000101 / 01), "Components affected by the change" (including 1HD12-S-CN-WH001 / 01 assembly and 1HD12-S-CN-WH002 / 01 assembly), and "Reference Materials" (including related document 1.xlsx, related document 2.pptx, and related document 3.pdf); the second ECR Under (46604-0000201 / 01), the nodes "Components Before Change" (including 46604-0000201 / 01), "Components Affected by Change" (including 1HD12-S-CN-WH004 / 01 assembly), and the "Reference Materials" node of the same structure are attached; under the third ECR (46604-0000301 / 01), the nodes "Components Before Change" (including 46604-0000301 / 01), "Components Affected by Change" (including 1HD12-S-CN-WH005 / 01 assembly), and the "Reference Materials" node are attached. The annotation in the lower right corner of the figure explains: Providing documents during the preliminary review stage is crucial for the current change document approval; uploading reference documents in advance facilitates the smooth progress of the change document approval process. In this embodiment, Figure 5 The core implementation scenario of the unified management mechanism in the mass production stage is demonstrated: dedicated personnel reasonably break down the change requirements of multiple departments into multiple independent ECR objects. Each ECR object independently carries its own pre-change components, change-affected components, and reference materials, ensuring that the change intent is clear and traceable.

[0070] In one example, for each BOM data record in the candidate BOM dataset, the association relationships between each BOM data record in the Teamcenter database and the ECR object, as well as with the ECN object, are retrieved one by one, including:

[0071] Perform a search on each BOM data record in the candidate BOM data set in the ECR object association table and ECN object association table of the Teamcenter database respectively, and obtain the ECR association search results and ECN association search results for each BOM data record;

[0072] When both the ECR and ECN related search results are empty, the relationship between the corresponding BOM data records is marked as unrelated; when there is at least one record in either the ECR or ECN related search results, the relationship between the corresponding BOM data records is marked as related.

[0073] In this example, the association status retrieval operation is performed sequentially on each BOM data record b (BOM data record b, the unit is "object instance", the purpose is to represent a single BOM object to be determined) in set S. That is, the unique identifier UID of the BOM data record in the Teamcenter database is read, and the ECR object association table and ECN object association table in the Teamcenter database are accessed respectively using UID as the search condition. The ECR object association table is used to search for whether there is a relationship record between UID as the association endpoint and any ECR object, and the ECN object association table is used to search for whether there is a relationship record between UID as the association endpoint and any ECN object. Executing a query in the ECR object association table yields ECR association retrieval result R5 (ECR association retrieval result R5, unit is "records", used to represent the set of associated records between the current BOM data record b and the ECR object, typically taking the value of 0 or more records). Executing a query in the ECN object association table yields ECN association retrieval result R6 (ECN association retrieval result R6, unit is "records", used to represent the set of associated records between the current BOM data record b and the ECN object, typically taking the value of 0 or more records). The number of records in R5 and R6 is determined, and an association status identifier I4(b) is defined (association status identifier I4(b), unit is "dimensionless", used to mark whether the current BOM data record b has an association relationship with ECR or ECN, typically taking the value of 0 or 1). When R5 is empty and R6 is empty, i.e., R5 = ... And R6= When I4(b) = 0, the association relationship of the BOM data record is marked as "no association", indicating that the BOM object is not currently occupied by any change request or change notification; when there is at least one record in R5 or at least one record in R6, i.e., R5 ≠ Or R6≠ When I4(b) = 1, the association relationship of the BOM data record is marked as "related", indicating that the BOM object has participated in at least one ongoing or historical change process. By sequentially performing dual-table retrieval and status determination logic on each BOM data record in the candidate BOM data set S, an association status label is established for each BOM object.

[0074] In one example, the stored value of the change action attribute on the ECR version object is read, and the changeable subset is mounted to the target relationship node according to the stored value. The locked subset is mounted to the associated change data relationship node, including:

[0075] Read the stored value of the change action attribute on the ECR version object, and determine the target relationship node according to the matching relationship between the stored value and the actual value of the change action;

[0076] Mount all BOM data records in the mutable subset to the target relationship node, and mount all BOM data records in the locked subset to the associated mutable data relationship node.

[0077] In this example, the current stored value v of the change action attribute lf2_ChangeAction is read from the ECR version object (stored value v, unit is "enumerated real value", used to represent the change action type selected by the user on the interface, typically 1, 2, 3, 4, 5 or 6). Based on the pre-configured real value mapping relationship, the stored value v is matched with the set of change action real values ​​to determine the target relationship node R required for this mounting (target relationship node R, unit is "relationship type identifier", used as the mounting bearer node for the changeable subset A, typically LF2_REL_SC, LF2_REL_TH, LF2_REL_XZ, LF2_REL_TDHQ, LF2_REL_TDSC or LF2_REL_XG). Specifically, when v=1, R=LF2_REL_SC (LF2_REL_SC, unit is "relationship type identifier", used to bear the BOM data record corresponding to the deletion action); when v=2, R=LF2_REL_SC is determined to be the target relationship node for this mounting. =LF2_REL_TH (LF2_REL_TH, unit is "relationship type identifier", used to carry the BOM data record corresponding to the replacement action), when v=3, R=LF2_REL_XZ (LF2_REL_XZ, unit is "relationship type identifier", used to carry the BOM data record corresponding to the add action), when v=4, R=LF2_REL_TDHQ (LF2_REL_TDHQ, unit is "relationship type identifier", used to carry the BOM data record corresponding to the substitute get action), when v=5, R=LF2_REL_TDSC (LF2_REL_TDSC, unit is "relationship type identifier", used to carry the BOM data record corresponding to the substitute delete action), when v=6, R=LF2_REL_XG (LF2_REL_XG, unit is "relationship type identifier", used to carry the BOM data record corresponding to the change attribute action), thus forming a one-to-one structured binding between the change action selection and the relationship node carrying.After the target relationship node R is determined, the Teamcenter object relationship creation interface is called. Using the current ECR version object as the source object and each BOM data record in the mutable subset A as the target object, a relationship of type R is created for each record. This completely mounts all BOM data records in the mutable subset A to the target relationship node R and forms a visible relationship node data list in the ECR version interface. At the same time, the object relationship creation interface is called in the same way to establish a relationship between each BOM data record in the locked subset B and the ECR version object with a fixed relationship type LF2_REL_UnableChange (the associated changed data relationship node LF2_REL_UnableChange, the unit is "relationship type identifier", the purpose is to isolate BOM data records that have been occupied or locked by the change process). This makes all BOM data records in the locked subset B uniformly mounted to the associated changed data relationship node, and thus form a structure in which "executable data" and "non-executable data" nodes are presented in parallel under the same ECR version object.

[0078] In one example, based on the target relationship node, an exact match existence check is performed on the material code to be operated, and a conflict comparison check is performed between the material code to be operated and the change operation record table. After both checks pass, the operation type, parent material code, parent material version, parent material name, material code, and material name are written to the change operation record table line by line to complete the batch change, including:

[0079] The system iterates through the first-level BOM row data of each BOM data record under the target relationship node, performs an exact match existence check on the material code to be operated, and performs a conflict comparison check between the material code to be operated and the change operation record table.

[0080] After both checks pass, determine the number of rows to write based on the target relationship node, and write the operation type, parent material code, parent material version, parent material name, material code, and material name to the change operation record table line by line to complete the batch change.

[0081] In this example, the system reads the complete set G of BOM data records under the target relation node R from the ECR version object (BOM data record set G, unit is "records", used to limit the scope of parent BOM objects for this batch operation, typically a list of BOM objects mounted to the target relation node R). At the same time, it receives the set C of material codes to be operated on (the set C of material codes to be operated on, unit is "entry set", used to describe the list of material codes to be deleted or replaced in each parent BOM, typically a multi-line code sequence formed by the user pasting) and the set N of material names corresponding to the set C of material codes (the set N of material names, unit is "entry set", used to describe the material names corresponding to the material codes to be operated on for table writing traceability, typically a name sequence parsed by the system from BOM row data or input boxes). For each BOM data record g (a BOM data record g, unit is "object instance", used to refer to a single parent BOM object) in set G, read the first-level BOM row data L1(g) of the BOM data record (the first-level BOM row data L1(g), unit is "row", used to represent the set of all BOM row records in the first-level structure of the parent BOM object, typically a list of several BOM row objects), and perform a row-by-row traversal of L1(g) in memory. Simultaneously, for each material code c (material code c, unit is "code entry", used to refer to a single material code to be operated on) in the set of material codes to be operated on, execute... The existence check involves extracting the BOM row material code field from each row in L1(g) and performing an equality comparison with c to obtain the existence indicator I1(c,g). (The existence indicator I1(c,g) indicates whether the material code c has an exact match in the first-level BOM row data of the parent BOM object g. The typical value is 0 or 1.) Where I1(c,g)=1 means that at least one BOM row satisfies an exact match and allows the next check to proceed. I1(c,g)=0 means that no matching entry was found in the first level and an error message is triggered, and the current table writing action is terminated, ensuring that the material to be operated on does indeed exist in the first level structure of the target range.Simultaneously, a conflict comparison check is performed on each material code c. This involves accessing the change operation record table T1 (change operation record table T1 is a structured record of batch change execution, typically a set of records related to conflict judgment in the deletion record table LF2_SCZJ or replacement record table LF2_TH), and reading the material code column Q used for conflict judgment in the change operation record table T1 (material code column Q, in "column", stores the recorded material codes to determine whether the same material has an action conflict, typically a set of code columns corresponding to lf2_WLBM in the LF2_SCZJ table). c is compared one by one with all existing codes in column Q to obtain the conflict indication value I2(c) (conflict indication value I2(c) indicates whether material code c already exists in the conflict comparison column of the change operation record table, typically a value of 0 or 1). Where I2(c)=1 indicates that material code c has appeared in the change operation record table and constitutes a conflict, thereby triggering an error message and terminating the current table writing action, and I2(c)=0 indicates that there is no conflict and the process can continue. Within the same execution cycle, it is required that for all c∈C and all g∈G, I1(c,g)=1 and I2(c)=0 simultaneously, forming a dual gating condition between existence verification and conflict comparison verification, avoiding the risk of data inconsistency caused by missed deletions, replacements, and duplicate actions. After both verifications pass, the number of rows to be written L is determined based on the target relation node R (the number of rows to be written L, in "rows", is used to determine the total number of records to be written to the change operation record table to ensure that the Cartesian combination of the parent BOM and the material to be operated is completely recorded). In the scenario of deletion action, the product writing rule L=M×N is adopted, where M (the number of parent BOMs M, the number of parent BOM objects attached to the target relation node R, typically the number of elements in set G) and N (the number of materials to be operated N, the number of materials in the set of material codes to be operated C, typically the number of elements in set C) jointly determine the combination scale of writing row by row, ensuring that each parent BOM object and each material code to be operated generates an independent record row.For each record to be written, construct a field group P (field group P, which carries the complete field values ​​required for a single row write), and write the operation type T (operation type T, unit is "string entry", identifying the semantics of the action, typically "delete" or "before replacement" "after replacement") into the operation type field of field group P. Write the parent material code F1 (parent material code F1, recording the object ID of the parent BOM object, typically the Teamcenter object ID) into the parent material code field of field group P. Write the parent material version F2 (parent material version F2, recording the version identifier of the parent BOM object, typically the object version string) into the parent material version field of field group P. Write the parent material name F3 (parent material name F3, unit is "name entry", used to record the name of the parent BOM object, typically the object name string) into the parent material field of field group P. The name field is used to write the material code c and the material name n (material name n, in the unit of "name entry", records the name of the material to be operated, typically the name string corresponding to the material code) into the material code field and material name field of field group P respectively. Then, according to the traversal order of the parent BOM object and the order of the material codes to be operated, L rows of field groups are generated sequentially and written to the table attribute lf2_SCZJ of the change operation record table LF2_SCZJ (table attribute lf2_SCZJ, in the unit of "table attribute identifier", used to locate the target table object of the deletion action) or to the table attribute lf2_TH of the replacement record table LF2_TH (table attribute lf2_TH, in the unit of "table attribute identifier", used to locate the target table object of the replacement action) to solidify the execution intention of the batch change in the form of structured records and maintain a strong association with the ECR version object.

[0082] In one example, the first-level BOM row data of each BOM data record under the target relationship node is traversed, an exact match existence check is performed on the material code to be operated, and a conflict comparison check is performed between the material code to be operated and the change operation record table, including:

[0083] Traverse the first-level BOM row data of each BOM data record under the target relationship node, and perform an exact match search for each record with the material code to be operated as the matching key value. When the first level of all BOM data records under the target relationship node finds BOM row data that matches the material code to be operated, the existence check is confirmed to be successful.

[0084] Read all existing codes stored in the material code attribute column of the change operation record table. Using the material code to be operated as the comparison key, perform string exact matching comparison on all existing codes one by one. When there is no existing code that matches the material code to be operated, the conflict comparison verification is confirmed to be successful.

[0085] In this example, the BOM data record set G under the target relation node R is read from the ECR version object (the BOM data record set G represents the list of all parent BOM objects attached to the target relation node R), and the material code c to be operated is received (the material code c is used as the key value for exact match lookup to locate the BOM row that needs to be deleted or replaced, typically a single code string entered or pasted by the user). For each BOM data record g in set G, read the first-level BOM row data L1(g) one by one (the first-level BOM row data L1(g) represents the set of all BOM row records in the first-level structure of the parent BOM object g), and perform a row-by-row traversal of L1(g). During the traversal, extract the material code field of each row and use the material code c to be operated as the matching key value to perform a string exact match search to obtain the matching result K(g). When there is at least one row that satisfies "material code field = c", it is recorded as K(g) = 1 and the search process of the current g ends. When the traversal of L1(g) is completed and no completely matching code is found, it is recorded as K(g) = 0 and an error message is immediately triggered. The existence check of all BOM data records in set G is determined. Specifically, if K(g) = 1 for all g∈G, it is determined that the first level of all BOM data records under the target relation node R has found BOM row data that matches the material code c to be operated and the existence check is determined to be passed. This avoids the risk of batch execution inconsistency caused by the existence of BOMs in some parent BOMs but missing them in other parent BOMs. Simultaneously, to complete the conflict comparison verification, the material code attribute column Q in the change operation record table T1 (change operation record table T1 is used to store historical or submitted change execution records for conflict determination, typically the deletion record table LF2_SCZJ or the table object on which conflict determination depends) is read, and all existing codes in column Q are loaded one by one into the existing code set H (existing code set H is the complete set of existing codes for conflict comparison, typically a list of all material code strings in the table). The material code c to be operated is used as the comparison key pair set H to perform string exact matching comparison for each existing code h. When any h=c occurs, the system determines that a conflict exists and sets the conflict comparison verification to fail. When all h∈H has been traversed and there is still no h=c, the system determines that there is no existing code that matches the material code c to be operated and determines that the conflict comparison verification has passed. This ensures that the material code to be operated will not have duplicate actions or logical conflicts with existing change records, so that the existence verification and conflict comparison verification form a pre-constraint condition in the same execution link.

[0086] In one example, after both checks pass, the number of rows to be written is determined based on the target relationship node, and the operation type, parent material code, parent material version, parent material name, material code, and material name are written to the change operation record table row by row to complete the batch change, including:

[0087] After both checks pass, count the number of BOM data objects attached to the target relationship node and the number of materials to be operated on this time. The number of lines to be written is determined by the product of the number of BOM data objects and the number of materials to be operated on.

[0088] Based on the number of rows written, and in the order of combination between each BOM data record under the target relationship node and each material to be operated, the operation type, parent material code, parent material version, parent material name, material code, and material name are written to the change operation record table line by line to complete the batch change.

[0089] In this example, all BOM data objects attached to the target relation node R (the parent BOM object carrying node that limits the scope of this batch change, typically LF2_REL_SC or LF2_REL_TH, etc., a document-given relation type) are counted to obtain the number of parent BOMs M. At the same time, the number of materials to be operated on C (the set of materials to be operated on, in "pieces", representing the total number of material codes to be deleted or replaced in this operation, typically the number of codes formed by user input or pasting) is counted to obtain the number of materials to be operated on N (the number of materials to be operated on N, in "pieces", representing the number of material codes in set C). Based on this, the number of rows to be written L (the number of rows to be written, used to determine the total number of records to be inserted into the change operation record table) is determined according to the defined product writing rule. The number of rows to be written satisfies the relation L=M×N, indicating that each parent BOM object must form an independent record with each material to be operated on, ensuring that the batch change structurally covers all combination scenarios. The logic for writing data line by line is constructed according to the combination order, that is, the parent BOM object g1 is fixed, and each material code c1, c2...c in the set of materials to be operated on is traversed sequentially. N For each pair of combinations (g1, c) i Generate a record field group P, and write the operation type T (operation type T identifies the semantics of this batch change action, typically "delete" or according to the description of the action), parent material code F1, parent material version F2, parent material name F3, and material code c into field group P. i And the corresponding material name N i After completing the combination writing of parent BOM object g1 and all materials to be operated, the system switches to parent BOM object g2 and repeats the above traversal logic until all M parent BOM objects and N materials to be operated are processed, generating a total of L rows of fields and writing them sequentially into the change operation record table T1.

[0090] Reference Figure 2 This embodiment provides a batch change system based on Teamcenter, including:

[0091] Parallel query module 1 is used to input the parent material code, parent material name, child material code, and child material name input by the user into the Teamcenter database to perform parallel queries and obtain a candidate BOM data set;

[0092] Subset splitting module 2 is used to split the candidate BOM data set into a mutable subset and a locked subset, and attach the mutable subset to the target relationship node, and attach the locked subset to the associated mutable data relationship node;

[0093] Batch Change Module 3 is used to perform an exact match existence check on the material code to be operated based on the target relationship node, and to perform a conflict comparison check between the material code to be operated and the change operation record table. After both checks pass, the operation type, parent material code, parent material version, parent material name, material code, and material name are written into the change operation record table line by line to complete the batch change.

[0094] In this embodiment, the specific implementation of each unit in the above system embodiment is described in the above method embodiment, and will not be repeated here.

[0095] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, system, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, system, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, system, article, or method that includes that element.

[0096] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A batch change method based on Teamcenter, characterized in that, include: Input the parent material code, parent material name, child material code, and child material name into the Teamcenter database and perform a parallel query to obtain a candidate BOM data set; The candidate BOM data set is split into a changeable subset and a locked subset, and the changeable subset is attached to the target relationship node, while the locked subset is attached to the associated changeable data relationship node. Specifically, this includes: for each BOM data record in the candidate BOM data set, retrieving the association relationships between each BOM data record in the Teamcenter database and ECR objects and ECN objects; classifying BOM data records that have not established association relationships with any ECR or ECN objects into the mutable subset, and classifying BOM data records that have established association relationships with at least one ECR or ECN object into the locked subset; reading the stored value of the change action attribute on the ECR version object, mounting the mutable subset to the target relationship node according to the stored value, and mounting the locked subset to the associated change data relationship node; Based on the target relationship node, an exact match existence check is performed on the material code to be operated, and a conflict comparison check is performed between the material code to be operated and the change operation record table. After both checks pass, the operation type, parent material code, parent material version, parent material name, material code, and material name are written line by line into the change operation record table to complete the batch change. Specifically, this includes: traversing the first-level BOM row data of each BOM data record under the target relationship node, performing an exact match existence check on the material code to be operated, and performing a conflict comparison check between the material code to be operated and the change operation record table; after both checks pass, the number of rows to be written is determined according to the target relationship node, and the operation type, parent material code, parent material version, parent material name, material code, and material name are written line by line into the change operation record table to complete the batch change.

2. The batch change method based on Teamcenter according to claim 1, characterized in that, The parent material code, parent material name, child material code, and child material name input by the user are entered into the Teamcenter database to perform a parallel query, resulting in a candidate BOM data set, including: Based on the parent material code values ​​stored in the parent material code array attribute, queries are performed on the parent material code and parent material name of the BOM data record in the Teamcenter database to obtain the first query result and the second query result. Based on the sub-material code values ​​stored in the sub-material code array attribute, queries are performed on the sub-material codes and sub-material names of the BOM data records in the Teamcenter database to obtain the third and fourth query results. The first query result, the second query result, the third query result, and the fourth query result are merged and deduplicated to obtain a candidate BOM data set.

3. The batch change method based on Teamcenter according to claim 2, characterized in that, The first, second, third, and fourth query results are merged and deduplicated to obtain a candidate BOM data set, including: All BOM data records from the first query result, the second query result, the third query result, and the fourth query result are merged into a comprehensive BOM data set; The unique identifier of each BOM data record in the Teamcenter database is used as the key to perform deduplication, resulting in a candidate BOM data set.

4. The batch change method based on Teamcenter according to claim 1, characterized in that, For each BOM data record in the candidate BOM data set, retrieve the association relationships between each BOM data record in the Teamcenter database and the ECR object, as well as with the ECN object, including: Perform a search on each BOM data record in the candidate BOM data set in the ECR object association table and ECN object association table of the Teamcenter database respectively, and obtain the ECR association search results and ECN association search results for each BOM data record; When both the ECR and ECN related search results are empty, the association relationship of the corresponding BOM data record is marked as unrelated; when there is at least one record in either the ECR or ECN related search results, the association relationship of the corresponding BOM data record is marked as related.

5. The batch change method based on Teamcenter according to claim 4, characterized in that, Read the stored value of the change action attribute on the ECR version object, mount the mutable subset to the target relationship node according to the stored value, and mount the locked subset to the associated change data relationship node, including: Read the stored value of the change action attribute on the ECR version object, and determine the target relationship node according to the matching relationship between the stored value and the actual value of the change action; All BOM data records in the modifiable subset are attached to the target relationship node, and all BOM data records in the locked subset are attached to the associated modified data relationship node.

6. The batch change method based on Teamcenter according to claim 1, characterized in that, The process involves traversing the first-level BOM row data of each BOM data record under the target relationship node, performing an exact match existence check on the material code to be operated, and performing a conflict comparison check between the material code to be operated and the change operation record table, including: The first-level BOM row data of each BOM data record under the target relationship node is traversed, and an exact match search is performed one by one with the material code to be operated as the matching key value. When the first level of all BOM data records under the target relationship node finds BOM row data that matches the material code to be operated, the existence check is confirmed to be successful. Read all existing codes stored in the material code attribute column of the change operation record table. Using the material code to be operated as the comparison key, perform string exact matching comparison on all existing codes one by one. When there is no existing code that matches the material code to be operated, the conflict comparison verification is determined to be successful.

7. The batch change method based on Teamcenter according to claim 1, characterized in that, After both checks pass, the number of rows to be written is determined based on the target relationship node, and the operation type, parent material code, parent material version, parent material name, material code, and material name are written line by line into the change operation record table to complete the batch change, including: After both checks pass, the number of BOM data objects attached to the target relationship node and the number of materials to be operated on are counted, and the number of write lines is determined by the product of the number of BOM data objects and the number of materials to be operated on. Based on the number of rows written, and in the order of combination between each BOM data record under the target relationship node and each material to be operated, the operation type, parent material code, parent material version, parent material name, material code, and material name are written line by line into the change operation record table to complete the batch change.

8. A batch change system based on Teamcenter, characterized in that, The steps for implementing the Teamcenter-based batch change method according to any one of claims 1 to 7, wherein the Teamcenter-based batch change system comprises: The parallel query module is used to input the parent material code, parent material name, child material code, and child material name into the Teamcenter database and perform parallel queries to obtain a set of candidate BOM data. The subset splitting module is used to split the candidate BOM data set into a mutable subset and a locked subset, and to attach the mutable subset to the target relationship node and the locked subset to the associated changed data relationship node; The batch change module is used to perform an exact match existence check on the material code to be operated based on the target relationship node, and to perform a conflict comparison check on the material code to be operated and the change operation record table. After both checks pass, the operation type, parent material code, parent material version, parent material name, material code, and material name are written into the change operation record table line by line to complete the batch change.

Images