Bapi_acc_document_post execution prevents manual (and simultaneous) acc posting

[Former Member]

Hi experts,

We have an inbound interface that, among other things, executes following standard BAPIS:

1. Bapi_acc_document_post

2. Bapi_transaction_commit

3. Bapi_transaction_rollback.

ISSUE: When executing that interface (in background, by means of a job, for example) for accounting documents in SAP, the inbound program calls the standard BAPI (bapi_acc_document_post) and so it accesses NRIV table.

At this point in time, the system prevents any accounting document regarding same company code (that is informed in the incoming interface) from posting in the system manually.

It looks like the system keeps waiting…

Finally, once the inbound interface finishes (commimt is done), the system posts the account document (the one that was intended manually and was kept waiting)

So my question is, is there a way of getting rid of this limitation? We would need to leverage full system performance but we do not know if this is a NRIV constraint. (that, on the other hand, could make sense)

Could you please be so kind as to confirm if this is how the standard works? We are planning to schedule the interfaces to be running during the night...

Thanks a lot in advance.

Best regards,

David

[Former Member]

Hello David,

I am afraid that this is the standard behavior.

if you post a document via BAPI_ACC_DOCUMENT_POST the number range

for the specific company code/document type is locked (table NRIV).

The lock is released as soon as you COMMIT your transaction

because before a COMMIT the system has to be able to rollback the

number range interval.

A single BAPI call is never a problem, but as soon as you have at

least two parallel processes posting via the BAPI deadlocks can occur

if each process posts more than one FI document within one logical

unit of work.

The safest way to generally avoid this is to generally do

a COMMIT WORK after each single call to BAPI_ACC_DOCUMENT_POST.

If you encounter performance problems doing so it might be helpful

to use "SET UPDATE TASK LOCAL." in your ABAP report so the

DB updates are done locally and not in update task.

By the way if you post inbound IDOCs with report RBDAPP01

it works the same way: Although you can specify a package size

there, within every package each document is COMMITTed independently,

the packages are just processed in parallel.

Other point that you can study is use "pseudo ascending number assignment".

Locks in NRIV are common when buffer is not used in order to guaranty
the sequential numbers. This setting prevents parallel running processes
to access the document number object at the same time and therefore a
deadlock occurs in that case.

I understand that you want to avoid gaps in the document number range.
We have a solution for you to allow buffering and still avoid gaps in
the number range. It's called "pseudo ascending number assignment".
The main point is to make the system focus on the document numbers and
not so much on timestamp. Note 840901 explains it in detail and provides
the steps.

Note 599157 describes parallel buffering as well, and note 840901
explains pseudo ascending document number assignment if this is
needed for legal regulations in some countries. This is also explained
on page 3 of note 1398444.

In BTE 00001170 you have the possibility to only activate/deactivate the
buffering for certain number ranges and company codes. This allows you
to adapt the buffering to your business requirements.

I hope this helps.

Kind Regards,

Raquel