Some big ideas, whishes and features in a big tirade

TLDR:

Items and Real world parts shouldn't be the same thing
Inventree is missing a way to auto-generate part Name, Description and IPN
I am proposing some new way to manage complex series of components with lots of variants, suppliers and alternatives.

Intro

I now have spend more than a week trying different ERPs and stock managers without finding anything that is up to my expectation. I think now is the time for the tools I have in my mind to come alive in some way. I'm sharing my ideas there because that project is gaining some traction and is a good candidate for integration with Kicad. I'm willing to put some effort into this and I am currently trying things out in python, but I'll need help for integration into existing codebases. I really enjoy the way ERPNext allows you to create variants from template parts, but their way of doing it is incomplete imo. Basically you have Attributes (like the Inventree parameters). Attributes have a fixed list of values and each values have an abbreviation. The abbreviation is used to generate parts name and internal reference. I would love to have the same mechanism implemented in Inventree but ameliorated:

Here is an example.

I have the Chip Resistors family, abbreviated 'RC'. Those Resistors have several common attributes independently of their Brand and MFN; Their type: Thin Film (N). Thick Film (K) Then there is the package... 0603 (1608 Metric) abbreviated '0603'. The values, for example 1.00kohms, abbreviated 1K00, and I want a dash '-' separator before this one. And tolerance with a dash also: 1% for example. From these data, I can generate a reference with description: RCK0603-1K00-1% (Chip Resistor, Thin Film, 0603 (1608 Metric), 1.00 kohm, 1%). I could have generated RCN0603-49R9-0.1% as easily while recycling some parameters.

What are the advantage

What I have in mind is to implement those kind of generators in Inventree, but with some enhancement compared to a simple item generator.

Your naming scheme is now immutable and consistent in time. You don't need to remember it.
Your internal naming is useful when designing a board and to sort your part storage, but it means nothing in the real world. The generator however can find what you are looking for because it know how to generate this link: 'Thin Film Chip Resistor 49.9 ohms 1%'.
The naming scheme for any part using generator is easy to remember because you create it exactly like you want, and simply typing a value from a known scheme in a kicad symbol value might enable you to find existing real world counterparts or create new inventree items fast.
As the parts are managed by a generator, any change made to the generator would be reflected on all the descendant items automagically. So, if your codification is incomplete from the start, you don't have to edit hundreds of items to reconciliate old and new naming schemes. It could be challenging however to then get back to schematic designs and change the references, but the generators when used as a search could maybe find the new reference from the old one.

How would the generators be implemented in Inventree:

I think some categories might be governed by a generator but it might not work for corner cases. Having item templates in your item list from which you generate variants is not a good idea. (this is how ERPNext does it) Generators could be global agents that knows where to put the generated item depending on the parameters and values selected during the creation. This last one looks like the best solution but it is only in my mind. I'm not sure how that would work exactly. Also, Parameters in Inventree are already globals which is going in the right direction, but they cannot be used to constraint the choices to some predefined values, or to generate custom codes. All of this need to be tried and I am currently working on a simple command line and dirty proof of concept python script.

Managing Variants and Alternatives:

