Inventory merging (org setting)
This organizational setting drives the Merge Inventories function by automatically consolidating identical part inventories from multiple receipts and purchase orders into a single inventory record.
This feature can be switched on and off by navigating to your Organization Settings in ION and selecting 'Merge Inventories (V2)', as shown below:

This functionality was developed to address the following challenges:
Manually managing separate inventory items for the same part across different POs and receipts
Multiple barcodes for identical parts lot tracked/untracked parts
Unnecessary inventory lines cluttering the system
Digital processes don't match real-world warehouse operations
This feature provides the following:
"Dump More Bolts in the Bin" - mirrors real-world warehouse operations where untracked and lot tracked COTS parts are naturally consolidated into single locations or bins,
Single Source of Truth - One barcode, one location, one inventory record
Seamless Consolidation - Automatically merge identical parts without losing traceability to purchase orders and receipts
Use Cases
✅ Use Case 1: Multiple Receipts, Different Purchase Orders
Scenario: Same part received on different dates from different suppliers
Example: 50 bolts received on Monday from Supplier A, 25 bolts received on Wednesday from Supplier B
Result: Automatically merges into single 75-bolt inventory with one barcode
✅ Use Case 2: Multiple Receipts, Same Purchase Order
Scenario: Same part received in multiple shipments against the same PO line
Example: 100 widgets ordered, received in 3 shipments (40 + 35 + 25)
Result: Consolidates into single 100-widget inventory while maintaining PO traceability
✅ Use Case 3: Non-PO Inventory Integration
Scenario: Additional inventory received without purchase order association
Example: Customer returns, engineering samples, or transferred inventory from other locations
Result: Seamlessly rolls into total available inventory count
Details
Note: If Merge Inventories V1 is also turned on via the feature flag, and the the V2 org setting is switched on, inventory will be merged according to V2 logic (discussed below).
How to trigger merging:
By making a change to a part inventory in the Inventories page. This workflow can be seen in the video below, along with a general overview of the merge functionality
By partially kitting an inventory item, as shown in the picture below. The fact that the selected amount (shown in the blue box below) is less than the available amount (shown in the green box below), indicates that a partial kitting operation will occur. The merge occurs on the remaining un-kitted inventory.

By unkitting an inventory item
Installing inventory (Partial)
Uninstalling inventory
Removing inventory from an Issue
Note: Currently, merging is only triggered by customer interaction with the UI and not by any actions from scanning.
Merge criteria
In order for inventory items to be eligible for merge, the inventory candidates must have:
Same underlying part id; part must be of type 'part' and not a tool
Tracking type can be untracked or lot tracked, but cannot be serial tracked
If part is lot tracked, lot IDs must match
A part inventory with an assigned serial number will not be merged, even if the underlying part is not serial tracked
The same location, and location must be set (i.e. two inventories with no location assigned will not merge)
The same status, and status must be 'available' or 'unavailable'
The same unit of measurement
Merge candidate cannot be installed on another inventory's aBOM
Merge candidate cannot have installations on its aBOM
No related purchase order lines that are in 'canceled' status
No related runs
No related origin runs
No related issues
No related part kits
No related plan reservations
The quantity kitted and the quantity installed both should equal zero
Must not be a 'Part used to fix issue' on an issue related to another inventory
⚠️ Important Limitations:
Merge will NOT occur when the same part is referenced on different purchase order lines within the same receipt.
Relationships currently existing between merge candidates and the following objects may block a merge, resulting in an error (but no change in data) or may be lost during merge:
build_requirements
run_steps
part_kit_items
origin_mbom
part_inventories
made_on_assembly_child_part_inventories
made_on_assembly_parent_part_inventory
Additionally, foreign key references for part inventory id will not be updated in the following places:
part_inventories_attributed_parts
part_inventories_attributed_users
part_inventories_requirements
build_requirement_reference_designators
On inventories created through a merge from inventories that have related purchase orders with different suppliers, the supplier on the inventory will be equivalent to one of the multiple suppliers associated with the merge candidates. Not all of them will be reflected on the merged inventory itself, as shown in the query below. Also in the query below it can be observed that all supplier ids associated with a merged inventory can found by looking at related purchase order lines:

If a part inventory was created by a split from an inventory that ended up being a merge candidate, but the inventory in question was later excluded from merge candidacy (i.e. moved to a different location, having an issue opened against it etc.), that inventory will be excluded from merge, but when looking at its transaction history post-merge, it will appear that the inventory has been merged when it has not:

Additionally, there may be other incorrect or incomplete transaction history line items related to an inventory being merged in this UI.
Finally, looking up transaction history on an inventory that has been merged (and thus deleted) will show an error in the UI, though the transaction history for that inventory will be available.

Differences from Merge Inventories set through Feature Flag:
Criteria for assessing merge candidates for a given inventory has changed (see above)
Upon merge, a new part inventory is created and the part inventories to be merged are deleted
Each custom attribute that has the same value across all merge candidates will have the value copied over to the new part inventory
Comments, file attachments and labels are copied over
No transaction history will exist prior to the merge for the newly created merged inventory (traceability to related PO lines and receipts is maintained)
Old barcodes for the inventories that were merged in will now point to the new merged inventory
Last updated
Was this helpful?