Deleting derivation rule for the existing characteristic in operating conce

Question

Hi all
   My customer has two characteristics" Billing Doc(VBELN)" and" Warranty status" in the development and testing client and not in the production now.
Option 1 : Is to delete them but as the data is already posted for the same in the test and development client,it is lot more complex( involves  implementation of OSS notes-SAPNET note 21207) .
Option 2: If we decide to keep them for now:These two have a derivation rules too. So  can we simply delete the derivation rules so that data will not get posted to them( So will not effect the PSG i.e ce4xxxx table in production once the same transport is moved to production). There are no dependencies on this derivation rule.
Option 3: Can we also remove them from segment level characteristics?
Please let me know pros and cons ?
I really appreciate your time and effort.
Thanks & Regards
Sri

Answer 1

Hi,
   If the characteristics have not been transported to production then why don't you delete them in the dev/test system ? Here you can take the risk.
To delete characteristics or value fields, perform the following
activities:
1. Delete the corresponding characteristics and value fields from Customizing in all clients (this includes forms, reports, planning
layouts, and so forth). To locate characteristics and value fields, use the appropriate where-used list in the Customizing Monitor. You can access it by choosing Tools -> Analysis -> Check Customizing Settings (TA KECM).
You can jump directly from the where-used list to the relevant Customizing transaction and then delete the appropriate field there.
2. Switch to the screen for maintaining the data structure of an operating concern (Maintain operating concern).
3. If you need to effect other changes to the datastucture for the operating concern before making any deletions, effect those changes and save the data structure.
4. In order to be able to select the fields of the data structure, choose Extras -> Characteristics (or Value fields) -> Unlock.
5. Select the characteristics and value fields to be deleted and remove them from the data structure with the "Reset fields" function.
6. Reactivate the operating concern. The system starts by checking whether the operating concern contains any data and whether the fields to be deleted are still being used in any Customizing settings.
7. If none of the fields are still in use, the system then starts the re-activation. If the operating concern does not contain any data or does not require the database system to be converted, the tables are activated. You are then able to activate the environment for the operating concern. In this case, the following activities no longer apply.
If the operating concern already contains data, a system message tells you that the database needs to be converted. If you proceed, an activation log appears (at the top of the list).
8. Analyze the activation log. If it only contains error messages telling you to convert the tables, proceed with the next activity.
You must otherwise remove the cause of the errors before the tables can be converted. In this case, you should answer "No" to the next prompt, which asks whether the conversion transaction should start.
9. If you still only receive error messages telling you to convert the tables, choose "Back" and start the conversion.
10. Plan a job for the conversion. A list of the tables to be converted is shown for this. If the tables only contain a small amount of data (less than 10 000 records), then all the tables can be converted in one job. In that case, you can select all the tables.
For larger tables, conversion should take place in several jobs.
However, you should ensure that table CE4xxxx (where xxxx = operating concern) is the last table to be converted.
Warning. No other changes can be made to the operating concern during the conversion.
A copy of the table is generated during the conversion. The database system should have sufficient memory available for this copy.
To schedule conversion as a job, use the "Schedule selections" function.
You can display the current status of the conversion by selecting the "Refresh" icon. Tables disappear from the list once they have been converted sucessfully. If a conversion is taking a while, it is also possible to leave the transaction. You can then continue the conversion using DB requests -> Mass processing in one of the following ways:
With the job overview. You access this by choosing System -> Services ->Jobs.
Using the database utility transaction. You access this by choosing Utilities -> Database Utility in the ABAP Dictionary menu.
You can use the status function to call up the status of the operating concern during operating concern maintenance. You need to activate all tables after conversion.
11. To analyze errors that have occurred during the conversion, you can use the database utility transaction by choosing Extras -> Logs. The log has the same name as the conversion job: TBATG-date. You can also restart the conversion with this transaction.
For more information on the database utility, choose Help -> Application help while still in the above transaction.
12. Once you have activated all the tables in the operating concern, generate the operating concern environment from within operating concern maintenance.
You can then use the operating concern again.
Please, refer to the IMG documentation under Controlling ->Profitability Analysis -> Structures -> Define operating concern
-> Maintain operating concern, for further details.
regards
Waman