Skip to main content
When a subset of units on a run develops a problem, you can split those units off into a separate location and keep the rest of the run moving. You create an issue ticket for the affected units, assign them a location such as an MRB cage, and continue running the remaining units. For how ION divides inventory by install state, see the Overview. For example, during receiving you inspect 10 parts from a supplier and find that 3 have visual defects. You split those 3 parts onto an issue, move them to a separate location, and let the other 7 continue through your process. For more information, see Issues.

How inventory splits by install state

When you split units off a run, ION divides inventory based on how far each unit has progressed: no installs, full or partial installs, or a mix. The final locations of child inventory reflect the locations of the child parts after the split.

No parts installed yet

Nothing has been installed onto the units being produced. When you split off some units, ION divides all required parts between the two groups. Each split-off group gets its own list of parts to install, and because nothing was installed beforehand, each group’s requirements are independent.

Some or all parts installed

Work has started and some parts are installed. When you split off a few units, ION cannot tell which installed parts belong to which group. ION links both sets of units, the ones staying in production and the ones you split off, to the already-installed parts. Each group shows the installed parts as shared, meaning the parts could belong to either set. This keeps every part accounted for and gives both groups the components they need.

Mix of installed and uninstalled parts

Some parts are installed and others are not. ION handles the installed parts as in the previous case, linking them to both groups and showing them as shared. ION allocates the uninstalled parts separately to each group based on the split. Production continues for the unaffected units while the split-off units stay accounted for.

aBOM installation sharing among parent assemblies

When aBOM installations are shared across split parent assemblies, calculate how much quantity and cost to attribute to one aBOM by dividing the shared installation across the parent assemblies it could belong to. A build requirement that was already installed before the split becomes a single install record linked to every lot that resulted from the split. Each of those lots shows the part as installed, and the aBOM for each lot lists the same install. This keeps the original build history intact for lots that share upstream work, rather than duplicating an install that only one lot could physically own. Because the sharing lots point at one record, an edit made from any of them reaches all of them. Adding an install, changing an installed quantity, or removing an install applies to every lot the build requirement is linked to, not only the lot on screen. A build requirement that was empty at the time of the split is instead copied independently to each lot, so later installs on one lot stay on that lot. ION marks a shared install on the build requirement row so you can tell before you edit. The row shows a Shared with N lots indicator, and opening it lists the lots the install is linked to, grouped as:
  • Direct siblings: the lots produced together in the same split as the lot you are viewing.
  • Other related lots: lots that share the install through an earlier or later split in a multi-generation chain, such as a lot split once into LOT-AB, then split again into LOT-ABC.

Remove a shared install

Removing an install from a shared build requirement removes it from every lot in the sharing set at once, so ION confirms the action first.
  1. On the build requirement, start the uninstall.
  2. In the Warning: Removing from a shared aBOM dialog, review the affected lots, grouped into Direct siblings and Other related lots.
  3. Click Cancel to keep the install, or Continue to remove it from every listed lot.
  4. After you confirm, the removal is held for about 10 seconds. A countdown toast lets you Cancel before it applies. If you don’t cancel within that window, the install is removed from every sharing lot.
Install and quantity changes on a shared build requirement apply to every linked lot without a separate confirmation. Only removing an install opens the confirmation dialog, because it clears the install from all sharing lots at once. Read the affected-lot list before you continue, and click Cancel on the countdown toast if you started the removal on the wrong set.
Per-lot divergence, where each lot after a split can carry a fully independent aBOM, is a separate capability under development. Today, an install that existed before a split stays shared across the resulting lots until you uninstall it.