ABAP Developmentadvanced

BAPI Part 10: "Success but No Document" — Debugging BAPI Problems

Key takeaway

Diagnose the classic BAPI incidents: a document number returned but nothing in the database, custom fields lost, values ignored, errors only in production. Use a structured checklist: payload capture, RETURN analysis, commit and session checks, SM13/ST22, X structures, conversions, authorizations and locks, and debugging the BAPI internally.

Explanation

📌 KEY POINTS
✅ "Number returned, document missing" almost always means: no commit, commit in another session, or the update failed afterwards (SM13).
✅ "Value ignored" usually means: missing X flag, external format, or a field the BAPI doesn't transfer (needs EXTENSIONIN).
✅ Reproduce with the exact payload and user — SE37 test sequence or a small test program — before changing code.
⚠️ Different behaviour between systems often comes from customizing, authorizations or user-specific settings (e.g. the RFC user's defaults), not from code.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–9 built correct calls. This final lesson is the support toolkit for when things still go wrong.

━━━━━━━━━━━━━━━━━━━━
▶ 1. CAPTURE THE EVIDENCE

Exact input (all structures, X tables, extensions), calling user, system, timestamp.
Full RETURN table (all lines, TYPE/ID/NUMBER/V1–V4).
For interfaces: the IDoc/message payload or middleware log.

"SUCCESS BUT NO DOCUMENT" CHECKLIST
Was BAPI_TRANSACTION_COMMIT called at all? (search the program / debug)
Same session? For RFC callers: commit through the same stateful connection.
Did the update fail? SM13 (update records for the user), ST22 (dumps in update task).
Was there a rollback later in the same LUW (e.g. an error in a following step)?
Did the BAPI return a number that is only assigned on commit (internal temporary number, e.g. $000000001)?

"VALUE IGNORED" CHECKLIST

X flag set? UPDATEFLAG correct in change BAPIs?
Internal format (ALPHA, units, partner functions, dates)?
Is the field part of the BAPI interface at all, or does it need EXTENSIONIN?
Is it overwritten later by determination (pricing, partner determination, copy control)?

"ERROR ONLY IN PRODUCTION"

Compare customizing (SCU0/table compare), master data, authorizations of the RFC/batch user (SU53 is empty for background — use STAUTHTRACE).
Locks: another user editing the same object (SM12).
Number ranges, fiscal periods (OB52, MMPV) closed.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DEBUGGING THE BAPI ITSELF

SE37 test with breakpoint; step into the mapping FORMs (e.g. search the BAPI source for the field or BAPE structure).
For RFC calls: external breakpoint for the RFC user, or reproduce with the captured payload locally.
For update errors: activate update debugging.

━━━━━━━━━━━━━━━━━━━━
▶ 6. CLOSE THE LOOP
Root cause, fix (code, mapping, customizing or data), regression test with the payload, monitoring improvement.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Take the Part 2 program, remove the commit and observe: number returned, no VBAK entry.
Re-add the commit but use an invalid customizing setup in a sandbox to create an update error; find it in SM13.
Write your own checklist for your main interface.

✅ CHECKPOINT: you can diagnose BAPI incidents systematically and prove the root cause.

Code example

ABAP Code

* ===== Diagnostic helper: verify a document really exists after commit =====FORM verify_sales_order USING iv_vbeln TYPE vbeln_va                     CHANGING cv_exists TYPE abap_bool.  DATA lv_vbeln TYPE vbeln_va.  cv_exists = abap_false.  CHECK iv_vbeln IS NOT INITIAL.  SELECT SINGLE vbeln FROM vbak INTO lv_vbeln WHERE vbeln = iv_vbeln.  IF sy-subrc = 0.    cv_exists = abap_true.  ENDIF.ENDFORM. * ===== Typical call sequence with evidence logging =====*  CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2' ... IMPORTING salesdocument = lv_vbeln*       TABLES return = lt_return ...*  PERFORM log_payload USING ls_header lt_items lt_return.   " evidence first*  IF no E/A in lt_return.*    CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'*      EXPORTING wait = 'X' IMPORTING return = ls_commit.*    PERFORM verify_sales_order USING lv_vbeln CHANGING lv_exists.*    IF lv_exists = abap_false.*      " -> check SM13 (update error), ST22, same RFC session, later rollback*    ENDIF.*  ENDIF. * ===== Incident checklist =====* Evidence : payload, user, system, full RETURN (TYPE/ID/NUMBER/V1-V4)* No doc   : commit called? same session? SM13/ST22? later rollback? temp number?* Ignored  : X flag? UPDATEFLAG? internal format? EXTENSIONIN needed? overwritten?* Prod only: customizing, authorizations (STAUTHTRACE), locks (SM12), periods, number ranges* Debug    : SE37 test sequence, external breakpoint for RFC user, update debugging

Real project scenario

A CRM middleware reported sales orders as created with numbers, but 2% were missing in ERP. The team captured payloads and found that all missing orders had an update termination in SM13 caused by a Z update function module in a user exit writing a log table with a duplicate key.
The BAPI RETURN had been clean because the error occurred after the commit. Fixing the key logic and checking the commit RETURN with WAIT = 'X' closed the gap, and the middleware now flags documents not found after commit.

Common mistakes

Trusting the returned number without verifying the document.
Commit via a different RFC connection.
Ignoring SM13/ST22 after "successful" BAPI calls.
Debugging code before capturing the exact payload.
Comparing systems without checking customizing and user authorizations.

Best practices

Log payload and full RETURN for every interface call.
Commit with WAIT and verify critical documents.
Monitor SM13/ST22 for interface users.
Use a written checklist per incident type.
Reproduce with the exact payload before fixing.

Interview angle

Questions: "The BAPI returned a document number but the document doesn't exist. Why?", "A field passed to the BAPI is not saved. What do you check?"
Strong answer: no commit, commit in another RFC session, update termination after commit (SM13/ST22), later rollback, temporary numbers; for ignored values: X flags/UPDATEFLAG, internal formats, field not in interface (EXTENSIONIN), later determination; prod-only issues: customizing, authorizations (STAUTHTRACE), locks, periods; capture payload and debug via SE37/external breakpoints/update debugging.

Practice this lesson

Quick check

1. A BAPI returned a document number but the document is not in the database. Which is NOT a plausible cause?

2. Where do you look for errors that occur after BAPI_TRANSACTION_COMMIT without WAIT?

3. Background interface user gets authorization errors. Which tool shows the failed checks?

Interview questions

1. BAPI returns success but data is not saved. Why?

Answer it in your own words first, then compare.

2. An accounting BAPI (BAPI_ACC_DOCUMENT_POST) fails only for one company code. How do you debug it?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.