同步和红线待查状况
本主题提供几种场景来说明红线的冲突和非冲突变更、同步及待查状况。
在红线的部件属性、部件使用和部件具体值的粒度级别同步变更。
同步过程会检查是否已为最新产生的对象和红线添加、替换、移除或修改部件。如果添加、移除、替换或修改了不同的部件,同步会在所有级别进行。如果修改同一部件,该过程会检查完成修改的级别。例如,该过程会首先检查部件,然后再检查使用、属性或具体值。如果修改出现在具体值中,该过程会检查数量或位号名称。根据所做变更是非冲突变更还是冲突变更,红线会保留最新发布的产生对象和/或红线中的变更。如果变更为冲突变更,会将红线标记为 “待查”。同步后,“红线”列会显示 “待查”图标。将红线标记为待查后,可以通过比较最新发布的产生对象和红线的变更来解决待查红线。解决待查红线后,系统会创建红线的新小版本。
有关冲突变更和非冲突变更的详情,请参阅同步和红线待查状况中的“非冲突变更和冲突变更”部分。
本主题介绍在根据以下变更修改部件时,红线的同步和待查状况可能存在的几种场景:
在结构树中添加了新部件或现有部件
已替换为结构树中的新部件或现有部件
移除了结构树中的部件
在结构树中修改了数量、位号、具体值或行号的部件使用链接
未变更 - 未对结构树中的部件执行任何变更
非冲突变更和冲突变更
非冲突变更可以是在不同部件上执行的变更,也可以是在同一部件的不同级别 (属性、具体值或使用) 上执行的变更。如果存在非冲突变更,会保留最新发布的产生对象和红线中的变更。如果变更是在红线的同一部件上执行的,而产生的对象却处于其他级别,那么这些变更便是非冲突变更。例如,您对产生的对象和同一部件的源进行了修改。如果另一用户已修改红线的“装配模式”,此类变更为非冲突变更,即使这些变更是在同一部件的同一点 (属性级别) 上执行的。在这种情况下,红线不会被标记为待查。
冲突变更是指在相同级别 (属性、具体值或使用) 对同一部件执行的变更。最新发布的产生对象版本与红线之间存在冲突变更。例如,要在产生的对象中替换部件并在红线中修改同一部件时。在存在冲突的场景中,会将红线标记为待查,并且会根据冲突情况,保留最新发布的产生对象或红线中的变更。
场景 1:部件使用关系的非冲突变更和冲突变更
如果存在非冲突变更,不会将红线标记为待查,并且会保留产生的对象或红线中的变更。
下表显示最新发布的产生对象和红线的同一部件的同步状况。
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
已添加部件 - 新建/现有
未更改部件
最新发布的产生对象
未更改部件
已添加部件 - 新建/现有
红线
已移除部件
未更改部件
最新发布的产生对象
未更改部件
已移除部件
红线
已替换部件 - 新建/现有
未更改部件
最新发布的产生对象
未更改部件
已替换部件 - 新建/现有
红线
已修改部件
未更改部件
最新发布的产生对象
未更改部件
已修改部件
红线
未更改部件
未更改部件
无变更
已添加部件 (部件 A)
已添加部件 (部件 B)
最新发布的产生对象和红线
已添加部件 (部件 A)
已添加部件 (部件 A)
最新发布的产生对象
如果存在冲突变更,会将红线标记为待查,并保留红线中的变更。
下表显示最新发布的产生对象和红线的同一部件的同步状况。
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
已移除部件
已修改部件
待查
红线
已移除部件
已替换部件
待查
红线
已移除部件
已移除部件
待查
红线
已修改部件
已修改部件
待查
红线
已修改部件
已替换部件
待查
红线
已修改部件
已移除部件
待查
红线
已添加部件 (部件 A,与红线相比,属性不同)
已添加部件 (部件 A)
待查
最新发布的产生对象
在上述场景中,在红线中修改的部件和最新发布的产生对象处于同一级别,例如,对于相同的部件使用关系,修改数量。因此,这些变更为冲突变更,且红线会被标记为待查。如果针对红线的数量修改了部件,并且针对产生的对象的可变属性修改了同一部件,此部件不属于冲突变更。系统会同时对这两项修改进行同步。
场景 2:红线属性的非冲突变更和冲突变更
如果修改红线和产生的对象的任何属性,会保留红线和产生的对象中的变更。
下表显示最新发布的产生对象和红线的属性的同步状况。
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
已更改装配模式 (例如,“可分离”)
已更改源 (例如,“制造”)
最新发布的产生对象和红线
未更改红线
已更改源 (例如,“购买”)
红线
已更改源 (例如,“制造”)
未更改红线
最新发布的产生对象
如果修改红线和产生的对象的任何属性,会保留红线中的变更,并将红线标记为待查。
下表显示最新发布的产生对象和红线的属性的同步状况。
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
已更改装配模式 (例如,“可分离”)
已更改装配模式 (例如,“不可分离”)
待查
红线
已更改源 (例如,“制造”)
已更改源 (例如,“购买”)
待查
红线
场景 3:行号的非冲突变更和冲突变更
行号表示一个部件在 ERP 系统中 BOM 内的位置。如果存在与行号的唯一性相关的冲突变更,红线会保留最新发布的产生对象中的变更。例如:
为产生的对象中的部件 (部件 A) 分配了行号 5,并且为红线中的不同部件 (部件 B) 分配了相同的行号。这违反了行号唯一性约束,因此,这些变更会被视为冲突变更。因此,红线会被标记为待查。
您为产生的对象中的部件 (部件 A) 分配了行号 10,并且为红线中的不同部件 (部件 B) 分配了行号 8。这并不违反行号唯一性约束,因此,这些变更不会被视为冲突变更。
如果存在非冲突变更,红线会同时保留最新发布的产生对象和红线中的变更。
下表显示在产生的对象和红线中添加两个不同部件 (A 和 B) 时,与唯一性行号相关的非冲突变更和冲突变更。
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
已将部件 A 添加到行号 (10)
已将部件 B 添加到行号 (8)
最新发布的产生对象和红线
已将部件 A 添加到行号 (5)
已将部件 B 添加到行号 (5)
待查
最新发布的产生对象
* 
更改预设检索号属性并不会发生冲突。但是,如果要配置检索号的唯一性,在红线中将相同的检索号分配给不同的部件时,会发生冲突。将红线标记为待查,同时保留最新发布的产生对象中的变更。
场景 4:部件具体值的非冲突变更和冲突变更
部件具体值同步会在数量、位号名称和位号级别进行。仅在满足以下条件时才会发生此情况:
对于产生的对象和红线中的部件,其部件使用关系、部件编号、组织 ID 和组件 ID 均相同。
产生的对象和红线的使用关系链接的单位为“个”
产生的对象和红线的同一部件都会被修改。
具体值具有系统生成的具体值标识符,用于比较具体值。
如果相同部件的具体值发生冲突变更,比如已移除或已修改的具体值或位置的变更,会将红线标记为待查。
如果对最新发布的产生对象和红线的部件具体值进行了如下修改,下表即说明同步和待查状况:
更改了红线的部件具体值位置。
为产生的对象添加了位号 R20,而为红线添加了位号 R10。
从产生的对象中移除了部件具体值。
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
未更改具体值 R1 位置
已更改具体值 R1 位置
红线
未更改具体值 R2
已移除具体值 R2
红线
未更改具体值 R3
未更改具体值 R3
红线
已修改具体值 R4
未更改具体值 R4
最新发布的产生对象
已移除具体值 R5
未更改具体值 R5
最新发布的产生对象
已添加位号 R20
已添加位号 R10 (未超出数量限制)
最新发布的产生对象和红线
已修改具体值 R3
已移除具体值 R3
待查
红线
同步和红线待查状况中“场景 3:行号的非冲突变更和冲突变更”场景中所述,如果修改使用关系链接的行号,并且针对唯一性行号的变更存在冲突,会保留最新发布的产生对象中的变更。如果修改具体值的此类使用关系链接,红线会保留最新发布的产生对象中的变更。
在整个子装配中,部件使用关系的位号名称应是唯一的。如果位号名称不是唯一的,会将红线标记为待查,并保留最新发布的产生对象中的变更。
如果具体值数量超出限制,会将红线标记为待查,并保留最新发布的产生对象中的变更。
如果对部件具体值的位号和数量进行了修改,下表即说明同步和待查状况。
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
位号名称 R1
位号名称 R1
待查
最新发布的产生对象
位号名称 R3
位号名称 R4
最新发布的产生对象和红线
已添加位号 R6
已添加位号 R10 (超出数量限制)
待查
最新发布的产生对象
场景 5:部件的特定替换部件的非冲突变更和冲突变更
下表显示针对同一使用关系链接的同一子项部件修改、移除或取消修改特定替换部件后的同步和待查状况。
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
未修改特定替换部件
已移除特定替换部件
红线
未修改特定替换部件
已修改特定替换部件
红线
未修改特定替换部件
未修改特定替换部件
红线
已移除特定替换部件
未修改特定替换部件
最新发布的产生对象
已修改特定替换部件
未修改特定替换部件
最新发布的产生对象
未修改特定替换部件
未修改特定替换部件
最新发布的产生对象
下表显示针对同一使用关系链接添加、修改或移除相同或不同的特定替换部件后的同步和待查状况:
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
已添加使用关系链接 UL1,且已向 UL1 中添加特定替换部件 S1
已添加使用关系链接 UL1,且已向 UL1 中添加特定替换部件 S2
待查
红线
已针对同一使用关系链接修改特定替换部件 S1 (已修改号和数量)
已针对同一使用关系链接修改特定替换部件 S2 (未修改位号,但已修改数量)
待查
红线
已将使用关系链接 UL1 替换为 UL2:
已移除特定替换部件 S1
未修改特定替换部件 S2
已将使用关系链接 UL1 替换为 UL2:
未修改特定替换部件 S1
已移除特定替换部件 S2
待查
红线
已针对使用关系链接添加具体值 O1-O3,且已修改特定替换部件 S1 数量
未针对使用关系链接添加任何具体值,但已修改特定替换部件 S1 数量
待查
最新发布的产生对象
场景 6:自动同步 - AML/AVL 的非冲突变更和冲突变更
如果修改红线和受影响对象的任何 AML/AVL,会保留红线和受影响对象中的变更。
下表显示受影响对象和红线的最新小版本的 AML/AVL 同步状况。
* 
如果计划对最新发布的部件的 AML/AVL 进行修改,必须使用小版本进行修改。如果对 AML/AVL 进行更改时不使用小版本,这可能无法正确同步未解决的 BOM 红线。
最新迭代的受影响对象/最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
采办上下文城市 2 (AML 1)
采办上下文城市 1 (AML 1 和 AVL 1)
最新迭代的受影响对象和红线
已移除制造商部件 (AML 2)
未变更
最新发布的产生对象
未变更
已添加制造商部件 (AML 6)
红线
已添加制造商部件 (AML 7)
已添加制造商部件 (AML 7)
最新迭代的受影响对象和红线
已将部件的采办状况从“不使用”修改为“合格”(AML 1)
未变更
最新发布的产生对象
已将部件的采办状况从“不使用”修改为“首选”(AML 4)
已将部件的采办状况从“不使用”修改为“首选”(AML 4)
最新迭代的受影响对象和红线
下表显示受影响对象和红线的最新小版本的 AML/AVL 同步状况。
最新迭代的受影响对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
已将部件的采办状况从“不使用”修改为“首选”(AML 1)
已移除制造商部件 (AML 1)
待查
最新迭代的受影响对象和红线
已移除制造商部件 (AML 2)
已将部件的采办状况从“不使用”修改为“合格”(AML 2)
待查
最新迭代的受影响对象
已将部件的采办状况从“不使用”修改为“首选”(AML 4)
已将部件的采办状况从“不使用”修改为“合格”(AML 4)
待查
红线
已将厂商部件 (AVL 1) 关联至部件 (AML 3)
已将部件的采办状况从“不使用”修改为“合格”(AML 3)
待查
红线
场景 7:自动同步 - 文档的非冲突变更
如果修改红线和受影响对象的任何“说明方文档”,会保留红线和受影响对象中的变更。
下表显示受影响对象最新小版本和红线的“说明方文档”的同步状况。
最新迭代的受影响对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
DBD 42 A.1
DBD 41 A.1
最新迭代的受影响对象和红线
合并:文档的非冲突变更
下表显示受影响对象最新小版本和红线的“说明方文档”的合并状况。
最新迭代的受影响对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
DBD 42 A.1
DBD 41 A.1
DBD 42 A.1
DBD 22 A.1
最新迭代的受影响对象和红线
如果修改红线和受影响对象最新小版本的任何“说明方文档”,会保留受影响对象和红线中的变更。
场景 8:自动同步 - 文档的冲突变更
下表显示受影响对象最新小版本和红线的“说明方文档”的同步状况。
最新迭代的受影响对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
DBD 3 B.1
DBD 3 A.1
待查
最新迭代的受影响对象
如果修改红线和受影响对象的任何“说明方文档”,会保留受影响对象中的变更,并将红线标记为待查。
场景 9:同步工作流 - 文档的非冲突变更
下表显示最新发布的产生对象和红线的“说明方文档”的同步状况。
最新发布的产生对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
DBD 42 A.1
未更改红线
最新发布的产生对象
如果修改红线和产生对象的任何“说明方文档”,会保留最新发布的产生对象中的变更。
场景 10:自动同步或同步分类属性 - 非冲突变更
在红线和最新发布的产生对象或最新迭代的受影响对象中修改分类属性/分类节点时,将保留最新发布或迭代对象的变更。
下表显示最新发布的产生对象或最新迭代的受影响对象和红线的属性同步状况:
最新发布的产生对象/最新迭代的受影响对象
红线
变更存在冲突
需要同步:是/否
保留变更 - 来源
在最新发布的产生对象上为部件 P1 重新分配节点
未变更
最新发布的产生对象
在最新发布的产生对象上为 P1 的子项部件分配分类节点。
未变更
最新发布的产生对象
在最新迭代的受影响对象上为部件 P2 重新分配节点。
未变更
最新迭代的受影响对象
在最新迭代的受影响对象上为部件 P2 重新分配属性。
未变更
最新迭代的受影响对象
场景 2:自动同步或同步分类属性 - 冲突变更
在修改红线和产生对象的分类属性/分类节点后,将保留红线的变更,并将红线标记为待查。
下表显示最新迭代的受影响对象和红线的属性同步状况。
最新迭代的受影响对象
红线
变更存在冲突
需要同步:是/否/待查红线
保留变更 - 来源
为部件 A1 分配分类节点
为部件 A1 分配其他分类节点
待查
红线
为部件 A1 重新分配分类节点
使用其他值为部件 A1 重新分配分类节点
待查
红线
为部件 A4 分配分类属性
为部件 A4 分配其他分类属性
待查
红线
管理红线待查
如果存在任何冲突变更,可以在红线结构阅览器中,手动将红线设置为 “待查”。要设置或取消设置 “待查”,请选择部件或红线,然后单击“编辑” > “管理红线待查”
解决待查红线后,系统会创建红线的下一个小版本。
“查看并发变更”操作有助于识别可能存在冲突和潜在待查条件的部件。通过查看报告,您可以在批准 BOM 红线修改之前解决这些问题。有关详情,请参阅查看并发变更摘要
* 
在标识冲突变更时,可以手动设置红线结构树和“使用”选项卡上的 “待查”图标。如果同步后存在冲突变更,系统会自动设置变更任务的“受影响的对象”表格中的 “待查”图标。如果在解决冲突后,取消设置红线结构阅览器中的待查标志,红线列的待查标志会被清除。
相关主题
这对您有帮助吗?