Software Component Vector in Modification Adjustment Transport

Question

Hello all,
We are in the middle of a support pack project for our SRM system, and I've run into a snag as I prepare to move them into QAS.  We've had this system for many years, and when DEV was originally installed in 2000 it was as a B2B 2.0a system.  It was upgraded to 2.0b before GoLive, and the QAS and PRD systems were installed directly as 2.0b systems.  The entire landscape has been upgraded several times in the twelve years since, and today it is on release SRM 5.0.
The problem is that the DEV system still shows an installed software component of NDI_ERM (Extended Relationship Management) in release 20A.  Obviously that is actually long gone, but it still shows up in SPAM in the Display Package Level function, and under Attribute SAPCOMPONENT in the properties of all transport requests released from this system.  It should have been passively deleted during the first (or subsequent) upgrade long ago, but for whatever reason that didn't happen.  This software component never existed in QAS or PRD and does not show up in SPAM in those systems.
This hasn't been an issue in the past, and so I've just ignored it as I always had bigger fish to fry.  I've performed upgrades and support packages for these systems without an issue, but we hadn't done any of these tasks for the past three years.
Until now.
I successfully installed support package stack 28 for SRM 5.0 into DEV a few months ago, and I performed the required modification adjustments in SPAU, creating the usual modification adjustment transport.  Now, however, when I am trying to import the support packs into QAS, I have a problem when defining the queue, at the step for adding the modification adjustment transport.  The transport is marked with a Software Component Vector that includes the defunct ghost NDI_ERM 20A, and NDI_ERM doesn't exist in QAS.  SPAM finds the transport, but marks it with a red light ("Transport does not fit").  Drilling into details shows me that everything matches perfectly except for my ghost.  On that line I get "The software component is not installed," and SPAM will not allow me to add the transport into the queue.
I should point out that I can import regular transports just fine, and I'm pretty sure I could just import the queue without the modification adjustment transport, and then import it manually when SPAM gets to the step about performing the adjustment.  No doubt that would work, and that's almost certainly what I'm going to end up doing.  But it bugs me that I can't fix this.
I have some thoughts about fixes that might work, and I'd like input on whether anyone else has dealt with (and solved) this problem before.
I think that I could probably just delete the line in DEV in table CVERS for NDI_ERM and so have it no longer show up in the attributes of future transports.  That might solve the problem going forward, though it won't fix the mod adjust transport I've already released.  Any thoughts about this?
I was able to get the existing transport to no longer show NDI_ERM in its attributes by deleting the appropriate line in DEV in table E070A.  After doing that the transport looked fine in the STMS queue for QAS when drilling into its properties.  However, this apparently isn't enough for SPAM.  As I had already uploaded the transport in SPAM once, SPAM 'remembers' it and seems to have therefore cached its properties, including the NDI_ERM software component.  I haven't been able to figure out how to get SPAM to 'forget' this transport so I could completely upload it anew and hopefully get new attributes that will then match the correct software component vector for the target system.  Resetting the queue status doesn't do it.
Any thoughts on where (what tables) SPAM stores information about modification adjustment transports, and how to clear that information out?  Any thoughts on the (admittedly drastic) measures I've mentioned above?
Thanks in advance,
--Matt

Answer 1

Hello,
SAP strictly forbids the modification of those tables for specific Add-Ons or even essential software component. As you do not really delete those products from a SAP system. This will only partially remove meta information from a SAP sytem.  After the "reinstallation" the data and many other log files are still exists and may have some really inconvenient side effects in a SAP systems (inconsistent installation, incomplete database table conversion, problems regarding maintenance via notes and support packages, modifications cannot be reverted...) .
Additionaly it will be very difficult or even impossible to resolve upgrade or maintenance issues.
If you have any  issue regarding an installation of a SAP product, you should contact the corresponding SAP support. They will provide you the right solution. 
Currently SAP only provides for a small subset of Add-Ons the deinstallation.
Thanks a lot for your understanding
with kind regards,
   Thorsten Scheyter  (Development support)