Conversion of FI-SL Pool Tables to Transparent Tables

Description

In Release 4.0, all FI-SL pooled tables that have been used since a previous Release for test or production purposes are to be converted to transparent tables.

Two exceptions are table GLT2 (Consolidation) and GLTPC (Profit Center) together with their dependent line item tables:

These tables MUST be converted for 4.0 (provided that they were being used by the Consolidation and Profit Center Components for test or production purposes since a previous Release).

Information About GLT2 Conversion

The procedure for converting table GLTPC is explained in detail in its own release note in Profit Center Accounting.

All other tables should be converted according to the following guide:

Guide for Converting FI-SL Pooled Tables to Transparent Tables

1. Advantages of Conversion
a) Transparence of FI-SL Tables
Every summary or line item table used in FI-SL is transparent after conversion. In other words, they can also be processed externally.
b) Improved Processing Times
Transparent tables have more efficient processing times than pooled tables.
c) Easy Changes to Table Definition
The structure of FI-SL object tables and object-containing tables makes it simple to carry out changes in table definition such as the re-inclusion of a key field.
In contrast, this is an extremely complicated process for pooled tables.
d) Master Data Checks Using an Object Table
By using the object table that belongs to each FI-SL summary table, you can check master data for, among other things, the validity period of certain account assignment combinations.
2. Scope and Method of Conversion

Converting FI-SL pooled tables to transparent tables takes place client by client. In other words, you must start the conversion programs in each client.
It is highly recommended to do a conversion test run in a test client before undertaking any conversions in the production system.

The following must be converted:
a) FI-SL Pooled Summary Tables
The 'Pooled table overview' function in the initial conversion screen provides you with an overview of all pooled tables used in FI-SL.
Every pooled table you use in production must be converted.
b) FI-SL Pooled Line Item Tables (Actual and Plan)
See procedure for FI-SL summary tables
c) FI-SL Control Tables
Because the table name changes during conversion, as well as the field name in some fields, all FI-SL control tables must be converted as well.
This extends to the conversion of all application areas in FI-SL, such as sets, Report Writer, assessment/distribution, and so on.
3. Time of Conversion

The point at which you carry out conversion to transparent tables is up to you within Release 4.0 (exceptions: GLT2 and GLTPC).
The option of first converting only summary tables and converting line item tables later offers additional flexibility in choosing when you want to begin conversion.
4. Conversion Procedure

To prevent errors in conversion, you must follow the exact sequence of the steps below.
Most of the steps listed here are also on the initial screen for conversion (FI-SL settings menu -> Tools -> Conversion).
Conversion initial screen
a) Preparatory Measures
b) Performing the Conversion
c) Generating Report Groups
After the Report Writer control tables and reports have been converted, you have to regenerate the report groups.
Read the log that is output and make any necessary changes.
If all report groups have been generated, you should execute the printed reports (see above) again and compare the results you got before and after conversion.
Generate report groups
d) Adapting Your Own Application Programs
If you are using your own application programs, you may have to adapt them to your new table names and new field names.

NOTE
The conversion of the summary table and the subsequent conversion of FI-SL control tables represents a single logical unit and MUST take place in one step, as the new table only becomes active once the control tables are converted. In no way is it permissible to convert the summary table and postpone conversion of the control tables. If you were to do this, data posted in the meantime would not exist in the new summary table.

If conversion has run without any serious errors, the 'new' summary table and the line item table(s) assigned to it are now active, that is, from this time, documents are posted in the line item table(s) and the summary table is updated.
'Old' tables can no longer be accessed by means of FI-SL from this point on.
e) Converting Line Item Tables
After converting the summary table and the FI-SL control tables, the new summary table and all of its dependent actual and plan line item tables become active. No more postings will be made to the 'old' tables from this point.
For this reason, you can convert the line item table(s) that belong to the summary table that was already converted at a later time.
If you want to convert the line items later, you must first save each line item table ahead of time in case you require a backup.
It stands to reason that you cannot access the line item tables between converting the summary table and the line item table(s). However, since the summary table is usually evaluated with reports, this restriction should not pose too great a difficulty for the short transitional period.
Another peculiarity occurs when line items are converted later: you may not execute a reversal run of an assessment, distribution, or rollup during the time that the line items are not yet converted.
You can convert old line item tables during production operation because they are no longer updated. However, it is still not advisable to convert them, as doing so places a burden on the database.

