Plans for tracking in house part stock and prices?

This is probably out of the scope of horizon, but I figured I’d ask anyways…

I order parts from all over the place and often get extra quantities to hit the price tiers. Keeping track of what is in stock and what was paid is cumbersome.

Since horizon already has the nice pools… It would be nice if there was a way to somehow associate a quantity in stock, prices, and maybe a inventory code with parts in the pool. Then the bom could show a cost without an external tool. It’d also be helpful to be able to filter parts in the pool by what is in stock when placing on the schematic.

Since horizon uses/shares multiple pools I think it would probably have to be implemented as a separate database that links a part uuid to stock/pricing information or perhaps simply some sort of api to pull/push to a server somewhere.

We already have the StockInformationProvider interface for that extra column in the pool browsers. Right now, there are implementations for Kitspace’s partinfo and the digikey API. Adding a third one that hooks up to some inventory management system shouldn’t be too difficult.

That might not be exactly what you had in mind, to me that seems to be the best way to avoid feature creep.

It looks like that should work. I should be able to make something to implement the partinfo api.

Since it already caches to a local sql database, what do you think about having one more stock info option to just use a local sql database (using the same schema and data format as partinfo but don’t do any fetching)? Then no server is needed.

Now idea how many people manage their stock in a SQLite database sitting on their disk and how useful that feature’s going to be.

OTOH, having though about it, adding a minimalist stock keeping system that maps part UUIDs to QTY and locator doesn’t seem that bad an idea since all of the part metadata is already there and doesn’t need to be duplicated into an external tool. Not sure about the cost part as that’s already covered by existing stock info providers.

Now idea how many people manage their stock in a SQLite database sitting on their disk and how useful that feature’s going to be.

Lol, probably none, but I bet some use excel. If the data format was well defined it would be easy to update it using scripts or something.

adding a minimalist stock keeping system that maps part UUIDs to QTY and locator

That was sort of what I was thinking. The interface is mostly there already.