Incorrect document number reported by BAPI_ACC_DOCUMENT_POST

[Former Member]

I am using BAPI_ACC_DOCUMENT_POST to create various document types and periodically I’m getting the wrong document number reported as being created. So for example the function module reports that it created document 100000605 but when I check the database it was actually created as document 100000607. This appears to happen randomly. Most of the time the document # returned is the correct one. It is also not a situation where another user as grabbed that document # because the document # returned has not been created.

These are the steps leading to the FM call:

SELECT SINGLE numkr FROM t003 INTO l_numkr

WHERE blart EQ l_doc_type.

CALL FUNCTION 'NUMBER_GET_NEXT'

EXPORTING

nr_range_nr = l_numkr

object = 'RF_BELEG'

• QUANTITY = '1'

subobject = l_comp_code

toyear = l_fisc_year

• IGNORE_BUFFER = ' '

IMPORTING

number = l_number

[…]

ADD 1 TO l_number.

ls_documentheader-obj_key = l_number.

CALL FUNCTION 'BAPI_ACC_DOCUMENT_POST'

EXPORTING

documentheader = ls_documentheader

IMPORTING

OBJ_KEY = L_OBJ_KEY

TABLES

[…]

return = lt_return

[…]

Now the document number returned by both “L_OBJ_KEY” and in the messages in “LT_RETURN” say it created “100000605” but in reality the document is “100000607”.

I’m assuming that the document number returned by 'BAPI_ACC_DOCUMENT_POST will always be just be whatever number I feed it from “ls_documentheader-obj_key”. (I also need to add 1 to "L_NUMBER" or else the document # reported as posted is always off by 1)

This problem is creating a bit of an auditing problem for me as the logs I’m creating do not match what is in the database sometimes.

I'm on an ECC 5.0 system.

Thanks for any help,

-Tom

[Former Member]

Hi Tom,

I think your problem is that you are calling function module 'NUMBER_GET_NEXT' and passing in the new document number.

You can call BAPI_ACC_DOCUMENT_POST without passing in the document number and the function module should assign the next available document number.

Also, you can look at OSS Note 561175 for internally assigning the Reference Procedure if needed.

Also, sorry if you already know this but, don't forget to call BAPIs BAPI_TRANSACTION_ROLLBACK or BAPI_TRANSACTION_COMMIT depending on whether there was an error or not.

I hope this helps.

Mike Vondran

[andreas_mann3]

Hi Tom,

why do you use fm 'NUMBER_GET_NEXT' ?

-do you use a document type with external number range ?

regards Andreas

[Former Member]

Mike / Andreas,

I know I don't need to use NUMBER_GET_NEXT to be able to create a document but the problem is that if I don't supply BAPI_ACC_DOCUMENT_POST with a document number then the message returned in TABLE RETURN will also not have the correct document # in it.

So I could just use something like "TEST000001BAPICALL" for OBJ_KEY but the message returned would be "Successfully created document TEST000001BAPICALL" which would be senseless to put on the execution log.

I'm thinking now that what I might have to do is call NUMBER_GET_NEXT after BAPI_ACC_DOCUMENT_POST and if the posting was successful, ignore the contents of TABLE RETURN.

[Former Member]

Hi Tom,

I don't think you want to be calling NUMBER_GET_NEXT at all.

You are incrementing the document number range that is used by standard SAP. In my opinion you should definitely not be doing this. This will lead to gaps in the numbers for actual accounting documents created which auditors hate.

If you leave the object key initial (ie, don't pass a document number or something like TEST000001BAPICALL) then SAP will call NUMBER_GET_NEXT internally with the FI transaction and generate a number. This should then be returned to you as the OBJ_KEY and also in your message as "Successfully created document 999999999".

In short, you should not pass the document number and the BAPI will generate one and return it to you. This will always correspond to the actual document created in SAP.

Also, you should always avoid using NUMBER_GET_NEXT on standard number range objects where the underlying SAP master data or transaction object uses internal number assignment.

Hope that helps.

Cheers,

Brad

[Former Member]

Brad,

Yes, the code was periodically creating gaps in the document numbers which as bothering me as well.

And you are right about not supplying OBJ_KEY. When I first removed it I got the error message:

"Required field OBJ_KEY was not transferred in parameter DOCUMENTHEADER"

But then I looked at my other parameters and I was filling in OBJ_TYP and OBJ_SYS as well. I blanked out those parameters as well and it stopped complaining about not providing OBJ_KEY.

I think the problem is solved.

Thank you !!!

-tom

[Former Member]

Thanks, that really helped!!!