Thanks @devbisme, hope you enjoyed your chops. 
I think I would have just been happy to use and promote the KiCost defaults in the past if it wasn’t for the lack of a definition of how to define multiple manf# fields per schematic symbol. Are you open to letting KiCost be adapted to allow this use case with the field name schema we will put in this document?
I have gone off the : seperator idea unless someone else makes a strong supporting case for it.
What’s your plan for handling multiple part information in the spreadsheet? I’m open to anything as long as it doesn’t make things more complicated for the basic user who only has a single part number/manufacturer for each part.
Well to adapt the proposal above to the use without : we would have:
| Name | Value |
|-----------------------+----------------|
| Manufacturer<Integer> | <Manufacturer> |
| MPN<Integer> | <MPN> |
| Vendor<Integer> | <Vendor> |
| SKU<Integer> | <SKU> |
With the example:
| Name | Value |
|-----------+-----------------------------------------|
| Reference | U1 |
| Value | NE555 |
| Footprint | KiCad/Housings_DIP.pretty:DIP-8_W7.62mm |
| Datasheet | |
| Manuf1 | Texas Instruments |
| MPN1 | NE555P |
| Manuf2 | Microsemi |
| MPN2 | NE555P |
| Vendor1 | Digi-Key |
| SKU1 | 296-1411-5-ND |
| Vendor2 | Ralph's Elec. |
| SKU2 | SEMI-NE555P |
| Vendor3 | Ralph's Elec. |
| SKU3 | TEXAS-NE555P |
In the spreadsheet we can either keep the explicit numbered headings or make use of the column order instead e.g.
| Manuf | MPN | Manuf | MPN | Vendor | SKU | Vendor | SKU | Vendor | SKU |
|-------------------+--------+-----------+--------+----------+---------------+---------------+-------------+---------------+--------------|
| Texas Instruments | NE555P | Microsemi | NE555P | Digi-Key | 296-1411-5-ND | Ralph's Elec. | SEMI-NE555P | Ralph's Elec. | TEXAS-NE555P |
| | | | | | | | | | |
The spreadsheet needs to be able to adapt to the possibility of additional headings though. Is this what you were asking? Would that break anything for you?
My question is even more basic: if I have multiple part numbers for a part, how does my costing spreadsheet figure out the total price of all the parts?
Ah, I would suggest trying the first one, if unavailable at that retailer, try the next one and so on.
EDIT: If you want to get really smart you can start trying to optimise for cost of course.
KiCost doesn’t currently keep any vendor names or SKUs on the left-hand portion of the sheet. The vendors are handled on the right-hand side with a set of columns for each vendor (Digikey, Mouser, etc.) showing ordering codes, pricing, availability. One advantage of KiCost is you don’t have to handle the vendor codes because it figures that out for you using the manufacturer’s number.
If KiCost only handles the first available part it finds at a particular vendor, then you might have cases where one manufacturer’s part would be ordered from Digikey, but another manufacturer’s part might be ordered from Mouser. The same issue arises if you do cost optimization.
Is that really a problem though? Doesn’t it make sense to not add multiple MPNs if you care about the exact part that needs to be ordered? By putting on multiple MPNs you are effectively saying “these are equivalent in this context”.
EDIT: Just a thought, we could even standardise on calling the first MPN field just MPN and the second one MPN2 etc. I guess this would be more backwards compatible with existing tools actually!?
I’m just thinking it would be a surprise to the designer, especially if they ordered parts from both vendors and they were different (even if functionally the same).
Yes, if MPN is used for the first choice, then KiCost doesn’t need any modifications.
+1 for the house part no.
Everything else I do outside of Kicad
I currently use several custom fields in my parts. I use house numbers and Manufacturer and MPN. The first one is to connect the fields with my BOM management system. The latter is as documentation. (and yes only one MFG and MPN because I want to know exactly which particular part I am using in the particular project, not all the possible options)
It is nice to have this as a standard. I am generally fine with whatever you guys end up deciding on. I voted on the polls according to my personal preference. At the end if it does not suite my workflow I will be able to customize it. So no harm done.
Completely off topic: What I am actually missing the most are custom fields in kicad_pcb, and having them synchronized using netlist export from the schematic. When exporting centroid data for the pick and place machine I need at least the house number to be in the final CSV. Currently I have to use an external tool to merge BOM with the centroid data from kicad_pcb. It would be nice if I could just generate the needed data for the P&P without the extra leg work.
Overall I like the effort of trying to standardize some fields. Good luck!
Could the house part make sense added to the schema?
| Name | Value |
|-----------------+----------------|
| Manuf<Integer> | <Manufacturer> |
| MPN<Integer> | <MPN> |
| Vendor<Integer> | <Vendor> |
| SKU<Integer> | <SKU> |
| House<Integer> | <House> |
| HPN<Integer> | <HPN> |
Where <HPN> is a house part number. With all fields I am now thinking, putting 1 as an integer is optional. The House field wouldn’t striclty be needed either and could be left off but really all the fields are optional anyway. (I don’t think I made this clear enough before.)
The main issue I see with looking at this is that HPN is quite close to MPN and makes it harder to see at first glance.
That is why I call it Key in my system. As it is used as a Key for the “other” database. One could call it HKey, or PartKey? But for someone who is new to it all, and does not read documentation, that might not be obvious what it means.
How about UID for “unique id” for linking to any external databases?
Sounds good to me.
“UID” is a very generic abbreviation, there are many things that could have a UID : footprint, symbol, supplier, etc. It’s best used as a suffix, e.g. PartUid.
I would suggest “UPN” instead, although I use CPN meaning “Company Part Number”, but could equally be “Common Part Number”.
+1 from me for “UPN” which can be regarded as User Part Number or Universal Part Number or Unique Part Number, depending on personal preference. This one identifier should cover the needs for everybody using external tools for parts management and might be more colloquial than using SKU et al.
While there might a gazillion use cases against having them, I’d like to see two fields for Manufacturer Part Number and Manufacturer (or Vendor and Vendor Part Number, or Distributor and Distributor Part Number, you get the concept) included as well, because that is what probably 99% of the hobby/not-for-profit users of KiCad will ever need and it saves them the hassle of creating the fields themselves.
Making life easy for the Newbies can only help in the proliferation of KiCad
It would only agree the field definition, it doesn’t mandate they’re used! The (blank) fields could be added to existing libraries with a simple script to “convert” them. …Or not!! Libraries can be left without these fields if desired.
The important thing is that if/when people/groups/projects choose to add manufacturer/part information to their libraries/designs that everyone uses the same field definitions. It’s a massive interoperability problem otherwise.
EDIT: this looks out of place because the forum doesn’t group/indent replies and I was replying to an older comment. Nevermind… Basically I think this is a great idea and heading in the right direction. My only two cents is I would prefer MPN1 MPN2 SKU1 SKU2 etc because they usually have a direct relationship. (SKU1 is only the number for MPN1, not MPN2). And having “MPN” and “MPN2” is just bizarre to me as this changes the format between the two fields.
Good point, I think this is what’s leading to most misunderstandings in the discussion about these fields (no matter how they are called): You are not obliged to use them but for them to be of any use, their name should be the same in all schematic symbols.
It is slightly uglier but allows for compatibility with existing tools, e.g. KiCost. It could be argued that it is nicer for parts that only have one of each. It’s not really changing the format it’s just that the integer “1” is implied when omitted.
Yeah you’re probably right. It’s only a minor point anyway. Either would be a huge improvement.