Currently, so I am told, there is no integration between Item properties and those in File Store on the same object.
Example: A file in File Store is at Revision 0, you assign it to an Item in the Item Master. In Item Master change the revision (manually or through an ECO or Lifecycle change), and push that revision out to the CAD file (idw or ipt etc). Make changes to the CAD file, save and check back in to Vault. The file in File Store is still at Rev 0, though the ITEM is at Rev 1.
Linked with this, the Vault Revision Table.... pulls it's Revision value from the File Store value... so if it's not in sync with Item Master... it becomes a useless tool.
I have recently run into several situations where we cannot assign the item number through a mapping of the filename. I found that this functionality was available back in 2010, but was lost when the properties module was redesigned for 2011 and has not worked that way since. This is most critical for non-CAD files, such as PDFs and TIFFs, as they do not typically have other properties to support a mapping. It would be great to have a way to assign the item number to use the filename without the extension.
We're using full SQL replication and as far as I know, the document numbering schemes are having no issues with being used across multi-sites so on face value, I can't see why the Item numbering schemes should.
Technically speaking again, I get the 'if a workgroup goes down' theory but to be honest if a business is large enough to justify having multi-site replication, it'll be sitting on a pretty good IT infrastructure so although you can never say never, it's a rare occurence for a site to compeletely go down. However, item's being created is an event that occurs multiple times, hundreds of times per day.
In addition to that, I worked in the reseller channel for nearly a decade and this was never publicised by Autodesk, I had no idea that we needed to consider this when building multi-site implementations. A Google search for "autodesk vault item number replication" returns zero information on this and confirms that I haven't missed an technical publications on this story.
The concept of having a numbering scheme per site isn't a practical one, if you allowed the option of defaulting a specific numbering scheme to a specific site then it would be close to being a considerable option. If it was up to me, I'd consider altering product behaviour to either:
1) Provide an administrative option whereby if a workgroup goes down, prevent any Items being generated. Then it's up to me, if a site goes down I can simply stop Items being made until things come back online.
2) Keep the current existing workflow, but in the event of a disconnection between publisher and subscriber, when the failed site comes back online, Vault creates an ADMS task to automatically renumber any Items created during that time with the [@WORKGROUP suffix], giving them the next available number. Warn all users with an in-client prompt that the Items they're creating may be automatically renumered when the system fault is resolved.
3) Most if not all everyday Vault users are not going to have a clue about what we're talking about here, so when this numbering conflict occurs through standard workflow, at least give them an in-client prompt or warning explaining why their Item number isn't now what they first thought it was.
4) Make the Item numbering schemes work the same way as the document numbering schemes!
I can think of many more options, most of which including the above are all much more favorable than what we have now which is Vault modifying production data at will without any warning to the user.
This isn't so much an idea or a wish, it's necessity. I have 150+ engineers using Items and working with the BOM tools, we've recently moved from a third party cheap BOM management system to Items, and this cheap system was a lot more user friendly, I hear the same words every day "so we've moved to a new system that does less than the old one?".
All of the below points all road back to one compelling factor, whoever at Autodesk was responsible for designing Items has never worked with an engineering BOM in real life.
1) It's currently not possible to search within an Item BOM. This is crazy. If I have a BOM with 2000+ lines in there, which I do, I have many of them, I can't search in context to check for something. People need to do this on a daily basis.
2) I can't see or check what the Item BOM was like at a specified date in the past. Vault has a habit of tampering with BOMs, people have a habit of tampering with BOMs, it's vital to be able to see the BOM quantities and contents at a specified previous date, currently this is not possible.
3) Copy/Duplicate an Item. It's normal practice to create multiple parts in the Item master, all that have very similar properties and descriptions, being able to right click an item and chose 'copy part' or 'copy Item' should be there.
Currently in Item Master, if I have just made changes to a file, and want to set the Item back to Released, or Review... I constantly get yelled at for forgetting to Update the item first. I think it might be helpful to have the Item automatically update from the file when a Lifecycle change is called. I can't think of anything that this could damage, but I'm open to comments if someone has a legit reason why this would be a bad thing.
It is easy to do copy design on CAD files and get new items and BOM, but some of our customers use vault to manage their design with no CAD models or with non-structured CAD files, so it is impossible to use copy design function on their files and promote new items and BOMs.
The only feasible way we found is to export items to a csv file, change the file manually in excel, and then import items with the modified csv file. But I don't think this is a good idea because it is very easy to make some mistake and it is not easy work.
We think a copy design function for items is needed here, it should just like the copy design function on files, we can choose the new item number for the copied item, choose which items to be reused, replaced, or copied as well, together with their attachments.
We also think a SaveCopyAs function for item is very useful in such situation, a new item will be created immediately with the same BOM stucture and same properties, then we can modify the new item as needed.