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 |
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 > .
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
