Single part per line don't make difference against footprints

[Alain Portal]

In my schematic, I have 2 74HCT04 with footprint SO14 and one 74HCT04 with footprint DIP14.
If I make a BOM using "single part per line" and "footprint", all 74HCT04 are reported as being SO14.

Same problem with 100nF condensators: some are SMD, others are not, all are reported as not being SMD.

[jean-pierre charras (jp-charras)]

Please, read eeschema doc, chapter 4.6

[Alain Portal (alain-portal-univ-montp2)]

OK, sorry.

Could this become a feature request?

[Jeff (jkaskey)]

Having read Ch 4.6 (4.7 in latest docs), I believe it describes a bug-workaround. Without warning the user, the tool creates an incorrect BOM unless you make up an artificially tweaked part name. Worse, as the docs state "...single part per line only requires the component properties to be edited for one component on the schematic and not all components with that same Value". This means that if you query a part in the schematic, its properties may or may not represent the value that will get printed in the BOM. That is not just a bug but likely an expensive one. Additionally, it suggests that there is some logic that determines which component property will be chosen from the conflicting ones, but it does not describe what that logic is. So there is no safe way to follow the instructions.

So if someone believes this behavior is desired (obviously I don't) then at the very least the user needs to be warned when their BOM will definitely be incorrect. But it makes much more sense to simply create a separate BOM entry for separate parts, where a part is, at minimum, defined by its Value and Footprint.

Even if this all worked correctly (proper warnings, defined logic) there is no reason the part name should have be manually edited to be 10K_small, 10K_med and 10K_large if you have an 0402, 0603 and 1/4W. Given that a sizable design can have hundreds to thousands of parts that exist in more than one footprint, this workaround creates a ton of manual work.

[Jeff (jkaskey)]

OK, I take it all back. Looks like this was fixed by Marco in bug 724531. Thanks!