“The secret of change is to focus all your energy not on fighting the old, but on building the new.” - Socrates (the fictional gas station attendant, not the Greek philosopher)
“All great changes are preceded by chaos.” - Deepak Chopra
Sometimes, despite your best efforts, you have to go back and change things after you’ve gone several miles down the road. Characteristics can be one of those things.
I have a tendency to create characteristics as simply as possible. I make them CHAR unless there’s a real reason not to. I only make them as long as the longest value I currently have. I make them Single Value if I can. And I don’t make them Restrictable unless I know they’ll need to be. I try to think about all the uses a characteristic will be put to. But, if there’s no compelling reason to do otherwise; simple is the rule.
Why? Because simple characteristics scale well. A model with a thousand simple characteristics will always perform better than a model with a thousand complex ones. And there are no other surprises, like finding out that you can’t do what you want to do with a characteristic because you made it multi-value. Unfortunately, most models need at least a few complex ones. It’s inevitable that you’ll find yourself well into the development of a model and decide that a certain characteristic absolutely has to change.
If you figure this out soon enough you can go to CT04 and just make the change. Click. Done. But not often. In those cases where the change is grayed out, or you get an error message telling you that you can’t do that, you have to be a little more industrious.
If you haven’t used a characteristic yet, you can still change whatever you want. Once you put it in a class, and in a table, and use it in dependencies, this changes. Since this usage is what prevents you from making changes, it stands to reason that undoing this usage will allow you to make changes.
Please note the following method only works if you have not yet deployed this characteristic, or applied Engineering Change Management to it. For those cases see “Caveats and Another Method” below.
So, if you lock all the dependencies, remove it from all the tables, remove it from all the classes, and remove it anywhere else it is used, I guarantee you’ll be able to change it. Simply put; that’s a royal pain. Fortunately, in most cases you don’t have to undo everything. You just have to undo some of it. It depends on specifically what you want to change.
Here’s a characteristic that is in use in a model. Note that things like Multi-Value, Restrictable, and Data Type are locked. In this case I want to make it Multi Value.
If you look at the Where Used report (Menu: Environment à Where Used) you’ll see why:
(I like to save a copy of this screenshot to refer to later when I’m putting the uses back on the characteristic.)
This characteristic is used in one class, one table, and 2 dependencies. What I’m going to do is “un-use” the characteristic a little at a time, and then see if I can change what I need to change. First, I’ll lock all the dependencies. Then, I’ll look again to see if I can change it now.
In this case, no dice. Still locked. I sort of knew this would happen, but locking the dependencies, making the change, and then unlocking the dependencies often does the trick. I’m guessing the table is still causing the problem.
I’m not going to remove it from the table (yet). First, I’m just going to remove the data (making a backup copy, of course) and then try again. Still not enough. Still can’t make the change.
Next I go into the table structure (CU62) and actually remove the characteristic. (I can’t do this without first removing the data, so I needed to do that in any case). Save the table and look again.
Now I see I can make most changes:
Now, I can make it multi-value, save it, and begin the process of putting all the previous “uses” back in place. So, I would need to put it back in the table, restore the table data, and unlock the dependencies one at a time.
Depending on the changes I made I may well have to make some changes to my dependencies. When I unlock them the syntax checker is now checking based on a multi-value characteristic instead of a single value one. The same code may not work. But, there was a reason I needed the characteristic to be multi-value, so I’ll have to make those changes.
But what about changing the data type?
Well, assume for the moment that I have not added it back to the table or unlocked the dependencies. If you’ll look at the where-used you’ll see it’s still used in the class.
To change the Type, I’ll actually have to remove it from there as well.
After I remove it from the class, it looks like this:
If you change it, and add it back to the class, table, and unlock the dependencies, you’ll absolutely have to change some code. But, you’ll have gotten what you wanted; a changed characteristic.
To recap, if you need to change a characteristic, see where it’s used and start “unusing” it. At some point in the process you’ll be able to change what you need and begin the process to “reuse” it. Sometimes, just locking all the dependencies is enough. Other times you have to actually remove it from the class (removing or locking all references in the code first). Worst Case Scenario? See the next section.
Caveats and Another Method
Once you’ve gone into production with a model containing the characteristic, or if you already had Engineering Change Management applied to the characteristic, this method of “unusing” and “reusing” may not work. In fact it probably won’t.
If the model has been deployed into production it is probable that configurations of the material have been saved with orders. These saved configurations will show up as “uses” in the where used list and will prevent the change in Production. You may well be able to make the change in Development, but the ALE will fail.
Engineering Change Management means it is probable that the characteristic will still exist in its old form even if you remove it from everywhere it’s currently used. This is because Engineering Change Management saves versions of the characteristic (and the tables and dependencies if they’re under ECM as well). Even though the uses are for the old version, SAP still won’t let you make the change.
The other method of changing a characteristic works even when the model is in production or is under ECM. This method involves making a completely new characteristic.
Create the new characteristic using all the settings you’ll need in the new world. Then add it to the class alongside the old characteristic. Then, using the where used list from the old characteristic go into every object used by the old characteristic and change the references to the new characteristic. Eventually, the old characteristic will only exist in the class.
Do not remove it from the class! If the model is in production and there are saved configurations, these saved configurations will contain references to the old characteristic. They cannot be deleted. You can hide the old characteristic so the user never sees it, but it will always be there in the background.
I thoroughly recommend regression testing this kind of change in the Quality system before deploying it to Production just to be sure. Your situation may have some circumstance I haven’t accounted for. Hopefully, you’ll be able to implement the changes you need.