Procedure in Case of Error
When line items are converted, the old line item records are deleted from the old table after they are converted and written in the new table. As a result, if the program terminates, you can restart the conversion of the line item table immediately. Conversion would then resume from the point at which it was previously interrupted.
Simultaneous deletion during conversion marks an essential difference from the conversion of a summary table:
Whereas you can access old summary records at any time during summary table conversion, this is not the case for line items.
Convert line item table(s)
f) Deleting Old Pooled Tables
If all pooled tables used in FI-Sl have been converted, their transaction data can be deleted with the 'Delete transaction data' function (Note: You only have to delete summary table data because data from line item tables is deleted when the latter are converted). To now increase storage space, you should also reorganize the pool in which the tables exist (Note: The name of the pool is in the R/3 Repository).
Delete transaction data
Afterwards, you can delete the installation of the old tables from FI-SL as well as the definition of the tables in the R/3 Repository.
The entire conversion must be successfully completed before you take the above steps.
5. Important Notes on Conversion
a) Defining the New Tables in the R/3 Repository
When you create new tables, you must also make sure to maintain the technical settings for the table correctly.
In addition, it is to your advantage in terms of processing time if each index does not have to be updated when the summary and line item tables are converted. For this reason, you should delete all indexes not defined as absolutely necessary prior to conversion with the database utility in the R/3 Repository (Transaction SE11 -> Utilities -> Database utility -> Index). Do not forget to recreate them in the same way after conversion has been concluded successfully.
Caution: Unique index 2 for line item tables (index using document number) and the indexes for the object table(s) must exist and may not be deleted for any reason.
b) Converting a Summary Table and FI-SL Control Tables in One Step
The conversion of a summary table and the subsequent conversion of FI-SL control tables represents a single logical unit and must take place in one step, as the new table only becomes active once the control tables are converted. It is in no way permissible to convert the summary table and postpone the conversion of the control tables. If you were to do this, data posted in the meantime would not exist in the new summary table.
c) Converting Several Summary Tables
If you are using more than one summary table at a time, it is not advisable to convert them all simultaneously. It is better to convert each summary table completely, with its FI-SL control tables (where possible also the dependent line item tables) and only move on to the next summary table after the first is successfully converted.
Although simultaneous conversion is technically possible, it is not advisable because the lack of clarity in such a situation would make errors highly likely.
There is also no appreciable improvement in performance for simultaneous processing.
d) Client By Client Conversion
Each client must be converted separately.
e) Report Painter Reports
Conversion of Report Painter reports is NOT supported at this time.
f) Background Processing
It is advisable to execute all functions in the background, as long processing times must be bargained with everywhere. The simplest way to do this is from the following menu path: Program -> Execute in batch. The program will be started in the background immediately.
6. Errors and How to Correct Them
a) No more extents available in the table space
Solution: Extend table space for the table.
b) Error message: Error when deleting a record
Solution: Call up function again. If it keeps happening, inform your system administrator.
c) Duplicate Records in an Insert in the Summary Table
Solution: Check the field movements for the conversion. Most likely, summarization took place during conversion without the 'Summarization during conversion' indicator being marked.
If this is the case, delete transaction data from the target table and restart conversion of the summary table (with 'Summarization during conversion').
d) Duplicate Records in an Insert in the Line Item Table
Solution: Index 1 or Index 3 has probably been defined as 'UNIQUE'. However, only Index 2 may be defined as 'UNIQUE'.
Another possible cause may be an incorrect definition of number range object 'GL_RECID': Check number range 01 of number range object 'GL_RECID' with transaction SNRO: The from number must be set to 00000000000000001 and the to number should be 999999999999999999.

Checklist for Conversion

(Print and fill out)

Source table (summary table):

Target table (summary table) :
------------------------------------------------------------