SAP Batch Input Session Checklist (SM35, SM36)

0%

0 of 31 items complete

5 critical items still open - these are the highest-risk gaps.

Download checklist:

Prepare

Confirm batch input is the right method; check for a BAPI, IDoc, LSMW or standard migration object firstCRITICALDocument the transaction, object and number of records in scopeGet the source file layout approved with the business ownerConfirm the executing user has authorization for the transaction and for SM35CRITICALCheck the screen sequence is stable in this release, since patches can change screensAgree the cut-over window and the rollback or correction approach

Record and build

Record the transaction in SHDB with realistic data, including the save stepRemove screen elements with fixed values and replace changing ones with variablesCheck the cursor position, OK codes and function keys, such as ENTER or /11 for saveHandle screens that appear only conditionally, such as warnings or popupsMind the user decimal and date formats in the profile of the executing userCRITICALGenerate the program from the recording, or transfer it to your own programUse a clear session name that contains object, wave and date

Validate before loading

Check source data for mandatory fields, lengths and leading zerosValidate master data references such as plant, material, vendor and company codeRun a small test of 5 to 10 records in a test clientRun a representative set in foreground mode (display all screens) and compare resultsProcess in error-only display mode to see exactly where a record stopsVerify created documents in the target transaction, not only the session log

Run

Lock or notify users of the target data where concurrent changes are likelyCRITICALChoose the processing mode: foreground, errors only or backgroundSchedule large sessions in background so a terminal timeout cannot stop themRun in several parallel sessions only if the object has no number range or lock contentionKeep sessions to a manageable size so a failure does not block the whole loadRecord start and end times and counts for the cut-over log

Verify and close

Review the session log in SM35 and list all transactions in errorCorrect the source data and reprocess only the failed recordsCRITICALReconcile counts and totals against the source fileHave the business owner sign off a sampleDelete or archive processed sessions according to policyDocument lessons learned and keep the recording and program under version control

Items marked critical can cause bad data or a failed cut-over if skipped. Batch input depends on screen layout, so re-test after any support package or customizing change. Newer releases favor BAPIs, standard migration cockpit objects and APIs where they exist.

Planning a big SAP data load?

Ask for a light review of your load plan and where automated pre-checks could reduce reruns.

Optional. The tool and every export work without this. No spam.

How to use the checklist

Work through the groups in order and tick items as you finish them. Use the critical items as a stop sign: if one is open, hold the load. Export the completed list to PDF and keep it with the cut-over documentation as evidence that the session was prepared and verified.

Session versus call transaction

A batch input session is stored in SM35 and processed later, which gives a log and a restart option. CALL TRANSACTION runs immediately in the program and returns messages directly. Sessions suit large and auditable loads, while call transaction suits quick synchronous updates. Both depend on stable screens.

Session method: stored, logged, restartable in SM35
Call transaction: immediate, messages returned to the program
Background processing avoids terminal timeouts
Error-only mode helps you fix problem records quickly

Alternatives to consider first

Check for a BAPI, a released API, an IDoc inbound process or the migration cockpit before you record screens. They are more stable across releases and give clearer messages. Batch input is a sensible fallback for objects without such an interface, but needs more regression testing.

Common mistakes

Recording with the developer's user formats and running with another user's, loading before master data exists, using a recording that includes a one-off popup, and running a very large session in one piece are frequent. Always reconcile the count with the source file.

Frequently Asked Questions

What is a batch input session in SAP?

It is a stored set of screen inputs for a transaction, created from a recording or program and processed later in SM35. The system replays the entries as if a user typed them and writes a log for each transaction.

How do I process a session in the background?

In SM35, select the session and choose Process, then pick the background option, or schedule the report RSBDCSUB in SM36. Background processing avoids dialog timeouts and runs without displaying screens.

Why do records fail in a batch input run?

Usual causes are unexpected popups, differences in user date or decimal format, missing master data, locked objects, and screens that changed after a support package. Run in error-only mode to see where each record stops.

Is batch input still recommended?

Only when no BAPI, API, IDoc or migration cockpit object exists for the task. It depends on screen layouts, so it needs regression tests after upgrades. Where an interface exists, prefer it for stability and clearer errors.

If you are planning a large SAP data load, Netray can help you build a validation layer that checks source files before they are posted, with your team approving the run.

Talk to an Expert Explore More Free Tools

Related Tools

SAP

More SAP tools

See all

SAP Batch Input Session Checklist