> ## Documentation Index
> Fetch the complete documentation index at: https://docs.firstresonance.io/llms.txt
> Use this file to discover all available pages before exploring further.

# mBOM change order

> Move units already built or in progress onto a released mBOM version with an mBOM version change order.

An mBOM version change order moves each unit's aBOM onto a released [mBOM version](/build-hardware/bills-of-materials/versions) of the same part. You pick the version and the units, decide how each difference applies to each unit, and apply the result once the change order is approved. For statuses and review, see the [change orders overview](/build-hardware/change-orders).

<Steps>
  <Step title="Create the change order">
    1. On the **Change Orders** page, click **Create Change Order**.
    2. Enter a **Title**, and optionally a **Description** for reviewers.
    3. Set **Change Order Type** to **mBOM version change**.
    4. Under **Target mBOM version**, pick the **Part** and the **mBOM version** to adopt. Only released versions are offered, and a part with nothing released can't be picked: the version control says to release an mBOM version first.
    5. Click **Create Change Order**. ION opens the change order.
  </Step>

  <Step title="Add the inventory">
    In **Affected Inventory** on the change order, click **Add inventory** and pick the units. Only inventory of the target part is offered, and a record whose quantity is zero is refused: an emptied lot has nothing to adopt the change.

    Each unit is a group you expand to see its differences.
  </Step>

  <Step title="Resolve each difference">
    ION writes one row per build requirement the change touches. Each row carries a resolution, preset to the option that writes nothing destructive.

    | Difference                                     | Resolutions                                                      |
    | ---------------------------------------------- | ---------------------------------------------------------------- |
    | A build requirement the target version adds    | **Add new build requirement** or **Waive new build requirement** |
    | A build requirement the target version removes | **Remove build requirement** or **Keep build requirement**       |
    | A build requirement the target version changes | **Update build requirement** or **Keep build requirement as is** |

    A resolution that can't be applied to that unit, or that comes with a caveat, is marked with the reason.

    Confirming a resolution is what records the decision:

    1. Select the rows you've decided with their checkboxes.
    2. Click **Confirm Resolution (`<n>`)**.
    3. To push the same decisions onto every unit carrying the same difference, use **Confirm Resolution on all Inventories** in the control's menu instead.

    To reopen a decision, select the rows and undo the confirmation. Every difference on every unit has to be confirmed before the change order can go for review.

    <Note>
      A unit can change under a draft change order, so its rows can go stale. **Recompute diffs** in the **More options** menu restates every difference against the units as they now stand: a row that no longer applies is dropped, a row appears for a change that has just shown up, and a row whose requirement moved loses its confirmation, so you confirm it again. It's available only on a draft, and only while a unit is still open.
    </Note>
  </Step>

  <Step title="Send it for review">
    1. In the **Reviews** section of the change order, pick a role, then a user or team that holds it.
    2. Click **Move into Review**. ION refuses the move and says why when the change order has no inventory in scope, no reviewer assigned, or an unconfirmed difference.

    The change order moves to **Approved** once every reviewer approves. To make more changes, click **Return to draft** in the **More options** menu.
  </Step>

  <Step title="Apply the change">
    Applying re-points each unit's aBOM at the target version and carries out the resolutions you confirmed. It's available once the change order is **Approved**.

    * To apply one unit, click **Apply Change** on its group.
    * To apply several, select their rows and click **Apply mBOM Change to Inventory (`<n>`)**.
    * To apply every unit still open, click **Apply all (`<n>`)** and confirm.

    Each apply is all or nothing. If one unit fails a check, ION rolls back the whole batch, so the change order is never half applied.

    ION refuses the apply on a unit that has drifted since its rows were written, and says which unit and why. Drift covers a build requirement that has moved and a unit that has since been re-pointed at a different mBOM version, and a unit emptied to zero quantity is refused here too. Take the change order back to draft with **Return to draft**, recompute its differences, confirm the rows again, and send it back for review.
  </Step>

  <Step title="Mark it complete">
    Once the units you meant to change are applied, click **Mark as complete** in the **More options** menu. When units are still open, the confirmation says they'll be canceled.
  </Step>
</Steps>

## Cancel a change order

Click **Cancel** in the **More options** menu, then confirm in **Cancel this change order?**. Canceling stops the update on every unit. The resolutions already recorded stay for audit, and the mBOM version itself is untouched.

<Warning>
  Once any unit has applied its change, ION refuses to cancel the change order and says so. Cancel the units still open, then mark the change order complete.
</Warning>

## Related

* [Change orders overview](/build-hardware/change-orders)
* [Manage BOM versions](/build-hardware/bills-of-materials/versions)
* [As-built BOM (aBOM)](/build-hardware/bills-of-materials/as-built-bom)
* [Editing build requirements](/build-hardware/bills-of-materials/editing-build-requirements)