SAP S/4HANA is SAP's current ERP, run on-premise, in a private cloud or as RISE with SAP. Lima reads it through CDS views that SAP has released for extraction, through table reads of the underlying tables and through BAPIs, and writes results back with every write confirmed. Change capture keeps the daily volume small.
Each method has a job. The first load uses the bulk method; the daily run uses the incremental or change-capture method; write-back uses the interface the system itself uses.
| Method | What it does | When it is used |
|---|---|---|
| Released CDS views | Reads SAP-defined database views, including delta-enabled views that return only changed rows. | Standard business data with SAP's semantics applied. |
| Table reads through a released function module | Reads application tables in partitions inside an agreed session cap. | First loads and history. |
| BAPIs and function modules | Reads and writes business objects with business logic applied. | Every write-back. |
| Change pointers and table-level change capture | Returns only rows that changed. | Nightly and intraday deltas. |
| SAP APIs on BTP | Calls released OData APIs where the estate exposes them. | RISE and public-cloud editions. |
Released CDS views, table reads through a named function module, BAPIs, change pointers and extractor delta queues. No ODP RFC (SAP Note 3255746), no RFC_READ_TABLE in production (SAP Note 382318), no reading of the HANA database log (SAP Note 2971304). No add-on is installed in SAP.
Dated draft, pending sign-off by engineering and legal. The full statement, with the named function module, is on the trust center.
The objects are the tables, views or records Lima reaches through the methods above. The patterns say how a copy is made and kept current.
| Object | Plain meaning |
|---|---|
| I_Product · I_Plant (CDS) | product and plant master views |
| MARA · MARC · MATDOC | material master and the single material document table |
| STKO · STPO · PLKO · PLPO | bills of material and routings |
| EKKO · EKPO · VBAK · VBAP | purchase and sales orders |
| ACDOCA | the universal journal |
| AFKO · AFPO | production orders |
| PRCD_ELEMENTS | pricing conditions (replaces KONV) |
| MBEW · CKMLCR | valuation |
| Pattern | Supported |
|---|---|
| Full load | Yes |
| Incremental | Yes |
| Change capture | delta-enabled CDS views, change pointers, table-level change capture |
| Streaming | — |
| Write-back | BAPIs, IDocs and released OData APIs, each write confirmed |
A planning dataset is assembled from these objects. The pair pages show how each planning application shapes them.
| Planning object | Source objects in SAP S/4HANA |
|---|---|
| Items | I_Product · MARA · MARC |
| Bills of material | STKO · STPO · MAST |
| Routings and production versions | PLKO · PLPO · MKAL |
| Stock by status | MATDOC · MARD |
| Open purchase orders | EKKO · EKPO · EKET |
| Open sales orders | VBAK · VBAP · VBEP |
| Production orders | AFKO · AFPO |
| Planned independent requirements | PBIM · PBED |
| Customers and suppliers | KNA1 · LFA1 · BUT000 |
| Calendars | TFACD · T001W |
The prerequisites are what the team that runs SAP S/4HANA grants. The four steps are the same for every connector.
Incoming data = valid records + exception records. A row that fails a check is kept, routed to the person who owns it with a deadline, and replayed once fixed. The load carries on with the valid rows and the report says exactly what was held back. How exceptions work →
Each pair page covers one path end to end: objects out, model in, checks, cadence and the offer.
Planning integration: first load, then net change on the planning calendar; the plan returns to the ERP.
Open the pair page →Planning integration: first load, then net change on the planning calendar; the plan returns to the ERP.
Open the pair page →Planning integration: first load, then net change on the planning calendar; the plan returns to the ERP.
Open the pair page →Planning integration: first load, then net change on the planning calendar; the plan returns to the ERP.
Open the pair page →Planning integration: first load, then net change on the planning calendar; the plan returns to the ERP.
Open the pair page →Planning integration: first load, then net change on the planning calendar; the plan returns to the ERP.
Open the pair page →Landing and history: full history landed with a count check per table, then kept current.
Open the pair page →Landing and history: full history landed with a count check per table, then kept current.
Open the pair page →Landing and history: full history landed with a count check per table, then kept current.
Open the pair page →Landing and history: full history landed with a count check per table, then kept current.
Open the pair page →Landing and history: full history landed with a count check per table, then kept current.
Open the pair page →Landing and history: full history landed with a count check per table, then kept current.
Open the pair page →3 more pair pages for SAP S/4HANA are listed in the directory.
No add-on is installed. Lima connects from outside through the interfaces listed above, with a user and authorisations your administrators grant.
Parallel reads are capped and the cap is agreed with the team that runs the system. Large reads run inside an agreed run window. Change capture keeps the daily volume small.
A report per run: rows in, rows out, control totals and variance per table, the exceptions held back and who owns them, and whether the deadline was met.
Yes. Most estates start with one source, one target and one dataset, then add tables and patterns on the same connection.
A trial connects this system, runs a first load and ends with a reconciliation report. Your administrators see the prerequisites before anything is installed.
