Enter Document Number in "BAPI_SALESORDER_CHANGE".

Question

Hi All,
I am facing some problem with BAPI_SALESORDER_CHANGE.
I am trying to update the Sales Order header with the BAPI BAPI_SALESORDER_CHANGE.
However, I am facing the below error though I pass the Sales document number correctly with all leading zeroes.
"Enter Document Number".
When I debugged, I found that it hits a function module SD_SALESDOCUMENT_CHANGE which inturn calls the FM
SD_SALES_DOCUMENT_READ. Inside the FM SD_SALES_DOCUMENT_READ, I could see that the value is being assigned to
VBAK-VBELN. But, there is a subroutine which gets executed after that. As soon as it enters in to the subroutine, the value of VBAK-VBELN gets vanished.
VBAK-VBELN = DOCUMENT_NUMBER.
  PERFORM BELEG_LESEN(SAPMV45A).    "Once it enters inside this subroutine, the value of VBAK-VBELN gets cleared.
  PERFORM KONV_SELECT(SAPFV45P).
Any pointers on this would be highly appreciated. I have gone through various posts of SDN. But, none of them could help me.
Note:  When I execute the above FM from SE37, it works fine and the VBAK-VBELN value doesnt get vanish even after entering the above mentioned Subroutine.
Thanks,
Babu KIilari

Answer 1

Hi Babu,
Just replying to update this thread in case it can help others in the future, as I had a similar issue (at our same client ).  To paraphrase/quote your reply to my mail on similar error " the solution for the same is not the implicit enhancement that we have created there. It was just a temporary solution and as you have highlighted that transport never moved into any other system across the landscape. The actual issue that caused the error was due to a conflict between the subroutine pool and the program SAPMV45A.  Someone had defined a subroutines in SAPMV45A and they were calling the same in the USEREXIT_SAVE_DOCUMENT_PREPARE which I think belongs to the same program. Don’t recall the actual glitch at the variable level, however VBAK-VBELN was being reset by the subroutine pool. Instead of calling the external subroutines from the parent program SAPMV45A, I had created one Subroutine pool and consolidated all the 6 subroutines into it and then I am calling these 6 subroutines from the FM." 
So your issue was within a sales order change being saved, in the save user-exit, someone was again referring to SAPMV45A which was blanking out VBAK-VBELN as you showed above.
In my issue, same issue was happening that VBAK-VBELN was disappearing.  The scenario for us was as follows.  We have an interface from a TMS system which can update STOs or Sales Orders (1 doc per IDOC).  We saw the Sales Order IDOCs were sometimes getting a 51 status if the BAPI call failed with V1045 Enter the Document Number.  By the hints above, we suspected somehow SAPMV45A was being called.  By analysis, we realized that the issue happened when an IDOC to do a BAPI_PO_CHANGE preceded the BAPI call for the sales order.  And then debugging showed us that someone had put a user-exit in a gATP exit which was performing a subroutine in SAPMV45A for  an STO (which the logic was only pertinent to SOs).  By going into the SAPMV45A routine, the (SAPMV45A)VBAK-VBELN work area was created albeit empty.  Then, when the Sales Order BAPI gets called (his IDOC was next in line of the IDOC processing program) that blank work area overlaid VBAK-VBELN when code entered into BELEG_LESEN.  Our solution will be to prevent the gATP exit from calling a perform into SAPMV45A when its working with STOs.