BAPI_ACC_DOCUMENT_POST Commit Behaviour and API_CV_AT...

[#1]

Dear SAP Community

We are seeking clarification on the transaction and object validation behaviour of SAP S/4HANA 2025 in the context of an automated process designed with SAP Build Process Automation to process accounting documents.

In SAP Build Process Automation our integration pattern is:

BAPI_ACC_DOCUMENT_POST

↓

Accounting Document Number Returned

↓

POST API_CV_ATTACHMENT_SRV / AttachmentContentSet

In S/4HANA 2025, we observed that an immediate attachment upload may intermittently return HTTP 400, while introducing a short delay (500 ms) eliminates the issue in our tests.

Questions

1. Does a successful return from BAPI_ACC_DOCUMENT_POST guarantee that the Accounting Document is already committed and visible in the database to subsequent HTTP/OData requests?

2. When the SAP Build BAPI SDK is configured with Commit = True, does it execute BAPI_TRANSACTION_COMMIT?

o If yes, is WAIT = 'X' used?

o Is the behaviour equivalent to COMMIT WORK or COMMIT WORK AND WAIT?

3. Could there be a delay between successful document posting and visibility of the document to API_CV_ATTACHMENT_SRV, even when the commit is successful?

4. What object or persistence layer is validated by AttachmentContentSet when uploading an attachment to an Accounting Document?

o Does the service validate directly against BKPF?

o Or through another business object/service layer?

5. Is adding a short delay or retry mechanism before calling AttachmentContentSet considered an acceptable integration pattern, or is there a preferred SAP-recommended approach?

It would be great to at least have some of the above questions answered so that we can align our SAP Build integration design with SAP best practices.

[cherry_li · Accepted solution]

1. Does BAPI_ACC_DOCUMENT_POST guarantee commit + visibility on return?

No. BAPI_ACC_DOCUMENT_POST by design posts to the update queue but does not commit. Even if RETURN is success (TYPE = 'S'), the document is not yet visible to a fresh transactional read until an explicit commit runs. This is the standard BAPI contract — the caller owns the commit.

2. Does SBPA's BAPI SDK with Commit = True issue BAPI_TRANSACTION_COMMIT?

Yes. When you set Commit = True (or the equivalent Commit-flag on the BAPI activity/Action), the SBPA runtime automatically issues BAPI_TRANSACTION_COMMIT after your BAPI call in the same RFC session. However — and this is the key detail — the SBPA runtime calls it with WAIT = ' ' (empty) by default, which is equivalent to a plain COMMIT WORK (async update). It is not COMMIT WORK AND WAIT. That's why you see the 500 ms visibility gap: the update task completes asynchronously after the RFC returns.

4. What does AttachmentContentSet validate against?

It does not hit BKPF directly. API_CV_ATTACHMENT_SRV delegates to the Generic Object Services (GOS) layer via SO_OBJECT_INSERT/BDS_BUSINESSDOCUMENT_CREATEF. GOS resolves the business object type (e.g. BUS2081 for Supplier Invoice, BKPF for Accounting Document) and asks that BO's persistence layer for existence. For BKPF, the check is SELECT SINGLE ... FROM BKPF on (BUKRS, BELNR, GJAHR) — so it's a normal DB read that depends on the commit having completed and the read not hitting an update-queue-still-pending state.

5. Is delay/retry an acceptable pattern?

Retries are absolutely acceptable and preferred over blind sleeps. SAP-recommended patterns for this specific split (BAPI post + attachment) are:

Use approach A above (explicit BAPI_TRANSACTION_COMMIT WAIT='X') — this is the cleanest, and it's what the S/4HANA extensibility guide recommends when combining classic BAPIs with cloud APIs in the same LUW.
If A isn't possible, use exponential backoff (100 ms → 200 ms → 400 ms, cap at 3 attempts) before treating 400 as a real error — a fixed sleep will fail on slow days and waste time on fast ones.
Reference chain: BAPI_ACC_DOCUMENT_POST → SBPA runtime Commit=True = BAPI_TRANSACTION_COMMIT WAIT='' = COMMIT WORK (async) → app server processes update task → BKPF row appears → GOS-backed OData AttachmentContentSet succeeds.