My suggestion is to have the Version ID box be editable during the ECO process so that we can define any version ID we need - as long as it doesn't already exist for that product. Likely the approach should include this as a configurable option in the SetUp, to allow for this field to be open. The logic does already look to see if the 'new version' exists, this logic should stay.

We ran into two scenarios where this functionality would have been and continue to be tremendously beneficial...

1. If you are migrating versions of a product, and there is a chance of a previous version becoming active again - include it in your migration - as there is no way to force a previous version, and then you will be out of sequence with your legacy information.


2. Double check your migration data for when you have multiple versions for a single product. We had several, where the versions were generated out of sequence (still unsure how), the only work around is to obsolete the whole product structure and create new manually so your versions are back in sequence. If you do not start over, you will not be able to create new versions as FO will not know what to do, the logic only looks at the 'last' version ID, but will error because the next one exists.


Thank you for your votes!

Needs Votes
Ideas Administrator

Thank you for your input! Engineering Change Management is designed so that the version control is inside the sytem and it should not be overwritten by any user. 

We see that the data management framework error that you had on your case is the exception and will not be a rule, so we consider this should not be needed in the application for most cases. 

However, we will keep the idea open so that we can monitor if this happens to other customers and may reconsider. 


Beatriz Nebot Gracia

Product Manager, Microsoft



Great idea Sonja

Category: Product Information Management