Skip to Content
Technical Articles
Author's profile photo Marc Ellison

Central Finance Tips and Tricks #5 – SLT

The SLT system is a critical component of central finance and is responsible to transfer real time replication data from source systems to the central system for both SAP and non-SAP systems. It also has the role of completing the initial load for cost object and controlling interfaces.

Where do you get started?

Great information and pre-defined templates are delivered by SAP to help accelerate and get you off to a solid start, refer to SAP notes:

  • 2154420 – SAP LT Replication Server for SAP Central Finance
  • 2462424 & 2481900 – SAP LT Replication Server for SAP Central Finance – Third-Party System Integration
  • 2223621 – Central Finance: Interface for Business Integration. This is for non-SAP systems with only a runtime database license

Note 2154420 has the prerequisite SLT components needed for each release. The DMIS add on is required on source systems and SLT itself, for the S/4 system the S4CORE component must be installed. To avoid issues the highest available version of DMIS is recommended to be installed.


The basic setup involves the use of transaction LTRC, this provides a wizard to create the connection between source and target systems. Before performing the initial setup some key points need to be considered.

  • RFC destinations need to be configured on source and SLT systems
  • Security access to the technical users assign to the RFC destinations needs to be setup correctly
  • Read from single client flag in most cases should be activated to limit data selection to the RFC client specified in the RFC connection. If you have multiple clients in a single instance then this can be set off and the client is determined from the setting of the RFC destination.
  • Allow multiple Usage flag should be selected. This allows multiple SLT configurations to access the same tables e.g. for table based replication to operate in parallel to Central Finance. For some customers with existing SLT replications (for example FICO accelerators in a HANA sidecar scenario) it may be required to convert the existing configurations first prior to using Central Finance. Note 2082199 – How to switch between 1:1 and 1:N replication in a SLT system explains the process involved to convert existing configurations.
  • In SLT runtime objects are created in the $TMP package, this means they are not transportable. I recommend the transport management system is disconnected for the migration workbench objects. You do this by setting the value ‘X’ in table DMC_RT_PARAMS for parameter NO_CTS_CONNECTION.
  • When using reading type 4 or 5 for the initial load this fills an index table on the source system during access plan calculation. The table space (example APPL1) must be entered in the setup of the configuration or you may face issues later.

Setup Example

In the SLT server, start transaction LTRC, choose the new pushbutton to create a new configuration. In the step Specify General Data, enter a configuration name (without any spaces).   In addition, you can specify a description.

In the step Specify Source System, you specify the connection data to the source system. In this case, specify an existing RFC connection to the source system.

In the step Specify Target System, the connection data to the target system must be defined. Select the RFC Connection radio button, and enter the existing RFC connection to the target system. In the field Scenario for RFC Communication, choose RFC scenario

In the step Specify Transfer Settings, you can define the initial load mode. I recommend using the option Performance Optimized but you will need approximately 10 % additional storage in the source system during the initial load. In the No. of Data Transfer Jobs field, enter the appropriate value e.g. 6. Note that you can increase this value later if required. Set data class of table space e.g. APPL1. Set the replication frequency as Real time.

In the step Review and Create, you can review your settings. Ensure that all settings are correct and choose the push button Create Configuration.

The mass transfer ID (MTID) is an internal number. You need this information to activate the pre-delivered objects in MWB. The MTID is also visible in transaction LTRC. Communication between source > SLT > Central Finance is now established.


When SLT is performing the initial load and replicating data, for both phases a migration workbench (MWB) object is created for every trigger table. A MWB objects stores the information of the source structure, the target structure and how the mapping should be executed. In other words, the MWB object holds the rules that transform the data from the table based structures on the source system into the remote function module interface of the central finance system. This is different from a table based standard scenario, like HANA replication, where the table is moved as an exact copy from source to the target.

For S/4 HANA 1511 to 1610 releases Central Finance is working with three trigger tables AUFK, CFIN_ACCHD, and COBK.  From 1709 onwards SAP have added other tables to support tax, withholding tax, commitments, accounting view of logistics data and EC-PCA postings.

An initial load object and a replication object must be created for each table. All of the MWB objects are stored for each configuration in LTRC and can be adjusted accordingly. SAP have done a great job and done most of the work, where templates can be download and installed using the notes mentioned in the getting started section above.

