- Project BOM: the same part can now be assigned to multiple items in the same BOM. This affects how a given part's availability is calculated (see below)
- Project Builds:
Assemble Qtyon planned items can now be changed and reset to original one. Once the item has been assembled or inventory is reserved,
Assemble Qtycannot be changed anymore
Enforce quote selectionis enabled (Settings > Workspace), items on a Purchase List without a quote will result in an error instead of a warning
- History events added:
- History log events are now coloured for easier visual identification
- Double clicking on most tables will trigger the
Editaction (if available)
[fix]Project Builds: prevent inventory to be decremented twice when assembling items from reserved inventory
[fix]Project BOM: allow using
-on BOM reference designators when not using it as a range (e.g
[fix]Don't generate history log when adjusting inventory with zero quantity
[fix]Create Purchase Order when
Enforce quote selectionis disabled
Assigning the Same Part To Multiple BOM Items
Previously, a single part could be assigned to a single BOM item only. This is not convenient, specially if later on a project build one part is replaced by an alternate one which happens to be already assigned to another item. Being able to use the same part in multiple BOM items is then essential.
This affects how availability is calculated though. Taking the example below:
In total we need 900 units but we only have 509 on-hand, so only the first item, that requires 300, can be assembled (or inventory can be reserved for). Items that have availability only partially cannot be assembled nor inventory can be reserved for.
Changing Quantities on a Project Build
You can now change the
Assembly Qty on items that don't have any
Sources defined yet (whether because inventory has been reserved or because those items have been assembled already). Once changed, the quantity can also be reset to its original value.
More (and Colourful) History Events
When looking through the History table of a part, it could be hard to interpret some apparent "gaps" on inventory. This is because when inventory is reserved it's no longer
on-hand, but reserving/unreserving inventory hasn't been logged in history. So, on the next
inventory changed event you'd see an initial quantity that wouldn't match the quantity on the previous
inventory changed event for that same storage location.
For this reason, there are now 3 additional events:
inventory unreserved and
inventory consumed. While the first two directly affect your
on-hand inventory by decreasing and increasing it, respectively, the last one as no effect but allows us to see that inventory previously reserved was at some point consumed (i.e. assembled in a project build).
On top of this additional information, events are now also coloured so they can be visually identified more easily.
inventory moved history log now includes the original and current quantities on each location.