Lesson 2 of 6
Replication architecture
10 min
Listen to this lesson
Central Finance has three moving parts: the source systems, which post as usual; the SAP Landscape Transformation Replication Server (SLT), which captures accounting documents and moves them; and the central system, which maps each document and posts it into its own Universal Journal. Errors are parked and handled in the SAP Application Interface Framework (AIF).
SAP sources and non-SAP sources
For SAP ERP sources, SLT reads the accounting documents as they are posted, using triggers on the source tables, and sends them to the central system, where a posting interface maps and posts them. The source needs the Central Finance-relevant components of the DMIS add-on and some notes; the central system's configuration lives under the Central Finance node of the implementation guide (transaction CFINIMG). For non-SAP sources, such as the Alternadores legacy ERP, documents are delivered in SAP's Central Finance interface format, typically through staging tables that SLT or another integration layer fills, and then follow the same mapping and posting path. Check the supported source releases and interface options in the current administration guide for your release.
Initial load, then real time
Replication starts with an initial load: master data and cost objects first, then balances and open items, then the documents of the current fiscal year as configured. Only then is real-time replication switched on. SAP's documented sequence matters, because a CO document that arrives before its cost object cannot post.
- Master dataG/L accounts, customers, suppliers mapped or replicated; MDG key mappings in place
- Cost objectsInternal orders, production orders and other CO objects loaded and mapped
- ProjectsWBS elements replicated where used
- FI and CO postingsBalances, open items and documents from the agreed start period
- CO internal postingsSecondary postings such as allocations and settlements
- Real-time replicationSwitched on per source; new postings flow continuously
What gets replicated
| Object | Replicated | Note |
|---|---|---|
| FI documents | Yes | G/L, customer and supplier lines; reposted with mapped values |
| CO postings | Yes, where configured | Primary costs with the FI document; CO internal postings separately |
| Cost objects | Yes | Internal orders, production orders, WBS elements, mapped or replicated |
| Commitments | Yes, where configured | Purchase order commitments for budget reporting |
| Logistics documents | No | Sales orders and deliveries stay in the source; only their accounting effect arrives |
| Summarized history | Depends | Classic initial loads read summarized tables; granularity may differ from real time |
Replication scope in a typical Central Finance design. Check the administration guide for your release.
One detail surprises testers: the central document is a new document. It has its own number, it may carry a different G/L account, profit center or document type after mapping, and it references the source document. Reports in the central system therefore show the source amounts under central keys, which is the whole point, but also why every reconciliation needs the mapping tables.
What would you do?
During the initial load test, many CO internal postings from EP1 fail in the central system with "cost object does not exist". FI documents posted fine. What is the most likely cause?
What goes wrong in testing
| Symptom | Usual cause | Test |
|---|---|---|
| Documents arrive hours late | SLT job capacity or a blocked queue | Measure latency per source during peak posting |
| Counts differ after initial load | Summarized source data loaded at a different granularity | Agree the comparison basis per period before counting |
| CO postings fail in bulk | Load sequence not followed | Script the load order and check each step before the next |
| Source performance drops | Triggers on heavily posted tables | Run a volume test on a production-size copy |
Replication defects to provoke in test.
Non-SAP sources in practice
In the what-if design, the Alternadores legacy ERP could not run SLT triggers. Its accounting documents would be extracted every few minutes into staging tables in Central Finance's interface format, one record per document header and line, with legacy keys. From there they follow the same mapping and posting path as EP1 documents. Two consequences matter for testing. First, completeness depends on the extraction, so the legacy side needs its own control total per extraction run. Second, the legacy ERP may allow things SAP does not, such as documents that do not balance in a second currency or posting periods that reopen after close; the staging rules must reject or correct them, and each rule needs a test.
| Check | EP1 (SAP source) | Legacy ERP (non-SAP) |
|---|---|---|
| Capture | SLT triggers on accounting tables | Scheduled extraction into staging tables |
| Completeness control | SAP comparison reports per source | Control totals per extraction run, plus comparison |
| Typical defects | Mapping gaps, closed periods, locked objects | Format errors, unbalanced documents, reopened periods |
| Who fixes source issues | Contoso ECC support team | Alternadores finance and IT |
SAP and non-SAP sources need different completeness controls.
- SLT captures source accounting documents; the central system maps and posts them; AIF holds errors.
- The initial load follows a fixed order: master data, cost objects, postings, CO internal postings.
- Central documents are new documents with central keys that reference the source.
- Logistics documents stay in the source; only their accounting effect is replicated.
Check your understanding · not graded
Lesson check
1. Which component captures source accounting documents for Central Finance?
2. Why must cost objects be loaded before CO postings?
3. What happens to a sales order in the source system?
4. Where is Central Finance configured in the central system?