Before you start the replication, you must create the initial load and replication objects. To define the initial load and replication objects start program DMC_UPLOAD_OBJECT in transaction SE38 and upload the relevant files from SAP note 2154420. It is possible for customer specific adjustments can be made to the mapping rules.

Once the template rules are available, they are applied to each mass transfer ID on the SLT server. This is completed after the setup of the mass transfer ID is completed for each source system.

Mapping Example

Before you start the replication in each SLT system, you must create the initial load and replication objects.  To define the initial load and replication objects use LTRC for the mass transfer ID, tab processing steps and the step Create Predefined Load and Replication Objects

Choose the Copy Predefined Object pushbutton, and enter the REPL_CFIN template in the Project field. Depending on whether you are integrating SAP or Non SAP system choose the relevant Subproject, in this case I am selecting REPL_CFIN.  In the Predefined Object field, you specify the predefined initial load object. Use the F4 help to view all available objects. For every table, there is a load object and a replication object. The load object contains the suffix L and replication object _R.

Under Target Object, you have to specify the table name. Use the same table that you specified for the predefined replication object. For example, if your predefined replication object is CFI_COBK_L, your table name is COBK. Repeat for the replication object with the predefined object with suffix _R and select the replication radio button.

Repeat the process for the other tables that require replication e.g. CFIN_ACCHD and AUFK.

Navigate back to the overview of the predefined objects and set the status of the initial load and replication objects to Active.

Once the replication objects are defined it is critical to perform a DDIC synch. This ensures that the MWB objects are consistent between source and target systems so runtime objects are created correctly.

From LTRC for the mass transfer ID, tab processing steps and the step Create Predefined Load and Replication drill down into the “ _TEMPLATE” MWB subproject.

When you start the replication from LTRC, SLT should automatically synchronize the data dictionary (DDIC) structures between the source and target systems. In some exceptional cases this does not occur and can lead to multiple short dumps due to DDIC inconsistencies. In this case it is possible to OPTIONALLY force the generation of runtime objects using the steps below:

  • For the runtime object causing inconsistencies, drill down and navigate to “Generate Runtime Object”, select the perform DDIC synch. Repeat for every MWB load and replication object.
  • This needs to be done once before you start initial load and replication.


Filters ensure that only the relevant data is transferred to Central Finance. Two types of filters can be defined:

  • Trigger filter – this implements a filter on the trigger of the source system, meaning that only the filtered data is transferred to SLT.
  • Runtime filter – this implements logic in the runtime objects on the SLT system to filter out irrelevant records. Using this method data is transferred from source to SLT and is filtered out at SLT runtime.

For the controlling interface, I recommend that a trigger filter is applied to table COBK and aligns with the initial load starting date set in view VCFIN_SOURCE_SET on source systems. For large installations that have lots of history, this will speed up the initial load process and only select relevant data. In some cases, it may be necessary to implement a runtime filter, for example where different initial load start dates are required for different company codes, or you need to filter out company codes on the Controlling interface.

Example Trigger Filter

You define trigger filters in transaction LTRS with respect to a configuration and table in the performance options folder. The reading type must be set to 4 or 5 for trigger filters to be defined. The example below shows a filter on table COBK with posting date >= 01 August 2018.

You can also disable update and delete triggers if desired using the Tables folder in LTRS.

Example Run time Filter

Run time filters are defined in the MWB content. Using transaction MWB navigate to the TEMPLATE subproject for the mass transfer ID where rules are to be defined and select the conversion logic icon. Here the template rules will be shown and can be adapted.

The example below shows a run time filter on COBK for event related rule SKIP_COBK to filter the record out of the posting date is less than 01 August 2018.


The Central Finance initial load process consists of two different parts.

  • Initial load via Central Finance customizing

For the Accounting interface, it transfers via RFC the FI documents, the balances and open items to the central system in CFIN* staging tables on the central finance system (not via SLT!)

For the Controlling interface, the CFINIMG activity Prepare for and Monitor the Initial Load of CO Postings must be executed before the table COBK initial load is started from the SLT system. This prerequisite step stores the CO-PA characteristics in a source system database table CFIN_COPA for the initial load of the CO documents.

  • Initial load and replication via SAP LT Replication Server