One distinction needs to be made in Inventree (I've seen in another issue that it is confusing for some people right now): Variants are not Alternatives. Variants are incompatible between each others unless proved otherwise. NE5532 in DIP8 and NE5532 in SOIC8 are variants of NE5532, but you cannot solder them on the same footprint, so they are not alternatives. You might create a board that have both SOIC8 and DIP8 footprint for the NE5532. Then those two variants becomes alternatives for this board BOM. I should be able to specify a resistor on a board as RCK0603-330R and I should be able to then tell Inventree that RCK0603-330R-1% and 5% are alternatives in this case, but not RCK0603-330R-0.1% as this item real world parts are too expensive. The workaround right now for adding Alternatives is to add Suppliers to an item, but I think it should be improved.

Managing manufacturer and supplier part references.

The hardest issue I had when trying to make all of this works in my mind was to imagine how to reconciliate suppliers, manufacturer references and generated items reference. I think Inventree needs multiple tables that are linked together. You have items that have an internal coding scheme and real world part references attach to the generated items, making them active. Right now the stock items can only be attached to a single item. But I would like to see all the variants and their references when I search for some incomplete internal ref.

Lets say I have some RCK0603-49R9-0.1%-TC100 in stock. When I search for RCK0603-49R9, I would like to see that I have RCK0603-49R9-0.1%-TC100 in stock, even if it is just a variant of a variant of RCK0603-49R9.

If I browse a page of a supplier, let's say CRCW06031K00FKEA, I might just use a Firefox extension to tell Inventree to add this reference for the Chip resistor category, and that extension would then ask me to select the parameter values of this part. This will generate a real world stockable item with the parameters attached, and then the generator will parse the parameters and link this part to the corresponding items and activate the variants. The imported real world item can now be found when searching for RCK0603-1K00. Now lets take a weird case... I also want to add CHP0603AFX-1001ELF to my stockable items, but there is a problem. CRCW is 1/10 of a Watt while CHP is 1/3 Watt... Do I need to create a new item? A new Generator?

Actually no. The generator was just incomplete. You add a Power parameter to your already existing resistor code generator. The first resistor is 0.1W but you don't need to add that parameter to the old item, the power will just stay undefined. The new high power resistor will have a power parameter of 1/3W that will get registered during the creation. Now there is two real world part responding to the RCK0603-1K00-1%-TC100 code. But only the high power resistor is showing under RCK0603-1K00-1%-TC100-0.33W.

To resume: CRCW06031K00FK-- and CMP2512AFX-1001ELF are now available when searching for: RCK0603-1K00 RCK0603-1K00-1% RCK0603-1K00-1%-TC100

A search for RCK0603-1K00-1%-TC100-0.33W would only return the CHP0603AFX high power resistor.

Some example use case:

You're not sure you have a part in stock:

Open inventree, search for your parameters
The part is not found, bummer
A generator made an imaginary item based on your parameter and is proposing search links for some suppliers
You click a link and find the components you want to have available in your database
You use the extension to add those real world components to your real part list
The new unique item linking to those real world part gets created
You can now use the internal item code in you design software
You import a BOM from Kicad
Your board contains internal references that have variants (RCK0603-1K00 without tolerance specified for example)
Inventree displays a dialog for each reference in the BOM that have variants
You choose what are the acceptable alternatives (The cheap 5% or 1% 1/10 Watt might be okay for your design, but not the high power ones)
You can now order your parts from Inventree or send an enhanced BOM to your manufacturer
Conclusion

Okay. This is some deep thinking and I am not sure I've been clear on everything. It's quite a lot... I've spend some days thinking about this organization strategy and I think it might greatly speed things up when designing and sourcing components. I needed to put it somewhere. Some things in here are quite hard to implement, I guess it's a long shot, but those new tools would make part creation and management very easy and formalized. Tell me what you think.

Hey @tionebrr Awesome post and love the way you picked my brain on this topic! Based on my personal experience, I'd like to chime in with my own reflection.

Generators

In an ideal world, all of us engineers use the same system for formatting our part names, description and internal part numbers. However, we don't live in an ideal world, and each of us use different formats. I've worked in few different companies, and each time I had to adapt to or setup a new system. Which means that generators are not linear, and need to be implemented in such a way that user can configure it using their own recipe. And doing so is HARD.

In the past, I've used a Cadence system called Component Integration Portal. This portal/web interface would let you configure the generator for each part category (eg. resistors, capacitors, diodes, integrated circuits, etc.). I started ambitiously setting this up and then I stopped:

The interface was cumbersome and if some parameters for each part ended up missing, you'll get a part name or number looking like: RES-10K--0.1 (missing tolerance value). Also standardizing the numbers (how many digits) and unit can be a pain!
We did not need it as we were adding parts mostly using Digi-Key built-in API. And Digi-Key already uses fairly good generator for their parts. Having to rewrite them felt pretty useless...

Now, in my new company we use KiCad. And I felt the pain of manually adding parts to our libraries, so I built Ki-nTree. I didn't want to reinvent the wheel so for part names and descriptions, it relies on the Digi-Key dataset fetched using their API.

The missing piece was the part number. I thought about adding a generator to InvenTree, a sort of plugin that would live inside the global settings. But then I wrote the code to generate our part numbers, it's literally less than 15 lines of code: https://github.com/sparkmicro/Ki-nTree/blob/master/common/part_tools.py#L7

I give it to you, it is hard-coded to our own format, and not a very flexible system. But it shows than anybody with a little python experience with manipulating strings can do it and therefore get external generators up and running in no time, using the InvenTree API to update the part fields.

I'm not against seeing user-friendly, flexible and reliable generators built-in in InvenTree. However, between describing them and building them, this is a challenge of its own!

Alternates

The way you described it, you use "alternates" in a loser way than I do.

Therefore I think there is two kind of alternates:

Specifications matching alternates with no deviation, which I think of as "true" alternate.
Somewhat matching alternate part, with one or two spec deviation, temporary bridging gap in build stock and supply: I would label those parts as "replacement" parts.

For the first kind, InvenTree does it well already. Having the ability to link multiple supplier and manufacturer parts to an InvenTree part is the way to go. One would never hesitate in buying any of the supplier items listed because they are spec-to-spec compatible, all the way.

For the second kind, InvenTree may benefit from improvements for the part and stock allocation during a build. With your given example, I can see one would like to replace a 0.1uF/25V/X7R with a 0.1uF/16V/X5R already in stock or only ceramic capacitor available at the moment, knowing this could affect the circuits using the original part but preferring the completion of the build instead.

I don't know that it deserves a system of its own where those are consider "alternates", because those are short-term replacement which I believe shouldn't be considered for the long-term.

One way you could do this right now is using the "Related Parts" feature of InvenTree to add some kind of relationship between all those parts that you consider replaceable with each others.However, it won't be showing during BOM import or build allocation, so for sure there might be a gap to bridge here.

Find part based on global parameter search

I do like this idea. I did implement the parts parametric view for each category with this in mind. But the search lacks the ability to scrub through part parameters. It may make the search slower though, depending on how many parts and parameters are in your database (we have a lot) so needs some thoughts before jumping on the boat!

Recommendation system and virtual shopping list

A generator made an imaginary item based on your parameter and is proposing search links for some suppliers

I personally wouldn't rely on the system recommendation to create a new part based on my search. I always search and select parts very carefully checking supply, availability, specifications and then move on to add a part to my library.

On the other hand, the extension you described could definitely be useful if it was made for browsers. I would love to be able to scroll through Digi-Key, add parts to my virtual "shopping" list using a custom Chrome extension and then create a batch of parts in KiCad and InvenTree with a single-click. When are you planning on working on this? 😄 More seriously, this would be sweet if someone made it real!

Hey @eeintech

In an ideal world, all of us engineers use the same system for formatting our part names, description and internal part numbers. However, we don't live in an ideal world, and each of us use different formats.

I agree so much and would add that, unfortunately, there will also always be exceptions to the rules.

Cadence system

lol Cadence... 'nough said. I see their stuff as over-engineered heaps of bugs at stellar prices. But I'm still curious. Did you liked using it in the end?

RES-10K--0.1 (missing tolerance value)

I wouldn't mind someone using that reference in a schematic to state that this part could be any tolerance, as long as I have the tool to help me link this partial reference to real world parts.

Digi-Key already uses fairly good generator for their parts

I'll look into that more closely. Might be some ideas to gather in there. I don't use Digikey personnally because they don't have DDP incoterms. But their catalog is huge. Too bad.

I built Ki-nTree

🎉😄

I'm not against seeing user-friendly, flexible and reliable generators built-in in InvenTree. However, between describing them and building them, this is a challenge of its own!

Big challenge indeed! I have a small generator working (about 2h of work) that asks for user inputs and spits an item name and description based on a JSON. Very crude but it's already something. And it kind of manage to create and read RKM codes. Will share that when it gets a bit more refined. The challenging part is actually making this more usable than JSON and crude command line. I think I'll first try to get something more complete working outside of Inventree and then try to integrate it (if it is deemed useful).

Therefore I think there is two kind of alternates:

Specifications matching alternates with no deviation, which I think of as "true" alternate.

Somewhat matching alternate part, with one or two spec deviation, temporary bridging gap in build stock and supply: I would label those parts as "replacement" parts.

Okay. The way I see it is different. For me there is no semi-variants or variants actually. Because the scope of Variant cannot be defined. (if you ask an accountant, resistors and capacitors are both variants of electronic components) The only variations you can observe consistently are the ones that are clearly defined within the parameters, because all the parameters defines what the thing is exactly. As your library grows you'll need more and more parameters to make the distinction between parts, and your naming scheme could become inconsistent. The generators are an attempt to keep a consistent naming scheme as your parameter list grows. When you see that some category are getting too much parameters, you could always duplicate the generator and modify it to create a new part category (standard power versus high power resistors for example).

Having the ability to link multiple supplier and manufacturer parts to an InvenTree part is the way to go.

I don't agree here. That part of Inventree could be way more flexible and consistent at the same time. More below.

those are short-term replacement which I believe shouldn't be considered for the long-term.

I can see counterexamples. You could have long term alternatives for reel diameters for example (they are the same part under different mfr ref).

Everyone can see two parts as being viable alternatives in different ways:

Your accountant will put capacitors and resistors as alternatives (you shouldn't let him do that btw)
Your technician will not be careful about temperature range for semiconductors
Your subcontractor may not care at all about reel size actually but will respect the brand and MFR ref.
Your other subcontractor will prefer a BOM with only 360mm reel size but also wants alternatives suppliers links... etc...

I think that if a solution is implemented, it needs to solve the general problem... With parts matching driven by parameters, you are able to choose exactly which parameters can be ignored when importing a BOM, and inversely exactly what parameters are very important. If you library of big enough, the search engine will spit out a list of alternatives tailored to the project.

Right now, Inventree traps you both ways. You can have alternatives at some point but would want to have them separated further down the line. But you can't easily do that because you need to create an item and recreate a supplier. And inversely you might have parts that could be alternatives but that are hard to merge because they are not the same item.

To improve Inventree, there need to be a way to match actual parts spec to spec via parameters (like Digikey, Mouser, etc...). And this could only be only done if you have a placeholder for the specs of each MFR parts in the database. That's why I think MFR parts should be separated from suppliers, and carry their own parameters like items. This is the only way to be 100% specific each time.

Generating the names from parameters is just an accessory convenience for having something central to put on the schematics and drawings.

Find part based on global parameter search

Yes, this is something that is going to be required for all of this to work, but like you said there are already existing solutions (Digikey, Octopart...). (as a side not, I've found resistors listed as being 5.1m ohm on Mouser that are actually 5.1 Mohms. Had to search them by MFG ref. Then I sent them a mail full of profanity and blasphemy :P). The + for having that search in house is that it is your curated list of component, and the search could be really fast (yes I'm looking at you ripgrep, fzf and the likes...👀)

Generated searches: I personally wouldn't rely on the system recommendation to create a new part based on my search. I always search and select parts very carefully checking supply, availability, specifications and then move on to add a part to my library.

Me neither. I don't care for prototyping stuff but when it comes to real production, I become weird. You will not be obligated to accept any link it is proposing. It is just showing that the part you are searching by parameters does not currently have a real world counterpart in the database, but that it is understanding what you are looking for. It might at least spit a link to the right family of components in octopart, or even a link with a query for the right parameters.

batch of parts in KiCad and InvenTree with a single-click. When are you planning on working on this? 😄 More seriously, this would be sweet if someone made it real!

Haha indeed that would be really nice. Ki'n'tree is halfway there tho. I took a look at the sources and there might be some ways to build on it. I'm not experienced enough with js to create a browser extension but will surely try sometime. I'm more interested in python right now.

I hope I clarified what I think are the shortcomings of Inventree (don't get me wrong here, Inventree is already awesome !). Also, what I could already do on my side is becoming more clear. Talking about it sure helps.

lol Cadence... 'nough said. I see their stuff as over-engineered heaps of bugs at stellar prices. But I'm still curious. Did you liked using it in the end?

This tool I mentioned was actually developed by another company called EMA (which was acquired by Cadence), it wasn't too bad and made adding part to our library pretty efficient, also integrates well with PLM tools like Arena. Yes Cadence software are powerhouse, Allegro is still the best tool I've used for layout, far far more advanced than Altium & Co. Its constraint-based system gives it an edge for high-complexity and high-density designs and despite its high license price, you get it back in saving countless hours of routing and debug afterwards. For simpler project though, Cadence loses the battle for user-friendliness (and price obviously). KiCad is actually far better than I expected it to be for open-source software, it's actually getting so great that the Altium team must be shitting in their pants 😄

I don't use Digikey personnally because they don't have DDP incoterms. But their catalog is huge. Too bad.

Wow I am surprised, it's the first time I hear someone is not relying on Digi-Key for delivery guarantees. Their part database is humongous (I have no idea how they manage to keep so many specifications, datasheet/drawing links, etc. up-to-date, their data is pretty much always accurate/valid) and in my experience Digi-Key never let us down for ordering what we wanted (they must have many Amazon-like warehouses to keep up). IMO their search tool is far superior than other suppliers too, makes me want to steal it and put it in InvenTree 😬 Overall, I would recommend them to anybody ordering parts online.

Big challenge indeed! I have a small generator working (about 2h of work) that asks for user inputs and spits an item name and description based on a JSON.

That's cool, do you happen to open-source your code?

For me there is no semi-variants or variants actually. Because the scope of Variant cannot be defined. (if you ask an accountant, resistors and capacitors are both variants of electronic components)

Umm I never like to talk about variants for parts, to me this is only relevant in the scope of Printed-Circuit Board Assemblies and BOMs.

I don't agree here. That part of Inventree could be way more flexible and consistent at the same time. More below.

Have you tried this feature in InvenTree after adding multiple supplier or manufacturer parts to a same part? The BOM you'll export will contain all those alternate parts in separate columns. Contract Manufacturers love to have multiple options when picking parts for assembly, because they can rely on your BOM data for figuring out which part to order given the current supply and/or their favorite suppliers. For in-house prototypes, it also gives engineers and technicians flexibility on part to pick from the current stock, or to order. I've seen countless BOMs from many companies rely on this too therefore I believe this is the base for alternates.

I'm sorry we don't agree (and we don't have to), I've tried to understand your point reading your explanation but I'm still unclear. I do not disagree that InvenTree can be improved in a lot of ways, however I'm coming from the idea that alternates are interchangeable without an ounce of doubt, at part level (not at packaging level), so maybe that explains why I'm still not clearly seeing what your seeing 😉

That's cool, do you happen to open-source your code?

Yes ! I'm using open source tools so I try to also open my code. Most of what I am working on right now (electronically speaking) is closed. I'm planning to open-source hardware submodules in Q1 2021. However from the start, if I work on some library keeping tool, it is going to be open-source.

Allegro is still the best tool I've used for layout, far far more advanced than Altium & Co.

Okay, that is impressive ! I guess the price point have an explanation after all

Altium team must be shitting in their pants 😄

😄 I can imagine them checking the nightly every morning. Did you looked at the interview of Wayne on the Robert Feranec channel?

Umm I never like to talk about variants for parts, to me this is only relevant in the scope of Printed-Circuit Board Assemblies and BOMs.

Yeah I didn't used quite the right terminology here. What I wanted to say is that everything could be an alternate of something else depending on the requirement of a certain use case. Inventree doesn't allows to dynamically change what might be accepted as compatible or not. You choose one time (by adding a supplier) and then it is hard to modify or move that choice.

The BOM you'll export will contain all those alternate parts in separate columns. Contract Manufacturers love to have multiple options when picking parts for assembly, because they can rely on your BOM data for figuring out which part to order given the current supply and/or their favorite suppliers. For in-house prototypes, it also gives engineers and technicians flexibility on part to pick from the current stock, or to order.

YES ! Exactly ! What I am proposing enables to auto generate a list of compatibles based on parameters requirements, exactly like a search in Digikey but on your own library of curated refs, automated and fast. It could be made in Inventree but each MFR refs should carry their parameters. You could then use generators to name a certain group of parts.

I think it should be a new application actually. I'll try to make a proof of concept with a crude GUI to check the feasibility...

Yes ! I'm using open source tools so I try to also open my code.

That's awesome! Let me know when you have some of those generators ready to share, I'd be interested to check them out 😉

Did you looked at the interview of Wayne on the Robert Feranec channel?

I watched parts of it as I've had already watched the 2-hour podcast of the KiCon 2020 and it had tons of information regarding KiCad, v6 and many other things. Wayne was in there too. Highly recommended watch to get you pump up for the future of KiCad!

I think it should be a new application actually.

Starting outside of InvenTree gives you more flexibility. If you don't know about Django web framework, there is a bit of a learning curve. I started on Django at the beginning of this year and now feel more comfortable with it after building few web applications and contributing to InvenTree. But for Ki-nTree, it could only be independent from InvenTree because it interfaces directly with KiCad library files, which for a web application is basically a security breach if you'd allow write access to the user's system. Not sure if it is the case for you here because you'd be exclusively using InvenTree data (or perhaps not? something to think about).

I'll try to make a proof of concept with a crude GUI to check the feasibility...

That'd be sweet! Btw, given you mentioned you're using Python, I highly recommend PySimpleGUI. Awesome library to build GUIs fast!

Hey guys, some great points of discussion here. Very interesting! I do not have time right now to fully respond to all the points raised, but there is certainly a lot to go on with in the future 👍

Global Parameter Search

Searching globally (or within a particular category / sub-category) based on parameters would be a fantastic feature to have. I'm not exactly sure how this would function on a database level, though. One possibility that has been discussed before is to add "value based filtering" to the existing part parameter table view on the category page.

e.g. you could filter resistors between 1K and 10K, and with tolerance < 5%

This is a future idea, not currently a work in progress. It would (probably) require a lot of work under the hood.

Substitute Parts

There is a lot of talk above about the distinction between "substitute" and "variant" parts. The current implementation of "variants" is not really compatible with the idea of "substitutes", and (as you rightly pointed out) what constitutes a substitute really depends heavily on context.

I do not believe there is a good way to determine solely from part parameters what other parts would work as a drop-in substitute for a Bill of Materials. For example, some designs might call for a 5% or better resistor. Some designs might call for a particular length of screw, but it could be longer by up to 5mm.

What about approaching this in a different way? When making a BOM, each line item could have alternative (substitute) parts linked to it, where the designer has absolute control over which alternative parts can be allocated.

Yes, this process is not automatic, but it ensures that there are no surprises.

Maybe there could be a middle-ground approach which takes elements from this and from your suggestions above...

Variants

I feel that the intent of variants (at least my particular intent when implementing them) is different from how most people see them or expect them to work. Essentially, at my work we sell electronic products which are available in a number of different Variants which the customer specifies. Elements that qualify as a "variant" might be:

Type of interface connector
Harness length
Supports Feature A
Supports Feature B

Here, we might swap out entire cable looms or have to use an entirely different enclosure. Clearly a "variant" in this sense is explicitly not a substitute because the end product is markedly different.

So why is this "variant" simply not a new part with a slightly different part number? For a number of reasons:

The variant "tree" allows InvenTree to ensure that serial number uniqueness is maintained across all variants of the same product
Required test parameters flow downward to part variants - so common tests can be defined for a top-level part and flow to any variants of that part
Stock levels are shown for a part and all its variants

I hope this explanation is clear? Please let me know if it isn't, or if there's something about this implementation that you think is wonky.

Name Generators

I find the idea of part name generators quite appealing. In particular, the concept of creating a new part simply by defining its parameters.

However I think that I disagree that this part name should be "dynamic", rather it should be a one-time generation step. The reason is that not all parts can or should be automatically generated from parameters, and it would cause complexity and conflicts with the existing (static) name field.

Unless you can suggest a way that the two concepts (static names and dynamic names) can intermingle?

=============================

I'd be interested in hearing your thoughts on the points above. And would certainly welcome your assistance in developing and improving InvenTree!

Hello @SchrodingersGat, thanks for having taken the time to read this humongous thread haha. Don't bother answering everything point to point. I think you got the idea right.

What about approaching this in a different way? When making a BOM, each line item could have alternative (substitute) parts linked to it, where the designer has absolute control over which alternative parts can be allocated.

This is almost exactly how I've imagined it! An agent first digest the value string in the BOM and tries to extract parameters. You then refine your parameters, and then do a final checkbox selection for real world parts. Optionally, you could trust you inventory parameters and let Inventree dynamically select components based on parameters only, without constraining the BOM to some parts. That way, if you add a new Part in the database that match the parameters, the BOM could be updated with that new reference added.

The variant "tree" allows InvenTree to ensure that serial number uniqueness is maintained across all variants of the same product Required test parameters flow downward to part variants - so common tests can be defined for a top-level part and flow to any variants of that part Stock levels are shown for a part and all its variants I hope this explanation is clear? Please let me know if it isn't, or if there's something about this implementation that you think is wonky.

Oh yeah this is very clear. That mechanism is very different that what would be managing group of components or substitues. The testing part is very interesting and may be useful for QC at reception.

However I think that I disagree that this part name should be "dynamic", rather it should be a one-time generation step. The reason is that not all parts can or should be automatically generated from parameters, and it would cause complexity and conflicts with the existing (static) name field.

Yes, @eeintech and you are right on this point, it is too complex. I've given a lot of thought to it and I still believe there is something there, although not at all like the original idea.

Let's imagine that Inventree is organized such that: 'Create a name'>'Add parameters'>'Add a supplier' Will be simplified into: 'Create a part'>'Edit/Check the parameters'

And, lets imagine that the database only contains Items that ARE real world parts.

Part = {
    'Manf':'Vishay',
    'ManfRef':'RC060349R9JSAE-HP',
    'Parameters':[
        {
            'type': params.componenttype,
            'value': resistors
            'id': 'resistorValId'
        },
        {
            'type':params.resistors.resistance,
            'value': 49.9
            'id': 'sd4qsfv8'
        },
        {etc...etc...}
    ],
    'id':'aeBzJ9r'
}

So, that was a part. It is a real world component and have a set of parameters values.

Now, the parameters are also defined elsewhere to establish rules about them:

resistors.chip.composition = {
    'name': 'Composition',
    'separator': None,
    'type_of_value': str,
    'values': [{
        'value': 'Thick Film',
        'shortVal': 'K',
        'id': 'sdf46s8v', },
        {
        'value': 'Thin Film',
        'shortVal': 'N',
        'id': 'tt984gfhn4', }],
    'acceptNewValues':'False',
    'strGenerator': None,
    'shortValGenerator': None,
    'id': 'Hiuv1hhh',
}

resistors.resistance = {
    'name': 'Resistance',
    'separator': '-',
    'type_of_value': float,
    'values': [],
    'acceptNewValues':'True',
    'strGenerator': None,
    'shortValGenerator': "to_RKM(value, length=4)",
    'id': 'Je0Hd6gH',
}

Notice that 'shortValGenerator' can be evaluated.

Hypothetically, from these datas, an agent could:

Digest a string to extract parameters (give 'RCK0603 49R9' or 'res thick 49.9', receive a list of resistors matching recognized parameters)
Generate a string to name a group of component based on a Rule.

Now, a Rule might be anything. It might define a category, a line in a BOM, a symbol in a schematic. It has a set of parameter and that set gets a generated name, description based on the short or long string attached to the parameter value. You do not store these, they are not items. Those 'names' are representations of a set of parameter values, and this name is not stored in the database like parts. It is just a handle for human readability and is generated based on a Rule.

The only thing that needs to be manually done is creating the parameters definition and checking that new parts have enough parameter values attached to them to differentiate them.

When a new part gets created, the parameters from Ki'n'tree are digested and you get a prefilled form. You just validate and correct the parameters of the new part if necessary.

All of this would be a kind of parameter driven inventory management system...

I have no clue how something that complex might work with a standard database at all... I think this is where the hard part lies. I have some idea, mostly using lists of ids. Each thing (part, parameter value, parameters, rules, categories etc...) might have a unique id and you would list things between each other bidirectionally... A parameter value would link to every parts sharing that value, and a part would link to every parameter value they respond to. The database could be parsed at start and everything could be python objects in memory during runtime, ready to be parsed. Big problem here is that living in RAM implies being vulnerable to bitflips and power shortage (plus surely taking a lot of RAM). But that might be mitigated by keeping db and ram in sync regularly. So yeah, this is where I am at. Just an idea about how that may be doable. But I may not be realistic there because I just have basic knowledge of how to use a database. Also, I don't see how Inventree right now could evolve toward this as Parts in Inventree doesn't mean 'real world part with parameters'. They are an handle to a list of 'real world parts' aka suppliers.

I hadn't had the time to work on my little proof of concept but will return to it shortly. I also started to learn Django :tada:

Okay I am putting this on hold. If I'm being realistic, I don't have the time at all to work on this efficiently. I already have too much projects going on. Too many passions, so little time... I love the idea and your feedback really helped to refine it. I'm already grateful for the tools you developed guys, so the inputs were interesting 😃 I will re-read everything back one more time and just write a specification sheet for reference.

If ever I have the time to come back to this I would love to get more of your inputs and help 👍

inventree / InvenTree