Organizations are always striving to find different options to have better and more flexible reporting of transactional data. Extending the standard SAP General Ledger code block for new customer-defined fields provides you with the option to enhance the reporting by entering specific data in those new fields. However, it is tricky to apply such new fields when the organization is already live and has a lot of transactional data.

Financial reporting is one of the main reasons why the SAP ERP Financials module exists, and generating financial reports accurately and flexibly is the prime objective in every organization. SAP has built in many reporting dimensions in the standard SAP ERP Financials solution (e.g., company code, plant, G/L account, cost center, profit center, internal order, segment, business area, and functional area). However, sometimes these dimensions are not sufficient and need enhancement for two reasons:

• The new reporting dimension need could not be met by any standard reporting dimension.
• The new reporting need can be met by a standard SAP reporting dimension, but that standard SAP dimension is already in use for other reporting purposes.

In such cases, you need to extend the standard G/L code block for new customer-defined fields. I focus on helping you understand different special steps involved in such G/L code block change in a live organization with historic transactional data.

Table 1 shows a summary of the various steps involved in activating a new field in the G/L code block.

Table 1

Some of the steps for activating a new field in the G/L code block

After you have activated the new customer-defined field, it is also important to retrofit the relevant historic transactional data to populate the values for this new field to ensure that the financial processes run smoothly and take into consideration the new field (for example, open items posted before activation of the new field and open items to be cleared after activation of the new field).

There are nine key steps involved in retrofitting historic transactional data. A few more steps may be needed based on an organization’s environment or customer-defined processes; however, these nine steps are applicable to all:

1. Create a customer-defined table to store the default value for the new field
2. Update table BSEG (the table for accounting document line items)
3. Update table BSEG_ADD (the table for accounting document line items posted in additional ledgers)
4. Remove the new G/L view of the FI documents
5. Rebuild the new G/L view of the FI documents
6. Update table FAGLFLEXT (the table for the general ledger view total level)
7. Update table FAGLFLEXA (the table for the general ledger view actual line items level)
8. Update FI secondary index tables (e.g., BSID and BSAD; this step is optional if reporting is based on these tables).
9. Update table FAGL_SPLINFO (the table for splitting information of open items)

Before I explain these steps in detail, note these recommendations:

• Make sure that all the technical objects that I describe are available in your system to avoid any interruption during execution of the procedure.
• You can perform the data selectively for the relevant historic transactional data. However, if it is time-consuming and complex to determine such data, then all of the historic transactional data can be retrofitted using the procedure that I describe.
• From a performance perspective, I have enabled the updating of the data in the block of 5,000 records at a time. You can increase or decrease this value during execution based on your system environment.
• Test the processes that I describe in a test system. A separate client is sufficient and a separate system is not needed.
• After all data is retrofitted, test your financial processes on historic transactional data (e.g., clearing an existing open item or foreign currency valuation).
• From the test execution, you receive the estimates of the time needed for such data conversion and, based on these estimates, you can plan for the downtime needed in your production system.

Step 1. Create a Customer-Defined Table to Store the Default Value for the New Field

The new customer-defined field needs to have a value for all the relevant historic data. You can define a customer-defined table to store a value for the new field based on various dimensions, such as company code or plant.

Continuing the example from Rohana Gunawardena’s article, “Expand Your Reporting Options with an Extended G/L Code Block,” in which a new field ZZLOB had been activated for Line of Business, I explain how you can define the fixed value per company code.

Execute transaction code SE11 and create a new customer-defined table named ZCC_LOB_MAPPING (company code to line of business mapping). The new table should have the fields listed in Table 2 defined.

Note
For details on how to create a customer-defined table, refer to the procedure mentioned in the “Create a Custom-Developed Table to Store Additional Information for Tasks” section of my article titled “How to Enhance Task Information in the SAP Financial Closing Cockpit in ECC 6.0.”

