Workflow Discrepancy (PartKeepr to Inventree)

[bmalatest]

We are migrating from PartKeepr to Inventree for component and product management, and have found that the workflow that we currently use is not immediately applicable to Inventree, and that our understanding of the intended Inventree workflow/traceability might be lacking. As we haven’t really found any documentation on this, we’re putting together an internal document that describes the intended workflow, and once we figure it out, we would be happy to share it with the community and add it to the support site.

In the meantime, we’re trying to figure out the best way to handle some of the differences between how we used PartKeepr and the proposed workflow suggested by Inventree.

To help provide context, we’re going to first discuss our understanding of how to use Inventree for parts and to track and manage the component usage. Then, we will discuss some of the specific problems and challenges that we’re facing when trying to identify specific physical packages. We invite developers or users to share with us where we might be going wrong, or whether this is a potential future avenue of development.

Inventree Workflow

For components:
Add Parts to Inventree -> Add Supplier Parts that meet the description of the added Part

For PCBAs:
Add Parts to Inventree -> Add BOM to Part -> Create a build order to use components to populate PCBs

For Products (that are made up of PCBAs):
Add Parts to Inventree -> Add BOM to Part -> Create a build order to use PCBAs to create product (done on an individual basis to ensure traceability of which PCBAs are in which product)

Objective 1: Adding new components to Parts in Inventree

Intended Process:

1. Create high level parts (e.g., C-100n-0402-5%) 
2. Add manufacturer, MPN, distributors and associated part numbers for each of the high level parts (e.g., manufacturer KEMET, MPN C0402C104J4RAC7867, DigiKey, 399-C0402C104J4RAC7867CT-ND)

Discussion:

• Our understanding is that Inventree parts are used in a similar way to PartKeepr metaparts (i.e., a “part” is not associated with one physical component but can be associated with multiple physical parts. For example, an inventree part with the name: C-100n-0402-5, might represent a number of capacitors with 100nF capacitance, 0402 footprint, and a tolerance of 5%.

Questions:

1. Within PartKeepr, we have the option of not only associating specific physical components with a meta-part, but to also include all physical components with specific attributes. For example, instead of listing all physical component MPNs that have those parameters, we can choose to include all components meeting some criteria of at least or less than (e.g., all 100nF 0402 capacitors with 5% tolerance or better). Is something like this possible, or desirable, to do within Inventree? The only way we see that being possible is to add all manufacturer MPNs and distributor part numbers to the specific Part (i.e., not only the 5% but also the 2%, 1%, etc.) as opposed to being populated automatically based on specific criteria being met.

NB: This is a pretty valuable feature to us because it allows our manufacturing team greater freedom in overcoming supply chain shortages or constraints. It allows them to poll our existing inventory of engineering approved components and see whether there exist alternative components, and immediately submit them for an ECO.

Objective 2: Assigning unique identifier to components in Inventree

Intended Process:

3. Order the part (creating a purchase order or adding to an existing one)
4. Issue order for the PO and confirm order
5. Receive line items
    1. If the part arrives in multiple packages, each physical package is received separately by changing the quantity and MUST have a unique part ID that is associated with that specific package.
    2. There are three fields that can be entered for each physical part (Barcode, Location, and Batch Code). Location is self explanatory, but we have questions (see below) on the other two. 

Questions:

2. When receiving a new part, there are 3 parameters we can set. Location is self explanatory. We assumed that “barcode” would be the unique identifier and the “batch code” would be the lot code or other relevant identifying information from the manufacturer. However, we’re not sure if that’s correct or intended based on the “barcode” not being visible later on in the process. Moreover, we’re not sure what field we should be using to store a unique identifier for that physical package. This is especially important when a component comes in multiple packages (ie: two separately sealed trays), or is back ordered, or partially shipped. More importantly, how do we view those fields when actually manufacturing (see subsequent questions), to help ensure traceability?

Objective 3: Taking a new PCB project to production

Intended Process:

We understand the workflow to take a PCB project to production to be:

6. Create a PCBA part (called PCBA1)
7. Add the BOM to PCBA1 (identifying the high level parts (e.g., C-100n-0402-5%) and quantities)
8. Create a new build order for PCBA1 with desired quantity
9. Allocate stock
    1. When allocating stock items to build order, the information provided for making the selection is the high level part name, location, quantity available, and batch (see figure 1). It is at this point we need to be able to do 2 things:
        1. Identify and select the parts we want to kit and send for assembling the PCB
        2. Ensure that after we select the physical parts based on unique ID that we can get a report after to retrieve the physical parts and include them in our kit for assembly
10. Under Incomplete Outputs create a New Build Output with the quantity made and batch code desired
11. Under Incomplete Outputs, in the table found in the lower section of the screen, select the green check mark to update the status, location, notes, and confirm the output
12. Select Complete Build (top right) and confirm the build is complete
13. Under consumed stock you will see the parts that were selected that need to be included in the kit.
    1. There seems to be a step missing because it is only at this point can you generate a report of the components that are to be used in the assembly process but the PCBAs would still be in the assembly process when you need to select the parts (i.e., during allocation) but before the build is complete.
    2. Downloading the table data will show the physical parts that need to be included in the kit with the Batch being the only visible unique identifying field (referring to 5-2 above about which field to use during the receiving process to include a unique identifier)

Figure 1

Questions:

3. Once the parts are allocated to a specific build, is there a csv file that can be downloaded to show a list of all of the parts based a unique identifier? It does appear to be present in the Consumed stock but only after the build is complete, which we would need to know the parts at allocation and there would be a delay for the time the PCBAs are being assembled.

4. When specifying a specific Inventree part, we still need to know the actual physical component used during manufacturing. For example, during kitting, we need to know exactly what component needs to be sent to the assembly house. We logically believe that this should be managed by referencing the IPN of the component, but it looks like we actually need to place the unique identifier (which in PartKeepr is called internal part number (IPN)) in the “Batch” field, as opposed to the IPN field or “barcode” field. This leads us to believe that we must be doing something wrong, or else misunderstanding the intended use case.

[SchrodingersGat]

@bmalatest I'll break up this into multiple items to respond to - otherwise it will be very hard to comprehend it all at once :)

[SchrodingersGat]

Our understanding is that Inventree parts are used in a similar way to PartKeepr metaparts (i.e., a “part” is not associated with one physical component but can be associated with multiple physical parts. For example, an inventree part with the name: C-100n-0402-5, might represent a number of capacitors with 100nF capacitance, 0402 footprint, and a tolerance of 5%.

We do not directly have a compatible concept to the "metapart" in PartKeepr. We have some "similar" concepts which I will outline below.

Part Parameters

A Part instance can have defined parameters which can be used to categorise and search parts via attribute. e.g. length, package, voltage rating, tolerance, etc.

Note: Currently you cannot filter parts very well by parameter. This would be a good candidate for a sponsored feature ;)

Supplier Parts

In InvenTree, a single part can be used to represent multiple manufacturer parts, available from multiple suppliers. In this sense, you can have a single "part" in InvenTree which can be sourced from different suppliers / manufacturers. As an example, let's say that you have a part:

C-100n-0402-5

This has the following parameters:

Parameter	Value
Capacitance	100nF
Package	0402
Tolerance	5%

(... etc ... there could be many others!)

This part defines the properties of the part, but the actual capacitors are sourced from specific suppliers and have defined manufacturer part numbers, supplier part numbers, etc. So for a single given part you can define multiple supplier parts which meet the defined specification for that part.

Part Templates / Variants

Finally, you can have template parts which provide a reasonably complex functionality. These can be very useful if you have parts which you manufacture, and there are subtly different variants of the parts.

You could also make use of the template / variant pattern to create something approaching a "meta part". You can add the "template part" to the BOM, and then when it comes time to pick stock for a build order, you can allocate stock of one of the "variant" parts.

[diankov]

Note: Currently you cannot filter parts very well by parameter. This would be a good candidate for a sponsored feature ;)

@SchrodingersGat I've seen some FR tagged with Fund. Maybe you can add this one? We will consider sponsoring that!

[SchrodingersGat]

@diankov - #4851 for reference :)

[SchrodingersGat]

Within PartKeepr, we have the option of not only associating specific physical components with a meta-part, but to also include all physical components with specific attributes. For example, instead of listing all physical component MPNs that have those parameters, we can choose to include all components meeting some criteria of at least or less than (e.g., all 100nF 0402 capacitors with 5% tolerance or better). Is something like this possible, or desirable, to do within Inventree? The only way we see that being possible is to add all manufacturer MPNs and distributor part numbers to the specific Part (i.e., not only the 5% but also the 2%, 1%, etc.) as opposed to being populated automatically based on specific criteria being met.

My response above regarding parameters / suppliers / templates partially covers this here. The other point worth mentioning is that you can specify substitute line items in a BOM.

You can also place a Template Part in the BOM, which allows you to use variant parts when it comes time to populate the PCB (as an example)

Other than this, the process of allocating items to a BOM is (by design) an intensive process which must be carefully considered!

[SchrodingersGat]

When receiving a new part, there are 3 parameters we can set. Location is self explanatory. We assumed that “barcode” would be the unique identifier and the “batch code” would be the lot code or other relevant identifying information from the manufacturer. However, we’re not sure if that’s correct or intended based on the “barcode” not being visible later on in the process. Moreover, we’re not sure what field we should be using to store a unique identifier for that physical package. This is especially important when a component comes in multiple packages (ie: two separately sealed trays), or is back ordered, or partially shipped. More importantly, how do we view those fields when actually manufacturing (see subsequent questions), to help ensure traceability?

Barcode

The "barcode" field could be repurposed for this but it is really intended as a custom barcode, i.e. you scan a (unique) barcode on an incoming item and allocate it to that item.

Batch Code

This would be a good candidate. It is a free-form field which can be assigned to any stock item.

Metadata

Any stock item can have arbitrary metadata - this is intended to be used by plugins. This is not directly integrated with the user interface however (unless you have a plugin).

[SchrodingersGat]

Once the parts are allocated to a specific build, is there a csv file that can be downloaded to show a list of all of the parts based a unique identifier? It does appear to be present in the Consumed stock but only after the build is complete, which we would need to know the parts at allocation and there would be a delay for the time the PCBAs are being assembled.

Not currently, but the framework is in place to allow such a feature. We do have a system for exporting csv data, all the parts are there. But this is a feature which would require some work to implement. Happy to discuss sponsorship of this if you want to pursue it further.

[SchrodingersGat]

When specifying a specific Inventree part, we still need to know the actual physical component used during manufacturing. For example, during kitting, we need to know exactly what component needs to be sent to the assembly house. We logically believe that this should be managed by referencing the IPN of the component, but it looks like we actually need to place the unique identifier (which in PartKeepr is called internal part number (IPN)) in the “Batch” field, as opposed to the IPN field or “barcode” field. This leads us to believe that we must be doing something wrong, or else misunderstanding the intended use case.

When you allocate stock to a build order, the StockItem references a specific SupplierPart. So, in this case the information on the specific manufacturer part number is available when you actually allocate the stock.

If you want any further data, it can be extracted, either from available processes or via new features or a custom plugin. It depends on exactly what information you want for your assembler and in what format.