Show TOC
Conversion of FI-SL Pool Tables to Transparent
Tables
Description
In Release 3.0, all FI-SL pool tables which were either productive or used
for testing purposes in previous releases, should be converted to transparent
tables.
An exception is the tables GLT2 (Consolidation) and GLTPC (Profit Center),
together with their dependent line item tables.
These tables MUST be converted for Release 3.0 (as long as they were used
either productively or for testing purposes in the components Consolidation
and Profit Center in previous releases).
Information about GLT2 conversion
At this point, refer to the the relevant Release Note in Profit Center
Accounting for the procedure regarding the conversion of table GLTPC.
All other tables must be converted according to the following
guidelines:
Guidelines for the Conversion of FI-SL Pool Tables to Transparent
Tables
1. Advantages of the conversion
a) Transparency of FI-SL tables
All the summary tables and line item tables used in FI-SL are transparent
after the conversion, which means that they can, for example, also be edited
using external means.
b) Improved processing times
Transparent tables have considerably better processing times than pool
tables.
c) Table definition can be changed
easily
Due to the structure of FI-SL object tables and tables with objects, it is
very easy to make changes to the table definition, for example, entering a new
key field.
For pool tables, this would require considerable effort.
d) Master data check using the object
table
Using the object table that is assigned to each FI-SL summary table, you can
validate the master data, for example, checking the validity period of
specific code combinations.
2. Tables to be converted
The conversion of FI-SL pool tables to transparent tables is carried out by
client, that is, you must start the relevant conversion programs in each
client.
It is recommended that you first perform a test run of the conversion in the
test client before converting in the productive system.
The following tables must be converted:
a) FI-SL summary tables of type 'pool'
In the initial screen of the conversion, you can call up an overview of all
the pool tables used in FI-SL using the function 'Overview of pool tbl'.
You have to convert all the pool tables you are using productively.
b) FI-SL line item tables (actual and plan)
of type 'pool'
See the procedure for FI-SL summary tables
c) FI-SL Control tables
All FI-SL control tables must be converted since the table name and also the
field name for some fields change during the conversion.
This applies to the conversion of all components in FI-SL, such as sets,
Report Writer, assessment/distribution, and so on.
3. Time of conversion
You can choose at what point you want to perform the conversion to transparent
tables within Release 3.0 (exceptions: GLT2 and GLTPC).
With the option of first only converting the summary table(s) and converting
line item table(s) at a later date, you have added freedom when choosing when
you want to perform the conversion.
4. Procedure for the conversion
To avoid errors during the conversion, you must strictly follow the sequence
of steps described below.
Most of the steps listed here can be found on the initial screen for the
conversion (FI-SL Configuration menu -> Tools -> Conversion).
Initial screen for conversion
a) Preliminary measures
- Defining a table group in FI-SL customizing
When defining a table group, a standard table group is suggested which you
must modify according to your requirements. It is recommended that the 'new'
tables contain basically the same fields as the 'old' tables.
Define table group
- Installation of the new tables in FI-SL.
Use your 'old' pool summary table as a reference.
Install table
For a more detailed explanation of these two points, refer to the FI-SL
Implementation Guide.
- Creating the field movements for the conversion
The field movements for the conversion define the rules on how the individual
fields of the source table are to be converted to the target table.
Since the field movements apply to both the summary table(s) and the line item
table(s), you only need to create these field movements for the summary
table(s) to be converted.
You must ensure that key fields whose names change during the conversion (for
example BUKRS -> RBUKRS) are also entered in these field movements. In
addition, all key fields that exist in the target table, but do not exist in
the soure table must also be entered here (for example, SBUKRS).
Key fields whose names do not change during the conversion must not be
entered; they are transferred automatically (for example, RACCT): All data
fields (for example TSL01) are also transferred automatically.
Using the field movements, tables do not have to be converted on a 1:1 basis.
You can also omit fields (only omit fields that are not used in any FI-SL
application), include new fields, or modify specific fields using a user exit
during the conversion. However, you must take into account that all
modifications to fields using user exits are made during the conversion of the
transaction data, but these changes are not taken into account in the
individual applications. For example, a summarization of accounts to account
groups using a user exit would take place when converting the transaction
data, but an automatic conversion of the sets for the files 'Account' would
not take place.
For more detailed information on field movements, refer to the online help for
the individual fields of table TGUMS.
Maintain field movements for the conversion
- Checking the field movements for the conversion
After creating the field movements between the source table and the target
table, you must check to see that they are correct.
You then receive a detailed list of all the error messages and warning
messages which the system found when checking the field movements.
Correct the errors and inconsistencies found in the field movements straight
away.
Warning messages are ignored later when the conversion is carried out, but
error messages prevent the conversion from taking place.
Check field movements for the conversion
- Estimate resources for the conversion of the transaction data
Using the 'estimate resources' function, you can determine the volume of data
in your summary and line item tables and how much storage space is needed in
the tablespaces for the new tables and their indices.
Since data is stored twice for the conversion, you should make sure that there
is sufficient storage space in the tablespaces. You will find the table space
names for the table and its indices in the repository (transaction SE11) under
the menu option Utilities -> Database utility -> Table or Index -> DB
parameters. Normally, the tablespaces BTABD or BTABI are used.
Storage problems could also occur in the export file during the conversion of
the summary table(s); the entire source table is first written into this file
and data is then imported again from this file. For more information on the
export file, refer to the online help.
It is also important to estimate the runtime for the conversion of the
transaction data and the sets. You should take into account, however, that the
conversion of the transaction data and the sets only constitutes part of the
time needed for the entire conversion. You should also include the off-line
database backup and the conversion of the FI-SL control tables in your time
schedule (see below).
CAUTION: All the information resulting from resource estimation only
represents test figures and can deviate widely for each individual case.
Estimate resources
- Deletion of all clients not required (optional)
First, all clients that are no longer required should be deleted; this creates
additional storage space (CLIENT REMOVE).
- Reorganization of the tablespaces (optional)
Since conversion requires a lot of storage space, it is advisable to
reorganize the relevant tablespaces for the new transparent tables before the
actual conversion.
- Executing and printing several Reort Writer reports
To be able to determine whether the Report Writer reports give the same
results both before and after the conversion of all the FI-SL control tables,
you should execute and print some Report Writer reports before the
conversion.
Execute report group
b) Executing the conversion
- Blocking the productive system
For the conversion, you must ensure that no data is posted to the FI-SL system
or any control tables are changed. For this reason, you must block the system
in which the conversion takes place for the other users.
You do so by entering the command 'Conversion start' at the operating system
level; you unlock the system after the conversion by entering 'Conversion end'
at the operating system level.
After the system has been blocked, only the user 'SAP*' can log on and thus
work in the system.
- Off-line database backup of the entire system
Although data consistency is guaranteed during conversion even if the system
terminates processing, an off-line databse backup of the entire system should
be carried out before the actual conversion; you can then access this backup
if problems occur during the conversion.
Include the time required for this off-line database backup in your time
schedule.
- Conversion of summary table(s)
When converting a summary table, you must check beforehand to see whether
there is enough storage space in the export file which is used for the
intermediate storage of the summary table. If the storage space runs out
during the conversion, the system cancels the conversion and returns an error
message to this effect. In this case, you must extend the file system or use a
different export file.
If you are using the 'ORACLE' database system, you should always use the
export file proposed by the system because the data will then be written to a
file which normally contains enough storage space. For other database systems,
the export file '/tmp/test.ums' is usually proposed as a default, but you can
overwrite this file if you so want.
CAUTION: The conversion is normally started in the background, you should make
sure that the export file is also open on the database computer on which
background processing runs.
Another important function is the indicator 'Summarization during
conversion':
This indicator determines whether the conversion takes place on a 1:1 basis or
whether data is summarized during the conversion (for example, omitting
fields). Check your field movements and set this indicator accordingly. If
data is summarized when the summary table is converted without this indicator
being set, there is a risk that the system will cancel processing due to
duplicate records and the entire conversion must be restarted. Refer to the
online help for more detailed information.
Procedure if an error occurs (processing cancelled, power failure, and so
on)
When converting the summary table, no data is deleted from the source table
which means that you can access the old data any time.
Storage space problems in the export file or insufficient tablespace for the
target table are examples of typical errors that can occur the conversion of
the summary table. In this case, print out the dump analysis and carry out the
necessary actions.
If data already exists in the target table after the system has cancelled
processing, you must first delete this data using the 'Delete transaction
data' function before restarting the conversion of the summary table. You can
only convert the summary table if the target table does not contain any
data.
If there is no data in the target table, you can start the conversion
again.
Convert summary table
- Check the results of the conversion
After the conversion of the summary table(s), there are two ways in which you
can check whether the conversion was performed correctly.
You can check the contents of the two tables directly using the function
'Compare tables' (using the selection parameters since a complete table
comparison can take a long time). If differences are found between the source
and target table, you must analyze these differences carefully. Errors in the
definition of the field movements or modifications made to fields using user
exits are typical examples of where differences can occur.
Compare tables
The function 'Display summary records' offers another option for checking to
see whether the summary table has been converted correctly. Here, you can
branch directly to the summary record display by entering the target table and
compare the target table (the assignment of the ledger to be displayed to the
target table is simulated) with the original table in another mode. However,
you cannot make an entry in the 'User table' field.
Display summary records
Once you are sure that the summary table has been converted correctly, you can
continue with the conversion.
CAUTION: The conversion field movements must not under any circumstances be
changed later. Any change would cause data inconsistencies between the summary
table already converted and the line item tables still to be converted.
- Conversion of FI-SL control tables
With this function, all FI-SL control tables are converted to the new summary
table names.
This conversion includes almost all the FI-SL components and may take a long
time. If you have defined a large number of sets and/or reports, you can
expect processing to take a long time. When timed, it was found that the
conversion of 1000 sets took approximately 25 minutes. The time required for
the conversion depends on the definition and structure of your reports and
sets and cannot therefore be predicted here.
After the conversion has been successfully completed, you receive a detailed
log of the conversion process in the individual components. The log is
displayed either as a dialog box (online execution) or is available as a list
in the spool file (background processing). Analyze this log carefully and make
any necessary corrections straight away.
Note: The sets and substitutions/validations/rules that are defined for table
GLU1 are changed when converting a summary table (for example, field
GLU1-BUKRS -> GLU1-RBUKRS). For this reason, you should make sure when
converting several summary tables that these tables are all converted because
otherwise inconsistencies could occur in the sets and
substitutions/validations/rules for the fields of table GLU1.
Another special feature occurs during the conversion of the sets if fields are
omitted or if 'Summarization of fields' is used (see field movements for
conversion): these sets no longer exist after the conversion and are therefore
no longer available in higher-level multi-dimension sets.
After the conversion of the control tables, check whether the main functions
in the individual FI-SL components still work. For example, checking reports,
the diagnosis tool (posting test) and checking rollups are good ways to check
the functionality.
Procedure if error occurs
If the program that performs the conversion of the FI-SL control tables
cancels processing for some reason, you can restart this program any time. The
conversion then starts from where it was interrupted.
If after the conversion of the components, however, the errors that occurred
during the conversion (for example, incorrect field movements for the
conversion) prevent you from working with the 'new' system, you must access
the available off-line database backup. In this case, you must repeat the
entire conversion (at a later date).
Convert control tables
c) Generate report groups
After converting the Report Writer control tables and reports, you must
regenerate the report groups.
Analyze the log that is output and make the necessary corrections.
If all report groups have been generated, you should again execute the reports
you printed earlier (see above) and compare the results from before and after
the conversion.
Generate report groups
d) Adapting application programs
If you are using your own application programs, you might have to adapt them
to the new table names and field names.
NOTE
The conversion of the summary table and the subsequent conversion of the FI-SL
control tables is a logical unit and MUST be carried out in one step because
the new table only becomes productive with the conversion of the control
tables. Thus, you must never convert the summary table and then postpone the
conversion of the control tables. In this case, the data posted between the
two conversions would be missing in the new summary table.
If, up to now, the conversion has run without any serious errors, then the
'new' summary table and its assigned line item table(s) are now productive.
This means that from now on, documents are posted to the line item table(s)
and the summary table is updated.
You can no longer access the 'old' tables using FI-SL means.
e) Conversion of line item table(s)
After the summary table and the FI-SL control tables have been converted, the
new summary table together with its dependent actual and plan line item tables
is productive.
For this reson, you can convert the line item table(s) belonging to the
already converted summary table at a later point in time.
If the line items are to be converted later, a backup of the respective line
items table must also exist before the conversion; this backup can then be
used in case something goes wrong during the conversion.
You cannot, of course, access the line items between the conversion of the
summary table and the conversion of the line item table(s). Since, however,
the summary table is generally always evaluated with reports, this restriction
should not cause too many difficulties for a short transition period.
A special feature must also be taken into account for a later conversion of
the line items: you must not perform a reversal run of an assessment, a
distribution or a rollup in the period between the two conversions.
The conversion of the old line item table(s) can also be carried out in the
productive system because they are no longer updated. However, it is not
recommended to do so because this conversion involves an extreme load in the
database.
Procedure if an error occurs
When converting the line items, the old line item records are deleted from the
old table after they have been converted and written to the new table. The
advantage of this being that the conversion of the line item table can be
restarted without any previous actions if the system terminates processing. In
this case, the conversion starts again from where it was cancelled.
Due to the simultaneous deletion during the conversion, however, there is one
important difference to the conversion of the summary table:
With the summary table, you can access the old summary records at any time,
but you cannot do so with the line items.
Convert line item table
f) Deleting the sets in the source
table
If all the pool tables used in FI-SL are converted, you can delete their sets
using the fuction 'Delete sets'.
Delete sets
g) Deleting the old pool tables
If all the pool tables used in FI-SL are converted, you can delete their
transaction data using the function 'Delete transaction data' (note: you only
need to delete the data of the summary tables since the data of the line item
tables has already been deleted during the conversion). To obtain storage
space, you should reorganize the pool which contains the tables (note: you
will find the name of the pool in the repository).
Delete transaction data
Afterwards, you can delete the installation of the old tables from FI-SL and
then you can finally delete the definition of the tables in the
repository.
However, these steps should only be carried out after the conversion has been
successfully completed.
5. Important notes on the conversion
a) Definition of the new tables in the
repository
When creating the new tables, the technical default settings of the table must
be maintained correctly.
Furthermore, processing time is improved if the indices of the summary and
line item tables are not updated during the conversion of these tables. For
this reason, you should delete all the indices defined for these tables before
the conversion using the database utilities in the repository (transaction
SE11 -> Utilities -> Data base utility -> Index). Do not forget to
create the indices again in the same way after the conversion is successfully
completed.
Caution: The indices for the object table(s) must always exist and must never
be deleted.
b) Converting the summary table and the
FI-SL control tables in one step
The conversion of a summary table and the subsequent conversion of the FI-SL
control tables is a logical unit and must be carried out in one step because
the new table is productive only after the control tables have been converted.
Therefore, you must never convert the summary table and then postpone the
conversion of the control tables. In this case, the data posted between the
conversions would be missing in the new summary table.
c) Conversion of several summary tables
If you are using several summary tables, it is advisable not to convert these
summary tables in parallel, but to completely convert each summary table
including FI-SL control tables one at a time (if possible, the dependent line
item tables as well). You should proceed to the next summary table after the
first has been successfully converted.
A parallel conversion is technically possible but is not recommended due to a
higher error rate based on a lack of clarity.
There is also no improvement in performance with parallel processing.
d) Conversion by client
The conversion must be carried out separately for each client.
e) Report Painter Reports
At this time, the conversion of Report Painter reports is NOT possible.
f) Background processing
It is recommended that you execute all functions in the background since you
must expect processing to take a very long time. The easiest way to do this is
via the menu option Program -> Run in background. In this case, the program
is immediately started in the background.
6. Errors and how to correct them
a) Storage space in the export file is too
small
Solution: Extend file system or choose a different export file.
b) No further extents are available in the
tablespace
Solution: Extend tablespace for the table.
c) Error message: Error when deleting a
record
Solution: Call up the relevant function again and contact your system
administrator if the error occurs again.
d) Duplicate records occur when inserting
into the summary table
Solution: Check the field movements for the conversion. A summarization was
probably carried out during the conversion without the indicator
'Summarization during conversion' being set.
If this is the case, delete the transaction data from the target table and
restart the conversion of the summary table (with 'Summarization during
conversion').
e) Duplicate records occur when inserting
into the line item table
Solution: Either index 1 or index 3 is probably defined as 'UNIQUE'. However,
only index 2 can be defined as 'UNIQUE'.
Another possible cause could be an incorrect definition of the number range
object 'GL-RECID': check the number range 01 of the number range object
'GL-RECID' using transaction SNRO: the FROM number must be set to
00000000000000001 and the TO number to 999999999999999999.
Check list for the Conversion
(please print and fill it out)
Source table (summary table):
Target table (summary table):
------------------------------------------------------------
- Preliminary actions Notes
- Field movements maintained?
- Resource estimation carried out?
- Reorganization of tablespaces carried out?
- Non-required clients deleted?
- Report Writer reports printed?
- Execution of the conversion
- Productive system blocked?
- Off-line database backup carried out?
- Control tables converted?
- Own programs adapted?
-----------------------------------
- Actual line item table converted?
- Plan line item table converted?
- Actions after the conversion
- Sets of pool table deleted?
- Transaction data of pool table deleted?
- Installation and definiton deleted?
- Clients
The conversion of the summary table and its dependent line item table(s) was
carried out for the following clients: