Data Management Capabilities > Managing Change > About Change Notices > About Redline > Synchronization and Redline Suspect Status
Synchronization and Redline Suspect Status
This topic provides several scenarios to explain conflicting and non-conflicting changes, synchronization, and suspect status of a redline.
The synchronization of changes takes place at a granular level of the part attributes, usage attributes, and the occurrence attribute level of a redline.
The synchronization process checks if a part is added, replaced, removed, modified, for the latest resulting object and the redline. If different parts are added, removed, replaced, or modified, then the synchronization occurs at all levels. If the same part is modified, then the process checks the level where the modification is done. For example, first it checks the part, then the usage or attributes or occurrences. If the modification is in occurrences, then it checks the quantity or reference designator name. Depending on whether the changes are non-conflicting or conflicting, the redline retains changes from the latest released resulting object or the redline or from both. If the changes are conflicting, then the redline is marked as Suspect. The Redline column displays the Suspect icon after the synchronization. When the redline is marked as suspect, you can resolve the suspect by comparing the changes of the latest released resulting object and the redline. After the suspect is resolved, the new iteration of the redline is created.
For more information on conflicting and non-conflicting changes, see the Non-conflicting and Conflicting Changes section in Synchronization and Redline Suspect Status.
This topic explains several potential scenarios of the synchronization and suspect status of the redline when the part is modified with the following changes:
Added a new or an existing part in the structure tree
Replaced with the new or existing part in the structure tree
Removed the part in the structure tree
Modified the part usage links for quantity, reference designator, occurrences, or line number in the structure tree
Unchanged – No changes performed on a part in the structure tree
Non-conflicting and Conflicting Changes
Non-conflicting changes are the changes that you perform on different parts or on the same part but at different level (attributes, occurrence, or usage). If there are non-conflicting changes, the changes are retained from the latest released resulting object and the redline. If the changes are taking place at the same part of the redline and the resulting object but at a different level, such changes are non-conflicting changes. For example, you have modified Source of the resulting object and for the same part. If another user has modified Assembly Mode of the redline, then such changes are non-conflicting changes, even though they are for the same part at the same point (attribute level). In this case, redline is not marked as suspect.
Conflicting changes are the changes that you perform on the same part at the same level (attributes, occurrence, or usage). There are conflicting changes between the latest released resulting object version and the redline. For example, when you are replacing a part in the resulting object and modifying the same part in the redline. In conflicting scenarios, the redline is marked as suspect, and the changes are retained either from the latest released resulting object or the redline, depending on the conflict.
Scenario 1: Non-conflicting and Conflicting Changes for a Part Usage
If there are non-conflicting changes, the redline is not marked as suspect, and the changes from the resulting object or the redline are retained.
The following table shows synchronization status of the same part of the latest released resulting object and the redline.
Latest Released Resulting Object
Redline
Changes Conflicted
Synch Required: Yes/No/Suspect Redline
Changes Retained from
Part added - new/existing
Part unchanged
No
Yes
Latest released resulting object
Part unchanged
Part added - new/existing
No
No
Redline
Part removed
Part unchanged
No
Yes
Latest released resulting object
Part unchanged
Part removed
No
No
Redline
Part replaced - new/existing
Part unchanged
No
Yes
Latest released resulting object
Part unchanged
Part Replaced - new/existing
No
No
Redline
Part modified
Part unchanged
No
Yes
Latest Released Resulting Object
Part unchanged
Part modified
No
No
Redline
Part unchanged
Part unchanged
No
No
No Change
Part added (Part A)
Part added (Part B)
No
Yes
Latest released resulting object and redline
Part added (Part A)
Part added (Part A)
No
No
Latest released resulting object
If there is a conflicting change, the redline is marked as suspect, and changes from the redline are retained.
The following table shows synchronization status of the same part of the latest released resulting object and the redline.
Latest Released Resulting Object
Redline
Changes Conflicted
Synch Required: Yes/No/Suspect Redline
Changes Retained from
Part removed
Part modified
Yes
Suspect
Redline
Part removed
Part replaced
Yes
Suspect
Redline
Part removed
Part removed
Yes
Suspect
Redline
Part modified
Part modified
Yes
Suspect
Redline
Part modified
Part replaced
Yes
Suspect
Redline
Part modified
Part removed
Yes
Suspect
Redline
Part added (Part A, attributes are different, as compare to redline)
Part added (Part A)
Yes
Suspect
Latest released resulting object
In the above scenario, the part modified in the redline and the latest released resulting object are at the same level, for example, quantity is modified for the same part usage. Therefore, the changes are conflicting, and the redline is marked as suspect. If a part is modified for quantity for the redline and the same part is modified for soft attributes for the resulting object, then it is not a conflicting change. The synchronization will take place for both modifications.
Scenario 2: Non-conflicting and Conflicting Changes for Redline Attributes
If any attributes of the redline and resulting object are modified, then changes from the redline and resulting objects are retained.
The following table shows the synchronization status of the attributes of the latest released resulting object and redline.
Latest Released Resulting Object
Redline
Changes Conflicted
Synch Required: Yes/No/Suspect Redline
Changes Retained from
Changed assembly mode (for example, Separable)
Changed source (for example, Make)
No
Yes
Latest released resulting object and redline
Redline unchanged
Changed source (for example, Buy)
No
No
Redline
Changed source (for example, Make)
Redline unchanged
No
Yes
Latest released resulting object
If any attributes of the redline and the resulting object are modified, then changes from the redline are retained and the redline is marked as suspect.
The following table shows the synchronization status of attributes of the latest released resulting object and the redline.
Latest Released Resulting Object
Redline
Changes Conflicted
Synch Required: Yes/No/Suspect Redline
Changes Retained from
Changed assembly mode (for example, Separable)
Changed assembly mode (for example, Inseparable
Yes
Suspect
Redline
Changed source (for example, Make)
Changed source (for example, Buy)
Yes
Suspect
Redline
Scenario 3: Non-conflicting and Conflicting Changes for Line Number
The line number represents the position of a part within the BOM in an ERP system. If there are conflicting changes related to the uniqueness of the line number, then the redline retains changes from the latest released resulting object. For example:
You have assigned the line number 5 for a part (Part A) for the resulting object, and the same line number is assigned to a different part (Part B) for the redline. This violates the line number uniqueness, and the changes are considered conflicting. As a result, the redline is marked as suspect.
You have assigned the line number 10 for a part (Part A) for the resulting object, and the line number 8 is assigned to a different part (Part B) for the redline. This does not violate the line number uniqueness, and the changes are not considered conflicting.
If there are non-conflicting changes, then the redline retains changes from both the latest released resulting object and the redline.
The following table shows non-conflicting and conflicting changes related to the uniqueness line number when two different parts (A and B) are added in the resulting object and the redline.
Latest Released Resulting Object
Redline
Changes Conflicted
Synch Required: Yes/No/Suspect Redline
Changes Retained from
Added part A to line number (10)
Added part B to line number (8)
No
Yes
Latest released resulting object and redline
Added part A to line number (5)
Added part B to line number (5)
Yes
Suspect
Latest released resulting object
* 
Changing the OOTB find number attribute does not cause a conflict. However, if you want to configure uniqueness for the find number, then it is a conflict if the same find number is assigned to a different part in the redline. The redline is marked as suspect, and the changes are retained from the latest released resulting object.
Scenario 4: Non-conflicting and Conflicting Changes for Part Occurrences
The part occurrence synchronization takes place at the quantity, reference designator name, reference designator level. It can occur only if the following criteria are fulfilled:
The part usage, part number, organization id, and component id are the same for the part of the resulting object and the redline.
The usage link of the resulting object and the redline have unit each.
The same part of the resulting object and the redline are modified.
The occurrence has the system-generated occurrence identifier, which is used for comparing the occurrences.
The redline is marked as suspect if there are conflicting changes of occurrences for the same part, such as removed or modified occurrences, or a change in the location.
The following table explains synchronization and suspect status if the part occurrences are modified for the latest released resulting object and the redline with these changes:
The part occurrence location is changed for the redline.
The reference designators R20 added is at the resulting object and R10 is added at the redline.
A part occurrence is removed from the resulting object.
Latest Released Resulting Object
Redline
Changes Conflicted
Synch Required: Yes/No/Suspect Redline
Changes Retained from
Occurrence R1 location unchanged
Occurrence R1 location changed
No
No
Redline
Occurrence R2 unchanged
Occurrence R2 removed
No
No
Redline
Occurrence R3 unchanged
Occurrence R3 unchanged
No
No
Redline
Occurrence R4 modified
Occurrence R4 unchanged
No
Yes
Latest released resulting object
Occurrence R5 removed
Occurrence R5 unchanged
No
Yes
Latest released resulting object
Added reference designator R20
Added reference designator R10 (quantity limit is not exceeded)
No
Yes
Latest released resulting object and redline
Occurrence R3 modified
Occurrence R3 removed
Yes
Suspect
Redline
As explained in the scenario of Scenario 3: Non-conflicting and Conflicting Changes for Line Number in Synchronization and Redline Suspect Status, if you modify the line number of a usage link, and if the changes are conflicting for the uniqueness line number, then the changes are retained from latest released resulting object. If you modify such usage link for occurrences, then the redline retains changes from the latest released resulting object.
The reference designator name should be unique for the part usage across the subassembly. If it is not unique, the redline is marked as suspect and the changes are retained from the latest released resulting object.
If the occurrences quantity exceeds, the redline is marked as suspect and the changes are retained from the latest released resulting object.
The following table explains the synchronization and suspect status if the reference designator and quantity of part occurrences are modified.
Latest Released Resulting Object
Redline
Changes Conflicted
Synch Required: Yes/No/Suspect Redline
Changes Retained from
Reference designator name R1
Reference designator name R1
Yes
Suspect
Latest released resulting object
Reference Designator name R3
Reference designator name R4
No
Yes
Latest released resulting object and redline
Added reference designator R6
Added reference designator R10 (quantity limit is exceeded)
Yes
Suspect
Latest released resulting object
Scenario 5: Non-conflicting and Conflicting Changes for Part Substitutes
The following table shows the synchronization and suspect status when the substitute part is modified, removed, or unmodified for the same child part of the same usage link.
Latest Released Resulting Object
Redline
Changes Conflicted
Synch Required: Yes/No/Suspect Redline
Changes Retained from
Substitute Unmodified
Substitute Removed
No
Yes
Redline
Substitute Unmodified
Substitute Modified
No
Yes
Redline
Substitute Unmodified
Substitute Unmodified
No
Yes
Redline
Substitute Removed
Substitute Unmodified
No
Yes
Latest released resulting object
Substitute Modified
Substitute Unmodified
No
Yes
Latest released resulting object
Substitute Unmodified
Substitute Unmodified
No
Yes
Latest released resulting object
The following table shows synchronization and suspect status when the same or different substitutes are added, modified, removed on same usage link:
Latest Released Resulting Object
Redline
Changes Conflicted
Synch Required: Yes/No/Suspect Redline
Changes Retained from
Usage link UL1 added and Substitute S1 added to UL1
Usage link UL1 added and Substitute S2 added to UL1
Yes
Suspect
Redline
Substitute S1 modified (Reference Designator modified and Quantity modified) on same usage link
Substitute S2 Modified (Reference Designator unmodified and Quantity modified) on same usage link
Yes
Suspect
Redline
Usage link UL 1 Replaced with UL2:
Substitute S1 removed
Substitute S2 unmodified
Usage link UL 1 Replaced with UL2:
Substitute S1 unmodified
Substitute S2 removed
Yes
Suspect
Redline
On Usage link occurrences O1-O3 added and Substitute S1 quantity modified
On Usage link no occurrences added and Substitute S1 quantity unmodified but attribute modified
Yes
Suspect
Latest released resulting object
Managing Redline Suspect
If there are any conflicting changes, you can manually set the redline as Suspect in the redline structure browser. To set or unset the Suspect, select the part or redline and click Edit > Manage Redline Suspect.
After you resolve the suspect, the next iteration of the redline is created.
* 
When you identify conflicting changes, you can manually set the Suspect icon on the redline structure tree and the Uses tab. When there are conflicting changes after a synchronization, the Suspect icon on the Affected Objects table of the change task is automatically set. If you unset the suspect from the redline structure browser after resolving the conflicts, the suspect of the redline column is cleared.
Related Topics
Was this helpful?