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 for Converting FI-SL Pooled Tables to Transparent
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
b) Improved Processing Times
Transparent tables have more efficient processing times than pooled
c) Easy Changes to Table
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
d) Master Data Checks Using an Object
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
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
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
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
Defining a Table Group in FI-SL Customizing
When defining a table group, a standard table group will first be
proposed to you, which you then modify according to your
requirements. It is advisable to keep essentially the same fields
in the 'new' tables that were in the 'old' pooled tables.
Define table group
Installing the New Tables in FI-SL.
Use your 'old' pooled summary tables as a reference.
You will find more detailed explanations on both topics in the
FI-SL implementation guide (IMG).
Conversion of Sets to Transparent Tables
Before you can start the actual conversion, all sets must first be
converted to transparent tables ( see Release
notes for 4.0A).
Creating Field Movements for Conversion
Field movements define the rules for converting individual fields
from the source table to the target table.
Because field movements apply to summary tables as well as line
item tables, they must be created only for the summary table(s) to
Remember that key fields whose names change during conversion (such
as BUKRS -> RBUKRS) absolutely must be entered in these field
movements. Also, all key fields that do exist in the target table
but do not exist in the source table must also be entered here
Key fields whose names do not change during conversion do not have
to be entered; they are transferred automatically (example: RACCT).
Every datafield (such as TSL01) is also transferred
Field movements not only allow for a 1:1 conversion of tables, but
also give you the option of leaving fields out (but only leave
those fields out that are not used in any FI-SL applications),
including new fields, or modifying certain fields with a user exit.
However, bear in mind that all modifications made to fields with a
user exit are carried out when transaction data is converted, but
individual application areas will not respond to the changes. For
example, a summarization of accounts into account groups with a
user exit would take place when transaction data was converted, but
the sets for the 'Account' field would not be automatically
More detailed information on field movements ia available in online
Help for the individual fields in table TGUMS.
Maintain field movements for conversion
Checking Field Movements for Conversion
After creating field movements between the source and target
tables, you must make sure they are correct.
You will see a detailed list of all the error messages and warnings
that occurred when the field movements were checked.
Correct the errors and inconsistencies that were identified in the
Warnings are ignored when you perform conversion, whereas error
messages prevent conversion from taking place.
Check field movements for conversion
Resource Estimation for Converting Transaction Data
Resource estimation allows you to gauge the volume of data in your
summary and line item tables, and how much storage space in table
spaces will be required for the new tables and their indexes.
Since conversion requires twice the amount of data to be kept, you
should make certain that there is sufficient storage space in the
table spaces. You will find the table space names for the table and
its indexes in the R/3 Repository (transaction SE11) from menu path
Utilities -> Database utility -> Table or Index -> DB
parameters. Normally, table spaces BTABD or BTABI are used.
Estimating conversion runtime is also important for the conversion
of transaction data and sets. (But remember that the conversion of
transaction data and sets only takes up part of the time required
for the entire conversion.) Include offline database saving and
converting the FI-SL control tables into your time planning (see
CAUTION: All results that come from resource estimation represent
empirical values only and may differ sharply from case to case.
Deleting Unnecessary Clients (optional)
Any clients that are no longer required should be deleted in order
to free up storage space (CLIENT REMOVE).
Reorganization of Table Spaces (optional)
Because conversion requires a great deal of storage space, it is to
your distinct advantage to reorganize the table spaces for the new
transparent tables prior to the actual conversion.
Executing and Printing Report Writer Reports
In order to determine whether Report Writer reports provide the
same results after conversion as before, you should execute and
print a few Report Writer reports prior to conversion.
Execute report group
b) Performing the
Locking the Production System
During conversion, you must ensure that no data is posted in FI-SL
and that no control tables are changed. For this reason, the system
in which conversion is to take place should be locked for other
You do this on operating system level by entering the command
'Conversion start' for locking and 'Conversion end' for unlocking
Once the system is locked, only user 'SAP*' can log on to and work
in the system.
Offline Database Save for the Entire System
Although the consistency of data is guaranteed even in the event of
an unforeseen termination during conversion, you should
nevertheless perform an offline database save of the whole system
before starting conversion so that you still have a backup.
Include the time required for this offline database save in the
calculations for your time planning.
Converting Summary Tables
An important point in this regard is the indicator 'Summary in
This defines whether a 1:1 conversion takes place or whether data
is summarized (ommitting fields) during conversion. Monitor your
field movements and set the indicator accordingly. If data is
summarized when summary tables are converted without the indicator
being set, there may be a danger of the system terminating because
of duplicate records, which means you would have to start the
entire conversion over again. More detailed explanations are
available from online Help.
Procedure in Case of Error (Termination, Power Outage, etc)
When summary tables are converted, no data from the source table is
deleted: that is, you can go back to the old data at any time.
A typical error that may occur during conversion of summary tables
is insufficient table space for the target table. If that happens,
print out the dump analysis and take any necessary action.
If there is already data in the target table after a termination,
you will have to delete it with the 'Delete transaction data'
function prior to restarting summary table conversion. Converting
summary tables is only possible if the target table contains no
If no data exists in the target table, conversion can be started
Convert summary table
Conversion Results Check
After converting the summary tables, you have two options of
checking whether the conversion was performed correctly.
You can check the content of both tables directly with the function
'Compare tables' (use selection parameters - a complete table
comparison may take quite a while). If there turn out to be
differences between the source and target table, you must analyze
these differences as closely as possible. A typical case in which
differences can arise is errors in the definition of field
movements or modification of fields with a user exit.
The 'Display summary records' function provides you with an
additional option for checking. It allows you to branch directly
into the summary record display from target table entry and also to
compare the target table (assignment of the ledger to be displayed
to the target table is simulated here) with the source table in
another session. However, you cannot make an entry in the 'User
table' field at this point.
Display summary records
Once you are certain that the summary table was converted
correctly, you can continue with the rest of the conversion.
CAUTION: You can now make no subsequent changes to the conversion
field movements, as a change would have the inevitable consequence
of creating data inconsistency between the summary table that was
already converted and the line items that have yet to be
Converting FI-SL Control Tables
This function converts all FI-SL control tables to the new summary
This conversion includes nearly all application areas in FI-SL and
may take up a fair amount of time. If you defined a large number of
sets and/or reports, you will have to reckon with a protracted
processing time. One measurement states that the conversion of 1000
sets takes approximately 8 minutes. The actual duration will depend
on the definition and structure of your reports and sets, and
therefore cannot be predicted with any accuracy here.
After successful conversion, you will see a detailed log about how
the conversion went in the individual application areas. The log
will either be displayed as a dialog box (execution online) or will
be available in the spool file as a list (background processing).
Read this log carefully, and make any necessary corrections
Note: The sets and substitutions/validations/rules defined for
table GLU1 are changed when a summary table is changed (example:
field GLU1-BUKRS -> GLU1-RBUKRS). For this reason, you should
make certain that if you are using several summary tables, all the
tables are converted. Otherwise, inconsistencies relating to sets
and substitutions/validations/rules for fields in table GLU1 may
An additional peculiarity in set conversion occurs when fields are
ommitted or combined (compare field movements for conversion):
these sets no longer exist after conversion and, as a result, are
no longer available in higher-level multi-dimension sets.
After conversion, check the control tables to see whether the
essential functions in the individual FI-SL application areas still
work. Your best options for doing this are checking reports,
diagnosis (posting test), and checking rollups.
Procedure in Case of Error
If the program that converts the FI-SL control table terminates for
any reason, you can restart the program at any time. Conversion
then resumes from the point at which it was interrupted.
If errors that occurred during conversion (such as incorrect field
movements for conversion) prevent working with the 'new' system
after successful conversion, you will have to fall back on the
existing offline database save. In this case, conversion will have
to be completely repeated (at a later time).
Convert control tables
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
If you are using your own application programs, you may have to
adapt them to your new table names and new field names.
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
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
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
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
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
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
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
The entire conversion must be successfully completed before you
take the above steps.
5. Important Notes on
a) Defining the New Tables in the R/3
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
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
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
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
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
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
6. Errors and How to Correct
a) No more extents available in the
Solution: Extend table space for the table.
b) Error message: Error when deleting
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
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