The initial load and replication for the tables AUFK, CFIN_ACCHD, COBK is executed via transaction LTRC on the SLT systems. In the context of Central Finance, the SLT initial load of CFIN_ACCHD refers to the loading of documents posted on source system since the start of the RFC initial load performed from the Central Finance system.

Execution Example

When the MWB objects are activated you can use SAP LT Replication Server to control your load and replication. In the SAP LT Replication Server Cockpit (transaction LTRC) enter your mass transfer ID. In the Table Overview tab page, you can stop or start a table by choosing the Data Provisioning pushbutton.

The option Start Load will execute an initial load of the data that is currently in the system. But there will be no delta replication. Using this function is generally not required. It could come in use for recovery scenarios where you need to load some data and not activate real time replication.

The option Start Replication will execute an initial load of the data and activates delta recording. After the initial load, the replication of delta data will start, no manual interaction is required

Enter the table (e.g. AUFK, CFIN_ACCHD, COBK) for which you have defined your predefined objects and choose Start Replication.


You can monitor the load and the replication using transaction LTRC.  On the tab page Data Transfer Monitor, you can view the table name once the initial load or replication object is created and view the status of the replication and objects. The tab Load Statistics is useful during the initial load phase to give you an overview of progress. The Application Log can be used to help troubleshoot and analyse issues, the log contains details about any issues regarding the replication process, and information if data cannot be replicated to the target system because of incorrect settings.

In many cases it is hard in SLT to detect the exact problem and you will need to use LTRC, ST22 and SM21 to trouble shoot.

To monitor more than one configuration at a time transaction LTRO can be used.


Setting up automatic alerts to send out notifications in case of issues in SLT is recommended. This helps avoid permanent monitoring of SLT. Notifications can be activated for a dedicated configuration. If activated, the system uses a background job to check the configuration periodically:

  • Whether the connections to the source system and target system are working correctly
  • Whether the master job is running
  • Whether the data load jobs are running
  • Whether acceptable latency times have been exceeded
  • Whether any errors occurred during the load or replication

The frequency and thresholds can be set up on a table basis per configuration. This is done in LTRC in the Expert Functions tab.

Reset Transfer Status / Repeated Testing

Central finance uses function modules to transfer data. Using this technique SLT stores the key references during initial load and replication into table DMC_FM_RESTART to ensure that the same data cannot be replicated to the target system again.

For testing it is likely that reloading of SLT data to Central Finance is required, due to configuration changes, defects etc. To reuse an existing mass transfer ID and load the same documents again you must first remove the entries in table DMC_FM_RESTART, otherwise none or not all data will be transferred to Central Finance.

To remove the entries, use transaction SE38 and enter the report DMC_FM_RESTART_COPY_DELETE enter the table name e.g. CFIN_ACCHD and choose Reset Transfer Status.

Managing Outages

As part of operations it is necessary to suspend the SLT replication from time to time to accommodate events such as upgrades and patching. When deactivating replication, the source systems will accumulate entries in the logging tables and these will be cleared down and processed to the central finance system once the SLT configuration is reactivated. However, for the AC_DOC Accounting interface for SAP source systems, sequencing is enabled with interface version 2 and there is no guarantee that SLT will processes the postings in the correct sequence. Read SAP note 2679070 – Central Finance: Resuming SLT replication that provide the steps to avoid sequencing issues:

  1. In SLT LTRC deactivate the mass transfer ID of the respective source systems
  2. In Central Finance deactivate the AIF runtime configuration group that is used for the replication by removing the indicator “Runtime Cfg Active” and save the change. This is done in transaction /AIF/PERS_CGR – Runtime Configuration Group.
  3. When ready to resume the replication, on SLT LTRC activate the mass transfer ID of the respective source systems. On Central Finance new messages will collect with the status “
    In Process” in the AIF monitor.
  4. On SLT, in LTRC for a mass transfer ID, on the Expert Functions Tab select the “View Unprocessed Logging Table Records” check the logging tables are empty, that signifies the backlog of postings have caught up
  5. In Central Finance, when the backlog of postings has been transferred, activate the AIF runtime configuration group again in transaction /AIF/PERS_CGR – Runtime Configuration Group.
  6. In the Central Finance system, execute in SE38 report /AIF/PERS_RUN_EXECUTE. On the start screen of the report, set the option “Include runs in status New”.

Structural Changes

From time to time data models may change on source or target central finance systems as a result of upgrades, configuration changes such as adding a new field to COPA or extending a field in the general ledger, also known as a coding block extension.

In all cases the SLT configuration must be deactivated before the structural changes are imported into the source or target system. When the replication is restarted SLT will normally automatically detect the changes and regenerate the run time objects. In some cases this could go wrong, for example the sequence was not strictly followed. In this case the run time objects will need to be synchronized and regenerated (Refer note 2531470).

Good to Know

My most frequently used SLT transactions

  • LTRC  – Detailed overview on a configuration
  • LTRO   – Monitoring of several configurations at a glance
  • LTRS  – Advanced replication settings
  • SM37  – Status system jobs
  • SM21  – System log
  • SM50  – Work Process Monitor
  • SM51  – Work Process Monitor including Application Server
  • MWB  – Migration Workbench

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo pankaj pandey
      pankaj pandey

      Thanks Mark really informative..from 1709 we have COPA mapping with enhanced replication method which is reducing all of manual and custom stuff .


      thanks Pankaj


      Author's profile photo Fischer Jan
      Fischer Jan

      Hi Marc,

      perfect Blogs about CFIN.

      Currently I try to setup the replication of Tax tables according to OSS 2494127, but I never find entries in the FINS_CFIN* tables in the target system.

      E.g. when I try ro replicate T001, I setup in IUUC_REPL_PREDEF_OBJECTS via copy of CFI_CFIN_ACCHD_L to target T001 (I also tried FINS_CFIN_T001 as I was not sure), afterwards I start the initial load and also get records according to the LTRC log read but not written. Also if I check the tables I could not find anything in the related tables e.g. FINS_CFIN_T001 in my target system.

      Did you ever tried the Tax customizing replication? Or do you have any idea how to setup?




      Author's profile photo Kris Stono
      Kris Stono

      Hi Jan,


      The tax check does not replicate configuration (well, it does but not in the traditional sense), only the table entries for the check to work. You still need to create the tax codes in Central Finance. The tax table replication will move entries from T001 to FINS_CFIN_T001 in central finance (see note 2494127) and if you activate the tax check for the company code in question then the tax configuration in Cfin will be checked against the FINC_CFIN* tables. As an example, if T001 in Cfin is determined to be different to FINS_CFIN_t001  an error will be issued.

      You should not be using CFI_CFIN_ACCHD_L to target T001!! Use CFI_T001_L with target object T001. Same for the replication object use CFI_T001_R. If the templates are not available in your SLT system then you need to upload the content files relevant to your release.

      Does this help?




      Author's profile photo Fischer Jan
      Fischer Jan

      Hi Kris,

      Thanks for your answer. Sure the replication is not used to replicate the configuration of tax settings from source to target, we did a full "traditional" customizing in the target for tax. It is clear that those replicated tables are only for the check.

      I assume you have a typo in the second part of your answer an mean FINS_CFIN_T001? So we have to set up the replication of predifined objects as follows?:

      Project: REPL_CFIN

      Subproject: REPL_CFIN

      Predifined Object: CFI_CFIN_ACCHD_L and CFI_CFIN_ACCHD_R

      Target object: FINS_CFIN_T001

      If this setting is correct I have the issue that the replication does not fill anything into FINS_CFIN_T001...

      Any Ideas?



      Author's profile photo Kris Stono
      Kris Stono

      Hi Jan,

      Project: REPL_CFIN

      Subproject: REPL_CFIN

      Predefined Object: CFI_CFIN_ACCHD_L and CFI_CFIN_ACCHD_R

      The above needs target table CFIN_ACCHD


      For the tax config your load and replication objects should be based on the delivered templates and look something like this:


      Project: REPL_CFIN

      Subproject: REPL_CFIN

      Predefined Object: CFI_T001_L and CFI_T001_R

      Target table: FINS_CFIN_T001


      Do same setup for the rest of the tables listed in note 2494127 by using the relevant predefined objects.


      Give it a go...I am conscious that we have hijacked Marc's blog 🙂





      Author's profile photo Fischer Jan
      Fischer Jan

      Hi Kirs,

      I did it exactly as discussed but still the initial load is reading records (according to the load statistics) from source but not updating to FINS_CFIN_T001.I also updated the latest content from 2154420 🙁

      I will open a message at OSS to get this checked.

      Thanks for your help!






      Author's profile photo Marc Ellison
      Marc Ellison
      Blog Post Author

      Hi Jan,

      Probably best to ask a question so it can be answered in the forum. Sounds like you’ve probably got an issue with SLT, I would start by looking at security of the SLT user on source and target, check logs for errors on source, SLT and target (SM21) and look for any shortdumps (ST22) to give clues. Raising a call with SAP is also a good option.

      Also dont forget to perform a DDIC synch!



      Author's profile photo Fischer Jan
      Fischer Jan

      Hi Marc,

      I found my issue. For instance it was mentioned in OSS 2494127 but really hard to recognize. The is a standard filter rule SKIP_CFIN_CLNT2 and in this rule by default all transactions are skipped to avoid unwanted data replication. So you have to adapt this filter allow the replication for you client.

      So for VAT Configuration Check for Company Codes you have to

      1 st copy the predefined Object e.g.:

      • Project: REPL_CFIN
      • Subproject: REPL_CFIN
      • Predefined Object: CFI_T001_L and CFI_T001_R
      • Target table: T001

      2 nd: adapt filter SKIP_CFIN_CLNT2 and if needed CFI_SET_CLNT

      3 rd: synch DDIC

      4 th: LTRC with the the original table (e.g. T001). FINS_CFIN_T001 will however be the the table to which SLT replicates, and this is taken care by predefined objects that you will copy.

      Thanks for all your answers!



      Author's profile photo Marc Ellison
      Marc Ellison
      Blog Post Author

      Well done!

      Author's profile photo Deloitte team
      Deloitte team

      What is the purpose of  “Activate VAT configuration check for company codes ” Does this lead to tax recalculations in the target /Central finance system and then a comparison check of tax amount between source and target ?

      Author's profile photo Matt Kangas
      Matt Kangas

      Hi Marc,


      I have a question about this part:

      Once the replication objects are defined it is critical to perform a DDIC synch. This ensures that the MWB objects are consistent between source and target systems so runtime objects are created correctly.

      Where did you get this step? I have never seen it in any SAP documentation for Central Finance. I am working with a customer where we were having problems with the replication objects. A load worked fine, but nothing happened in replication. When I wen through the steps they were taking, they showed me the DDIC synch step from this blog. Contrary to what you wrote, it was this DDIC synch step that seemed to be causing the problems. Once we removed the step during the copy of the load and replication objects, our errors went away and replication worked fine.

      The initial generation of objects by SLT should take care of synch-ing everything up anyway, so I do not know why that step is necessary. I have never had issues with the MWB object consistency and this step seems problematic and unnecessary. Can you tell me why you do it and where it is documented? Thanks.

      Best Regards,


      Author's profile photo Marc Ellison
      Marc Ellison
      Blog Post Author

      Hi Matt,

      This blog is based purely on my experience. I had the opposite problem as you, the run time objects would not synchronize correctly when I started the replication phase, causing loads of short dumps. I instead had to force the synchronization first using a DDIC synch. Perhaps this was a specific problem with our DMIS version and SP level. In any case many thanks for the feedback, I have updated the blog to reflect the DDIC step as optional to resolve issues in exceptional circumstances.


      Author's profile photo Nilesh Pathak
      Nilesh Pathak

      Hi expert,

      We are working on scenario whee SLT (on HANA DB)getting  data from non sap and feeding to S4 HANA Central Finance, now we have couple of staging tables in SLT like line item , customer extension, etc.. due to increase in disk space, we need to plan clean up of staging tables, can you suggest quick solution to clear the data and one solution for long term solution like archiving, to avoid these issue, ?


      Also let me know is there any adverse impact of deleting data from staging tables ?


      Is there a method or any housekeeping job which can clear data from staging tables automatically once data gets posted to S4.

      Any other jobs we can run to keep deleting info not required.

      pls help.

      Author's profile photo Roberto Sposito
      Roberto Sposito

      Hi Pathak,

      There is no a SAP program available to clean the SLT staging tables. Customer needs to find out a way to either clean or reset these tables.

      2826493 - SAP Program to clear SLT staging tables in Central Finance - SLT


      Roberto Sposito.

      Author's profile photo Gourab Banik
      Gourab Banik

      Thanks Marc for the blog. it is one of the most comprehensive blog out there in CFIN & SLT space.