[internal] Proposal: shorten BOM part number attributes

[formatc1702]

I propose shortening the part number attributes from

    manufacturer: ABC
    manufacturer_part_number: 123
    internal_part_number: 456

to

    pn: 456
    mpn: 123
    manufacturer: ABC

MPN seems to be an industry standard abbreviation.
Also, they are currently rendered as MPN and IPN anyway.

I propose pn over ipn in the YAML, and rendering it as P/N: in the output, but that's up for debate.

@Tyler-Ward (and others, of course) any thoughts?

[Edit]
As a side note, I would also like to swap the order of the fields in the graphic output to match the above:
P/N: 456 | MPN: 123 | ABC

[Tyler-Ward]

This seems sensible to me. I usualy go for longer names to avoid confustion but these look just as clear and take up less space.

Swapping to P/N rather than ipn sounds good, removing the explicit internal could also allow for people to use that field for a distributor/supplier part number if they dont have an internal part numbering system.

The order swap sounds logical as the pn field will likley contain the most usefull information in that group.

[aakatz3]

I agree, only suggestion is for MPN to render as MP/N or M P/N.

[formatc1702]

Perhaps the most elegant option would be to show only two fields in the node:
P/N: {pn} | {manufacturer}: {mpn}

And replace {manufacturer} with MPN/MP/N/some variant only if the field is None.
My thinking is that it will be rare to supply an MPN without also specifying a manufacturer... and even if the manufacturer appears e.g. in the type attribute (like the many Molex KK 254 in the examples), you'd probably still want it in a separate BOM field, for sorting/filtering by manufacturer easily.

removing the explicit internal could also allow for people to use that field for a distributor/supplier part number if they dont have an internal part numbering system.

My thinking almost goes the other way... people could use manufacturer+mpn to specify e.g. Digikey: 12345678 which would be more practical, for the hobbyist level.

Obviously you could go wild, allowing lists in the fields to specify multiple alternative suppliers and a number for each, but IMHO if you (as a user) are that serious, you should be looking at an ERP and internal numbering systems, and keep track of supplier variants there. In other words, do NOT think I'm advocating for adding even more fields/flexibility here :)

[formatc1702]

@Tyler-Ward would it be OK for you to submit a pull request [draft] with the proposed changes?

If so, please prioritize this over the additional BOM fields, since I'd like to have this one included in v0.2 soon-ish, where as the other one would make a nice addition to v0.3, since there's quite a few open points on that one.

[Tyler-Ward]

Happy to take a look at this, will aim to do this tomorow evening.

[aakatz3]

The main case I can see where you would specify a manufacturer part number and part number, but no manufacturer, would be if you are using "internal" part numbers, or supplier part numbers.

One possible solution would be to implement and use the octopart API, however this would require every user of the project to get a developer key for Octopart. My suggestion would be to show each field (P/N, MP/N, manufacturer) as long as the field is not None/null

[formatc1702]

The main case I can see where you would specify a manufacturer part number and part number, but no manufacturer, would be if you are using "internal" part numbers, or supplier part numbers.

In your screenshot, would 5555165-1 be the internal (=Octopart?) number, and A31422-ND the MPN (supplier part number, in this case)?
If so, what use is giving the Digikey part number without saying that it's from Digikey? Sure, Google might work it out in most cases, but I would never want to rely on that. The same logic applies if you consider Octopart your "manufacturer"/"supplier".

One possible solution would be to implement and use the octopart API

Let's not go down that rabbit hole, please ;) At least not now.

My suggestion would be to show each field (P/N, MP/N, manufacturer) as long as the field is not None/null

My proposal (quoted below) does this, but using two cells instead of three to keep the manufacturer and their number tied together (also visually) but allowing manufacturer to be Null as well.

Perhaps the most elegant option would be to show only two fields in the node:
P/N: {pn} | {manufacturer}: {mpn}

And replace {manufacturer} with MPN/MP/N/some variant only if the manufacturer field is None.

[kvid]

My proposal (quoted below) does this, but using two cells instead of three to keep the manufacturer and their number tied together (also visually) but allowing manufacturer to be Null as well.

Perhaps the most elegant option would be to show only two fields in the node:
P/N: {pn} | {manufacturer}: {mpn}
And replace {manufacturer} with MPN/MP/N/some variant only if the manufacturer field is None.

I agree to render {manufacturer}: {mpn} together to clearly show in what context the number is valid without needing the literal MPN, and the other details in your proposal also make sense to me.

If we sometime in the future want to support more numbers, it can be done with a separate look-up table of dict for each unique pn value similar to this:

parts:
    123 : ['Acme': '1234', 'Digikey': '5678']
    124 : ['Molex': '1244', 'Digikey': '5878']
    124a : ['Molex': '1034', 'Digikey': '5698']

Edit: A library file (included with --prepend-file) of often used connector and wire templates is also a good candidate to store information like this.

[Tyler-Ward]

If we sometime in the future want to support more numbers, it can be done with a separate look-up table of dict for each unique pn value similar to this:

From the discussion above I had also considered suggesting adding an extra bom atributes field or similar to let people add extra data to bom lines for components, however this felt like it might be better done by another tool/spreadsheet for those who need extra information on each part rather than featurecreeping beyond describing a wiring harness.

[formatc1702]

Closed by #121.