top of page
  • Joé Desbiens

SAP VC: Best Practices and Warnings for Change Management

Engineering Change management (ECM) is a powerful feature of SAP. It allows you to implement changes using effectivity dates and keep a thorough history of changes made to most VC elements. ECM lets you keep VC elements in two states: before the change, and after the change. This is especially true when existing sales documents use the configurable material that contains the changed object.

Sales documents with a validity date before the change date will explode the VC model using elements as they were in the past, therefore preserving the consistency of the saved configuration. Without ECM, those sales documents could throw an error when re-opened if the saved configuration no longer fits the changed rules. ECM also gives the possibility of reverting those changes using transaction “CCUNDO”, starting from latest to oldest. You can think of it as peeling back layers of an onion.

However, one must keep in mind that once ECM is introduced, there is sometimes no going back. For example, a VC element which was processed once with a change number will always require a change number after that (unless the initial engineering change is undone). More importantly, there are instances where you cannot ever change certain attributes of VC elements once ECM is introduced, even with a more recent change number. The focus of this article will therefore be on best practices when using ECM in VC, as well as a word of warning on potential issues related to locking elements with ECM.


Value length

In a non-ECM world, although you cannot reduce the length of a characteristic, you can always make it longer (up to 30 characters). After using ECM on a characteristic however, you will no longer be able to change its length, even to make it longer. This can be of particular importance when the value set of a characteristic changes throughout a project. If the modeler took this into account and gave himself some “leeway” using a longer characteristic than required, then this can be averted.

Best practice: before implementing an engineering change on a characteristic, think carefully about the maximum length it needs to have. When possible, try to figure out with your customer if there is a possibility that longer characteristic values are later introduced and choose the length accordingly.

Case sensitivity

If ECM was used, this setting can never be changed again unless all engineering changes are reverted on that VC element. Although it is a fact that this attribute is locked after using ECM, it is generally a better idea to stay away from using case sensitive characteristics altogether as it can cause issues when used in dependencies, particularly with variant functions.

Best practice: Try to stay away from case sensitive characteristics. Use a custom variant function to address the requirement if absolutely needed.

Value assignment (single/multi-values) and restrictable flag

Keep in mind that these attributes will be locked after using ECM on a characteristic. Generally, switching a characteristic between single value and multi-values midway through a project is less common, as single value and multi-values are conceptually very different and behave differently in procedures etc. The same goes with the restrictable flag.

Best practice: Since restrictable and non-restrictable characteristics serve different purposes, you can’t just make all your characteristics restrictable in case ECM is ever used. There are things you can do with non-restrictable which you cannot do with restrictable, and vice-versa. You need to figure out what the behavior of the characteristic needs to be in the user interface and select the correct attributes accordingly[1].

Variant table structure

Several situations can prevent you from editing a variant table’s characteristics and keys. If you have dependencies referring to a table for example, then you can only add (not remove) characteristics from the structure (more on this in the last topic, specifically with ECM).

On the ECM side of things however, this goes a bit further. Even if you have no active VC elements referring to your variant table, you will not be able to change a table’s structure if you used ECM to maintain the values themselves in the table. As soon as ECM is used for that, then you can only add new characteristics to the table structure and you cannot change which characteristics are keys either. To change the structure, you need to revert whatever engineering change was done to the table contents. Please also note that ECM is not supported on the table structure itself – it is only supported on the table contents. This means that you cannot have a “before” and “after” stored in the system, and only the current state of the table structure is saved in the database.

Best practice: It is always best to make do without ECM tied to variant table contents if possible, although sometimes you will not have a choice and will need to use it to change table contents with an effectivity date. Keep in mind that it is always a trade-off and that if you do so, then you will not be able to change the structure unless you revert the change to the table contents.

Potential issues when locking dependencies with ECM

Lastly and most importantly, you must always be careful when you are changing the status of a dependency from “active” to “locked” using ECM, as it can impact other VC elements referenced by it, even if those elements don’t have ECM used on them specifically.

This is because of the way locking elements works with ECM. Remember that change management ties validity dates to the changes – once it is used, there is a “before” and “after” state. When you lock an element with ECM, it is locked starting at the valid-from date, but it also remains in the system as an active element with a date of 00/00/0000. It is a rather specific, non-intuitive issue, but it can happen and cause a headache if you don’t know where to look. Here are two examples.

Characteristic example

If you use ECM today to lock a dependency which refers to some characteristics, then you will not be able to change any of the previously mentioned attributes for any of those characteristics, unless the change is reverted on the dependency. That is because the system will still see an active VC element referencing the characteristic(s) with a date of 00/00/0000, even though as of today it is locked.










If you did a where-used on one of those characteristics with today’s date, you would not see any reference to the characteristic, even though the restrictable flag remains greyed out. But if you did a where-used and removed the valid-from date, you would see the culprit dependency referencing the element with a date of 00/00/0000.

You will not be able to make the dependency locked on valid-from date 00/00/0000. The only solution in that case is to revert the dependency change if you need to modify attributes of that specific characteristic. Once you have removed all engineering changes on the dependency, this will remove the 00/00/0000 entry in the database. You can then lock it for all dates (without ECM) and change the restrictable flag.






Valid since creation date, not in database before that

Best practice: if you do not see ECM used on a characteristic, but some of its attributes are locked, check the where-used list without a valid-from date entered. It is very possible that ECM was used on a dependency, which would need to be reverted layer by layer before locking the dependency again.

Variant table example

One last example would be variant table structures, as discussed earlier. Let’s say you either lock a dependency or remove the reference to one of the characteristics in the structure using ECM. You then want to remove one of the columns of the table. Unfortunately, SAP won’t let you do that, for the same reason as mentioned earlier. The system will still see a dependency referencing that table column and will throw you a message like this when you try to save your changes in CU62:

Characteristic “CHAR_X” in table “TABLE_X” is used in dependencies during the period from 00/00/0000 to 00/00/0000. This means that you cannot delete the characteristic.

Best practice: like characteristics, undo the changes layer by layer then lock the element before removing the table column. If there are too many changes to revert, consider the trade-off of using another table instead, but do note that the old table cannot be deleted.


Sometimes, you really do need to use ECM to continue supporting customers for which VC requirements have changed. If you keep the aforementioned considerations in mind, however, you are less likely to run into surprises down the road and will know how to handle them if they arise.

[1] The behavior of characteristics based on their restrictable flag is a rather lengthy topic by itself, which will be discussed in another article.

bottom of page