KiCad already has support for coupling with an external database. This is not obvious when you’re using KiCad (The default libraries don’t use it at all). The main goal is that companies who were using an in-house database for parts management can couple it with KiCad, so all their parts can be efficiently used in KiCad too.
How do you plan to achieve multi-distributor real-time? These all play pretty close to the vest with their API access.
I would like a basic plugin that lets me type in an MPN and get my choice of SnapEDA/Ultralibrarian/Samacsys libs pulled into my project. However, I would want the output to match my preferred library organization, so this is probably not one size fits all.
I don’t do enough design work to justify paying for it (sorry!), but for the designs that I do create I think this sort of integration would be a game-changer for me.
I have found that companies try more and more to keep engineers away from pricing and part ordering. One of the main reasons for house number systems is to keep a wall between the designer and commercial aspects.
Direct links to potential vendors also leak a lot of BOQ information out of the organisation
FYI. All these distributors crack down on scraping. You will have to gain access to their APIs.
Honestly in my world? No. We don’t choose parts based on price alone. At the end of the day, once we build up our components library of parts we have used on some designs, we basically reuse those parts until they go obsolete or a very good reason emerges to find a new one.
What would make your component sourcing easier?
Here is where you’ll run into differences on how firms work. Many firms just pass this all onto their PCBA. The design firm does not get involved in purchasing the parts or storing them. Other firms source parts, warehouse them and consign them to PCBAs or build boards themselves. Personal experience is most firms just outsource it. It’s not worth the logistics overhead and PCBAs are more specialized at managing it.
I wrote a tool a few years back KC2PK which illustrates two of the problems with this approach - especially for a solo developer and hobbyist user of Kicad.
I keep my electronic stock inventory in PartKeepr. It was a great program with a MySQL backend which could be interrogated for stock levels etc. it has now been abandoned and is a nightmare to reinstall on anything as it has an outdated and specific php dependency.
I linked this to access the Octopart API to pull in stocks and costs for a variety of suppliers. After a few months the API changed very significantly and I was just about to get around to a rewrite when my access token was pulled and Octopart refused to answer my emails.
I think this sort of functionality could be very useful for some users but it is always going to be built on the hope that the underlying API is not changed, access remains affordable and that some change in the EULA doesn’t render your project dead in the water.
Just another thought on these - Octopart shows those pretty graphs from their historical stock data, which will be difficult enough for you to get your hands on.
But what actually valuable enough for people to pay for is analysis and insider connections that will tell you when a part is going to become unavailable, BEFORE its OOS at Digikey or the PCN is published. You’re not going to get there with some basic time series analysis.
It internally use the Digikey, Mouser and other APIs (needs user registry/token) to get price and stock.
My (and other authors) concern was creating a BOM (Bill of Materials) in Spreadsheet format that would allow us to purchase from fewer distributors while saving money (for me, mainly by reducing customs costs). However, the workflow requires manually fill the MNF (manufacturer part number code) into each Eeschema symbol.
