Two FI documents for one billing document.

Question

Hi,
   This problem occurs rarely. We do VF04 and generate billing documents. Some billing documents thus generated were not found as actual billing documents by looking at VF03 but are posted in FI in the corresponding company code. When we see these documents in FB03, the header of the document indicates that they came from billing and are not manually posted in FI, thus indicating that billing ran, the FI document was processed, but the billing for some reason failed to be saved in SD. For each of these FI document which do not have a corresponding billing document in FI, there is one more billing document which is existing with the same billing amount and references the same details. It has a corresponding FI document too. So, the crux of the issue is there one only one billing document and two FI documents.
SAP service has given an OSS note 92592 to find out all the orphaned FI documents and then a way to reverse these documents. This is sort of a workaround. But the root cause for this issue is not found. The note also says the following..
"In one of the function modules called by FI/CO interface, a 'commit work' is performed.
A 'commit work' can, for example, be triggered in a Native SQL or result from an RFC.
A commit work is not allowed here.
The commit work should not be performed until the billing document is transferred to the update program."
I have gone through most of the custom codes written by us in the SD billing and FI accounting areas. None of the custom codes use 'commit work' staements. Since this issue doesn't happen frequently, we understood that this is due to a 'commit work' problem in the database but are unable to nail down on the exact piece of code.
Any suggestions/ideas or experiences of similar instances, please share.
Regards,
- Raja.

Answer 1

Hi Raja!
Explicit commit work wasn't very likely (but of course you never know). Now you should extend your search for the implicit commit works -> database commit.
"Database commits are triggered either implicitly or explicitly in an SAP system.
<b>Implicit Database Commits</b>
The implicit database commits in an SAP system are caused by the fact that the SAP system is logged on to the database system via its work processes . A work process can only ever execute a single database LUW but cannot interfere with the database LUWs belonging to other work processes. Since an ABAP program can be executed by different work processes during its runtime, the database LUW for the current work process must be completed each time an action takes place that leads to a change of work process. As a result, a database commit is performed implicitly in the following situation:
Completion of a dialog step
The program waits for a user action and does not occupy a work process during this time. The next free work process is assigned to the program in the next dialog step.
Calling a function module in a synchronous or asynchronous Remote Function Call
The current work process hands over control to a different work process or system.
Completion of a function module accessed with a synchronous Remote Function Call in a separate work process
The calling program is assigned a new work process.
Execution of a RECEIVE statement in a callback routine specified in an asynchronous RFC
The current work process is interrupted so that the data can be received from the other application server.
Interruption of the current work process with a WAIT statement.
After interruption, the program is assigned the next free work process.
Sending error and information messages and warnings.
These messages interrupt the current dialog step (see above).
<b>Explicit Database Commits</b>
Database commits can be triggered explicitly in ABAP programs in the following ways:
Use of the corresponding database-specific native sql statement.
Calling the function module DB_COMMIT.
This function module, which has no parameters, encapsulates the corresponding native sql statement.
Executing the open sql statement COMMIT WORK."
Maybe there is somewhere a wait or sometimes a RFC is called - that are the most likely implicit commits.
Also calls of standard FMs can contain dangerous coding - include calling of 'bigger' standard functions into your search (not something like 'MARA_SINGLE_READ', but all BAPI).
Regards,
Christian