What are the data upload methods in SAP?
SAP data upload methods are batch input (session or call transaction), direct input, BAPIs over RFC, IDocs, LSMW, the S/4HANA Migration Cockpit, OData and SOAP APIs, and SAP GUI scripting or eCATT. Each one runs SAP's application logic; a direct table write does not. PostNow.ai uploads from Excel through BAPIs, recorded transactions and released APIs.
- The S/4HANA status differs per method. SAP Note 2287723 calls LSMW not recommended on S/4HANA, the Migration Cockpit is SAP's tool for the initial load, and the public cloud edition integrates through released APIs.
- Choosing one for a specific Excel upload? The method per object is on SAP mass upload from Excel.
This page is the reference list of SAP data transfer techniques, the ways to upload data in SAP that SAP itself provides: one definition each, the mechanics that set them apart, and each one's S/4HANA status in one table. For the steps of a first upload, see how to upload data into SAP from Excel; for migration tools rather than load methods, see SAP data migration tools.
What the SAP data upload methods are
PostNow.ai, an Excel add-in, is a front end on top of these SAP data upload methods: it posts each row through a BAPI, a recorded transaction or a released API. The other ten rows are the ways SAP itself takes data in.
| Method | What it is | Where you meet it |
|---|---|---|
| Excel add-in (PostNow.ai) | Posts each spreadsheet row through a BAPI over RFC, a recorded transaction replayed as batch input, or a released OData or SOAP API, and writes SAP's answer back to the row | PostNow.ai ribbon in Excel; SHDB for recordings |
| Batch input session | A program stores screen-by-screen data (BDCDATA) in a session, which is processed later with a log per transaction | SHDB, SM35, BDC_OPEN_GROUP / BDC_INSERT / BDC_CLOSE_GROUP, RSBDCSUB |
| Call transaction | A program runs the transaction at once with the same screen data and collects SAP's messages | CALL TRANSACTION ... USING, table BDCMSGCOLL |
| Direct input | SAP-delivered programs that skip the screens and call function modules that run the checks, in the background, with a restart function | BMV0; RMDATIND (MM), RFBIBL00 (FI), RVAFSS00 (SD), RAALTD11 (AM), RKEVEXT0 (CO-PA) |
| BAPI over RFC | A released, remote-enabled function module of a business object, with messages in a RETURN table and an explicit commit | BAPI Explorer (transaction BAPI), BAPI_TRANSACTION_COMMIT |
| IDoc / ALE | A message per business document that an inbound function module posts, with a status per IDoc | WE20 partner profiles, WE02, WE19, BD87 |
| LSMW | A workbench that maps a legacy file onto one of four import methods: standard batch or direct input, batch input recording, BAPI, or IDoc | Transaction LSMW |
| Migration Cockpit | S/4HANA's tool for the initial data load, with delivered migration objects filled from staging tables or transferred directly from an SAP source system | Migrate Your Data app, LTMOM |
| OData and SOAP APIs | Released S/4HANA APIs that create and change business objects over HTTP | SAP Business Accelerator Hub, e.g. API_BUSINESS_PARTNER |
| SAP GUI scripting | A desktop script, usually VBA or VBScript, that drives SAP GUI screens through the scripting API | RZ11 parameter sapgui/user_scripting, SAP Logon options |
| eCATT | SAP's test tool, whose scripts can replay transactions and call function modules with test data | SECATT, SCC4 client setting |
Two names cause most of the confusion. BDC (batch data communication) is the older name for batch input, so "BDC" covers both the session and the call transaction variant. LTMC was the transaction of the first Migration Cockpit and is replaced by the Migrate Your Data app.
How PostNow.ai uploads through BAPI, recording and API methods
PostNow.ai is an Excel add-in that posts through three SAP data upload methods, chosen per template by the designer who builds it. Operators fill the sheet and run it; the method underneath does not change their steps.
1. BAPI over RFC
The template calls the BAPI for each document and reads its RETURN table. On Run, PostNow.ai calls BAPI_TRANSACTION_COMMIT only when SAP returns no E or A message, and rolls back otherwise. Simulate calls the BAPI and then BAPI_TRANSACTION_ROLLBACK, so nothing is committed.
2. Recorded transaction (batch input)
The designer records the transaction once in SHDB. Run replays the recording with CALL TRANSACTION in an SAP GUI session on the user's PC, with synchronous update, so each row's messages and document number come back before the next row starts. Simulate replays the screens without the final save.
3. Released OData and SOAP APIs
API mode posts rows through the OData V2, OData V4 and SOAP APIs SAP has published, the route S/4HANA offers for objects maintained in Fiori apps.
4. The same checks around every method
Validate checks the sheet offline first: required fields, type, length, dates, decimals and allowed values. Run writes SAP's message to each row's Run Log and the document number to its own column, and Retry Failed re-posts only the rows marked ERROR.
PostNow.ai logs in to SAP GUI only on the user's own computer, with the user's own stored login, when the user starts the action: Record, Run, Debug or Call Transaction. Every posting therefore runs under that user's SAP authorizations. Which of the three methods fits a given object is decided on SAP mass upload from Excel, and the trade-offs between the first two on BAPI vs BDC in SAP.
Batch input: session vs call transaction vs direct input
PostNow.ai's recorded templates use the call transaction variant of batch input. The session method and direct input are the two other classic SAP data transfer methods, and the three differ in when the data posts and how errors come back.
| Batch input session | Call transaction | Direct input | |
|---|---|---|---|
| How the data reaches SAP | The program writes BDCDATA into a session; SM35, or RSBDCSUB in the background, processes it later | The program runs CALL TRANSACTION ... USING with the BDCDATA table at once | A delivered program calls function modules that check and write the data; no screens are processed |
| Database update | Synchronous | Set by the program: A (asynchronous, the default), S (synchronous) or L (local) | Written by the program's function modules |
| Errors | A log per session; failed transactions stay in the session for correction and reprocessing | Messages returned to the program in a BDCMSGCOLL table, plus a return code; the program decides what to log | Background only; a restart function in BMV0 continues an interrupted run |
| Fits | Loads that need a reprocessing log in SAP | Uploads that need each record's result before the next one | High-volume standard loads for objects that have a program |
The update mode is the detail that catches people. With the default A, the update runs as a normal COMMIT WORK without waiting, so a success message tells the program the transaction finished, not that the database update did. With S the call waits, as COMMIT WORK AND WAIT does, which is why PostNow.ai replays with S.
Batch input needs classic SAP GUI screens (dynpros), and a recording is tied to the screen sequence it was made on. How to record so the replay holds is in the BDC recording guide. Direct input exists only where SAP delivered a program for the object; the SAP Help list names RMDATIND for the material master, RFBIBL00 for FI documents, RVAFSS00 for SD, RAALTD11 for assets and RKEVEXT0 for CO-PA, each with its own program documentation.
BAPI and RFC
PostNow.ai's BAPI templates call the BAPI over RFC, the same interface any external program uses. A BAPI is a method of a business object in SAP's Business Object Repository, implemented as a remote-enabled function module and released by SAP for use from outside.
- No screens. The BAPI takes structured parameters and tables, so screen changes, popups and field order do not affect it.
- Messages in RETURN. Errors, warnings and success come back in a BAPIRET2 table, one line per message.
- The caller commits. Most create and change BAPIs save nothing until the caller runs
BAPI_TRANSACTION_COMMIT, andBAPI_TRANSACTION_ROLLBACKdiscards the work. - Callers. Any RFC client: an Excel add-in, SAP .NET Connector, SAP Java Connector, Python's pyrfc, or another SAP system.
Not every object has a BAPI that suits a load. SAP Note 1135984, for example, says BAPI_PRICES_CONDITIONS is not released, which is why condition records are usually loaded through a VK11 recording. Customer-written RFC function modules work the same way technically, but SAP does not maintain them. The full BAPI versus batch input comparison is on BAPI vs BDC in SAP, and calling a BAPI from a spreadsheet step by step on call SAP BAPIs from Excel.
LSMW and its four import methods
PostNow.ai templates take over the recurring loads that teams used to build in LSMW; the LSMW alternative page shows how. LSMW (Legacy System Migration Workbench) reads a file, maps and converts its fields, and hands the result to one of four import methods:
| LSMW import method | What actually posts |
|---|---|
| Standard batch input or direct input | An SAP-delivered program, such as RMDATIND for the material master |
| Batch input recording | A recording of the transaction, run as a batch input session |
| Business object method (BAPI) | A BAPI, called through an IDoc that LSMW generates |
| IDoc | An inbound IDoc of the chosen message type |
LSMW itself checks nothing in SAP: the import method does, so the log, the error handling and the S/4HANA behaviour are those of the method chosen. On S/4HANA on-premise, LSMW is still in the system, but SAP Note 2287723 calls its use not recommended and at the customer's own risk and points to the Migration Cockpit for migration. The 14 steps of an LSMW object and its common errors are on the LSMW page.
Migration Cockpit: staging tables, direct transfer and Migrate Your Data
PostNow.ai loads Excel data into SAP during a project and after go-live; the SAP S/4HANA Migration Cockpit is SAP's tool for the initial load of a new implementation. SAP's documentation describes it as designed for an initial load and not for keeping data in sync between systems.
- Migration objects. SAP delivers one per business object, such as material, supplier or open item, and each object calls SAP's own APIs to create the data.
- Two approaches on-premise. Migrate Data Using Staging Tables, filled from SAP's XML templates or from your own tools, or Migrate Data Directly from SAP System, which reads an SAP ERP source.
- The app. The Fiori app Migrate Your Data replaces transaction LTMC; from S/4HANA 2021, LTMC cannot create new projects (KBA 3355075).
- Simulation. A simulation runs the object's checks and writes no data. LTMOM adjusts delivered objects or builds your own.
Changing existing records is outside the Cockpit's scope, which is where business-as-usual loads, and tools such as PostNow.ai, take over. Templates, mock loads and Cockpit errors are covered on SAP S/4HANA Migration Cockpit.
IDoc and ALE
PostNow.ai posts data a person prepares in Excel and returns the result to the row at once; an IDoc is the SAP data upload method for data another system sends. An IDoc is one business document in SAP's intermediate format, typed by a message type such as MATMAS (material), DEBMAS (customer), CREMAS (vendor) or ORDERS (sales order).
- Inbound processing. The partner profile in WE20 assigns each inbound message type a process code, which names the function module that posts it, either immediately or by a background job.
- Status per IDoc. Status 53 means the application document was posted, 51 means it was not, and 64 means it is ready to be passed to the application. WE02 shows the IDocs with their messages.
- Correction and test. BD87 reprocesses IDocs after the cause is fixed; WE19 builds a test IDoc from an existing one.
- Where it fits. EDI with customers and suppliers, ALE distribution between SAP systems, and middleware: the sender queues the document and does not wait for the posting.
LSMW can also write a file into IDocs, which is how its IDoc and BAPI methods post. On S/4HANA on-premise, IDocs remain in use; SAP's S/4HANA Cloud public edition integrates through the released APIs in the next section.
APIs and OData in S/4HANA
PostNow.ai's API mode posts Excel rows through these released OData V2, OData V4 and SOAP APIs. S/4HANA exposes released APIs for its business objects, listed with their operations and fields on the SAP Business Accelerator Hub (api.sap.com); API_BUSINESS_PARTNER for business partners is one of them.
APIs matter most where the classic routes stop. In S/4HANA, customers and suppliers are maintained as business partners in transaction BP, XD01 and XK01 hand over to it, and SAP does not support batch input for BP (KBA 1951318), so the business partner APIs or BAPIs are the route; the SAP Business Partner automation page covers it. A process that lives only in a Fiori app has no dynpro to record, so its OData service is the way in. In SAP S/4HANA Cloud public edition, released APIs are the integration route.
SAP GUI scripting and eCATT
PostNow.ai uses SAP GUI scripting to log on, start a recording and start its replay report in SAP GUI; the data itself posts inside SAP, through the replayed recording. A GUI script used as an upload method works differently: it types each value into the screens the way a user would.
SAP GUI scripting has to be switched on twice, on the server with the RZ11 parameter sapgui/user_scripting and in SAP Logon on the PC, as the enable SAP GUI scripting page shows. A VBA or VBScript macro then fills fields and presses buttons, and its result is whatever text it reads from the status bar. Every SAP check runs, because the real transaction runs, but a new popup or a moved field stops the script. The options for teams moving off macros are on SAP GUI scripting alternative.
eCATT (transaction SECATT) is SAP's test tool. Its scripts can replay a transaction with a test data container or call function modules, so some teams have used it to load data. It is built for tests: clients can restrict or forbid eCATT in SCC4, and test tools are covered on SAP test automation.
SAP data upload methods compared: result per record, change documents, S/4HANA status
PostNow.ai adds a result per Excel row on top of the SAP interface it calls. The other rows compare the SAP data transfer methods themselves on what a project, an auditor and an S/4HANA conversion ask about: how data enters, what comes back per record, whether change documents are written, and the S/4HANA status.
| Method | Enters SAP through | Result per record | Change documents | S/4HANA status |
|---|---|---|---|---|
| PostNow.ai (Excel add-in) | A BAPI over RFC, a recording replayed with CALL TRANSACTION, or an OData or SOAP API | SAP's message and the document number, written to the Excel row | Written by SAP's application logic, as for manual entry | ECC and S/4HANA |
| Batch input session | The transaction's screens, processed from SM35 | Session log per transaction | Yes, by the transaction | Works on SAP GUI transactions; not for BP or Fiori-only apps |
| Call transaction | The transaction's screens, at once | BDCMSGCOLL messages and a return code | Yes, by the transaction | As batch input session |
| Direct input | Function modules called by a delivered program | Program log; restart in BMV0 | Per the program's documentation | Check the program for your release |
| BAPI over RFC | A released function module | RETURN table | Yes, where the object keeps them | Carries over; some add fields, such as the 40-character material number |
| LSMW | One of its four import methods | That method's log | As the import method | Not recommended, at own risk (SAP Note 2287723) |
| Migration Cockpit | Delivered migration objects that call SAP's APIs | Messages per migration object instance | As the APIs it calls | SAP's tool for the initial load; Migrate Your Data app |
| IDoc / ALE | An inbound function module via the process code | IDoc status (53 or 51) with messages | Yes, by the posting function module | In use on-premise; public cloud uses released APIs |
| OData / SOAP API | A released API over HTTP | Response with SAP's messages | Yes, by the application logic | SAP's route for Fiori-maintained objects and the public cloud |
| SAP GUI scripting | The SAP GUI front end, field by field | Status bar text the script reads | Yes, by the transaction | Works where scripting is enabled on server and PC |
| eCATT | Transaction replay or function module calls in a test script | eCATT log | Yes, by the transaction or module | A test tool; clients can forbid it in SCC4 |
Choosing among these for one Excel upload is a different question, answered per object on SAP mass upload from Excel. Comparing migration products, such as SAP Data Services or the Migration Cockpit against third-party tools, is on SAP data migration tools.
Why direct table updates are not an SAP data upload method
PostNow.ai posts every row through a BAPI, a transaction or a released API, so SAP's checks run on each record. Writing values straight into SAP tables, with an ABAP INSERT or UPDATE or an edit in a table display tool, bypasses every layer the methods above go through.
- Checks. Values no transaction would accept, such as a plant that does not exist, go in unchallenged.
- Number ranges and locks. No number is drawn and no lock is set, so keys can collide with a user working at the same time.
- Dependent tables. The other tables the transaction would have updated, from texts to totals, no longer match.
- Change documents. Nothing is written to CDHDR and CDPOS, so the change has no audit trail.
The update does not fail; it succeeds, and the damage shows later as reports that do not reconcile or a transaction that refuses a record for a reason no one can trace. SAP Note 1420281 (SE16N: Deactivating &SAP_EDIT) switched off the function code that let users change table entries in SE16N. If no method on this page can make a change, raise it with SAP support rather than editing the table.