[BUG] Error using custom column order in KiBoM output

[hkleen]

Describe the bug
When specifying the column order for KiBoM output, non standard (i.e. custom) fields can not be specified.

For Example KiBot_KiBoM-columns.zip:
The components specify manufacturer and part No. in the "Manufacturer" resp. "MPN" field. As far as I understand, if I want to create a BoM using KiBoM using the the following column order: "Reference" "Manufacturer" "MPN" "Quantity Per PCB", I would specify the following "conf":

        columns:
          - References
          - Manufacturer
          - MPN
          - Quantity Per PCB

But this results in the following error msg

ERROR:In section 'bom' (kibom): Invalid column name `Manufacturer`. Valid columns are ['Component', 'Description', 'Part', 'Part Lib', 'References', 'Value', 'Footprint', 'Footprint Lib', 'Sheetpath', 'Quantity Per PCB', 'Datasheet']. (kibot - error.py:40)

This seems to be caused by Kibot running KiBoM to get a list of available columns and not taking custom fields into account.

To Reproduce

1. Download and extract KiBot_KiBoM-columns.zip
2. run kibot in folder

Expected behavior
Create a BoM containing only the columns "Reference" "Manufacturer" "MPN" "Quantity Per PCB" in the given Order

Environment (please complete the following information):

• KiBot and KiBoM built from current repository
• running on Ubuntu 22.04

[set-soft]

Hi @hkleen !
Thanks for reporting it. You are right, KiBot calls KiBoM to find the columns defined by KiBoM (which turns to be not really necesary since KiBoM isn't evolving much). But we didn't add the columns from the fields of the schematic. Now we do.

[set-soft]

BTW: The internal BoM is much better than KiBoM. I keep KiBoM for people that uses already created configurations. The internal BoM started expanding KiBoM and now can do a lot of extra stuff

[hkleen]

Hi @set-soft !

Thanks for the quick fix. I'm kind of stuck with using KiBoM, since we use a modified version to generate the BoM the way we need it (some color coding of rows depending on some field values, custom header, etc.). So using the internal BoM generator sadly isn't really an option.

[set-soft]

Hi @hkleen !
Is this modification something really specific for your team or something other people could use?

[hkleen]

Hi @set-soft !
I guess it is kind of specific but I think it might also be useful for others. I can give a short description of our modification:

We use one field to categorize our components to indicate which components may be changed by the manufacturer (non critical components) and which components must not be substituted. Based on the value of this field the row in the BOM will use a different color, so that the categorization is obvious at the first glance. We also include a color key below the component table. The field used for categorization is not included in the component table, but it is used to choose a background color for the row.

A very simple example might look like this:

[set-soft]

Hi @hkleen !

We use one field to categorize our components to indicate which components may be changed by the manufacturer (non critical components) and which components must not be substituted.

This is the DNC flag on KiBot (Do Not Change)

Based on the value of this field the row in the BOM will use a different color, so that the categorization is obvious at the first glance.

Ok, I see, a change of color because of a flag.

We also include a color key below the component table.

Ok, so you have more than 2 values.

The field used for categorization is not included in the component table, but it is used to choose a background color for the row.

Do you have some examples?

[hkleen]

Hi @set-soft !

You are right, basically this is like the DNC flag. But we use more than 2 values in fact we normally use 4 values, for example:

• 0: Component is not critical, mfg may use any component with the correct value
• 1: mfg may choose the actual component from a list of approved alternatives / same part No. but different manufacturer
• 2: Component mus not be substituted
• 3: Component will be provided by us, the mfg does not need to source this component

Let's suppose we have a 100 nF cap and we want the mfg to use any 100 nF cap we specify 0 as the value of the "Category" field. During BoM-Generation the background color will be looked up in a hard coded table, in this case light green.
The color key below the component table is also hard-coded in our modification.

A real world example will look like this:

This might be to specific to be of use for others. So I guess in order to make this useful to others it would require some modifications. For example it might be possible to specify a component field that contains the background color of the component in the BOM, maybe even using hex color codes like #2ecc71. Additionally a facility to specify an explanation / color key would be needed. This mapping of color code to meaning would have to be made in the configuration, as I can't think of any other way to achieve this.

[set-soft]

Hi @hkleen !

Now you can select colors for rows. We use filters to match the desired rows. You can find a naive example here.

The filters in the example are really silly, they match components using the reference, but you can use regular expressions to match any field you want. Note the filter inversion (we want to include, not exclude)

You might want to disable the column colors, to avoid confusion.

Here is an example for the HTML output:

[hkleen]

Hi,

Thank you for the update! This should work for me quite nicely...

Thanks for all the work you put into this SW.