inventree/InvenTree
2
0
Fork 0
mirror of https://github.com/inventree/InvenTree.git synced 2025-12-17 09:48:30 +00:00
Code Activity

Docs refactor (#9545)

Browse Source 
* Refactor / reognaize docs structure

* Refactor plugin docs structure

* More refactoring / cleanup

* Update build images

* Gallery updates

* Order images

* Update part docs

* Settings images

* Stock images

* Reitntroduce gallery

* Add custom icon macro

* Update icons

* Cleanup

* Fix link

* Fix internal links

* Revert some page moves

* Fix links

* Fix links
This commit is contained in:
Oliver
2025-04-22 08:18:32 +10:00
committed by GitHub
parent 9b489911e5
commit 6b08e45eac
240 changed files with 964 additions and 831 deletions
Download Patch File Download Diff File Expand all files Collapse all files

154
docs/docs/manufacturing/allocate.md Normal file
View File

@@ -0,0 +1,154 @@
---
title: Build Allocation
---
## Build Allocation
Allocating stock items to a build order signals an intent that those stock items will be removed from the InvenTree database once the build order is completed.
Depending on the particular requirements of the build, and your stock control setup, allocating stock items to a build can be a complex task. In this regard, InvenTree provides an allocation interface which attempts to keep the number of user interactions required to a minimum.
!!! warning "Build Completion"
Marking a build as *complete* will remove allocated items from stock. This operation cannot be reversed, so take care!
### Untracked vs Tracked Stock
Before continuing, it is important that the difference between *untracked* and *tracked* parts, as they impose different requirements when it comes to stock allocation.
#### Untracked Stock
*Untracked* stock items are consumed against the build order, once the order is completed. When a build order is completed, any allocated stock items which are not [trackable](../part/trackable.md) are marked as *consumed*. These items remain in the InvenTree database, but are unavailable for use in any stock operations.
!!! info "Example: Untracked Parts"
You require 15 x 47K resistors to make a batch of PCBs. You have a reel of 1,000 resistors which you allocate to the build. At completion of the build, the available stock quantity is reduced to 985.
#### Tracked Stock
[Tracked](../part/trackable.md) stock items, on the other hand, require special attention. These are parts which we wish to track against specific [build outputs](./output.md). When the build order is completed, *tracked* stock items are installed *within* the assembled build output.
!!! info "Example: Tracked Parts"
The assembled PCB (in the example above) is a *trackable* part, and is given a serial number #001. The PCB is then used to make a larger assembly in a subsequent build order. At the completion of that build order, the tracked PCB is *installed* in the assembly.
#### BOM Considerations
A [Bill of Materials](./bom.md) to generate an assembly may consist of a mixture of *untracked* and *tracked* components. The build order process can facilitate this, as documentated in the sections below.
### Tracked Build Outputs
If a Build Order is created for an assembled part which is itself designed as *trackable*, some extra restrictions apply:
- Build outputs must be single quantity
- Build outputs must be serialized as they are created
## Allocating Untracked Stock
Untracked stock items are allocated against the *Build Order* itself. We do not need to track which *Build Output* these items will be installed into, and so the allocation process can be simplified.
Navigate to the *Allocate Stock* tab to view the stock allocation table:
{% with id="build_allocate_detail", url="build/build_allocate_detail.png", description="Allocate stock" %}
{% include "img.html" %}
{% endwith %}
In this example, there are two BOM line items which have been partially allocated to the build. Each line has a progress bar indicating how much of the required stock has been allocated.
Clicking on a particular row expands the row, showing a list of stock items which have been allocated against this build.
!!! info "Multiple Allocations"
Note that multiple stock items can be allocated to the given BOM line, if a single stock item does not have sufficient stock
{% with id="build_allocation_expand", url="build/build_allocation_expand.png", description="Allocate expand" %}
{% include "img.html" %}
{% endwith %}
## Manual Stock Allocation
For each line in the BOM, stock will be automatically allocated if one (and only one) stock item (for the referenced part) is found (within the specified *source location* for the build):
Selecting *Allocate Stock* opens a dialog window which displays the stock items which will be allocated to the build during the auto allocation process:
{% with id="build_auto", url="build/build_auto_allocate.png", description="Auto allocate" %}
{% include "img.html" %}
{% endwith %}
Note here that there are two parts in the BOM which can be automatically allocated, as they only have a single corresponding StockItem available.
However the other BOM line item exists in multiple locations, and thus cannot be automatically allocated. These will need to be manually selected by the user.
### Row Allocation
Stock can be manually allocated to the build as required, using the *Allocate stock* button available in each row of the allocation table
### Edit Allocations
Stock allocations can be manually adjusted or deleted using the action buttons available in each row of the allocation table.
### Deallocate Stock
The *Deallocate Stock* button can be used to remove all allocations of untracked stock items against the build order.
## Automatic Stock Allocation
To speed up the allocation process, the *Auto Allocate* button can be used to allocate untracked stock items to the build. Automatic allocation of stock items does not work in every situation, as a number of criteria must be met.
The *Automatic Allocation* dialog is presented as shown below:
{% with id="auto_allocate_dialog", url="build/auto_allocate_dialog.png", description="Automatic allocation dialog" %}
{% include "img.html" %}
{% endwith %}
**Source Location**
Select the master location where stock items are to be allocated from. Leave this input blank to allocate stock items from any available location.
**Interchangeable Stock**
Set this option to *True* to signal that stock items can be used interchangeably. This means that in the case where multiple stock items are available, the auto-allocation routine does not care which stock item it uses.
!!! warning "Take Care"
If the *Interchangeable Stock* option is enabled, and there are multiple stock items available, the results of the automatic allocation algorithm may somewhat unexpected.
!!! info "Example"
Let's say that we have 5 reels of our *C_100nF_0603* capacitor, each with 4,000 parts available. If we do not mind which of these reels the stock should be taken from, we enable the *Interchangeable Stock* option in the dialog above. In this case, the stock will be allocated from one of these reels, and eventually subtracted from stock when the build is completed.
**Substitute Stock**
Set this option to *True* to allow substitute parts (as specified by the BOM) to be allocated, if the primary parts are not available.
## Allocating Tracked Stock
Allocation of tracked stock items is slightly more complex. Instead of being allocated against the *Build Order*, tracked stock items must be allocated against an individual *Build Output*.
Allocating tracked stock items to particular build outputs is performed in the *Pending Items* tab:
In the *Pending Items* tab, we can see that each build output has a stock allocation requirement which must be met before that build output can be completed:
{% with id="build_allocate_tracked_parts", url="build/build_allocate_tracked_parts.png", description="Allocate tracked parts" %}
{% include "img.html" %}
{% endwith %}
Here we can see that the incomplete build outputs (serial numbers 15 and 14) now have a progress bar indicating the status of tracked stock item allocation:
- Serial number 15 has been fully allocated, and can be completed
- Serial number 14 has not been fully allocated, and cannot yet be completed
### Allocated Stock
*Tracked* stock items which are allocated against the selected build output will be removed from stock, and installed "inside" the output assembly. The allocated stock items will still exist in the InvenTree database, however will no longer be available for regular stock actions.
!!! note "Example: Tracked Stock"
Let's say we have 5 units of "Tracked Part" in stock - with 1 unit allocated to the build output. Once we complete the build output, there will be 4 units of "Tracked Part" in stock, with 1 unit being marked as "installed" within the assembled part
## Completing a Build
!!! warning "Complete Build Outputs"
A build order cannot be completed if there are outstanding build outputs. Ensure that all [build outputs](./output.md) are completed first.
Once all build outputs have been completed, the build order itself can be completed by selecting the *Complete Build* button:
{% with id="build_complete", url="build/complete_build.png", description="Complete build order" %}
{% include "img.html" %}
{% endwith %}
### Allocated Stock
All *untracked* stock items which are allocated against this build will be removed from stock, and *consumed* by the build order. These consumed items can be later viewed in the [consumed stock tab](./build.md#consumed-stock).

121
docs/docs/manufacturing/bom.md Normal file
View File

@@ -0,0 +1,121 @@
---
title: Bill of Materials
---
## Bill of Materials
A Bill of Materials (BOM) defines the list of component parts required to make an assembly, [create builds](./build.md) and allocate inventory.
A part which can be built from other sub components is called an *Assembly*.
{% with id="bom_flat", url="build/bom_flat.png", description="Flat BOM Table" %}
{% include 'img.html' %}
{% endwith %}
## BOM Line Items
A BOM for a particular assembly is comprised of a number (zero or more) of BOM "Line Items", each of which has the following properties:
| Property | Description |
| --- | --- |
| Part | A reference to another *Part* object which is required to build this assembly |
| Quantity | The quantity of *Part* required for the assembly |
| Reference | Optional reference field to describe the BOM Line Item, e.g. part designator |
| Overage | Estimated losses for a build. Can be expressed as absolute values (e.g. 1, 7, etc) or as a percentage (e.g. 2%) |
| Consumable | A boolean field which indicates whether this BOM Line Item is *consumable* |
| Inherited | A boolean field which indicates whether this BOM Line Item will be "inherited" by BOMs for parts which are a variant (or sub-variant) of the part for which this BOM is defined. |
| Optional | A boolean field which indicates if this BOM Line Item is "optional" |
| Note | Optional note field for additional information
### Consumable BOM Line Items
If a BOM line item is marked as *consumable*, this means that while the part and quantity information is tracked in the BOM, this line item does not get allocated to a [Build Order](./build.md). This may be useful for certain items that the user does not wish to track through the build process, as they may be low value, in abundant stock, or otherwise complicated to track.
In the example below, see that the *Wood Screw* line item is marked as consumable. It is clear that 12 screws are required for each assembled *Table*, but the screws will not be tracked through the build process, as this line item is marked as *consumable*
{% with id="bom_item_consumable", url="build/bom_consumable_item.png", description="Consumable BOM Item" %}
{% include 'img.html' %}
{% endwith %}
Further, in the [Build Order](./build.md) stock allocation table, we see that this line item cannot be allocated, as it is *consumable*.
### Substitute BOM Line Items
Where alternative parts can be used when building an assembly, these parts are assigned as *Substitute* parts in the Bill of Materials. A particular line item may have multiple substitute parts assigned to it. When allocating stock to a [Build Order](./build.md), stock items associated with any of the substitute parts may be allocated against the particular line item.
!!! tip "Available Quantity"
When calculating the *available quantity* of a particular line item in a BOM, stock quantities associated with substitute parts are included in the calculation.
### Inherited BOM Line Items
When using the InvenTree [template / variant](../part/template.md) feature, it may be useful to make use of the *inheritance* capability of BOM Line Items.
If a BOM Line Item is designed as *Inherited*, it will be automatically included in the BOM of any part which is a variant (or sub-variant) of the part for which the BOM Line Item is defined.
This is particularly useful if a template part is defined with the "common" BOM items which exist for all variants of that template.
Consider the example diagram below:
{% with id="inherited_bom", url="build/inherited_bom.png", description="Inherited BOM Line Items" %}
{% include 'img.html' %}
{% endwith %}
**Template Part A** has two BOM line items defined: *A1* and *A2*.
- *A1* is inherited by all variant parts underneath *Template Part A*
- *A2* is not inherited, and is only included in the BOM for *Template Part A*
**Variant B** has two line items:
- *A1* is inherited from parent part *A*
- *B1* is defined for part *B* (and is also defined as an inherited BOM Line Item)
**Variant C**
- *A1* inherited from *A*
- *C1* defined for *C*
**Variant D**
- *A1* inherited from *A*
- *B1* inherited from *B*
- *D1* defined for *D*
**Variant E**
- Well, you get the idea.
Note that inherited BOM Line Items only flow "downwards" in the variant inheritance chain. Parts which are higher up the variant chain cannot inherit BOM items from child parts.
!!! info "Editing Inherited Items"
When editing an inherited BOM Line Item for a template part, the changes are automatically reflected in the BOM of any variant parts.
## BOM Creation
BOMs can be created manually, by adjusting individual line items, or by upload an existing BOM file.
### Add BOM Item
To manually add a BOM item, navigate to the part/assembly detail page then click on the "BOM" tab. On top of the tab view, click on the {{ icon("edit", color="blue", title="Edit") }} icon then, after the page reloads, click on the {{ icon("plus-circle") }} icon.
The `Create BOM Item` form will be displayed:
{% with id="bom_add_item", url="build/bom_add_item.png", description="Create BOM Item Form" %}
{% include 'img.html' %}
{% endwith %}
Fill-out the `Quantity` (required), `Reference`, `Overage` and `Note` (optional) fields then click on <span class="badge inventree confirm">Submit</span> to add the BOM item to this part's BOM.
### Add Substitute for BOM Item
To manually add a substitute for a BOM item, click on the {{ icon("transfer") }} icon in the *Actions* columns.
The `Edit BOM Item Substitutes` form will be displayed:
{% with id="bom_substitute_item", url="build/bom_substitute_item.png", description="Edit BOM Item Substitutes" %}
{% include 'img.html' %}
{% endwith %}
Select a part in the list and click on "Add Substitute" button to confirm.
## Multi Level BOMs
Multi-level (hierarchical) BOMs are natively supported by InvenTree. A Bill of Materials (BOM) can contain sub-assemblies which themselves have a defined BOM. This can continue for an unlimited number of levels.

306
docs/docs/manufacturing/build.md Normal file
View File

@@ -0,0 +1,306 @@
---
title: Build Orders
---
## Build Orders
A *Build Order* is used to create new stock by assembling component parts, according to a [Bill of Materials](./bom.md) (BOM).
A BOM can be specified for any [Part](../part/index.md) which is designated as an *Assembly*. The BOM consists of other Parts which are designated as *Components*.
A *Build Order* uses the BOM to allocate stock items to the assembly process. As the *Build Order* is completed, the required stock quantities are subtracted from allocated stock items.
### View Build Orders
To navigate to the Build Order display, select *Manufacturing* from the main navigation menu, and *Build Orders* from the sidebar.
The *Build Order Index Page* allows the user to view all build orders:
{% with id="build_display", url="build/build_display.png", description="Display Builds" %}
{% include "img.html" %}
{% endwith %}
The following view modes are available:
#### Table View
*Table View* provides a table of Build Orders, which can be filtered to only show the orders you are interested in.
{% with id="build_list", url="build/build_list.png", description="Build List" %}
{% include "img.html" %}
{% endwith %}
#### Calendar View
*Calendar View* shows a calendar display with outstanding build orders, based on the various dates specified for each order.
{% with id="build_calendar", url="build/build_calendar.png", description="Build Calendar" %}
{% include "img.html" %}
{% endwith %}
The build calendar allows the user to navigate month-by-month and display the filtered build orders
## Build Order Details
### Build Order Reference
Each Build Order is uniquely identified by its *Reference* field. Read more about [reference fields](../settings/reference.md).
### Build Parameters
The following parameters are available for each Build Order, and can be edited by the user:
| Parameter | Description |
| --- | --- |
| Reference | Build Order reference e.g. '001' |
| Description | Description of the Build Order |
| Part | Link to the *Part* which will be created from the Build Order |
| Quantity | Number of stock items which will be created from this build |
| Sales Order | Link to a *Sales Order* to which the build outputs will be allocated |
| Source Location | Stock location to source stock items from (blank = all locations) |
| Destination Location | Stock location where the build outputs will be located |
| Start Date | The scheduled start date for the build |
| Target Date | Target date for build completion |
| Responsible | User (or group of users) who is responsible for the build |
| External Link | Link to external webpage |
| Notes | Build notes, supports markdown |
### Build Output
A *Build Output* creates a new stock instance of the assembly part, of a specified quantity. Each *Build Order* requires at least one build output. Multiple build outputs can be specified if the build is completed in batches.
Read more about build outputs [here](./output.md).
### Build Status
Each *Build Order* has an associated *Status* flag, which indicates the state of the build:
| Status | Description |
| ----------- | ----------- |
| `Pending` | Build order has been created, but is not yet in production |
| `Production` | Build order is currently in production |
| `On Hold` | Build order has been placed on hold, but is still active |
| `Cancelled` | Build order has been cancelled |
| `Completed` | Build order has been completed |
**Source Code**
Refer to the source code for the Build Order status codes:
::: build.status_codes.BuildStatus
options:
show_bases: False
show_root_heading: False
show_root_toc_entry: False
show_source: True
members: []
### Stock Allocations
When a *Build Order* is created, we then have the ability to *allocate* stock items against that build order. The particular parts we need to allocate against the build are specified by the BOM for the part we are assembling.
- A *Stock Allocation* links a certain quantity of a given *Stock Item* to the build.
- At least one stock allocation is required for each line in the BOM
- Multiple stock allocations can be made against a BOM line if a particular stock item does not have sufficient quantity for the build
!!! info "Example - Stock Allocation"
Let's say that to assembly a single "Widget", we require 2 "flanges". So, to complete a build of 10 "Widgets", 20 "flanges" will be required. We *allocate* 20 flanged against this build order.
Allocating stock to a build does not actually subtract the stock from the database. Allocations signal an *intent* to take that stock for the purpose of this build. Stock allocations are subtracted from stock at the completion of a build.
!!! info "Part Allocation Information"
Any part which has stock allocated to a build order will indicate this on the part information page.
For further information, refer to the [stock allocation documentation](./allocate.md).
## Build Order Display
The detail view for a single build order provides multiple display panels, as follows:
### Build Details
The *Build Details* panel provides an overview of the Build Order:
{% with id="build_details", url="build/build_panel_details.png", description="Build details panel" %}
{% include "img.html" %}
{% endwith %}
### Line Items
The *Line Items* panel displays all the line items (as defined by the [bill of materials](./bom.md)) required to complete the build order.
{% with id="build_allocate", url="build/build_panel_line_items.png", description="Build line items panel" %}
{% include "img.html" %}
{% endwith %}
The allocation table (as shown above) provides an interface to allocate required stock, and also shows the stock allocation progress for each line item in the build.
### Incomplete Outputs
The *Incomplete Outputs* panel shows the list of in-progress [build outputs](./output.md) (created stock items) associated with this build.
{% with id="build_outputs", url="build/build_outputs.png", description="Outputs tab" %}
{% include "img.html" %}
{% endwith %}
!!! info "Example: Build Outputs"
In the example image above, a single output (serial number 2) has been completed, while serial numbers 1 and 4 are still in progress.
- Build outputs can be created from this screen, by selecting the *Create New Output* button
- Outputs which are "in progress" can be completed or cancelled
- Completed outputs (which are simply *stock items*) can be viewed in the stock table at the bottom of the screen
### Completed Outputs
This panel displays all the completed build outputs (stock items) which have been created by this build order:
### Allocated Stock
The *Allocated Stock* tab displays all stock items which have been *allocated* to this build order. These stock items are reserved for this build, and will be consumed when the build is completed:
{% with id="allocated_stock_table", url="build/allocated_stock_table.png", description="Allocated Stock Table" %}
{% include "img.html" %}
{% endwith %}
### Consumed Stock
The *Consumed Stock* tab displays all stock items which have been *consumed* by this build order. These stock items remain in the database after the build order has been completed, but are no longer available for use.
- [Tracked stock items](./allocate.md#tracked-stock) are consumed by specific build outputs
- [Untracked stock items](./allocate.md#untracked-stock) are consumed by the build order
### Child Builds
If there exist any build orders which are *children* of the selected build order, they are displayed in the *Child Builds* tab:
{% with id="build_childs", url="build/build_childs.png", description="Child builds panel" %}
{% include "img.html" %}
{% endwith %}
### Test Results
For *trackable* parts, test results can be recorded against each build output. These results are displayed in the *Test Results* panel:
{% with id="build_test_results", url="build/build_panel_test_results.png", description="Test Results panel" %}
{% include "img.html" %}
{% endwith %}
This table provides a summary of the test results for each build output, and allows test results to be quickly added for each build output.
### Test Statistics
For *trackable* parts, this panel displays a summary of the test results for all build outputs:
{% with id="build_test_stats", url="build/build_panel_test_statistics.png", description="Test Statistics panel" %}
{% include "img.html" %}
{% endwith %}
### Attachments
Files attachments can be uploaded against the build order, and displayed in the *Attachments* tab:
{% with id="build_attachments", url="build/build_attachments.png", description="Attachments tab" %}
{% include "img.html" %}
{% endwith %}
### Notes
Build order notes (which support markdown formatting) are displayed in the *Notes* tab:
{% with id="build_notes", url="build/build_notes.png", description="Notes tab" %}
{% include "img.html" %}
{% endwith %}
## Create Build Order
To create a build order for your part, you have two options:
### Part Detail Page
- Navigate to the detail page for the assembly part you wish to create
- Select the *Build Orders* tab
- Select *Start new Build*
{% with id="build_create_from_part", url="build/build_create_from_part.png", description="Create build from Part view" %}
{% include "img.html" %}
{% endwith %}
### Build Order Page
- Navigate to the Build Order overview page
- Click on *New Build Order*
Fill-out the form as required, then click the "Submit" button to create the build.
### Create Child Builds
When creating a new build order, you have the option to automatically generate build orders for any subassembly parts. This can be useful to create a complete tree of build orders for a complex assembly. *However*, it must be noted that any build orders created for subassemblies will use the default BOM quantity for that part. Any child build orders created in this manner must be manually reviewed, to ensure that the correct quantity is being built as per your production requirements.
## Complete Build Order
To complete a build, click on {{ icon("tools") }} icon on the build detail page, the `Complete Build` form will be displayed.
The form will validate the build order is ready to be completed, and will prevent you from continuing if any of the below conditions are present unless you select one of the presented options to override the validation and accept completion of the build anyway.
!!! info "Incomplete Build"
If the warning message `Required build quantity has not been completed` is shown, you have build outputs that have not yet been completed.
In the unlikely event that you wish to proceed despite this, you can toggle the `Accept Incomplete` option to true to override the error and allow completion without the required number of build outputs.
!!! info "Incomplete Allocation"
If the warning message `Require stock has not been fully allocated` is shown, make sure to allocate stock matching all BOM items to the build before proceeding with build completion.
If you wish to complete the build despite the missing parts, toggle the `Accept Unallocated` option to true to override the warning and allow completion with unallocated parts.
!!! info "Overallocated Stock Items"
If the warning message `Some stock items have been overallocated` is shown, you have more stock than required by the BOM for the part being built allocated to the build order. By default the `Not permitted` option is selected and you will need to return to the allocation screen and remove the extra items before the build can be completed.
Alternatively, you can select `Accept as consumed by this build order` to continue with the allocation and remove the extra items from stock (e.g. if they were destroyed during build), or select `Deallocate before completing this build order` if you would like the extra items to be returned to stock for use in future builds.
Select a `Location` to store the resulting parts from the build then click on the confirmation switch.
Finally, click on the "Complete Build" button to process the build completion.
!!! warning "Completed Build"
**A completed build cannot be re-opened**. Make sure to use the confirm only if you are certain that the build is complete.
## Cancel Build Order
To cancel a build, click on {{ icon("circle-x", color="red") }} icon on the build detail page.
The `Cancel Build` form will be displayed, click on the confirmation switch then click on the "Cancel Build" button to process the build cancellation.
!!! warning "Cancelled Build"
**A cancelled build cannot be re-opened**. Make sure to use the cancel option only if you are certain that the build won't be processed.
## Build Scheduling
Build orders can be scheduled for a future date, to allow for planning of production schedules.
### Start Date
Build orders can be optionally scheduled to *start* at a specified date, by setting the *Start Date* field. This field can be left blank if the build is to start immediately.
### Target Date
Build orders can be optionally scheduled to be completed by a certain date, by setting the *Target Date* field. This field can be left blank if the build has no specific deadline.
### Overdue Builds
If the *Target Date* is reached but the build order remains incomplete, then the build is considered *overdue*.
This can be useful for tracking production delays, and can be used to generate reports on build order performance.
## Build Order Settings
The following [global settings](../settings/global.md) are available for adjusting the behavior of build orders:
| Name | Description | Default | Units |
| ---- | ----------- | ------- | ----- |
{{ globalsetting("BUILDORDER_REFERENCE_PATTERN") }}
{{ globalsetting("BUILDORDER_REQUIRE_RESPONSIBLE") }}
{{ globalsetting("BUILDORDER_REQUIRE_ACTIVE_PART") }}
{{ globalsetting("BUILDORDER_REQUIRE_LOCKED_PART") }}
{{ globalsetting("BUILDORDER_REQUIRE_VALID_BOM") }}
{{ globalsetting("BUILDORDER_REQUIRE_CLOSED_CHILDS") }}
{{ globalsetting("PREVENT_BUILD_COMPLETION_HAVING_INCOMPLETED_TESTS") }}

57
docs/docs/manufacturing/example.md Normal file
View File

@@ -0,0 +1,57 @@
---
title: Build Order Example
---
## Build Order Example
For example, let's say we wish to create 10 new "Widgets". We create a new build for the widget, which signals an *intent* to assemble the "Widget" in quantity 10. As the *Widget* is a serialized part, with tracked subcomponents, the build outputs must themselves be serialized. This means that we need to generate 10 separate build outputs for this build order.
### Create Build Order
First, create a new build order for the *Widget* assembly:
{% with id="build_example_create", url="build/build_example_create.png", description="Create build order" %}
{% include "img.html" %}
{% endwith %}
### Generate Build Outputs
Generate build outputs for this build order. As this is a tracked item, with tracked subcomponents, the build outputs must be serialized:
{% with id="build_example_create_outputs", url="build/build_example_create_outputs.png", description="Create build outputs" %}
{% include "img.html" %}
{% endwith %}
A list of new build outputs will have now been generated:
{% with id="build_example_incomplete_list", url="build/build_example_incomplete_list.png", description="Incomplete build outputs" %}
{% include "img.html" %}
{% endwith %}
### Allocate Untracked Stock
Untracked stock items are allocated to the build order in the *Allocate Stock* tab:
{% with id="build_example_allocate_untracked", url="build/build_example_allocate_untracked.png", description="Allocated Untracked Stock" %}
{% include "img.html" %}
{% endwith %}
### Allocate Tracked Stock
Tracked stock items are allocated to individual build outputs:
{% with id="build_example_allocate_tracked", url="build/build_example_allocated_tracked.png", description="Allocated Tracked Stock" %}
{% include "img.html" %}
{% endwith %}
### Complete Build Outputs
Mark each build output as complete:
{% with id="build_example_complete_outputs", url="build/build_example_complete_outputs.png", description="Complete Build Outputs" %}
{% include "img.html" %}
{% endwith %}
### Complete Build Order
Once the build outputs have been completed, and all stock has been allocated, the build order can be completed.

25
docs/docs/manufacturing/index.md Normal file
View File

@@ -0,0 +1,25 @@
---
title: Manufacturing
---
## Manufacturing
InvenTree offers a comprehensive and flexible manufacturing system designed to streamline production workflows, manage inventory consumption, and track build progress in real-time. It is ideal for organizations looking to manage in-house manufacturing, sub-assemblies, and production lines with high visibility and control.
### BOM Support
InvenTree provides comprehensive multi-level BOM (Bill of Material) support, allowing users to define complex assemblies with multiple sub-components. BOMs can be created and managed directly within the InvenTree interface, enabling users to easily track the components required for each assembly.
Read more about BOM management in the [BOM documentation](./bom.md).
### Build Orders
Build orders are used to manage the manufacturing process, allowing users to create and track production runs for specific assemblies. Each build order is linked to a specific BOM, ensuring that the correct components are consumed during the manufacturing process.
Read more about build orders in the [Build Order documentation](./build.md).
### Stock Allocation
InvenTree allows users to allocate stock items to specific build orders, ensuring that the required components are reserved for production. This helps to prevent stock shortages and ensures that the right parts are available when needed.
Read more about stock allocation in the [Stock Allocation documentation](./allocate.md).

119
docs/docs/manufacturing/output.md Normal file
View File

@@ -0,0 +1,119 @@
---
title: Build Outputs
---
## Build Outputs
With reference to a [build order](./build.md), a *Build Output* is a finished product which is expected to be produced by completing the order.
- A single build order may have multiple build outputs which are produced at different times or by different operators.
- An individual build output may be a single unit, or a batch of units
- Serial numbers and batch codes can be associated with a build output
### Incomplete Outputs
The *Incomplete Outputs* tab displays any outstanding / in-progress build outputs for the current build order.
{% with id="build-outputs-incomplete", url="build/build_outputs_incomplete.png", description="Incomplete build outputs" %}
{% include "img.html" %}
{% endwith %}
### Completed Outputs
The *Completed Outputs* tab displays any [completed](#complete-build-output) or [scrapped](#scrap-build-output) outputs for the current build order.
{% with id="build-outputs-complete", url="build/build_outputs_complete.png", description="Complete build outputs" %}
{% include "img.html" %}
{% endwith %}
## Create Build Output
Create a new build output by pressing the <span class="badge inventree add">{{ icon("plus-circle") }} New Build Output</span> button under the [incomplete outputs](#incomplete-outputs) tab:
{% with id="build_output_create", url="build/build_output_create.png", description="Create build output" %}
{% include "img.html" %}
{% endwith %}
### Create Options
The following options are available when creating a new build output:
| Option | Description |
| --- | --- |
| Quantity | The number of items to create as part of this build output |
| Serial Numbers | If this is a tracked build output, the serial numbers for each of the generated outputs |
| Batch Code | Batch code identifier for the generated output(s) |
| Auto Allocate Serial Numbers | If selected, any available tracked subcomponents which already have serial numbers assigned, will be automatically assigned to matching build outputs |
### Specifying Serial Numbers
Refer to the [serial number generation guide](../stock/tracking.md#generating-serial-numbers) for further information on serial number input.
## Complete Build Output
*Completing* a build output marks that output as finished, in the context of the given build order.
An individual build output is completed by selecting the "Complete build output" button associated with that build output:
{% with id="build_output_complete", url="build/build_output_complete.png", description="Complete build output" %}
{% include "img.html" %}
{% endwith %}
Here the user can select the destination location for the build output, as well as the stock item status.
Marking the build output(s) as complete performs the following actions:
- The completed build quantity is increased by the quantity of the selected build output(s)
- The build output(s) are marked as "completed", and available for stock actions
- Any [tracked BOM items](./allocate.md#allocating-tracked-stock) which are allocated to the build output are *installed* into that build output.
### Complete Options
The following options are available when completing a build output:
| Option | Description |
| --- | --- |
| Status | The [stock status](../stock/status.md) for the completed outputs |
| Location | The [stock location](../stock/index.md#stock-location) where the outputs will be located |
| Notes | Any additional notes associated with the completion of these outputs |
| Accept Incomplete Allocation | If selected, this option allows [tracked build outputs](./allocate.md#tracked-build-outputs) to be completed in the case where required BOM items have not been fully allocated |
## Scrap Build Output
*Scrapping* a build output marks the particular output as rejected, in the context of the given build order.
An individual build output is completed by selecting the *Scrap build output* button associated with that build output:
{% with id="build_output_scrap", url="build/build_output_scrap.png", description="Scrap build output" %}
{% include "img.html" %}
{% endwith %}
Marking the build output(s) as scrapped performs the following actions:
- The build outputs are marked as "rejected" and removed from the build
- The completed build quantity *does not increase*
- The build outputs are not available for any further stock actions
- Optionally, any [tracked BOM items](./allocate.md#allocating-tracked-stock) which are allocated to the build output are *installed* into the rejected build output
### Scrap Options
The following options are available when scrapping a build order:
| Option | Description |
| --- | --- |
| Location | The stock location where the scrapped build output(s) will be located |
| Notes | Any additional notes associated with the scrapping of these outputs |
| Discard Allocations | If selected, any installed BOM items will be removed first, before marking the build output as scrapped. Use this option if the installed items are recoverable and can be used elsewhere |
## Delete Build Output
*Deleting* a build output causes the build output to be cancelled, and removed from the database entirely. Use this option when the build output does not physically exist (or was never built) and should not be tracked in the database.
{% with id="build_output_delete", url="build/build_output_delete.png", description="Delete build output" %}
{% include "img.html" %}
{% endwith %}
Marking the build output(s) as deleted performs the following actions:
- Any allocated stock items are returned to stock
- The build output is removed from the database