Variant Configuration – Using CCUNDO

Home / Blog / Variant Configuration – Using CCUNDO

Well, I recently ran into a case that I needed to pull this old trick out of the archives.  It had been so long, that I needed to go to the CWG and look around to remember what it was.  It’s transaction CCUNDO. A rather handy transaction when you use VC and engineering change management together.  CCUNDO allows you to remove VC items like object dependencies, classes, characteristics, etc. from a change number.  For those of you familiar with ECM, you probably remember that you can just break the link by going into CC02.  CCUNDO allows you to select the items you need to remove from the change number, and magically, the change number link is gone.

Now, there are 2 major scenarios I use this transaction for.  The first and most common is a mistake.  I typed in the wrong change number when I went to change “X”.

The 2nd is also a mistake, but sometimes it’s a mistake from long ago.  In VC world, inevitably an object will be created without ECM, then later, an ECM gets attached to it.  Normally, this isn’t a huge deal, until you need to do something like add a new characteristic to a variant table, or change the value assignment alternatives to a table. These things can only happen when you lock everywhere the table is used.  And if you use ECM, it has to be locked throughout history.  If you created a dependency or constraint without a change number, but then added ECM later.  There will always be a date period from 00/00/0000 until the first change number was applied that you can never again touch.  Making it impossible to update that table.  Before CCUNDO, the only option was to create a brand new table and change everything over.  While this isn’t the end of the world, it sure is easier to just continue using the original table.  In this case, you use CCUNDO to remove ALL change numbers from the object, thus getting it back to a state of never being under ECM.  Then you can either delete the object and create it with ECM, or just reset it back with the latest change number.

Now one of the biggest things to keep in mind is that I do NOT encourage this to be used in production for anything other than scenario 1.  In scenario 2, you are likely to lose ALL your history on these objects.  Again, not the end of hte world, but having this history is the whole reason you use ECM.

Thanks for reading,

As always, thanks for reading and don't forget to check out our SAP Service Management Products at my other company JaveLLin Solutions,

Leave a Reply

Your email address will not be published. Required fields are marked *