Default manufacturer's part number field in KiCad libraries


Using 3rd party part numbers in a change controlled schematic is asking for problems later. House part numbers are the standard way of preventing the need for frequent changes


It doesn’t have to be under a change-control system. Any assembly that will ever need more than one parts purchase has a potential for problems.

Please keep KiCAD as a design tool until it is fully matured and truly state-of-the-art. Don’t try to add in MRP functionality.



[quote=“me”]Remember the real goal is to have a BOM which includes orderable part numbers, something you can submit to Mouser or DigiKey or whomever without doing any further part-number lookup.

[quote=“kuro68k, post:60, topic:4387”]
I think that’s a bad idea. We tried it at work, the problem is that after a while parts go obsolete or out of stock and the data becomes stale. It’s better to have an application that can recognize things like resistors and capacitors and automatically select the cheapest, in-stock option that meets the required spec

At my day job, we have an ERP system which uses house part numbers which map to orderable part numbers. That’s the application you reference. Engineering only cares about the house part numbers, in the sense that they are embedded in the schematic components.

In other words. I don’t particularly care whether we buy Panasonic or Yageo or Vishay or Susumu 1% 0603 resistors. The house part number isolates engineering from those purchasing issues. This is all above the level of the schematic and PCB.

Certainly when parts go obsolete, purchasing asks engineering whether suggested replacements can actually work in current designs. If they can, then in the ERP system the new manufacturer part numbers replace the obsolete numbers.

If there is no form/fit/functional replacement for an obsolete, we remove it from the company library and it gets marked as such in the ERP system. This means that it can’t be used for new designs. The bosses also make projections about how many boards which use those obsolete parts will be built in some given time frame and we’ll do last-time buys to meet that demand. Those boards also get flagged for future updating to replace obsolete parts.

That’s all beyond the purview of a CAD program!

What about when you use multiple suppliers? I know our purchasing person trades off between all of the usual suspects when ordering, so she needs to start with a manufacturer’s part number, not the supplier’s number.

I realize that hobbyists don’t care about this, but the goal is to encourage the use of Kicad in professional environments, and I suppose that’s why there is so much discussion about BOMs.


That’s why I suggest not having supplier order numbers or anything like that. And yes, the purchasing department needs to have a little intelligence to handle generic parts, that’s unavoidable.

Again, no one is forcing you to use all this stuff, it’s just that BOM generators can do so much more if there is some agreed standard for the data.


That is certainly true, but many of us keep pointing out that there is no real consensus on the ultimate objective of the data structure, much less a standard for the data elements in that structure.

Many of us would prefer to have the capability to define a significant number of fields - probably a dozen or more - by giving each of them a locally-defined name and filling them with the data we individually find useful. Then a BOM-Generating tool needs a way for us to define a map that essentially says, “My local field nn, which I call “Part Type”, should appear in column mm of the BOM, which the BOM calls “Description”.”



I made a request for comment on the KiCad dev mailing list to and a standard MPN field:


Dammit! I wish I’d seen this 6 months ago. Its just what I’ve been looking for - a way to globally add fields to my projects! It nicely renders the need for default fields in the library moot.
BUT - it would be good to have a community wide naming convention for common fields, to facilitate the creation of add-on scripts for BOM handling, etc.
(And I want to offer a huge thankyou to those people writing and publishing their scripts.)