Upchain Backend Change Notifications

[adam.abernathy]

Why is there no system in place to notify tenants admins of backend changes.  Just learned that changes were made to the eBOM checkin where the item name field on an eBOM excel file needs to be unique.  This has not always been the case and had to spend a day coding up a workaround.  First off, the name field should never be unique.  There are better fields to use as unique, i.e., part number or item number.  Second, I got an error and that was my notification.  There was no discussion or warning from Autodesk about this change.  Can we please make this process for change better and easier on the admins.  

[CGBenner]

@emily.caulfield Can you help with this question?  Should this be moved to the Ideas forum?

[emily.caulfield]

Hi adam.abernathy, apologies for not responding sooner. I have been investigating why this change occurred and why it was not communicated. Generally, we include significant changes such as this in our release notes. However, it appears this one was missed.

For this change, it seems to have coincided with another change we made to electrical imports back on Nov 20th, 2023. The change was: "When importing an electrical BOM, if a mechanical item already exists with the same Manufacturer and Manufacturer Item Number as the item specified in the Excel spreadsheet, the item type now changes to a Purchased ElectroMechanical Part upon import." My guess is that this change has also meant that the Excel spreadsheet must contain unique file names, though I have not been able to determine why this was necessary. I will respond here if/when I receive an answer.

Apologies for the surprise inconvenience.

[emily.caulfield]

Hi adam.abernathy, I have an answer for you.

According to this help article, you must map item name, Mfr and Mfr item # at a minimum when creating an eCAD template. This has not changed. However, back in May 30^th, 2023 we introduced the functionality that when you import a spreadsheet where the Mfr and Mfr item # is the same in multiple locations, all of the other item attributes being mapped must be the same as well, but all other eBOM attributes (such as quantity, ref only, etc) must be unique. This functionality was also extended to allow the Mfr and Mfr item # fields to be left empty (again as long as all other item attributes were the same). All of this allowed users to import spreadsheets where the same item existed in multiple locations but with different eBOM attributes.

What this means is that if Upchain detects that multiple items have the same name or same mfr/mfr item # combo, then all the rest of the item attributes must be the same as well. Only the eBOM attributes are allowed to be different. So the logic has changed to check all three: item name, Mfr, and Mfr item # when determining which components in the sheet are the same item.

I've attached some examples of where an import was successful and one that has failed. I hope this helps. Apologies that this was not clearly described in the release notes.

[adam.abernathy]

This change is not an improvement.  In testing, I imported an eBOM with 2 rows of the same item, just different designator.  In the past, it would error out telling you that you have the same item listed twice.  Now it imports just fine but I have the same item listed twice in the cBOM.  This isn't how the system is supposed to work.  I don't know any scenario that I would want two of the same items listed twice in the same cBOM.  Just want the name being unique to be removed.  This is a very difficult thing to do because parts can have the same name, i.e., ADC or Optoisolator, and have very different operating characteristics.  

[tomislav.horvat8NHUW]

Dear Adam,

It is an improvement because before that change you would get a new Item number for each one of those combinations even though they were the same Item.

Upchain has always supported electrical packages to have the same Item number listed multiple times in BOM, that is not a new functionality.

There are two types of attributes when we are talking about Items - Item and eBOM attributes.
Item attributes are the same for all instances of that Item across the system - even in search. Those are the Item name, description, revision note, history, etc.
eBOM attributes are values that are stored on the relationship between that Item and its parent. An example of that is the quantity. Item does not know how many times it will be used in the context of the assembly, that's why it is not an Item attribute. The same is true for your Reference designator. The system does not know if that resistor will be R1, R100, or R1, R2, R100. That is up to the design of the PCB board.

The system limitation was always there and that is that only one Item can have the same manufacturer/manufacturer # combination. An additional restriction was added to the Item name so that the system does not create multiple Items in the system with that combination if that was left empty. It has happened in the past and that is why that restriction was added almost a year ago.

As for this use case that you are describing:
"I don't know any scenario that I would want two of the same items listed twice in the same cBOM."
We have automotive PCB designers in the system that have separated their components based on the PCB side - that means that they have resistors that go to side A (top) as one line Item going to one assembly machine and a second one for Side B (bottom) going to another machine.

As for Item names, either you use that system that has generic names such as 100ohm Resistor and you list different suppliers in the supplier's section or you create specific Items for those resistors 100ohm Resistor-Optoisolator. That way you will always have one Item number for that Excel line and the correct BOM which is what you need.
What other customers are using for prototypes is that they use generic names because they are not interested in having top components but available ones and as the design matures then they are changing it to specific components.

I hope this provides you with more context about how the system works, why there are certain limitations, and also what are the best practices.

Best regards,

Tomislav

[adam.abernathy]

If users are leaving field empty in their eBOM import, why has that been escalated to break our tenant and others?  And with no notification to anyone anywhere.  Why can't you logic the algorithm to check for unique mfg & mfg num before demanding name be unique.  Then if field is blank, goto name being unique.   My biggest issue is that there was no communication at all on this.  

[tomislav.horvat8NHUW]

Dear @adam.abernathy,

I agree that there should have been clearer release notes communication a year ago when those changes were made, I apologize for not making it clearer then.

Those were the changes that were verified then with users also during Inside The Factory event ITF-2023-Q1 and there was no feedback on making the Item name optional. The system is designed to fit the needs of the majority of the customers and their workflows, to ensure they have the correct data and provide them with correct BOM representations.

Best regards
Tomislav