Vault Item Numbering

[dbrblg]

Whenever I create an item, it creates it with all the parts having a sequential number rather than the part number becoming the item number.

I'm sure i've seen this before but I cannot see where it is set.  does anyone know where this is controlled?

Thanks

[paul.gunn]

Hi,

This is done via property mapping (property admin dialog). There is a property named 'Number' - the initial value mappings (e.g. part number, component name) are used to determine the item number. The item number defaults to sequential only if these mappings are missing or don't apply (e.g. file doesn't contain a mapped property). It sounds like possibly those mappings may have been removed?

Hope this helps,

Paul

[dbrblg]

Hi Paul, 

Thanks very much for your reply.  We have managed to get hold of our reseller (which we couldn't do last night due to time differences) and they are looking into this it looks like there could be a bug somewhere.  These mappings are present and they are the exact same mappings on another vault which does work, so we believe there is something lurking in the background somewhere 

Thanks

[smilinger]

Actually I have experienced the same such thing.

What I have done is:

Export a configuration from a vault and import it to another, then some thing in the vault is broken, Item numbers cannot correctly get assigned.

I opened the SQL database and find the reason: the default revision scheme for the Item in the SQL database is messed up.

When you set a new default revision scheme for Items and then export configuration and import into another vault, In the SQL database it will end up with two default revision scheme, because at the end of the configuration import operation, ADMS will re-apply the default vault configuration.

Fortunately it is easy to fix, just set your default revision scheme to another, and then set it back, then it will all get back to normal.

[smilinger]

I did a little more test. It turns out not only Items, but also files have the same problem, only I didn't see any bad impact for files (not so bad as items). The results are as follows:

For file category "Engineering", added a new LifeCycle Definition and a new Revision Scheme and set them as default, export and import configuration to another vault:

For LifeCycle:

For Revision:

So there is two default LifeCycle Definition (or Revision Scheme) for the "Engineering" File Category, which one will show in vault category settings and which one will be the winner? The result is interesting, In my test, the default LifeCycle Definition show in vault settings is "Flexible Release Process", but the new created LifeCycle Definition actually won the game, the file assigned the "Engineering" Category follows the new created LifeCycle Definition; for Revision, the default Revision scheme show in the vault settings is the new created revision scheme, but actually the file revision follow the "Standard Alphabetic Format" revision scheme.

So, I think the best practice after import a configuration is, for all your file categories and item categories, reset your default lifecycle definition and revision scheme if it's not using vault default settings.

[Neil_Cross]

I'm not entirely sure how the above couple of posts regarding lifecycle definitions and revision schemes are relevant to equivalence mapping during the assign item process.  It's worth mentioning though that unless you know exactly what you're doing and are prepared to have an unsupported implementation, never directly edit the SQL tables yourself.

I've had this issue a few times, and there's been a number of completely different reasons for it happening.  Working on the basis that you have the correct property mapping set, which you've confirmed.

Keeping this as simple as possible, if I try and assign an Item to a part named 35000.ipt which should create an Item called 35000, but instead it gives the Item a sequential number from a different numbering scheme, the following reasons have been the cause:

1) There was already an Item in the Item Master with the number 35000, and the option 'auto-select first duplicate' was disabled.  Vault couldn't create a new item called 35000 so it gave it a new sequential number.

2) There had previously been an Item with the number 35000, it was deleted from the Item Master but something went wrong.  There is still a ghost record of this Item in the SQL tables but it cannot be searched for and found in the Item Master.  To check whether this is the cause, try renumbering another random item and manually typing in the number 35000, if Vault says another item already exists with this number then you have this issue.

3) I discovered and reported a bug with copy design which corrupted equivalance values and caused the assign Item command to link the new design to the item for the old design, this was swiftly fixed in the latest service pack for Vault Pro 2015, but will still be present in older releases of Vault and Vault 2015 SP0.  

Just a few suggestions, however I know how messy these issues can be and kind of require someone sat at a workstation to perform multiple tests so I guess your reseller should take this on and troubleshoot.  But whatever the issue is, it's usually quite easy to find it with some trial & error troubleshooting.

[minkd]

It sounds like you have already checked this, but just to be sure ...

Make sure you have the "initial mapping" set, rather than the overall mapping - see attached images.

-Dave

[smilinger]

I realised that my posts above may be too much digged into SQL Server or such things else, it can be confusing, so I should clear it up here: the issue I described above can be very easily reproduced, although it may not be the exactly same issue the original poster have experienced. Anyway, the steps to reproduce the issue is as follows:

1. To make it simple, create 2 new vaults in ADMS: VaultA and VaultB.
2. In VaultA, create a copy of the original Standard Numeric Format revision scheme, named Test.
3. In the Configure Categories settings, assign the new Test revision scheme to be the default revision scheme for the Part item category.
4. In ADMS, export configuration from VaultA and import it into VaultB.
5. In VaultB, check in a new created inventor part, 123456.ipt, for example.
6. Right click the part 123456.ipt and select Assign Item, normally, it should get 123456 as item number, but instead it will get 100001.

