An As-built Bill of Materials (aBOM) tracks the build process of parts in a hierarchical tree structure. The aBOM will track which part instances and lots are used within the creation of parts, subsystems, and systems. The aBOM can be thought of as a more intricate copy of the mBOM, with relations to physical inventory objects rather than parts.
ABOM Items | Description |
id | Unique identifier of the aBOM Item |
originMbomItem | Relation to the mBOM Item from which this aBOM Item originated |
partInventory | Inventory object, must be from the part specified in the originMbomItem or one of its valid mBOM substitutes |
parent | Parent aBOM Item |
children | Children aBOM Items |
query ABOMItems($filters: ABomItemsInputFilters) {abomItems(filters: $filters) {edges{node {idoriginMbomItem { id }parent { id }partInventory { id }children { id }}}}}
{"filters": {"parentId": {"eq": 1}}}
query ABOMItem {abomItem(id: 1) {idoriginMbomItem { id }parent { id }partInventory { id }children { id }}}
Mutation to query abom items
To create an aBOM, you will need a part that is tracked in inventory. See the Part Inventory API for details on creating inventory. A part with inventory will have a part number, and that part should have an mBOM. This mBOM will be used to create the aBOM.
In order to maximize traceability an aBOM Item is created for each quantity specified on the mBOM Item from which the aBOM Item originated. In the example below the origin part mBOM only contains one mBOM item with a quantity of three, therefore four aBOM items will be created. The first aBOM item is the parent aBOM item related to the part instance itself, the other three are the children aBOM items one for each of the specified quantities.
A run can be related to the part instance, which allows for the tracking of which part instances or lots are used within the run. Multiple runs can be related to a single part instance, but in this case we will create a single run which is responsible for the creation of the part instance.
mutation CreateRun($input: CreateRunInput!) {createRun(input: $input) {run {idtitlepartInventory {serialNumber}}}}
{"input": {"title": "abom test","procedureId": 1,"partInstanceId": 1}}
Trace is maintained at the inventory level, not the run. This is because the as-built tree is actually a property of the parts and not the process. If a partInventory does not have an aBOM record, you will need one to install components to it. A part does not necessarily need to have an aBOM tree of its own, if it's going to be installed in another part's aBOM. For example, a piece part bought from a supplier does not need an entire Trace aBOM tree to be installed in a higher level assembly.
mutation CreateABomForPartInventory($id: ID!, $etag: String!) {createAbomForPartInventory(id: $id, etag: $etag) {abomItem { id partInventoryId children { id } }}}
{"id": 1,"etag": "etag"}
When a an aBOM is created for a serialized part, its mBOM is used as a skeleton for the aBOM. To install serial-tracked, lot-tracked, or untracked inventory items into the aBOM, use the UpdateABomItem
mutation. The partInventoryId
is the serial or lot-tracked part that you are installing in the aBOM node for the top-level part.
mutation UpdateABomItem($input: UpdateABomItemInput!) {updateAbomItem(input: $input) {abomItem {id updatedById partInventoryId}}}
{"input": {"id": 1,"partInventoryId": 1,"etag": "etag"}}
There are restrictions on inventory items being installed on aBOMs, which are enforced and communicated by the API errors when an invalid transaction is made. For example, a serialized part can only appear in one aBOM.
Multiple transactions to an aBOM will give a tree structure, as shown below. For more information, see the Trace aBOMs section.