[FR] Add IPN as matching field for BoM import
Please verify that this feature request has NOT been suggested before.
- [x] I checked and didn't find a similar feature request
Problem statement
I have used IPN as part identifier for BoM imports from KiCad. I just realized that the PUI BoM importer do not support that. In the latest documentation it is stated that IPN is the prefered way. Specifying the Part_IPN field matching is very powerful as it allows to create direct pointers to InvenTree parts
Suggested solution
Would be nice to get IPN matching possibility also in PUI.
Describe alternatives you've considered
Easily solved with a bit of processing in Excel between the KiCad BoM and an Inventree part export, but it would be better to avoid this step.
Examples of other systems
Inventree 17.x / CUI
Do you want to develop this?
- [ ] I want to develop this.
With the amount of dev buy-in we are getting currently I would not hold my breath waiting for this
How do you judge the level of complexity to implement? If it's easy enough I can give it a try myself. As it has been supported in CUI I guess the backend already has the necessary support - or has the IPN macthing been re-considered and actively removed?
The import backend has been completely rewritten due to massive performance problems. Matching capabilities are implemented in theory so it should be simple
This would be best implemented using a generic "natural key lookup" feature for the importer - https://github.com/inventree/InvenTree/issues/7574
i.e. for a given dataset you can specify that the part can be looked up from the "IPN" field (in addition to the PK field)
OK, so there is no "easy" way to solve this right now as https://github.com/inventree/InvenTree/issues/7574 seems to be a rather big change?
What's your suggestion for the best stable way forward right now? If Inventree "pk" will be the the recommened key rather than IPN I have to re-work our KiCad symbol library to include also the Inventree "pk". It's not really user friendly as "pk" is not visible anywhere in the Inventree GUI as I'm aware of but it can at least be picked from the browser address bar when creating new parts.
But if you think IPN still could be a viable long term option I will leave the KiCad library as is for now and process the BoMs in excel until IPN can be used again.
Do you use the inventree-kicad plugin? This already maps inventree ID values into your kicad libraries. I use this all the time for BOM import back into InvenTree.
But yes, #7574 will take some time to get working.
Nope, I create our KiCad symbols eiter manually or by copying from the libriaries provided by KiCad or other sources and then adding a few additional fields - IPN being one of them. Our KiCad library has for long been the "master data" for parts so to say.
It sound like I better rethink the workflow and find a way to add the Inventree "pk" as a field either manually or a more automated flow. Just reading the inventree-kicad plugin documentation I do not fully understand how disruptive the transition would be for existing KiCad libraries/projects but I will definitely give it a try.
If you do not see IPN maching as a feasible option any longer I beleive this Issue can be closed? And if so I would also suggest to remove the recommendation to use IPN as matching key from the documentation.
If you do not see IPN maching as a feasible option any longer I beleive this Issue can be closed?
IPN matching will be feasible once the linked issue is addressed - so happy to leave this open.
If you are able to contribute towards that feature (either in development, sponsorship, documentation) then I'm sure that would help it go faster :)
@SchrodingersGat Thanks a lot. Then I think I will add the InvenTree pk to the exported KiCad BoM as an intermediate step until the IPN maching is available again. Either in Excel or probably even easier with a script based on the InventTree Python module. The inventree_kicad plugin looks nice for new parts but if I understand it correctly it's a bit uphill for already existing libraries.
You guys are doing an amazing and valuable job and I would be really happy to contribute with development and/or documentation. Still early on the learning curve though...
@gunstr any assistance is greatly appreciated - we are a small team who are overworked trying to service such a widely used software product :)
This issue seems stale. Please react to show this is still important.
Not stale
This issue seems stale. Please react to show this is still important.
Not stale