Deletion of CI_COBL

[Karthik31]

Hello Experts,
We have one field in CI_COBL which needs to be deleted. As the structure cannot be empty we have to delete CI_COBL completely. Doing that makes our system inconsistent as some transaction says CI_COBL is not there.

The questions here are, 
1. SAP is giving option to add fields and deletion cant be?

2. As we have deleted CI_COBL our DDIC tables were inconsistent, BSEG, ACDOCA. We are looking for ways to regenerate it as SE14 is not working (The filed in CI_COBL still remains in table level)

[Sandra_Rossi]

1. SAP allows you deleting CI_COBL. 2. SE14 should work. As you got into the inconsistent state, you may repair it as explained in the forum (user DDIC client 000) but BE CAREFUL with SE14 you may lose the data in your tables, you need to be very careful now. First ask the users to stop using the system during the repair due to the high risk (otherwise you need to restore the database, it may take hours).

[aatan]

Hi again,

This post is a continuation of my previous post about deleting CI_COBL.
This time, I tested the process on a development system, not a demo environment, and I will share my experience step by step.

What did we do in short?

In the previous work, we did the following:

* We added a custom field starting with ZZ* to the CI_COBL include structure.

* No value was assigned to this field anywhere in the system.

* The work was never moved outside the development environment.

Important:

CI_COBL only contained the field we added.
Because there were no other custom fields, we wanted to remove CI_COBL entirely.

No problems were found during testing in the demo system.
Then, we decided to do it in the development system.

Deletion Process on the Development System

I carried out this process late at night.

First, to ensure no one was working on the system:

* I logged all users out of the system.

* I locked logon access.

Then I started the deletion steps.

Step 1 – Deleting CI_COBL

First:

SE11 → Data Type → CI_COBL → Delete

The deletion process took about 15 minutes.

During this time, I checked via ST22 and saw that several inconsistency dumps had occurred.

The dumps originated from RFCUSER and my own user.

Step 2 – CDS Activation Errors

After the deletion, some CDS views did not activate.

I got these errors:

DDL source V_COEPACDOCA_AGE could not be activated
DDL source V_COEP_ACDOCA_DDL could not be activated
DDL source V_COEP_ACDOCA_R1 could not be activated
Most recent runtime object DTDC FINS_DC_ACDOCA_GL could not be read
DDL source NSDM_DDL_MSEG could not be activated
DDL source V_COEP could not be activated
DDL source V_COVP_KAEP could not be activated
DDL source V_COVP_KAEP_11P could not be activated
DDL source V_COEP_V2_4 could not be activated
DDL source V_COVP_WOTP could not be activated

NSDM_DDL_MSEG Problem

There was a previously made extend view via ADT.
I deleted it and MSEG became active again.

Solution for V_COEP* CDS Views

To fix the V_COEP* CDS views, I ran the following program:

FCO_CDS_VIEW_GENERATE

iv_no_check = X
iv_reset = X **I set these parameters to X in debug mode.

After running the program, all V_COEP views were activated successfully.

I also checked it in SQL, and it worked fine.

Step 3 – Testing Basic Operations

To check for issues, I ran some key transactions:
F-02, FB05, FB03, MIGO, MB5B

I received no errors.

OData Service Control

I also reactivated some services that were inactive because of the CI_COBL field:

FAC_MANAGE_POSTING_TMPL_SRV
FAC_FOREIGN_VAL_POST_SRV
FAP_MANUAL_CLEARING_SRV
FAR_PAYMENT_POST_SRV
FAC_GL_DOCUMENT_POST_SRV
FAR_DOWN_PAYMENT_REQUEST_MANAGE_SRV
FAC_FINANCIAL_DOCUMENT_SRV_01
FAR_BS_ITM_REPROC_SRV
FAC_GL_MANUAL_CLEARING_SRV
FAR_MANUAL_CLEARING_SRV

Everything is working again. Great.

Step 4 – Dump Occurring the Next Day

The next day, consultants reported dumps in the following transactions:

F-44 and ACACPOSTINGRUN

Dump reason:
SYNTAX_ERROR

The details stated:
The data object "BSEG" does not have a component called "ZZ*"

This means the system was still expecting the old ZZ field.

Solution:
To fix this issue, I ran the following program:

RGUGBR00 → Application Area = FI

After this, the dump issue was resolved.

Current Status:
Two days have passed since the deletion.
No new problems so far 🙂

Final Thoughts:
Changes to core structures like CI_COBL are very risky.

For this reason:
Do not apply functional requests immediately.
Always question if they are really needed.
Never do this in production without planning.

See you next time,
aATAN

[aatan]

Hi,

An error was reported. Details are as follows:

When transaction code FBL1H was executed, the program terminated with a short dump.
Error details:
"invalidated view: V_GLPOS_C_VEN_CT: line 1 col 155 (at pos 154) [dbdbslst 5958] Exception = CX_SY_OPEN_SQL_DB_Sql_Error, program = FAGL_LIB_PIVB=================CM00W, line = 88"

After analyzing the error, I found that it was caused by the ZZ* field in the CI_GLPOSCCT customer include, which is used in the V_GLPOS* views.

Solution:
I deleted the CI_GLPOSCCT include via SE11 and then regenerated the views using transaction code HDBVIEWS.

[Sandra_Rossi]

Thanks for the great experience feedback! It's worth a blog post for finding it more easily.

[aatan]

CI_COBL ZZ* Field Removal (Tested)

We added a ZZ* field to CI_COBL in the customer system for a requirement. Later we realized it was not needed and wanted to remove it. After reading SAP Note 3456968, I thought it should not be deleted. But I tested it in a DEMO system and successfully removed it.

Steps:
1) Check all tables where the ZZ* field is used and make sure there are no values stored. If there are values, clear them first.
2) In SE11, select CI_COBL and click Delete.
3) If CDS activation errors occur (CDS_DS_CCS_PAR, V_COEP_V2_4):
- Activate CDS_DS_CCS_PAR in ADT (Eclipse).
- Run FCO_CDS_VIEW_GENERATE again and use IV_RESET (via debug) to regenerate the views so the ZZ* field is removed.
4) Finally, to resolve the NSDM_E_MSEG error, I deleted the Extend View object (ZCI_MSEG_E) that I had created.
5) Check key objects/tables (ACDOCA, BSEG, V_COEP, MATDOC, MSEG). No errors occurred.

Result:
This worked in the DEMO system, and I plan to apply the same steps in the customer development system.

[RaymondGiuseppi]

So you didn't read 3456968 - Deletion of coding block fields from CI_COBL ...

'The only recommendation is to customize the field as suppressed in all field status groups (in transaction OB14 and OB41) to hide the field from entry or display in any standard transaction, but you should NEVER delete the field from CI_COBL structure or any database table it was included.'