Community
I think this is one for the devs. This isn't unique to one item, this has occured across dozens that I've seen so far within an hour of looking around.
In a nutshell, after migrating a Vault from 2013 > 2015, Vault has added new BOM lines to Items. Those lines are not there in 2013 and there is no file link either. They're shown as 'Off', but they're there and they shouldn't be.
1. Here's the Item BOM in Vault Pro 2013 (Released Rev 3):
2. This is the exact same item in Vault Professional 2015, same Vault, immediately after the migration:
3. There is absolutely no reference to this file in the primary associated model (Inventor), in either 2013 or 2015:
4. The random Item that appeared is Item Number AG4062. It's Item has no parents, it shouldn't as the BOM row is off but the primary file for AG4062 is also not shown as used anywhere:
So why has Vault put this Item into the BOM of another Item when there's clearly no visible reference or link between the entities?
Bearing in mind this Item was Released, there shouldn't be any permitted BOM alterations of any type.
5. As it was released, I've changed the state to WIP and performed an Item Update... Vault then removes the reference to the random Item after an update! It's almost like it's there, it shouldn't be there, so an update gets rid of it. But why is it there in the first place?
Some of our items have multiple parts in like this, you update the Item and they are then removed. It's of no comfort that there are shown as 'Off' as there has ultimately been a BOM modification, and these are what stand out, so who knows if I run a fine tooth comb over all the 'On' rows will I also find extra rows in there? I don't know. I need an explanation as to what is happening here though.
Thanks in advance to anyone who looks into it, I appreciate very few people will have an exact replica of their Vault in 2 different release versions so it may be difficult to get an answer here.
For anyone reading this, although I haven't fixed it I've found the source of the problem.
2 years ago I ran a mass import script which imported 180,000 Items into the Item Master, then another script which imported 500,000 BOM structure lines. Essentially transferred all the parts and BOM details from a third party system into Vault.
Since then, users have obviously used Vault Pro Client to remove BOM rows and add BOM rows etc etc.
After migration to 2015 from 2013, Vault has re-added all the rows that were originally there on the initial import!! The ghosted out 'Off' rows you see above where present in the BOM 2 years ago, subsequently removed via the correct methods, and suddenly they're back in the BOM! Even if the Item was released during the migration! This has systematically occured across thousands of Items, so it's become a huge problem. It's an even bigger problem than that though...
If the ghosted out 'Off' row is an assembly Item, setting the BOM view to 'Parts Only' will then populate the BOM with it's child pieces. Essentially destroying our BOMs.
Luckily, well not luckily as you'd be stupid not to, but this is confined to a test system. It's a show stopper for my migration until I can clean the database somehow. I'd be very surprised if anyone else has this issue but I'll post a solution once I have it.
I've heard that this is on the roadmap to be fixed in a future 2016 update. Can someone please advise whether this is due to also be resolved for 2015 users, as this is still a supported product I should hope that it will be.
A lot of time has gone by since I reported this. I've determined that the Items appearing in the BOMs are previously deleted rows which the migration process has decided to put back into our BOMs. Obviously, this is crazy, and dangerous, and isn't in any way nullified by them being OFF. We've already had a BOM sent out to a fabricator with these spurious rows included which nearly resulted in a very very expensive mistaken purchase.
I guess it's good that it's been finally recognised as a product issue, but customers on 2015 should also receive the fix.
Because they're still there and they shouldn't be. The core issue is that the migration inserted additional BOM rows into production BOMs, which is if anything potentially dangerous.
Switching the view preferences is merely a temporary band-aid, and I have 100+ users and no way to ensure they all do that.
Also, most export routines from Vault Client and Web Client ignore cosmetic view preferences and export these rows, which when printed become unrecognisable from genuine BOM rows.
I don't want to get all dramatic about it, but surely someone is taking this seriously? It's data corruption caused by migration.
Hi Paul. A number of points to discuss there.
Firstly.
In 2014 and earlier, there was only one option/command available to the user for removing/deleting an Item BOM row. The command was called Remove row, correct? Not one single Vault Professional user would have used that command and knew that these rows they're removing where actually only being hidden. Every single user used that command because they wanted to delete the row from their BOM, it had no other purpose, it was there to DELETE a BOM row or so the user was taught.
So, who in Autodesk actually thought that there would have been a demand for these rows to re-appear? What possible research was that decision based on? Please do feel free to put that person in touch with me as I'd love to understand what this person was thinking and what other parts of Vault they have influence over. You can't just let users remove lines from a BOM and not tell them that they'll come back in the future, regardless of that being in an off or on state.
So I completely understand what you're saying has happened, but it's no less ridiculous. From my conveniently naive point of view, the migration did add the rows because those rows had been consciously and intentionally deleted by the user (because the user had no reason to think otherwise), if Autodesk are saying no they weren't deleted, just hidden, then that's a massive failure in product design & communication from Autodesk. At no point did anyone from Autodesk or any literature explain that removing a BOM row in 2014 and earlier was actually just hiding the row, and that when you migrate in the future they'll all come back on again! Can you not see how unbelievably ridiculous that is? Obviously it isn't your fault, please don't feel like I'm yelling at you.
The other point to discuss here is the belief that this doesn't matter, because they're 'off'. And I think this boils down to Autodesks lack of real world understanding of industry and the people who work with their products. Please understand that many many many people who view BOMs have zero computer knowledge, zero Vault knowledge, zero technical skills. They follow a set of instructions to log on, punch in a part number, and look at the BOM. They've done the same routine for 10 years, they haven't got a clue what anything in Vault does other than their little routine. Now, all of a sudden, there's new rows in there and they're a slightly different shade of grey. You can't expect that person to understand the **** & balls story of "no actually they aren't deleted, they're hidden, now they're off". I've had to explain this to experienced engineers who are PC literate, and even those guys struggled to grasp what the hell was going on with this. In addition to that, as I previously mentioned, these 'off' rows will print from Vault client looking almost identical to on rows, and in some instances they can't be excluded at all. And please, pretty please, please do not think that the client 'show on rows only' is a suitable fix for this. I'm sure we've all been working with Vault for long enough to know how frequently the UI resets itself for no apparent reason, users are given new computers, new login accounts, that setting does not stick permanently.
So just to cap this off. The most unacceptable aspect of this saga is that these rows are re-appearing in Released item BOMs. After a migration, a Released BOM has additional rows. A technical explanation of historical behaviours isn't going to cut it here and make it all OK, this needs fixed and the rows need removed.
I will legally change my name to Puff the Magic McDragon if anyone, and I mean anyone who isn't a crazy loonatic, genuinely knew all along whilst using 2013/2014 that their rows are just being hidden, and they kept a record of what rows would come back, knowing they would come back, and they're genuinely delighted it all came back like a big massive recycle bin of carnage. I can't wait to migrate to 2015 so I can see all the Item rows I've deleted in the past come back! Jesus christ. 
Paul - on that note, if a customer does begin to use the on/off functionality brought by 2015 and later, how does that user then differentiate between a row they've legitimately turned off and a recycle bin row? Obviously whoever made this decision didn't weigh up that consideration when figuring out the right thing to do!
Just so you can understand my situation, I have an item master with 200,000 Items, it's impossible to gauge exact figures but I'd say around 50-60% of the Items in there have these recycle bin rows in them. I've seen items with more recycle bin rows than genuine rows. When you potentially have over 100,000 items requiring a cleanse, with the vast majority of them being Released... as well as being in an ERP system, I'm not about to fix this manually! In fact, in US dollars, we've been quoted around $8000 in Autodesk Consulting Services time to have this issue resolved via a cleanup script for 2015. Clearly that cost should never fall on the customer but this is why we need these rows gone...
A few weeks ago, a girl in the purchasing team logged into someone elses PC (new UI layout, default is all rows on) and printed a BOM which included many recycle bin rows, she then sent that out to be purchased... which she had every right to do, it was a released structure. That structure had a recycle bin row in there which costs around half a million dollars to buy, obviously it shouldn't have been in there, if it wasn't for the dilegence on behalf of the recipient of the order... who questioned it's presence in the BOM, that could have financially crippled our company.
I know I'm being all preachy but this isn't a harmless cosmetic issue, this could bankrupt a company in a worst case scenario, or even worse an electrical BOM could be issued with incorrect parts and components which could put lives at risk. I suggest the persons responsible weigh up this consideration when figuring out the right thing to do.
Thanks for your understanding though and any feedback you can pass through regarding this.
2 years and 2 product releases later, this issue hasn't been resolved. I've just migrated this database into 2017 and those ghosted BOM lines are still present after migration.
@paul.gunn are you aware of any update to this? Is there anything we can do to have a targeted script written to remove these rows? They've been wasting hours upon hours of peoples time on a weekly basis for 2 years now.
But these rows (on face value) are not identical to normal 'off' rows, they are off, but they're sat there with a quantity of -1 and must have some back-end identifier to distinguish them from user executed normal intentional off rows? Surely?
Yes the hardship is strong with this one, if the only avenue available from here is to go through Product Support then I'll raise a case and see what happens.
Thanks.
p.s. tbh I'm amazed that you guys are OK with this being left as it is. The migration to 2015 directly interfered with and distorted production data on a huge scale and no action was taken whatsoever. The rows are off but they're still present and appear on many various outputs from Vault.
Ok, just out of interest what have other customers done to counter this? We went through a straight forward migration to 2015 whilst using Items, 190,000 of them, and this happened, so this must also have happened for all other customers using Items at the point of migrating to 2015+?
Yea I see the benefit to having the capability of off rows, I just don't understand how it's not a concern to take every BOM line that was ever deleted in the past, and then empty that recycle bin back into the live Released BOMs as off rows. You can't control the view filters of every client indefinitely, no matter how many thunderdomes or whatever else you throw at it.
Never mind though, I'll take it up with Product Support and see about getting a bespoke script created to clear this up.
Thanks again for the response.
Can't find what you're looking for? Ask the community or share your knowledge.
Post to forums
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")