Such issue can be very difficult to spot, I remember it took me two days to figure it out, the reason and the solution are as I described in the posts above.

Hope Autodesk can pay some attention to this issue and fix it.

[minkd]

This is actually as-designed.  When importing a configuration it will not overwrite an existing configuration item with the same name. Therefore modified out-of-the-box definitions won't import.

You can avoid the problem by creating your own lifecycles, revision schemes, categories, etc; rather than modifying the out-of-the-box configurations.

Or you can create the 2nd vault with the exported configuration, rather than importing it.

-Dave

[smilinger]

I can't totally agree with you.

The AS-DESIGNED thing is actually OK, I can accept it that if I import a configuration I actually need to do some reconfiguration to make it work, at least it can save me lots of work, but I can't accept that after the import everything looks OK but somewhere you may never spot is actually broken, practically make your vault unusable.

The real problem here is that when Autodesk Vault import the configuration, it just literally import it, never do any checking to make sure it is correct. And when something is broken, people even need to dig into SQL Server to find out why, otherwise you will be forced to dump the vault you may have been working on configuration for hours and create a new vault from scratch. For such thing (such as a category has two default revision scheme) I will not call it as-designed, I will call it carelessness.

And when you said Therefore modified out-of-the-box definitions won't import, you are not correct, at least not accurate, in the steps I described above, after the import, the definition of the Part item category is actually changed, thus cause the problem.

However the last advice you proposed is considerable, I didn't realised that create a new vault with an existing configuration is different from import it to a new vault, I always thought thay are the same thing. I did a little test and the problem of mine is indeed gone, but I'd like to have more information of this, what's the mechanism behind this? what's the difference of it from the import procudure? what's the as-designed thing of this procedure, in case someday I may run into it.

[dbrblg]

Whilst I appreciate that Daves response goes a long way to describing how the import/export works, which is extremely useful, I do however have to agree with smilingers' views that this is a little careless in its design.

The import may be as-designed but at the very least it should provide a warning to say which settings have been successfully imported and those which have been unsuccessful.

Most software on the market today, does at least overwrite current settings with imported settings otherwise whats the point?

[minkd]

I totally agree that this could/should be improved. Adding a request to the Idea Station would probably be the best way to communicate your issues/ideas to product management.

The import will only add stuff to the current configuration, it will not replace or delete anything.  I believe collisions are logged in the ADMS-Console log.  And before you say it - I already agree that this is too hidden and hard to read - please see above. Personnally, I would prefer to see exactly what is being imported so I can pick and choose, and have the option to overwrite an existing setting - all before I click OK to do it.

When a configuration is not specified when creating a vault, we will create the out-of-the-box configuration.  If a configuration file is specified we will use it instead of creating any out-of-the-box configuration so there would be nothing present that would collide with settings from the exported config file.

-Dave

[tmoney2007]

It seems like one of those warn and overwrite situations.

I think that the reasonable expectation of performance would be that when a configuration is imported, it would be fully imported and replace anything already present. People shouldn't be importing configurations into vaults that already have content in them. That is a whole other level of functionality (configuration management rather than creation/import/export) that isn't even implied in any of these tools.

There are pieces of software out there that help to manage and move whole or partial configurations between environments. They are really great for enterprise companies that have development and testing instances in addition to production, but Vault has quite a few other things on the punch list before that becomes the biggest need.

[smilinger]

---

@minkd wrote:

When a configuration is not specified when creating a vault, we will create the out-of-the-box configuration.  If a configuration file is specified we will use it instead of creating any out-of-the-box configuration so there would be nothing present that would collide with settings from the exported config file.

---

I think this is not completely true. I did a test, I changed some of the out-of-the-box property names to what I need, for example, I changed Number to Material Number, then I export the configuration and use this configuration to create a new vault, but in the new vault it is still Number. So I think there is still some basic out-of-the-box configuration there not overwritable by a specified configration.

[smilinger]

I also tried to change the initial value mapping for Number, make sure it use Stock Number as the default Item number instead of Part Number, in the new vault, it's back to Part Number again, this is definitely not what we need.

So we still need to check our vault configuration carefully after such procedure and do come reconfiguration, just same as the import procedure.

[minkd]

The "Number" property is a system property so nothing about it (display-name, mappings, etc) is exported to, or read from a config file. So yes, any mappings you add to a system property will need to be re-added to new vaults, regardless of whether the vault was created from a config or had a config imported to it.

Also, beware that any system properties will "reset" after any migration, including the "b2bmigration" required for certain hotfixes. The good news is that this behavior has been corrected in the latest updates for 2015 & 2015-R2, but system property customizations are still not part of the config.

-Dave