Note 1451330 - Storing customer fields from BSEG in APPEND

Summary Symptom In a coding block enhancement (transaction OXK3), you added customer fields to the include CI_COBL and enhanced the cluster table BSEG with a modification. You want to clean up these modifications so that you do not have to perform a modification adjustment of BSEG with SPDD during future upgrades or when importing Support Packages. Reason and Prerequisites When you enhance the coding block, the system usually also enhances DDIC structures. Transparent tables such as COEP or VBSEGS are enhanced without modification - the customer include CI_COBL is already added to these tables in the standard system and new fields must only be added to CI_COBL centrally, which does not mean a modification (CI_COBL is never delivered by SAP but is created in the customer system only). For cluster tables or pool tables, this option did not exist before Basis Release 7.00, which means that customer fields had to be added to BSEG using a modification from transaction OXK3. As of this Basis Release (accordingly, as of ERP Version ECC 6.0), the ABAP Dictionary supports "cluster appends". You can use these to ensure that BSEG has no modifications and to obtain the customer fields including the field contents without having to perform a complex table conversion. Solution The solution is to delete customer fields from the table BSEG and add an APPEND to BSEG at the same time (in other words, in a transport request), in which the customer fields are added again using .INCLUDE CI_COBL in the same way as the transparent tables. As preparation, make sure that you have implemented Note 1283197 in all systems in which you want to clean up BSEG; otherwise, there may be an unnecessary data conversion. In addition, do not perform the steps described here during an upgrade or when importing a Support Package. Proceed as follows:     1. Call transaction SE11 for the table BSEG in change mode. Delete all existing fields in CI_COBL from BSEG (if these exist). Also check whether each of the fields in BSEG are the same type as those in CI_COBL. If not, do not proceed; otherwise, BSEG may have to be converted later. When using this procedure, make sure that no fields are duplicated when subsequently adding CI_COBL. At most, new fields should be added only if they did not already exist in BSEG. Save the table definition but do not activate it yet. The system requests a transport request. Exit transaction SE11.     2. Call transaction SE11 again for BSEG in change mode. In the menu, choose "Goto -> Append Structure" and then choose "Create Append" in the dialog box. Select an APPEND name in your namespace (for example, "ZBSEG"), enter a short description on the follow-on screen, position the cursor on the first line in the field list and choose "Edit -> Include -> Insert" from the menu. In the following dialog box, enter the structure CI_COBL. Save and activate it. In the following dialog "Inactive Objects", select both entries TABL BSEG and TABL ZBSEG to activate them together. This may take several minutes because the dependent DDIC objects have to be activated.     3. Use transaction SE11 to check that the table BSEG is active and the runtime object is consistent (in the menu, choose "Utilities -> Runtime Object -> Check").     4. Use transaction SE09 to check again that both of the objects LIMU TABD BSEG and R3TR TABL ZBSEG are contained in the same transport and can be activated together during the import. Otherwise, a complex conversion of BSEG is required in the follow-on systems.