Action Types in BOM Compare

This topic describes how actions are determined and applied during BOM compare and update: Insert, Delete, Modify, and Move.

Principles

  • Compare context: Compares a source and a target document.
  • Matching within the same parent: A source child is matched to a target child only under the same parent (Belongs to Entry No.).
  • Identity for matching (field values for base compare): Type, No., Variant Code, optionally Operation No., geometry (Depth, Width, Length), and Pre‑Order (as applicable).
  • Ambiguity: If more than one candidate would match under the same parent, no automatic "Modify" is assigned; the results remain "Insert"/"Delete" for user decision.

Insert

  • Meaning: A source child has no counterpart under this parent in the target.
  • Displayed as: Action = Insert.
  • If applied: Creates a new target line under the parent; sets fields flagged Include in Insert; subordinate data (attributes, comments, tools, personnel, quality measures) are inserted where applicable.

Delete

  • Meaning: A target child has no counterpart under this parent in the source.
  • Displayed as: Action = Delete.
  • If applied: Deletes the line where allowed; otherwise marked Deletion postponed (e.g., due to reservations, posted production orders, separate production order).

Modify

  • Meaning: Source and target child are uniquely matched under the same parent and differences exist in allowed fields/substructures.
  • Triggers for Modify:
    • At least one field flagged Include in Modify = true differs, or
    • Differences exist in substructures (attributes, dimensions, manufacturing dimensions, comments, tools, personnel, quality measures).
  • When NOT Modify:
    • No match under the same parent → then "Insert"/("Delete").
    • Only fields differ that are NOT flagged Include in Modify → no "Modify".
    • Swap of different items at the same position (A ↔ B) → no unique match under the same parent → "Insert" and "Delete", not "Modify".
    • Ambiguous matching (more than one candidate) → no automatic "Modify" assignment.
  • If applied: Only allowed fields are changed (with Validate where appropriate); substructure changes are applied entry‑by‑entry.

Move (Pure Structural Re‑parenting)

  • Goal: Reduce "Insert" and "Delete" noise when an identical part only changes its parent.
  • Creation (user‑driven):
    • Auto Move: The page action Auto Move runs a pairing algorithm and converts uniquely matchable "Insert" and "Delete" pairs into "Move".
    • Manual Move: Select exactly one "Delete" and one "Insert", then choose the Move action. The Undo Move action reverts the pairing.
    • Optional: Integrations can enable immediate pairing after compare via an AutoCalcMovements parameter (off by default).
  • Matching criteria for Move:
    • Identity (field values): Type, No., Variant Code, Pre‑Order, and geometry (Depth, Width, Length). Operation No. is not used for "Move" pairing.
    • Progressive relaxation: The algorithm first tries to match all field values; if none found, it relaxes Length, then Width, then Depth.
    • Uniqueness required: Only a single unique "Insert" and "Delete" pair is converted; otherwise it remains "Insert" and "Delete".
  • Displayed as: Action = Move is shown separately; the moved‑to line retains Action = None (or Modify if allowed fields differ) and shows origin via the Moved from Entry No. and parent description.
  • If applied, re‑parenting only: The moved‑to line's Belongs to Entry No. is updated to the new parent (no create/delete). Sub‑lines follow the re‑parented node.

Special Considerations

  • Cannot skip Move: Move entries cannot be skipped; use the Undo Move action to revert to "Insert" and "Delete" if you need to skip.
  • Numbering normalization: After applying changes, BOM line numbering may be re-assigned. As a result, visible Entry No. of lines can change without creating or deleting lines.
  • Blockers/Severity: Conflicts (reservations, posted production orders, purchasing status) appear as info/warning/error and can affect application (e.g., "Delete" postponed).
  • Ambiguity handling: Multiple candidates → no automatic Move; remains "Insert" and "Delete" for manual decision.

Quick Decision Logic

  • Match within the same parent?
    • No → "Insert" (source), "Delete" (target).
    • Yes → Differences only in fields flagged Include in Modify or substructures?
      • Yes → "Modify"
      • No → None (no change)
  • Not Modify if:
    • Identity changed (e.g., item swap A ↔ B)
    • Differences only in non‑allowed fields
    • No unique match
  • Post‑compare Move:
    • Unique "Insert"/"Delete" pair with same identity across different parents → use Auto Move or manual Move; otherwise leave as "Insert" and "Delete".

Feedback
Submit feedback for this page .