You may even design this field value derivation as multi-level or more condition based. To keep the example simple, I am illustrating the value derivation based on company code only. (If you are using a more complex setup for this, then you would also need to make corresponding changes in logic accordingly. (I explain how to make these changes in logic later in this article.)

After you create the customer-defined table, you can maintain the fixed value for each company code. To maintain the entries in this table, execute transaction code SM30. In the Maintain Table Views initial screen, enter the name of the customer-defined table name (e.g., ZCC_LOB_MAPPINGin the Table/View field (Figure 1) and click the Maintain button.

Figure 1

Maintain the customer-defined table

In the next screen (Figure 2), click the New Entries button.

Figure 2

New entries for the customer-defined table

This action opens a new screen in which you maintain the line of business for each company code. For my example, populate the fields shown in Figure 3 and then click the save icon.

Figure 3

Enter and save the records for line of business mapping

Step 2. Update Table BSEG

Table BSEG  is the backbone table of financial accounting and has all the line items level data stored. For historic data, you need to update the line items for the following accounts:

• All profit and loss accounts
• All balance sheet accounts not automatically filled up by document splitting

This updating ensures that the entry view of the accounting document also shows the value of the new field as if it was originally posted with this value. 

To update the various BSEG documents en masse, create a customer-defined program called Z_UPDATE_BSEG. To create this program, execute transaction code SE38 and create a customer-defined program by following the procedure to create a custom report as shown in my article “Cross Task List Monitoring in the SAP Closing Cockpit in ECC 6.0.” You can use the code shown in Figure 4 and the selection screen data shown in Table 3 to create the customer-defined program Z_UPDATE_BSEG.

Step 3. Update Table BSEG_ADD

Table BSEG_ADD is a background table for documents posted in particular ledgers. These documents are not updated in table BSEG and instead are present in table BSEG_ADD. Here also for historic data, you need to update the line items for the following accounts:

• All profit and loss accounts
• All balance sheet accounts not automatically filled up by document splitting

This updating ensures that the entry view of the accounting document also shows the value of the new field as if it was originally posted with this value.

To update the various BSEG_ADD documents en masse, create a customer-defined program called Z_UPDATE_BSEG_ADD. To create this program, execute transaction code SE38 and create a customer-defined program by following the procedure to create a custom report as shown in my article “Cross Task List Monitoring in the SAP Closing Cockpit in ECC 6.0.” You can use the code shown in Figure 5 and the selection screen data shown in Table 4 to create the customer-defined program Z_UPDATE_BSEG_ADD.

REPORT Z_UPDATE_BSEG_ADD.
TABLES:     bseg_add.
TYPES:     tt_bseg_add   TYPE STANDARD TABLE OF bseg_add.
DATA:     lt_bseg_add   TYPE tt_bseg_add,
          ls_bseg_add   LIKE LINE OF lt_bseg_add,
          l_lob         TYPE zzlob,
l_counter(7)  TYPE p.

SELECT-OPTIONS: s_belnr   FOR  bseg_add-belnr OBLIGATORY.  “Doc. Number
PARAMETERS:     p_bukrs   TYPE bseg_add-bukrs OBLIGATORY,  “Company Code
                p_gjahr   TYPE bseg_add-gjahr OBLIGATORY,  “Fiscal Year
                p_counter TYPE p DEFAULT VALUE ‘5000’.     “Batch Size

* Get accounting documents’ line items (Ledger Specific)
  SELECT * FROM bseg_add INTO TABLE lt_bseg_add
                     WHERE bukrs EQ p_bukrs
                       AND belnr IN s_belnr
                       AND gjahr EQ p_gjahr
                       AND zzlob EQ space.

  SELECT SINGLE zzlob INTO l_lob
                    FROM ZCC_LOB_mapping 
                WHERE bukrs     EQ p_bukrs
                        AND validfrom LE sy-datum.
* Update custom field ZZLOB (Line of Business)
CLEAR l_counter.
  LOOP AT lt_bseg_add INTO ls_bseg_add.
                    UPDATE bseg_add
                   SET zzlob = l_lob
                     WHERE bukrs = ls_bseg_add-bukrs
                   AND belnr = ls_bseg_add-belnr
                   AND gjahr = ls_bseg_add-gjahr
                   AND buzei = ls_bseg_add-buzei.
        ADD 1 TO l_counter.
            IF l_counter = p_counter.
          COMMIT WORK.
          CLEAR l_counter.
            ENDIF.
  ENDLOOP.
  IF l_counter <> 0.
    COMMIT WORK.
  ENDIF.

Step 4. Update Table FAGL_SPLINFO

Table FAGL_SPLINFO is for generating the SAP General Ledger view of the financial accounting document. It contains the splitting characteristics for each BSEG line and thus should be updated to have values for new customer-defined field based on the mapping created in step 1.

To update the various FAGL_SPLINFO documents en masse, create a customer-defined program called Z_UPDATE_FAGL_SPLINFO. To create this program, execute transaction code SE38 and create a customer-defined program by following the procedure to create a custom report that I describe in my article “Cross Task List Monitoring in the SAP Closing Cockpit in ECC 6.0.” You can use the code shown in Figure 6 and the selection screen data shown in Table 5 to create the customer-defined program Z_UPDATE_FAGL_SPLINFO.

REPORT Z_UPDATE_FAGL_SPLINFO.
TABLES:     fagl_splinfo.
TYPES:     tt_splinfo   TYPE STANDARD TABLE OF fagl_splinfo.
DATA:     lt_splinfo   TYPE tt_splinfo,
          ls_splinfo   LIKE LINE OF lt_splinfo,
          l_lob        TYPE zzlob,
          l_counter(7) TYPE p.

SELECT-OPTIONS: s_belnr   FOR  fagl_splinfo-belnr OBLIGATORY. “Doc. Number
PARAMETERS:     p_bukrs   TYPE fagl_splinfo-bukrs OBLIGATORY, “Company Code
                p_gjahr   TYPE fagl_splinfo-gjahr OBLIGATORY, “Fiscal Year
                p_counter TYPE p DEFAULT VALUE ‘5000’.           “Batch Size

* Get split info
  SELECT * FROM fagl_splinfo INTO TABLE lt_splinfo
                         WHERE belnr IN s_belnr
                         AND gjahr EQ p_gjahr
                         AND bukrs EQ p_bukrs
                         AND zzlob EQ space.

  SELECT SINGLE zzlob INTO l_lob
                    FROM ZCC_LOB_mapping 
                WHERE bukrs     EQ p_bukrs
                        AND validfrom LE sy-datum.
* Update custom field ZZLOB (Line of Business)
  CLEAR l_counter.
  LOOP AT lt_splinfo INTO ls_splinfo.
                   UPDATE fagl_splinfo
                  SET zzlob = l_lob
                    WHERE belnr  = ls_splinfo-belnr
                    AND gjahr  = ls_splinfo-gjahr
                    AND bukrs  = ls_splinfo-bukrs
                    AND buzei  = ls_splinfo-buzei
                    AND spl_no = ls_splinfo-spl_no.

    ADD 1 TO l_counter.
    IF l_counter = p_counter.
      COMMIT WORK.
      CLEAR l_counter.
    ENDIF.
  ENDLOOP.
  IF l_counter <> 0.
    COMMIT WORK.
  ENDIF.

Step 5. Remove the New G/L view of the FI Documents

Now you need to remove the SAP General Ledger view of the financial accounting documents of historic transactional data, as that had not been considered the new field value at the time of posting.

To complete this step, SAP has provided a standard program FAGL_DELETE_DOCUMENT. However, the limitation of this program is that it considers only one document at a time. There is no standard workaround for this limitation, and therefore, I describe a custom program to use to counteract the limits of the FAGL_DELETE_DOCUMENT program.

To remove the SAP General Ledger view for FI accounting documents en masse in table FAGL_SPLINFO, create a customer-defined program called Z_FAGL_DELETE_DOCUMENT. To create this program, execute transaction code SE38 and create a customer-defined program by following the procedure to create a custom report as shown in my article, “Cross Task List Monitoring in the SAP Closing Cockpit in ECC 6.0.” You can use the code shown in Figure 7 and the selection screen data in Table 6 to create the customer-defined program Z_FAGL_DELETE_DOCUMENT.

REPORT Z_FAGL_DELETE_DOCUMENT.
TABLES:     bkpf.
DATA:     t_bkpf TYPE STANDARD TABLE OF bkpf,
          l_bkpf TYPE bkpf.

SELECT-OPTIONS:    s_belnr   FOR bkpf-belnr OBLIGATORY.    “Doc. Number
PARAMETERS:      p_bukrs   TYPE bkpf-bukrs OBLIGATORY,   “Company Code
                  p_gjahr   TYPE bkpf-gjahr OBLIGATORY,   “Fiscal Year
                 p_test    AS CHECKBOX DEFAULT abap_on.  “Test Run

START-OF-SELECTION.
  SELECT * INTO TABLE t_bkpf
    FROM bkpf
    WHERE bukrs EQ p_bukrs
      AND belnr IN s_belnr
      AND gjahr EQ p_gjahr.

LOOP at t_bkpf INTO l_bkpf.
       SUBMIT FAGL_DELETE_DOCUMENT 
   WITH p_bukrs EQ l_bkpf-bukrs 
   WITH p_belnr EQ l_bkpf-belnr
   WITH p_gjahr EQ l_bkpf-gjahr
   WITH p_test  EQ p_test
   AND RETURN.
    CLEAR l_bkpf. 
ENDLOOP.

Step 6. Rebuild the SAP General Ledger View of the FI Documents

After completing step 5, the previous SAP General Ledger view of the financial accounting document is removed and from steps 2, 3, and 4, the back-end tables are updated with the new field information. Now the SAP General Ledger view of these documents has to be regenerated.

For this, SAP has provided a program RGURECGLFLEX (transaction code GLGCU1), which can be executed for multiple documents en masse.

The table FAGLFLEXT should be updated automatically following step 6. However, for certain lines where the balance carry forward is already completed, the new field still has no value. For these cases, you need to update the table FAGLFLEXT.

To update the various FAGLFLEXT documents en masse, create a customer-defined program called Z_UPDATE_FAGLFLEXT. To create this program, execute transaction code SE38 and create a customer-defined program by following the procedure to create a custom report that I describe in my article “Cross Task List Monitoring in the SAP Closing Cockpit in ECC 6.0.” You can use the code shown in Figure 8 and the selection screen data shown in Table 7 to create the customer-defined program Z_UPDATE_FAGLFLEXT.  

Z_UPDATE_FAGLFLEXT.
TABLES:     faglflext.
TYPES:     tt_faglflext TYPE STANDARD TABLE OF faglflext.
DATA:     lt_faglflext TYPE tt_faglflext,
          ls_faglflext LIKE LINE OF lt_faglflext,
          l_lob        TYPE zzlob,
l_counter(7) TYPE p.

PARAMETERS: p_bukrs   TYPE faglflext-rbukrs OBLIGATORY,      “Company Code
            p_gjahr   TYPE faglflext-ryear  OBLIGATORY,      “Fiscal Year
            p_counter TYPE p DEFAULT VALUE ‘5000’.           “Batch Size

* Get FAGLFLEXT info
  SELECT * FROM faglflext INTO TABLE lt_faglflext
                      WHERE ryear  EQ p_gjahr
                        AND rbukrs EQ p_bukrs
                        AND zzlob  EQ space.

  SELECT SINGLE zzlob INTO l_lob
                    FROM ZCC_LOB_mapping 
                WHERE bukrs     EQ p_bukrs
                        AND validfrom LE sy-datum.
* Update custom field ZZLOB (Line of Business)
  CLEAR l_counter.
  LOOP AT lt_faglflext INTO ls_faglflext.
                     UPDATE faglflext
                    SET   zzlob = l_lob
                      WHERE ryear   = ls_faglflext-ryear
                    AND OBJNR00 = ls_faglflext-objnr00
                    AND OBJNR01 = ls_faglflext-objnr01
                    AND OBJNR02 = ls_faglflext-objnr02
                    AND OBJNR03 = ls_faglflext-objnr03
                    AND OBJNR04 = ls_faglflext-objnr04
                    AND OBJNR05 = ls_faglflext-objnr05
                    AND OBJNR06 = ls_faglflext-objnr06
                    AND OBJNR07 = ls_faglflext-objnr07
                    AND OBJNR08 = ls_faglflext-objnr08
                    AND drcrk   = ls_faglflext-drcrk
                    AND rpmax   = ls_faglflext-rpmax.
  
        ADD 1 TO l_counter.
            IF l_counter = p_counter.
          COMMIT WORK.
          CLEAR l_counter.
            ENDIF.
ENDLOOP.
  IF l_counter <> 0.
    COMMIT WORK.
  ENDIF.

The table FAGLFLEXA should also be checked to determine whether there is any line that is relevant and not updated for the new field. If any lines are not updated, then you would need to develop a customer-defined program to update it.

To update the various FAGLFLEXA documents en masse, create a customer-defined program called Z_UPDATE_FAGLFLEXA. To create this program, execute transaction code SE38 and create a customer-defined program by following the procedure to create a custom report as shown in my article “Cross Task List Monitoring in the SAP Closing Cockpit in ECC 6.0.” You can use the code shown in Figure 9 and the selection screen data shown in Table 8 to create the customer-defined program Z_UPDATE_FAGLFLEXA.

REPORT Z_UPDATE_FAGLFLEXA.
TABLES:     faglflexa.
TYPES:     tt_faglflexa  TYPE STANDARD TABLE OF faglflexa.
DATA:     lt_faglflexa  TYPE tt_faglflexa,
          ls_faglflexa  LIKE LINE OF lt_faglflexa,
          l_lob         TYPE zzlob,
          l_counter(7)  TYPE p.

SELECT-OPTIONS: s_docnr   FOR  faglflexa-docnr OBLIGATORY.  “Doc. Number
PARAMETERS:     p_bukrs   TYPE faglflexa-rbukrs OBLIGATORY, “Company Code
                p_gjahr   TYPE faglflexa-gjahr OBLIGATORY,  “Fiscal Year
                p_counter TYPE p DEFAULT VALUE ‘5000’.         “Batch Size

* Get FAGLFLEXA info 
  SELECT * FROM faglflexa INTO TABLE lt_faglflexa
                      WHERE ryear  EQ p_gjahr
                        AND docnr  IN s_docnr
                        AND rbukrs EQ p_bukrs
                        AND zzlob  EQ space.

  SELECT SINGLE zzlob INTO l_lob
                      FROM ZCC_LOB_mapping 
                WHERE bukrs     EQ p_bukrs
                        AND validfrom LE sy-datum.
* Update custom field ZZLOB (Line of Business)
  CLEAR l_counter.
  LOOP AT lt_faglflexa INTO ls_faglflexa.
                     UPDATE faglflexa
                    SET zzlob = l_lob
                      WHERE ryear  = ls_faglflexa-ryear
                    AND docnr  = ls_faglflexa-docnr
                    AND rldnr  = ls_faglflexa-rldnr
                    AND rbukrs = ls_faglflexa-rbukrs
                    AND docln  = ls_faglflexa-docln.

    ADD 1 TO l_counter.
    IF l_counter = p_counter.
      COMMIT WORK.
      CLEAR l_counter.
    ENDIF.
  ENDLOOP.
  IF l_counter <> 0.
    COMMIT WORK.
  ENDIF.

Step 9. Update FI Secondary Index Tables (BSID, BSAD, BSIK, BSAK, BSIS, BSAS)

These secondary index tables are normally not needed for the data retrofit. However, if any reporting is based on these tables and the new field is a needed reporting dimension in such reports, then the new field’s values should also be filled in such secondary index tables. The customer-defined program can be created in a similar way for these secondary index tables as done in step 2 for updating table BSEG.